Depuis quelques jours, le soir, je rencontre de grosses difficultés de connexion à internet. En effet j'ai des pings à 6000ms avec 50% de pertes de paquets. J'ai remarqué que le fait d'éteindre mon serveur @home permettait de résoudre le problème, ce qui est un peu étrange car j'imagine mal comment on peut mettre à genoux une connexion de 100Mbps. Plus étrange encore, le fait de désactiver les services nginx et postfix permettait également de résoudre les problèmes. En revanche la lecture des logs de ces services et ceux du système n'indiquait rien d'anormal.

Je m'orientais donc soit vers un ddos, soit un bug de lxc car la version proposée sur Debian est obsolète et on peut très bien imaginer des problèmes avec le bridge menant à des tempêtes de broadcast ou autres joyeusetés du genre. Désespéré, j'ai upgradé mon serveur en Jessie. Exit le kernel 3.2 et bonjour au 3.16, exit lxc 0.8 et bonjour lxc1.0. Suite à cela j'ai remarqué un retour à la normale et même une hausse de la réactivité du serveur. Je pensais donc le problème résolu.

Mais ce soir, rebelotte. Ping à 6000ms, 50% de pertes de paquets, et encore une fois le fait de couper mon serveur faisait disparaitre le problème. Cette fois j'ai donc fait tourner une analyse wireshark sur l'interface réseau du serveur.

Capture du trafic avec wireshark

Côté serveur (remote)

Installer tcpdump :

# apt-get install tcpdump

Côté PC portable

Installer Wireshark puis exécuter les commandes suivantes :

# mkfifo /tmp/wshark
# ssh root@192.168.0.1 "tcpdump -s 0 -U -n -w - -i eth0 not port 22" > /tmp/wshark

Puis, dans un autre onglet :

 # wireshark -k -i /tmp/wshark

Wireshark doit s'ouvrir et commencer à afficher le traffic du serveur :

Analyse des résultats

J'ai donc observé que pour deux IP, les trames suivantes inondaient le serveur :

3	0.023193000	5.39.90.132	192.168.0.2	TCP	66	[TCP Port numbers reused] 80→25 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1

Sans connaître tous les détails il semble que ce soit donc bien une attaque. Apparemment c'est du SYN flood.

Actions

A l'aide d'iptables, j'ai bloqué les deux adresses IP en cause :

# iptables -I FORWARD -s 5.39.90.132 -j DROP
# iptables -I FORWARD -s 37.187.112.166 -j DROP

Note : j'utilise FORWARD car j'ajoute cette règle sur l'hôte alors que les paquets sont à destination d'un container LXC qui dispose d'une autre adresse IP. INPUT doit être mis à la place si ce n'est pas le cas, ou dans le doute, les deux.

Miracle, après avoir bloqué ces deux IP, ma connexion à internet est revenue à la normale.

Ma deuxième action fut d'exécuter un whois sur ces deux IP pour en apprendre un peu plus. Elles appartiennent à des serveurs dédiés OVH, j'ai donc rempli le formulaire abuse sur leur site pour leur signaler que ces serveurs ont un comportement étrange.

Conclusion

Mon interprétation est la suivante : deux serveurs m'ont inondé de requêtes, qui arrivent sur nginx et postfix puisqu'elles sont destinées aux ports 25/80/443 d'après Wireshark. Si mon container LXC est éteint, elles finissent dans le vide. En revanche s'il est allumé, elles aboutissent et se multiplient jusqu'à saturer la BBox (le routeur en amont), ce qui provoque les ralentissements. Wireshark m'a beaucoup aidé à diagnostiquer ce problème, c'est maintenant mon meilleur ami.

iptables a pour instruction de "droper" (DROP) les paquets en provenance de ces deux adresses, ce qui revient donc à reproduire le comportement du serveur éteint. Le signalement à OVH permettra, j'espère, de faire couper ces deux serveurs probablement compromis.

En 4 ans d'auto-hébergement c'est la première fois que je suis confronté à un tel problème. On en revient aux raisons qui m'ont poussé à externaliser le blog maniatux.fr sur un VPS OVH, à savoir que si des attaques doivent avoir lieu, autant que ce ne soi pas chez moi. Mais il me reste un serveur @home que je pensais suffisamment "discret" pour ne pas se faire attaquer. J'espère que cela ne se reproduira pas à l'avenir...