Just Another Geek

Pourquoi est-ce que je sens que tous les chercheurs de vulnérabilité/exploits sont en train d'essayer de bindiff-er [archive] les IOS pour comprendre les dernières vulns de la nuit ? Peut-être parce qu'on peut r00ter tous les IOS du monde grâce à ça... Il suffit de voir les scores assignés par Cisco (8.3 et 10) pour se rendre compte de leurs gravités.

• Crafted IP Option Vulnerability [archive]
• IPv6 Routing Header Vulnerability [archive] (Félicitations Arnaud !)
• Crafted TCP Packet Can Cause Denial of Service [archive]

Le premier qui réussira à écrire un exploit stable et quasiment générique (modulo quelques adresses en fonction de l'IOS) doit pouvoir le vendre beaucoup plus cher qu'un exploit pour Vista ou un XP SP2 à mon avis.

Qu'est-ce que Gmane ?

Gmane est une passerelle de mailing list vers le protocole NNTP [archive]. Gmane s'inscrit sur les listes et republie les messages dans des groupes.

Pourquoi utiliser les services de Gmane.org ?

Gmane est bon pour la planète :

• Économe : Plus besoin que le serveur de liste envoie N fois le mail en entier à chaque personne alors que vous n'allez en lire que la moitié, rien qu'en sélectionnant les titres.
• Spam : Avant d'injecter les messages, plusieurs traitements anti-spams sont appliqués aux messages avec une efficacité redoutable.
  De plus, si des spams venaient à passer, vous pouvez les marquer vous-même comme tel et les messages seront supprimés après modération, ce qui permettra à d'autres personnes de profiter de votre marquage.
• Inscription facile aux listes : Plus besoin de voir si le gestionnaire de liste est un Mailman, Sympa, ecartis, etc. Vous avez juste à cocher la case du groupe dans votre lecteur de news et vous êtes inscrit.
• Possibilité de lire les groupes en NNTP, mais aussi grâce aux interfaces Web : vous pouvez alors envoyer un lien facilement vers un article donné.

En fait, la seule raison qui pousse les gens à ne pas utiliser Gmane est qu'ils n'utilisent pas de client de news (alors qu'une personne sérieuse utilisera Gnus [archive]). Non, je ne fais pas de la publicité car j'ai reçu mon tee-shirt d'admin [archive] gratuit :)

Si vous ne voulez pas perdre quelques heures pour récupérer une table des partitions écrasée (par un installateur complétement débile venant de Redmond), je vous conseille vivement de vous envoyer les tables de partition de tous vos périphériques de stockage :

% sfdisk -d | mail -s 'table des partitions' monmail@cretin.fr

fdisk -l n'est pas la meilleure solution (car il ne tient pas compte des arrondis et d'autres joyeusetés) et n'est pas un format d'entrée pour une restauration.

La recherche Google sur Ricard [archive] est intéressante : le deuxième résultat est... le site de Richard Stallman [archive].

J'aime Dave Aitel et sa pensée sur la "sécurité" de MacOS X [archive] :

« If I did a reasonably good translation, then my comment would be that perhaps it's because OS X users are so horribly bad at security that they never notice when they get hacked? This can be compounded by hackers not doing obvious things like stealing money from their OS X targets or putting up pop-ups, etc. Likewise, I think it would be affected by OS X being rarely used in a corporate environment, and hence not protected by the typical corporate IT trappings. »

Juste ce billet de mauvaise foi contre les intégristes Mac Breton (non, c'est pas contre toi Arnaud)...

La killer-app de gajim [archive] par rapport aux autres clients Jabber est qu'il est potentientellement plus difficile d'exploiter ce client pour la simple raison qu'il est écrit en Python.

En effet, si on regarde les vulnérabilités publiques de gaim [archive] (logiciel écrit en C), elles touchent toutes à des débordements de buffers ou autres joyeusetés des langages des années 80 :)
Bien sûr, gajim a sûrement des bugs de sécurité, algorithmiques, mais ça signifie que les chercheurs devront se passer de grep et compagnie... On est tranquille :)

