Chiffrement de disque (3/n) [OpenBSD]

Je vais parler ici du chiffrement de disque (pas juste un fichier, ou bien un disque dans un fichier monté en loop, non, vraiment une partition physique entière). Comme il y a beaucoup de choses à dire sur le sujet, je vais découper en plusieurs parties.
Voyons ce que propose OpenBSD.

4. OpenBSD

J'ai été surpris du peu d'information dispo dans OpenBSD sur les méthodes de chiffrement de disque. Est-ce tout simplement parce qu'il y a peu de choix pour chiffrer son disque? Le seul moyen que j'ai trouvé pour y parvenir est d'utiliser vnd(4), pour monter un fichier en disque virtuel, tout en le chiffrant en utilisant l'algorithme Blowfish. La procédure est décrite dans ce howto.

Résumons : sous OpenBSD, on peut utiliser un fichier pour y stocker une partition chiffrée avec l'algorithme Blowfish. C'est simple et efficace.
Cependant, on ne peut utiliser qu'une seul clé de chiffrement (une seule passphrase), on a deux couches de partitions (une partition dans un fichier, qui lui-même est stocké sur une partition) ce qui peut ralentir les accès, et on ne peut pas chiffrer la partition racine. J'ignore si l'on peut chiffrer directement un device sans passer par un fichier physique, je teste ça dès que j'ai du temps. Bref on en est réduit au strict minimum mais au moins, ca marche.

A noter qu'OpenBSD est le seul OS jusqu'à présent qui propose un chiffrement automatique du swap (un seul sysctl à faire et c'est parti; faut dire qu'ils étaient pionnier en la matière). Cette option sera d'ailleurs activée par défaut à partir d'OpenBSD 3.8 (qui doit sortir le 1er novembre, soit dit en passant).

Chiffrement de disque (2/n)

Je vais parler ici du chiffrement de disque (pas juste un fichier, ou bien un disque dans un fichier monté en loop, non, vraiment une partition physique entière). Comme il y a beaucoup de choses à dire sur le sujet, je vais découper en plusieurs parties.
Après les raisons pour le faire, voyons les features que l'on peut attendre d'un chiffrement de disque, et les moyens d'y arriver.

2. Les features

Avant de voir ce que proposent les différents OS libres (je ne parlerai pas des autres, car je ne connais pas d'outils de chiffrement libre sur OS propriétaire), voyons ce que l'on peut attendre d'un chiffrement :

• chiffrement de fichier (facile...)
• chiffrement de partitions (différent du fichier, malgré le paradigme *nix device=fichier)
• chiffrement de la partition racine (toute une histoire, étant donné que le kernel doit savoir déchiffrer les informations dès son chargement, avant même le lancement du script init)
• modification du mot de passe et/ou clé de chiffrement du disque (pour cette dernière, il faut souvent rechiffrer l'intégralité de son disque, ce qui n'est pas aisé).
• possibilité de détruire les données de façon irreversible et rapide

3. Les moyens

Pour chiffrer une partition, on a deux moyens : le filesystem chiffré et le chiffrement au niveau du pilote de périphérique.

Dans le premier cas, le chiffrement n'est pas toujours complet, par exemple CFS ne chiffre que les fichiers, et non les metadata liés au filesystem. Par contre, il peut être utilisé pour fournir un disque chiffré partagé en réseau (sa sécurité repose alors sur celle d'NFS, ce qui n'est pas forcément beau à voir).

Pour le deuxième cas, le chiffrement se fait grâce à un driver, entre le driver de disque et le filesystem. Ce moyen est beaucoup plus souple, puisqu'il permet de poser n'importe quel filesystem au-dessus.

Je me concentrerai sur la seconde catégorie, car c'est celle qui est choisie le plus souvent (pour des raisons certainement liées aux défauts des filesystems chiffrés). Nous verrons donc (dans le désordre), OpenBSD, NetBSD et FreeBSD (les trois BSD proposent chacun un système différent), et Linux (qui propose plusieurs procédés). Avant de finir par un tableau comparatif et synthétique (date de livraison inconnue :D)

Réduction des droits sous Windows

Une fois n'est pas coutume, je vais parler de Windows, je sais que quelques uns de mes amis utilisent ce petit OS alternatif sur leur machine principale, je m'adresse donc à eux!

Parmi les problèmes de sécurité rencontrés sous Windows, les failles de sécurité des différents navigateurs web ou clients mails sont innombrables (même firefox s'y est mis...). Et pour ne rien arranger, il n'y a peu ou pas de séparation des privilèges : la plupart du temps, on utilise sa machine avec des droits administrateurs (ce que tout utilisateur *nix trouvera incroyable, mais si, ça existe). Et donc on utilise son browser avec des droits complets sur la machine : si le browser est corrompu par une vilaine page, pouf! c'est tout le système qui y passe.

La solution consiste en la réduction des droits lorsqu'on utilise des applications sensibles. Utiliser Windows en tant qu'utilisateur non privilégié relevant de la galère perpétuelle, il fallait un outil qui arrange ça, et bien il existe! Dropmyrights, comme son nom l'indique, va permettre de lancer une application avec des droits réduits : simple utilisateur, utilisateur restreint, utilisateur indigne de confiance (oui c'est dur de traduire "untrusted user"). Lancer un navigateur avec des droits de simple utilisateur va donc épargner le système complet en cas d'attaque (seul le profil de l'utilisateur sera touché).

