Just Another Geek

J'ai été livré hier soir, vers 2h00 du matin, de ma Dedibox [archive] après plus de trois semaines d'attente, j'ai juste eu le temps d'installer une Debian dessus et de regarder comment avait été configuré le système et je suis épaté : les paramètres par défaut sont très bien pensés et d'un point de vue sécurité, je n'ai rien trouvé à redire.

Un très bon point pour les administrateurs.

J'espère juste que l'infrastructure réseau tiendra le coup si des leechers monopolisent la bande passante...

J'ai toujours fait un point d'honneur à ne jamais parler de ma vie sur ce blog : mes réflexions, humeurs, états d'âme, sentiments, etc. Mais pour une fois, je vais faire une exception :

Read next [archive]

Les 300 spam-commentaires quotidien sur ce blog ont fini par me pousser à utiliser un captcha [archive] afin de compliquer la vie aux spammeurs.

Une solution très simple demandant de résoudre une addition ou une soustraction est disponible sur le forum de dotclear par Olivier Meunier [archive].

Update : En fait j'ai fait de la boue, c'est pas encore efficace :)

Je suis le seul à avoir été choqué par la page 23 de MISC #24 (mars-avril 2006) ?

C'est un formulaire d'abonnement avec la possibilité de payer par carte bleue : vous devez donner votre numéro de carte, sa date d'expiration ainsi que le cryptogramme visuel ! Et puis tu veux pas le numéro de ma soeur aussi ?

Pour un magazine de sécurité, ca parait tout de même douteux. Poisson d'avril ?

Avec mes 15 heures d'autonomies de batteries (une longue histoire à raconter) pour mon Thinkpad, me voila prêt pour Rabat (Maroc) où j'ai été invité à présenter une conférence atelier [archive] sur les failles informatiques exploitées par les spammeurs.

Je vais y parler :

1. L'organisation des spammeurs,
2. Les techniques utilisées pour l'envoi de courriers en masse,
3. Les failles utilisées,
4. L'identification de classes de spammeurs,
5. La lutte contre le spam,
6. En conclusion, donner les actions à mener pour chaque catégorie de personnes (ISP, entreprises, particuliers) ;

Merci Cédric [archive] et Fred [archive] !

J'ai beau ne pas aimer les GUIs en général mais NetworkManager [archive] est très prometteur et supporte déjà le WPA (même si la fonction n'est pas encore integrée encore dans le paquet Debian car en attente d'une dépendance de version avec wpasupplicant).

Pour ceux qui jonglent entre les réseaux, ca fait du bien. N'empêche, quand on voit tout ce que ca utilise, on se demande si ca va pas finir en usine à gaz : HAL, D-BUS, Gnome, dhcbd, etc.

Note : un troll s'est caché dans ce billet (et même deux en fait)

Ma connexion ADSL semble être morte (FranceTelecom avait joué avec les fils => GAMOT!) donc avant de trouver une solution, je ne peux plus recevoir mes mails @mouarf.org. Ne soyez pas étonnez que je ne réponde pas...

Update une semaine plus tard : Ca y est, après 9 jours et des mails perdus (bouncés), j'ai retrouvé ma connexion à la maison et donc mes mails.

SSTIC 2006 [archive] me voila [archive] !

Le premier brouillon de la GPLv3 [archive] est sortie il y a une dizaine de minutes, même si cela est inutile avec les papiers parlant de droits ou de licence, je l'ai lu en diagonal (ca sert à rien car chaque virgule a son importance et la moindre nuance est fatale) et une bonne couche à été mise sur les covered work (je pense aux rapports Nessus, code généré par un compilateur, etc).
J'attends avec impatience les réponses des experts de debian-legal [archive] à ce sujet.

Ca me fait mal de dire ça mais je songe de plus en plus à passer mes serveurs sous OpenBSD. Pourquoi ? Ma gateway principale, un AMD64 avec une carte mère POURRIE de chez ATI, ne supporte que le noyau 2.6.

Or, la série 2.6 n'a vraiment pas atteint sa maturité question sécurité. Même si je ne me fais pas de doute sur le fait que lorsqu'OpenBSD sera autant sur le devant de la scène, il y aura sûrement autant de problèmes. Néanmoins, les développeurs d'OpenBSD sont beaucoup plus intéressés par les questions de sécurité...

Quitter un noyau Linux, ca ne me dérange pas vraiment (sauf pour les performances :p) mais quitter Debian, là ca me blesse...