Rien que pour ça (et aussi un peu pour ton support natif d'OpenPGP), gajim, malgré ta lenteur, je te garde!

Pourquoi réimplémenter le support des filesystems dans les bootloaders (tel que Grub) alors qu'ils sont déjà disponibles dans le noyau Linux ? C'est en partant de cette problématique que les développeurs de kboots [archive] ont développé un bootloader basé sur... le noyau Linux lui-même.

Le fonctionnement idéal de kboots est qu'une fois le stage1 chargé, il lance le noyau trafiqué avec son propre initramfs contenant une mini distribution basée sur µlibc et busybox. Dès lors, le menu de sélection peut s'afficher (qui tourne en userspace). Jusqu'ici, rien d'extraordinaire, mais voyons plutôt le potentiel de ce genre de bootloader :

• Support natif de tous les filesystems (et il n'y a alors plus le support b0rken d'XFS comme dans Grub) de base,
• Accès à toutes les fonctionnalités du noyau Linux et de la mini-distribution integrée. Par exemple, vous pouvez faire tourner un sshd (ok, c'est un dropbear) dans le bootloader ce qui est pratique si vous vous êtes complétement foiré dans la configuration de votre noyau hebergé dans une salle aux USA.
• Vous pouvez booter n'importe quel device supporté par Linux : Firewire, USB, Flash, etc.
• Et même par le réseau : FTP, HTTP, TFTP, etc.

Je pense qu'il y a un vrai potentiel à kibboutz [archive]^Wkboots. Après essai (et la compilation pendant une heure de tout ce qu'il fallait dans une petite VM), ca marche bien mais :

• C'est tout de même lent : il faut attendre le temps de boot d'un noyau Linux classique, donc au moins 30 secondes, puis le vrai noyau est lançé via kexec donc encore 30 secondes d'attente
• C'est testé sur x86 only :(
• Il n'y a pas encore le support de système autre que Linux
• Le stage1 n'est pas encore implémenté ! Donc en gros, il faut lancer kboot via votre bootloader favori. Pas glop mais ca marche très bien.

Même si certains médisants du bureau ne prennent pas au sérieux cette solution, je trouve ça très prometteur et j'envisage d'utiliser kboots sur des serveurs lointains...

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...

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...

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 ?

Ce patch [archive] proposé sur la liste [archive] de développement de tcpdump ajoute un filtre pour que notre sniffeur favori ne loggue ou n'enregistre pas les paquets de votre session ssh si vous êtes connectés de cette manière.

Ca serait bien pratique si les développeurs acceptaient ce patch mais en modifiant la manière de parser la variable SSH_CLIENT car après lecture rapide du patch, il ne tient pas compte des adresses retournées par un noyau et ssh compilés avec le support IPv6 (mais Buffer Overflow pas possible, rassurez vous).
Je pense que les développeurs de tcpdump vont vite s'en rendre compte...

Depuis la version 1.1.2 (version supérieure à celle qui était dans Debian Woody, donc on ne pouvait pas en profiter), vsftpd permet d'adapter une configuration particulière en fonction de l'adresse IP du client.

L'implémentation ressemble (un peu) à de la bidouille avec l'utilisation de tcp_wrapper. C'est-à-dire que lors d'une connexion provenant d'une adresse donnée, tcp_wrapper va initialiser une variable d'environnement (VSFTPD_LOAD_CONF par exemple) indiquant à vsftpd qu'il faut une configuration spécifique qui va s'appliquer sur la configuration globale.

Dans les faits, ca se fait comme ca :

% grep tcp_wrapper /etc/vsftpd.conf
tcp_wrappers=YES
% grep vsftpd /etc/hosts.allow
vsftpd:192.168.19.88:setenv VSFTPD_LOAD_CONF /etc/vsftpd_special_guest.conf

Ainsi, la configuration special guest surchargera les réglages globaux. On pourra, par exemple, n'autoriser que l'écriture dans certains répertoires en anonymous, le téléchargement, le listing de (certain) fichiers (Merci A. !), etc.

Alors ? Qui a dit que vsftpd était pauvre en fonctionnalité ? Ok, sa configuration diffère totalement d'autres serveurs FTP réputés user-friendly, mais pourquoi pas utiliser des outils reconnus, même si ils sont vieux ?

Pour ceux qui seraient tenté d'utiliser Vmware GSX server [archive] sur une Debian Sarge et qui s'étonneraient de ne pas voir le serveur HTTP se lancer, n'oubliez pas d'installer la bibliothèque fournissant libdb.so.3, ok rien de compliqué, mais la difficulté est de prendre le bon paquet Debian avec la bonne version.

$ sudo /etc/init.d/httpd.vmare start
Starting httpd.vmware: 
 httpd: /usr/lib/libdb.so.3: version `GLIBC_2.0' not found (required by httpd). 
$ sudo apt-get install libdb2
$ sudo /etc/init.d/httpd.vmare start
Starting httpd.vmware: done

Donc voila, si vous n'avez pas envie de perdre votre temps, c'est le package libdb2, logique non?

Je répondrais bien à ce malheureux [archive] mais j'ai la flemme de m'enregistrer...

Voila la migration de mon serveur est enfin finie, ca aura mit du temps mais c'est fait.

Résumé, depuis une connexion ssh :

$ sudo dpkg --audit
$ sudo apt-get install aptitude
$ sudo aptitude install doc-base
$ sudo aptitude -f --with-recommends dist-upgrade

Quelques dizaines de questions plus tard... C'était fait.

J'ai utilisé aptitude comme recommandé dans les Release notes [archive] qui, parait-il, gère mieux les dépendances.

Maintenant la partie la plus chi*nte : effectuer des tests de non-regression :(

Update: Les permissions CVS semblaient avoir été changées... Bizarre. De toutes façons, j'atttendais Sarge pour enfin avoir Subversion, adieu CVS :)

Aux États-Unis, un constat simple montre que la probalité d'accidents par armes à feux est beaucoup plus grande chez les personnes ayant des armes chez eux que chez les autres. C'est logique.

Alors je me demandais si celà était vrai pour le spam : est-ce qu'une machine qui nous a déjà spammé a plus de "chance" de nous spammer à nouveau ?

Voici les stats chez moi :

% zcat /var/log/exim4/mainlog*gz | perl ~/spammed-once-or-again.perl
1312 hosts spammed once (80.88% of spammers)
310 hosts spammed multiple times (19.11% of spammers)
     average time difference between spam: 91630s

Approximativement 20% des spammeurs vont recommencer, avec un intervalle moyen de deux mois environ. Je ne suis pas très étonné de ces résultats puisque le spam est désormais servi principalement par des machines Windows infectées par des vers (dont la durée d'activité d'une machine est très courte).

Je pense que le résultat serait complétement inversé si on faisait les stats sur les Sender addresses (ou même sur le sujet du message). À voir...

Rappel, un reverse DNS, c'est récupérer un (ou des) nom de domaine depuis une adresse IP. Un reverse cassé est lorsque :

% dig +short -x 1.2.3.4
smtp.plop.org
% dig +short smtp.plop.org
2.4.5.6

Maintenant, amusons nous à compter les reverses DNS cassés qui envoient des mails à mon serveur SMTP :

% zcat /var/log/exim4/mainlog*gz | awk 'BEGIN {                         \
                           ok = 0;                                      \
                           ko = 0                                       \
                         };                                             \
                                                                        \
                       /broken reverse/ {                               \
                           if (getline > 0 && $0 !~ /rejected/) {       \
                              ok += 1                                   \
                           } else {                                     \
                              ko += 1                                   \
                           }                                            \
                       };                                               \
                                                                        \
                       END {                                            \
                           print "ok=", ok, "ko=", ko                   \
                       }'
ok= 48 ko= 448

Ce qui signifie que 448 machines avec un reverse DNS cassé ont vu leur message refusé dès la session SMTP (Spamassassin, ou sanity check réalisé par Exim4) contre 48 serveurs SMTP qui, malgré leur DNS tout pourri, ont vu leur message accepté tout de même.

Après avoir jeté un coup d'oeil rapide aux messages acceptés, seul une dizaine ne sont pas du spam.

En conséquence, cela signifie qu'il n'est pas possible de mettre en production ce type de règle car elle déclenche trop de faux-positif (10 pour 500 messages, c'est beaucoup trop). C'est dommage car cette solution est très économe en ressources et permet de bloquer très tot les messages...

J'adore les pertes de paquets ! Aujourd'hui, ma connexion ADSL dégroupée Free a déraillé complètement pendant une demie-heure : plus de 15% des paquets étaient perdus.

Le truc chouette. C'est que comme par hasard, tous les paquets DNS étaient perdus, pas un seul n'est arrivé, ou en tout cas, pas une seule réponse n'est parvenue. Et sans DNS, on peut pas faire grand chose : le serveur SMTP refuse tout temporairement étant donné qu'il ne peut pas faire de vérification DNS, on ne peut plus visiter de sites Internet, bref la joie.

C'était d'ailleurs assez étonnant que les connexions TCP fonctionnaient aussi bien (ma connexion ssh était juste un peu lente, mais pas de blocage particulier).

Note pour plus tard, ne plus JAMAIS faire cp /usr/local/ssl/lib/*(.) /usr/lib/ pour la mise à jour d'Openssl lorsque vous êtes connecté en ssh car dès que les fichiers seront copiés, la communication sera coupée INSTANTANÉMENT ! Les clients ainsi que le serveur sshd seront tous killés !

Résultat, la machine, installée dans une belle salle machine située aux États-Unis se retrouve coupée du monde. Et là... c'est vraiment le drame car vous êtes un hébergeur [archive] tout de même, et le client attend.

Par chance, les connexions sortantes du serveur ne sont pas bloquées par le firewall (pas bien, quoique...) et vous avez un Apache qui peut executer vos scripts CGI uploadés via FTP (et non par SFTP comme d'hab').

Vous vous dîtes "facile", y a qu'à uploader un script qui appelle netcat afin de faire un reverse shell (oublier le reverse ssh puisque je vous ai dit qu'il était complément mort). Ce shell tournera avec l'identité d'Apache mais c'est pas grave, vous ferez un /bin/su... sauf que netcat n'ouvre pas un tty et donc su ou sudo refusent de travailler !

Le temps presse et vous vous rappelez de rrs [archive], un programme conçu pour faire des reverses shells proprement : il ouvre un tty au moins. Donc vous le compilez à la va-vite et l'uploadez par votre moyen favori...

Et c'est gagné ! La coupure ssh a duré 40 minutes, promis la prochaine fois, je ferais mieux :(

Non mais quelle idée de ne pas utiliser une distribution Debian et ses paquets magiques...

Update : Ah oui et puis j'ai oublié de dire que j'avais essayé phpshell.php [archive] mais comme le safe_mode est utilisé... Pas possible.