D'après cet article de SecurityFocus le gain en sécurité est réel, même s'il est loin d'être parfait (ça ne résoud pas tous les problèmes, c'est seulement une protection qui réduit l'attaque à une petite partie du système) et les problèmes d'incompatibilité sont relativement rares.

Chiffrement de disque (1/n)

Je vais parler ici du chiffrement de disque (pas juste un fichier, ou bien un disque dans un fichier monté en loop, non, vraiment une partition physique entière). Comme il y a beaucoup de choses à dire sur le sujet, je vais découper en plusieurs parties.
Voici la première partie : les (bonnes) raisons pour chiffrer un disque.

1. Les raisons

Chiffrer son (ou ses) disque(s) répond essentiellement à une menace : celui de l'accès physique à une machine. Le chiffrement empêche alors la lecture des données du disque, à quiconque ne possédant pas la passphrase qui va bien. Globalement, la raison, c'est celle-ci. Affinons un peu désormais.

Pourquoi préferer un cryptage des données plutôt qu'une autre protection contre l'accès physique? C'est assez simple, le cryptage des données coute 0 euros, et à peine quelques ressources CPU négligeables. Alors qu'une tour verrouilée, une porte blindée, etc. ca peut couter très cher. Sans parler de l'impossibilité de protéger un laptop : il peut être volé, perdu, ou même seulement "emprunté".

Avec un disque chiffré, impossible de démarrer le système (si la partition racine est chiffrée), impossible de lire des données importantes (des mp3 illégalement acquis? des données confidentielles sur votre ordinateur de travail? des choses que votre copine ne doit pas voir?), et également impossible de récupérer des clés utilisées précédemment (chiffrement de la partition swap).

Il faut peut-être éclaircir ce dernier point. Après avoir utilisé une clé ou un mot de passe dans une application sécurisée, les informations sont en général effacées de la mémoire par le programme, par mesure de sécurité. Mais ce n'est pas toujours le cas, par exemple lorsque un process a besoin de façon récurente d'une clé. Le danger vient alors du fait que ce process peut se retrouver swappé, et donc écrit sur le disque. Lors de l'arrêt du process, les données ne sont pas forcément effacées du swap. Si le disque se retrouve en de mauvaises mains, une analyse de la partition swap peut révéler pas mal de choses. La solution consiste donc à chiffrer la partition de swap avec une clé volatile, qui change à chaque démarrage du système et qui est "oubliée" dès son extinction.