Heureusement que je n'écoute pas mes coups de tête sinon le drame aurait déjà eu lieu.
Car en y réfléchissant un peu plus quelques minutes, heures puis nuits, je me dis que je serai bien emm*rdé :

• Sont où mes paquets Debian ?
• Sont où mes performances ?
• C'est quoi cette c*nnerie de tout mettre dans /usr/local ?
• C'est quoi ce shell par défaut de daube ?
• C'est quoi ce /etc/init.d/ inexistant ? Vous trouvez pas d'une goretitude extrême que de killer/relancer soit-même les daemons ?
• Hein ? La NAT est faite en userspace, WTF !?!
• C'est pas les GNU tools par défaut ? Pfff...
• Ah parce que je dois rebooter le serveur pour mettre à jour la distribution tous les six mois ? Et que je dois merger moi-même les fichiers de configuration ? Mouaaaaaaaaarf !
• Un compilateur sur la machine de prod ? (le premier qui me dit de compiler les paquets sur ma machine Linux, je le renvoie me monter tout l'environnement de cross-compilation avec tous les headers qui vont bien, j'ai vraiment que ça a faire)

Après toutes ces réflexions, je me dis que je suis si bien sous Debian...

Je relisais dernièrement phrack #63 : Keeping 0day Safe [archive] et sa conclusion est tellement vraie (malheureusement) :

You are 10x better off using a 56 bit encryption algorithm with no known "John the Ripper" plugins than you are using a well known and well tested standard such as 3DES or Blowfish. Why? The answer is simple. Because only about 0.0001% of all "security professionals" actually know how to develop code. And the inability to develop code also means that they will be unable to provide real tools to cope with security problems that they can "conceptually" solve.

C'est pour cette raison que je ne me fatigue même plus à utiliser des outils automatisés du style de chkrootkit lors d'incident car un pirate utilisant un rootkit détecté par ce programme serait bien... stupide.

Pour ces mêmes raisons, j'en viens à douter de l'efficacité des règles publiques de snort matchant une vulnérabilité ou un exploit particulier (attention, je ne parle pas des actions connexes). Qui utiliserait un exploit qui ferait clignoter la machine de l'administrateur comme un sapin de Noël ? (Réponse simple : parce qu'il n'y a personne pour lire les logs)

Ne mettez SURTOUT PAS à jour X.org si vous êtes en Debian Unstable et que vous possedez une carte radeon. Ca provoque des gentils kernel panic/oops [archive] au lancement du serveur X [archive].

C'est trop tard car vous l'avez déjà fait ? Revenez en arrière :

% sudo apt-get install  xserver-xorg/testing xlibs/testing \
                                xserver-common/testing xlibmesa-dri/testing\
                                x11-common/testing xlibs-data/testing

Y a pas à dire, un fichier de configuration newsyslog [archive] est d'une limpidité et d'une simplicité exemplaire.

Comme son nom ne l'indique pas, newsyslog est un équivalent de logrotate qu'on peut trouver sous quelques saveurs BSDiennes. La killer-feature (pour moi en tout cas) est la syntaxe du fichier de conf :

# logfile_name          owner:group     mode count size when  flags
/var/cron/log           root:wheel      600  3     10   *     Z
/var/log/authlog        root:wheel      640  7     *    168   Z
/var/log/daemon                         640  5     30   *     Z
/var/log/pflog                          600  3     250  *     ZB /var/run/pflogd.pid

Sympa non ?

Je viens de remarquer que ni Perl, ni Python, ni Ruby n'implémentaient l'appel système fchown() ou fchmod(). C'est quand même trèèèèèèèèèèèèèèès facheux...

Je me posais la question suivante : lorsqu'on télécharge une clef PGP depuis un serveur PGP (gpg --recv-key 0x9223052 par exemple), est-on sûr que c'est la clef 0x9223052 ?

Note pour les gens pressés que je parle du KeyID et pas de la personne possédant la clef.

La FAQ PGP [archive] indique qu'on est capable de forger des clefs pour une fingerprint donnée, ou un KeyID donné, ou un Userid donné mais pas pour tous ces composants à la fois.

On ne peut donc être sûr d'avoir télécharger la bonne clef que si le KeyID, la fingerprint et la taille correspondent (on doit donc les connaître avant de la télécharger) à ce qu'on s'attend. Il est également bien de vérifier que la clef est auto-signée par son propriétaire.