Aujourd'hui j'ai voulu mettre à télécharger une ISO d'ArchLinux sur le serveur. Rien d'anormal jusque là, et c'était vraiment un torrent de l'image d'ArchLinux, prise sur archlinux.org et tout et tout.

• Ajout du torrent sur Transmission, okay.
• Attente de quelques secondes pour voir le torrent apparaître dans la liste, …
• Heu… syn ? syn ? syn ? … ping ?

ALAAAAAAARM !

1. Remonter le temps : qu'ai-je fais avant que tout cela n'arrive ?
2. Installé /usr/libexec/mail.local via les sources car après jailage de postfix, il vaut mieux réinstaller le sendmail de base. Ce que je n'ai pas fait et donc ce programme était manquant.
3. Ajouté ce torrent.

Comme j'utilise FreeBSD 9.2-RC1 avec ZFS en système de fichier, je n'ai pas pu utiliser le rescue-pro fourni pour OVH car la version de ZFS est trop récente. Erf. Et ils ne proposent plus le vKVM. Re-erf.

À ce moment là je ne pensais pas que transmission pouvait être en cause, et je suis donc parti sur mail.local, vu qu'il a été compilé via les sources et qu'il ne provenait donc pas des tarbaballes de base. À part un segfault il n'aurait pas pu faire grand chose d'autre… mais peu importe.

Redémarrage bourrin via l'interface de gestion d'OVH, les yeux rivés sur le ping 5.135.177.31, un ssh katana rm -rf /usr/libexec/mail.local prêt à bondir dès que le serveur répond et… la commande s'exécute… puis plus rien. Le ping ne trouve plus de pong, ça n'était donc pas ça.

À nous deux, face de torrent

(Re)²boot, ssh katana service transmission stop

La magie opère, le problème venait donc de là. Dans les logs on trouvera :

Aug 12 11:26:16 katana kernel: Limiting closed port RST response from 543 to 200 packets/sec

RST

Avec TCP, reset, permet de mettre fin à une connexion. C'est ce qui va se passer quand on veut joindre un port fermé par exemple, la connexion est fermée avec RST. Donc ça veut dire quoi, qu'on a floodé le serveur sur un port fermé jusqu'à ce qu'il crève sous les réponses à envoyer ?

Malheureusement je n'ai pas d'informations à ce sujet, ou du moins pas encore, pflog (oui, en français) va bien me cracher quelque chose.

Des sysctl sympatiques

En plus d'un firewall, on peut se prémunir de ce genre d'attaque en utilisant les sysctl suivantes :

net.inet.tcp.blackhole
net.inet.udp.blackhole

Avec la valeur 1 ou 2. Voir man blackhole pour plus d'informations (a priori FreeBSD only)