J'aurais pas mal de liens à vous donner, mais la plupart sont sur les techniques, donc ça attendra les prochaines parties.
Voici quand même le paper de Niels Provos, pour OpenBSD, à propos du chiffrement du swap:
http://www.openbsd.org/papers/swapencrypt.ps

Le projet Uberlogger

Il est temps de faire un peu de pub pour un des projets open-source auxquels je participe. Le projet Uberlogger est un "observatoire niveau noyau", c'est à dire une modification d'un système *nix qui va "espionner" le fonctionnement interne du système, par le biais des appels systèmes. Vous voyez les informations que sort strace? Ben Uberlogger c'est pareil mais en se situant au niveau du noyau.

Quelles sont les applications d'un tel projet? Principalement (c'est à la source du projet), Uberlogger peut être utilisé pour produire un honeypot à forte interaction. C'est à dire un système "piégé", volontairement vulnérable en certains points pour attirer pirates et malwares, et qui va permettre l'observation de ce qu'il se passe sur le système pour étudier les attaques, les outils des pirates, etc. Dans ce sens, Uberlogger se rapproche du projet Sebek, avec toutefois la volonté d'être plus complet dans l'analyse. Pour plus de détails sur les honeypots et leurs applications, jetez un oeil à http://www.honeynet.org/.

Une seconde application pour Uberlogger est son utilisation comme outil de forensics. En effet Uberlogger peut se présenter comme un module noyau chargeable dynamiquement, et qui permet donc l'analyse du comportement d'une machine compromise. Les logs qui en ressortent peuvent trahir les outils (keylogger, rootkits, etc.) qui plombent la machine.

Je cherche actuellement une autre application à Uberlogger, mais pour ça je vous en dirais plus ultérieurement ;)

Uberlogger est sous licence CeCILL, et a été développé pour l'instant pour les plateformes Linux/UML, Linux, et FreeBSD. Toutes les informations sur Uberlogger sont sur http://uberlogger.rstack.org

Nessus passe en closed source

Le premier véritable post de mon blog sera la répercussion d'un signal d'alarme qui risque de faire du bruit dans le monde de l'open-source, particulièrement celui de la sécurité. La prochaine version de Nessus, l' "open-source vulnerability scanner", sera distribué uniquement en binaire et passe donc en propriétaire. Les développeurs de Nessus justifient leur action par le fait que quasiment rien n'a été fait pour améliorer le moteur de Nessus dans le monde de l'open-source, et donc y'en a marre de se faire pigeonner, merde.

Le problème derrière ça, c'est qu'on peut difficilement faire reposer les outils de sécurité sur du closed-source, qu'on ne peut auditer. Combien d'admins habitués à se fournir dans l'open-source feront confiance à du propriétaire?

La solution est simple : contribuons. C'est en substance le message délivré par l'auteur de nmap : http://archives.neohapsis.com/archives/nmap/2005/0016.html

Ouverture du blog

Ca y est, je me lance dans l'aventure blog (je sais, c'est tard, mais bon j'aurai quand même réussi à rattraper la mode avant qu'elle ne passe, pour une fois!) sur un thème qui m'est cher : la sécurité informatique. C'est vrai que pour beaucoup ça a l'air chiant comme sujet, mais je pense que certains y trouveront leur compte ;) Et puis dans la mesure du possible j'essaierai de pas être aussi lourd que ce premier post, forcément un peu descriptif...

Faisons le tour de ce que je souhaiterai développer dans ce blog:
- l'actualité de la sécurité
- mes 'découvertes' au hasard du net, que je souhaite partager avec vous
- des 'dossiers' sur certains thèmes auxquels je me suis frotté
- le développement des projets de sécurité à moi que j'ai
- ...

Je pense qu'au début ca se remplira assez vite, j'ai forcément plein de trucs à dire (sinon je retournerai mater des animes au lieu de faire un blog!). Mais vous avez aussi la parole, n'hésitez pas à laisser un mot, un commentaire sur l'actu, un troll, une question, etc.