Après quelques recherches sur « db_recover » et après avoir essayé de lire les pages man introuvables… je me lance à la sauvage:

Le service repart, puis s’écroule quelques minutes plus tard en m’insultant de la même façon. Seule option restante: Récupérer les .bdb stocké sur la bande de sauvegarde de la veille:

A la recherche de mes fichiers:

Ouf, tout est là: On restaure.

Si, comme moi, vos fichiers font plus de 2Go, allez donc boire une cafetière de café.. ou prendre un Xanax..

Je vous passe le tas de logs qu’il m’a vomi à ce moment précis -c’est plutôt bon signe- il est enfin lancé… et à l’air de s’y plaire. Attention à ne pas le stopper à l’aide d’un CTRL+C, ce qui pourrais causer une nouvelle corruption ! Pour cela on va lui demander plus poliment:

Puis on relance, proprement:

Note: n’oubliez pas de vérifier que les fichiers contenus dans le répertoire /var/lib/ldap appartiennent bien à ldap:ldap après la restauration, c’est du vécu..

Sachant que le serveur mail est Postfix.

En quelques lignes cela pourrais se répondre: man aliases, RTFM, mais je ne suis pas un salop, alors je vais vous décrire la solution que j’ai trouvé.. ;)

Le fichier aliases de Postfix permet, comme son nom l’indique, de créer des alias et donc de ridiriger tout les mails pour les comptes locaux. Ce fichier est un bête fichier texte qui, une fois modifié servira a postalias pour créer un .db. Il faudra donc le modifier en respectant une syntaxe particulière, le sauvegarder, puis l’exporter avec la commande « newaliases ». Mais rentrons directement dans le vif du sujet:

Le fichier accepte un format bien précis, de la forme suivante:

Exemple: Mettons une adresse grouik@crashdump.fr dont j’aimerais envoyer une copie de tout les messages à patate@crashdump.fr et à dindon@crashdump.fr (ça fait moins serieux, du coup!) mon fichier aliases ressemblera donc à ça:

Notez que j’ai répété grouik dans les destinataires, sinon il ne recevra plus les message qui lui sont destiné.

Un petit programme se charge de tout:

astuce: si vous avez beaucoup de destinataires, vous pouvez les écrire sur plusieurs lignes en commençant les lignes suivantes par un espace.

Merci de votre lecture, et n’hésitez pas a poser vos questions dans les commentaires. J’y répondrais le plus vite possible.

Ces lignes ont été retirée parce qu’elle produisait des erreurs avec certains outils (Utilisation d’une donnée non initialisée dans la plupart des projets liés a OpenSSL). Mais la suppression de des lignes en question à eu des effets collatéraux sur OpenSSL PRNG. En fait au lieux de mélanger différentes variables aléatoire pour la génération initiale, la seule variable « aléatoire » qui a été utilisée étais le PID du générateur -et quand on sais que le nombre maximal par défaut sous linux est de 32,768- le résultat est que PRNG utilise une très petite fourchette de valeurs initiales.

Impact:

Toutes les clés SSL et SSH générées sur des systèmes basé sur Debian (Ubuntu, Debina, Mint…) entre Septembre 2006 et le 13 Mai 2008 sont affectée par la vulnérabilité. Dans le cas des clé SSL, tout les certificats doivent être révoqué et a nouveau généré. Tous les administrateurs système doivent auditer leurs clés pour être sur qu’ils ne sont pas touché par la vulnérabilité ! D’ailleurs tout les outils liés de près ou de loin a OpenSSL PRNG peut être vulnérable, attention.

Tout flux d’un serveur SSH qui utilise une clé générée par un système vulnérable peut être sujet a une interception (man in the middle) sans que l’administrateur ne se rende compte de rien. Je vous rassure, les projets Debian et Ubuntu on développé des outils pour identifier les clé vulnérables, vous trouverez plus d’information a leurs propos en fin de page.

Q: Combien de temps cela prendrais de générer toutes les clés touchées ?
A: Avec 31 Xeon @ 2.33Ghz. Cela prend deux heures pour les clés DSA 1024-bit et RSA 2048-bit pour x86. Les clés RSA 4096-bit sont générés en 6 heures. En ce qui concerne les clés RSA 8192-bit cela prendrais environs 100 heures.

Q: Combien de temps cela prendrait il de cracker un SSH avec ces clés ?
A: Tout dépend de la vitesse du réseau et de la configuration du serveur SSH. Il devrait être possible d’essayer toutes les clés (32,767 DSA 1024 et RSA 2048) en quelques heures. Attentions aux scripts tels que Fail2Ban (anti-bruteforce).. etc.

Q: J’utilise une clé RSA 16384 bit, suis-je vulnérable ?
A: Oui, c’est juste une question de temps (processeur et réseau). Pour le RSA 8192 bit, cela prend environ 3100 heures pour générer toutes les clés. J’imagine que pour le 16384 bit, nous serions dans les 100,000 heures (en temps CPU). Mais gardez en tête que la « fourchette » réele est bien plus mince, basée sur PID du processus qui a servit a générer le tout. Donc, inutile de générer toutes les clé pour en couvrir la majorité ! (La plupart de ces clés sont dans les premiers 3,000 PID)..

http://www.debian.org/security/key-rollover/
http://wiki.debian.org/SSLkeys

Et que vous êtes dans l’impossibilité de la supprimer, voila la solution:

..et dire que c’est même pas écris dans les man pages.. Voila qui m’a donné envie d’écrire un tutoriel sur route ! a bientôt ;)