Suite de Sabordage de TrueCrypt.
Bonne nouvelle. Les résultats de la deuxième partie de audit de l’outil TrueCrypt (7.1a) sont rendus publics. Et il n’y a ni faille majeure, ni porte dérobée.
Il n’y a donc pas d’urgence à le remplacer pour le moment.
CF : https://truecrypt.ch/wp-content/uploads/2015/04/TrueCrypt_Phase_II_NCC_OCAP_final.pdf
Il y a semble-t-il un bugg récent assez gênant sur la libraire GnuTLS sous Debian 7. Suite à une mauvaise implémentation semble-t-il au niveau de la négociation des algorithmes de chiffrement, il est impossible de générer ou d’utiliser des certificats pour les programmes qui utilisent cette librairie. Et c’est le cas notamment de slapd, le serveur d’annuaire LDAP (OpenLDAP) sous UNIX.
Le problème aurait pu passer presque inaperçu… mais il y eu heartbleed…Et il se trouve donc qu’un certain nombre d’admins systèmes ont dû changer très rapidement les certificats de leurs serveurs, et ont dû tomber sur ce problème.
Il devient ainsi impossible de relier un serveur de messagerie ou un serveur web avec un annuaire LDAP utilisant OpenLDAP. J’ai notamment le problème avec mon serveur postfix…
Il est possible de ne pas utiliser la connexion à l’annuaire via TLS. C’est potentiellement un gros problème de sécurité en fonction des différents réseaux que vont traverser ces flux. Bref, ont n’a plus de sécurité sur un flux qui contient toute l’authentification du réseau. C’est assez moyen.
Il est aussi possible de mettre en place une solution de remplacement avec stunnel. Cela revient en fait à faire manuellement la connexion et le tunnel sécurisé par TLS. En plus, on peut conserver les mêmes certificats que le démon slapd.
Il faut commencer par désactiver l’utilisation du port tcp/636. Pour cela, il faut modifier une ligne dans le fichier /etc/default/slapd :
SLAPD_SERVICES="ldap://127.0.0.1:389/"
Redémarrer le démon slapd.
Ensuite,on concatène le certificat et sa clé dans un seul fichier :
cat /etc/ssl/private/slapd.key /etc/ssl/certs/slapd.crt > /etc/ssl/private/slapd-all.crt
Enfin, on crée le bout du tunnel côté serveur, en réutilisant le certificat :
stunnel -d 636 -r 127.0.0.1:389 -p /etc/ssl/private/slapd-all.crt
Le client, c’est le service qui utilise l’annuaire LDAP, par exemple postfix.
On crée le bout du tunnel côté client :
stunnel -c -d 6389 -r ldap.serveur.net:636
Enfin, on dit au client, en l’occurrence postfix, d’utiliser le tunnel. Modifier le fichier /etc/postfix/main.cf (ou équivalent) :
account_server_host = ldap://localhost:6389/
Et on redémarre postfix…
CF : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737921
Depuis le 28 mai, TrueCrypt, le logiciel de chiffrement de disque dur, est mort. C’est ce que dit la page officielle. Il est conseillé au visiteur d’utiliser Bitlocker à la place.
Ce sabordage est étrange en plein audit de sécurité et alors que les premiers retours sont prometteurs. En l’absence d’informations supplémentaires, les spéculations sont à l’honneur. Cela fait maintenant plus de 2 semaines et on en sait pas plus en fait. C’est assez inquiétant quand même de voir un produit de sécurité majeur disparaître du jour au lendemain sans plus d’explication. Pour Lavabit on sait pourquoi, au moins.
En fait, à part la disparition d’un logiciel comme OpenSSL, il serait difficile d’imaginer pire. Et ceci malgré les récents problèmes graves d’OpenSSL. Bien qu’il y ai des produits concurrents, c’est assez catastrophique.
Il reste aux utilisateurs de TrueCrypt à migrer rapidement vers un concurrent ou un des forks qui va émerger et je l’espère s’imposer.
Moi, de mon côté, je ne suis pas concerné parce que je ne l’utilise pas. Je préfère cryptsetup. LUKS, que la force soit avec toi…
La tempête commence à passer pour OpenSSL et sa récente faille critique. C’est pour rappel un programme généraliste pour tout ce qui est chiffrement, y compris les certificats X509, les tunnels SSL et assimilés. On peut voir un peu partout sur internet les implications de cette faille nommée Heartbleed.
Un site web et un logo sont dédiés à cette faille :
Évidemment, c’est un gros problème pour une grande partie des serveurs sur Internet, et pas que pour les serveurs web. Tous les services qui sécurisent leurs communications avec TLS sont potentiellement impactés, et surtout tous ceux qui utilisent la librairie OpenSSL. Cela inclut des serveurs web (https) mais aussi la messagerie (smtp, imaps, pop3s), la messagerie instantanée (xmpp), etc…
Le plus rude pour un administrateur d’un serveur concerné, c’est que rien n’apparaît dans les logs (journaux). Tout au plus peut-on voir les tentatives avec un IDS ou une analyse fine du trafic réseau.
Pour résumer l’ambiance, rien de mieux que la citation :
« Si vous gardez votre sang-froid alors que tout le monde panique autour de vous, peut-être avez-vous mal évalué la situation »
Stéphane Bortzmeyer (site)
Aujourd’hui, un serveur concerné par la faille et non à jour est un serveur vulnérable.
Et les machines utilisateurs ?
Elle sont concernées aussi. OpenSSL est inclus dans beaucoup de logiciels pour gérer facilement le chiffrement. La faille marche aussi en sens inverse, depuis un serveur malveillant.
Pour ma pomme, mon principal serveur utilise une version un peu plus ancienne de OpenSSL, packagée. Cette version reçoit régulièrement des correctifs mais n’est pas impactée par Heartbleed. Ça passe pour cette fois même si je suis bon pour devoir mettre à jour tout mon serveur prochainement…
J’utilise aussi OpenSSL pour le projet nebule et le projet sylabe. Les fonctions internes de chiffrement et signature ne sont pas concernées. L’accès aux serveurs, via https, est concerné pour certains robots de test de sylabe. Ils n’ont pas été utilisés pendant la semaine de tempête.
Quels utilisateurs sont potentiellement concernés ?
En fait, tous les utilisateurs qui ont utilisés un compte sur un serveur utilisant OpenSSL avec la faille.
Il suffit pour les admins de regarder les logs des connexions côté public et de prévenir tous les utilisateurs qui se sont connectés pendant la période de temps critique. Mais une société commerciale a-t-elle vraiment envie de diffuser à ses utilisateurs que ses serveurs ne sont pas forcément aussi sûrs que ça !?
Doit-on prendre comme début de période de temps la date de diffusion publique de la faille ? Ou doit-on prendre la date d’ajout de la faille (volontaire ou pas), 2012 ? On passe de la semaine aux deux dernières années. On passe des dernières connexions à tous les utilisateurs. L’impacte n’est pas le même.
Et puis ce n’est pas aussi simple que ça. Si le chiffrement des connexions est séparé des serveurs web, si on a des frontaux dédiés aux tunnels TLS, seuls ceux-ci sont concernés. Il n’est dans ce cas pas utile de faire changer les mots de passes des utilisateurs.
Certaines grosses sociétés américaines ont été prévenues un peu en avance de la diffusion pour être à jour au bon moment. Il ne s’agirait pas que des services critiques comme Google ou Facebook ne soient bloqués, les banques peuvent attendre ;-)
Il pourrait être tentant pour certains admins de changer de solution de chiffrement. Oui, mais laquelle choisir? GnuTLS? Celle de Microsoft? Une solution propriétaire payante?
Je ne suis pas sûr du tout qu’échanger un programme avec les sources publiques par un programme aux sources fermées (programme privateur) soit une bonne solution. Quelque soit la qualité de certains programmes de M$, en logiciels de sécurité, il n’est pas très bien vu de ne pas disposer des sources. Quelle confiance peut-on apporter à un programme qui ne peut être librement audité par tout le monde. Je passe sur les récentes affaires révélées par Mr Snowden. La sécurité par l’obscurité, c’est comme ça que cela s’appelle, est très souvent employée pour cacher les choses mal programmées.
Ceci dit, la diversité à aussi du bon. Mixer les technologies et implémentations permet de ne pas se retrouver avec tous ses serveurs à poil en même temps en cas de coup dur comme Heartbleed…
GnuTLS a eu des problèmes récemment, SecureTransport de Apple aussi. Les problèmes ne sont donc pas spécifiques aux logiciels à code ouvert.
Ce n’est pas la première fois que l’on a ce genre de problème, et ce ne sera pas la dernière.
Une solution, séparer la fonction de chiffrement TLS sur des serveurs dédiés. Le bout des tunnels sécurisés s’arrêtent aux portes des serveurs web, sur des machines spécialisées. Dans ce cas, seules les connexions en cours, leurs clés de sessions, sont vulnérables.
Les certificats de ces serveurs frontaux TLS sont aussi potentiellement compromis, donc à changer, sauf si ceux-ci sont stockés sur des cartes dédiées (pas en mémoire).
C’est d’ailleurs une bonne pratique pour tous les serveurs, et pas seulement les frontaux web : séparer les services entres eux et les applications sur des serveurs différents. Les séparer sur des machines physiques différentes et des réseaux physiques différents si leurs criticités sont différentes. Mais comme toujours, ça demande du temps, des compétences et du pognon.
L’autre solution, si tu es concerné :
Une question reste en suspend. Est-ce une 0-days ?
Va-t-on découvrir que certains l’utilisaient depuis quelques temps ? La NSA par exemple ? Rien n’est jamais définitivement écrit.
Voici la suite de l’article sur les Station Linux et serveur Windows.
Le même script fonctionne avec un serveur M$ Windows au niveau fonctionnel 2008R2.
Tout est passé du premier coup :
– la génération d’un ticket Kerberos ;
– l’ajout de la machine dans l’AD ;
– la consultation du LDAP.
Pour rappel, la station est sous Ubuntu Linux 13.10 .
Attention – Documentation partielle !
Cette exercice a été abandonné en cours d’installation.
Partial installation.
Après la Clé USB bootable chiffrée sous OpenBSD, le Disque chiffré et boot sur clé USB sous Linux et le Système bootable chiffré sur deux clés USB interdépendantes (et suite) sous Linux, voici le disque chiffré et boot sur clé USB sous FreeBSD.
Objectifs :
1. Chiffrer l’intégralité du disque dur ;
2. Placer le nécessaire pour le démarrage uniquement sur une clé USB amovible ;
3. Permettre le démarrage du système sans saisir de mot de passe.
Basé sur le tutoriel :
– http://namor.userpage.fu-berlin.de/howto_fbsd9_encrypted_ufs.html
L’exercice est réalisé avec le DVD1 de FreeBSD V10.0 RELEASE amd64.
Continuer la lecture de FreeBSD РDisque chiffr̩ et boot sur cl̩ USB
Nous allons réaliser ici la première étape pour intégrer des stations Linux dans un domaine Microsoft Active Directory de niveau fonctionnel 2003. L’intégration dans un domaine AD de niveau 2008 et plus sera abordé une prochaine fois.
Conditions de départ de l’expérience :
La documentation ci-dessous s’appuie beaucoup sur l’article ‘koo.fi blog – Ubuntu 12.04 Active Directory Authentication‘.
Plan :
Sur la station, toutes les commandes sont lancées en tant que root ou, mieux, via sudo.
Il y a plusieurs choses qui peuvent être améliorées dans le système bootable chiffré sur deux clés USB interdépendantes.
C’est un peu technique et aucune solution complète n’est fournie. Si vous voulez les mettre en place, il va falloir gratter par vous même. Continuer la lecture de Système bootable chiffré sur deux clés USB interdépendantes – suite
Voici une base de système qui nécessite deux clés USB pour pouvoir fonctionner. Si l’une manque, le système ne peut démarrer et, plus important encore, les données sont indéchiffrables.
Le schéma de principe :
L’exemple est réalisé à partir de Debian Linux 7.0, mais ça n’a pas de raison de ne pas fonctionner avec d’autres distributions. Ça marche aussi avec Ubuntu Linux par exemple. Il faut obligatoirement que cryptsetup soit disponible sur la distri. Il faut de préférence que l’on puisse mettre en place le chiffrement dès l’installation du système. Il faut aussi de préférence que le système soit installable directement sur clé USB et sur une partition chiffrée. Si ces deux dernières conditions ne sont pas remplies, l’exercice est réalisable mais il est beaucoup plus complexe à mettre en place.
Continuer la lecture de Système bootable chiffré sur deux clés USB interdépendantes
En visitant le blog de Bruce Schneier, je suis tombé sur un long et intéressant article : How to Remain Secure Against the NSA
Le contenu de cet article me semble important par rapport à toutes sortes de spéculations sur le cassage d’algorithmes cryptographiques suite aux révélations d’Edward Snowden. Je vais me concentrer sur les 5 points, traduits ici :
Petite remarque sur ce qui semble une incohérence. Il cite au point 4 d’essayer d’utiliser des logiciels à sources ouvertes. Et il dit utiliser plus bas un ordinateur sous M$ Windows : « And I’m still primarily on Windows, unfortunately. Linux would be safer. »
L’aveu est franc. Je pense que l’explication est simple, il se sent plus à même de sécuriser un système qu’il connaît bien plutôt qu’un système inconnu. Ça se défend.
D’autres développements sont fait plus spécifiquement sur le blog de nebule…
Liens :
– https://www.schneier.com/blog/archives/2013/09/how_to_remain_s.html
– http://blog.nebule.org/?p=1206
Les divulgations autour du programme PRISM font se poser des questions à beaucoup de monde. Une des solutions préconisée est d’utiliser des outils de chiffrement et/ou d’anonymisation.
On savait déjà que l’anonymisation de données avait des limites. Des études au USA ont permit de retrouver les identités de personnes à partir de données anonymisées de la sécurité sociale. Le big data présente toutes les caractéristiques pour permettre des corrélations aboutissant au rattachement de données isolées à des personnes.
Mais intéressons-nous au réseau TOR. Ce réseau de re-routage et d’anonymisation a été conçu aux USA. Il est aujourd’hui encore maintenu par une fondation américaine.
La page de Wikipédia sur TOR parle d’une possibilité d’attaque dite Time Pattern, c’est à dire une attaque sur l’empreinte temporel des flux réseaux passants par des nÅ“uds TOR. En effet, un nÅ“ud qui reçoit un paquet réseau TOR essaye comme un routeur de le renvoyer au plus vite vers le nÅ“ud suivant, et ainsi de suite jusqu’au serveur destinataire. La façon (temporel) qu’une machine a de « parler » sur le réseau est donc assez bien retransmise jusqu’au serveur destinataire.
Il faut, me direz-vous, pouvoir sniffer le serveur destinataire et le poste client (si il est connu), mais sûrement aussi tous les relais TOR intermédiaires pour pouvoir remonter du serveur au client. Cette méthode permet de lever l’anonymisation.
Si il semble facile, au moins pour un gouvernement, de capturer le trafic réseau d’un serveur en particulier, il semble difficile de pouvoir faire la même chose pour tous les nÅ“uds TOR et encore moins tous les postes clients du monde, même pour un gouvernement. La robustesse du réseau TOR repose sur cette propriété.
Le réseau TOR repose aussi sur de la cryptographie, mais uniquement pour les échanges « proches ». Et cela ne protège pas du Time Pattern.
Or, que fait PRISM ?
Et bien il fait justement cette chose qui semble difficile à faire : capturer le trafic réseau d’une grande partie des ordinateurs de l’Internet, voir peut-être tous. Et cela comprend les serveurs, les nÅ“uds TOR et les postes clients…
Voici la documentation pour installer un système Debian Linux 7.0.0 avec un disque chiffré et un boot sur clé USB uniquement :
http://technix.starend.org/si/index.php/Serveur_-_Disque_chiffr%C3%A9_et_boot_sur_cl%C3%A9_USB
Cette documentation est réalisée suite à la réinstallation du serveur neptune.
Conclusion :
Voila, nous avons bien un serveur avec un disque intégralement chiffré et qui démarre tout seul uniquement si sa clé USB associée est branchée.
On peut partir en vacance avec la clé USB, sans elle le serveur ne redémarrera pas et les données resteront au chaud.
Je m’intéressais à la YubiKey de Yubico.
J’ai un peu gratté autour et publiée le résultat de cette petite étude sur le projet nebule. Le faible coût d’achat couplé à la nécessité d’ajouter partout ou je peux (…) la reconnaissance de l’authentification via le YubiCloud m’a rapidement fait comprendre que, malgré les avantages, ce n’est pas tout à fait ce que je cherchais…
J’utilise pour certaines de mes sauvegardes des containers (fichiers) chiffrés avec cryptsetup et ensuite formatés en ext3 ou vfat. Jusque là , rien que du classique si ce n’est qu’il faut au préalable faire reconnaître ce fichier ‘normal’ en question comme un fichier de type ‘bloc’ via la commande losetup…
LOOP=$(sudo losetup -f) sudo losetup $LOOP space/$CONTAINER.dsk
Là où cela devient plus complexe, c’est que le tout se trouve sur une machine à l’autre bout de la France (et potentiellement du monde) et est donc exploité via sshfs, donc comme un partage réseau en quelque sorte.
sshfs user@machine:/space space -o allow_other
Continuer la lecture de Changer de mot de passe avec cryptsetup
L’opération consiste à chiffrer le répertoire personnel (home) d’un utilisateur.
En quoi consiste l’opération ?
Tout simplement à protéger les données des utilisateurs d’une machine. Contrairement à de simples droits posés sur des fichiers ou des répertoires, le chiffrement de ces mêmes fichiers est bien plus sûr pour en restreindre la lecture par des personnes tierces.
Continuer la lecture de Chiffrer le répertoire home d’un utilisateur sous Ubuntu
