Mon serveur @home est la cible d'attaques de type SYN flood depuis quelques temps. Au début elles n'étaient pas très importantes mais depuis peu elles ont gagné en intensité, m'obligeant à bloquer une dizaines d'IP par jour (à la main). Les différentes astuces sur le web faisant appel à iptables ou au fichier sysctl.conf ont aidé, mais devant la virulence de l'attaque je dois toujours intervenir pour bloquer les IP.

Mon serveur @home tourne sous Debian Jessie et fourni plusieurs containers LXC dont un qui fait tourner une instance Yunohost et héberge mes mails. Quand une attaque violente se produit les mails ont des difficultés à arriver et j'ai du mal à les lire. De plus cela sature mon routeur en amont (la Bbox) ce qui me ralenti la connexion à internet pour toutes les machines du réseau (ping 6000ms, 50% de pertes de paquets).

Aujourd'hui je suis à court d'options, mon serveur ne semble pas assez robuste pour filtrer efficacement toutes ses requêtes. Il me faudrait une appliance pare-feu en amont pour filtrer tout cela, mais je n'ai pas envie de m'encombrer avec du matériel supplémentaire ou devoir à nouveau tout réinstaller.

J'ai déjà dit du bien du VPS Classic 1 chez OVH, qui me permet de faire tourner le blog maniatux.fr pour un coût dérisoire (2,39€ TTC par mois, soit moins de 30€ par an...). Ces VPS sont protégés contre les attaques ddos donc à priori je ne serai plus embêté.

Je reconnais que c'est une solution de facilité, mais je ne suis pas équipé pour contrer du ddos chez moi.

18 Mai, année 2005. Je suis lycéen et aujourd'hui n'est pas un jour comme les autres. C'est le jour de la sortie de l'Episode III de Star Wars et moi et mes "potes" avons acheté nos billets le midi au cinéma pour la séance du soir.

Après avoir terminé les cours en avance, nous prenons une petite bière, quelques gâteaux, et nous nous rendons au cinéma totalement rempli (le cinéma, pas nous). Une foule incroyable, les guichets pris d'assaut, la queue devant la salle qui n'ouvrait pas avant l'heure prévue !!! Et puis la séance débuta avec une publicité pour le jeu World of Warcraft encore nouveau à l'époque mais déjà très populaire...

Et puis.... LE FILM !!! Cette émotion quand le générique défile !!! Cette bataille spatiale avec des vaisseaux tellement perfectionnés qu'ils font du bruit dans l'espace !!! La branlée de Doku !!! Un démarrage en fanfare qui nous a vite fait oublier les lourdeurs de l'Episode II qui nous faisait craindre l'avenir.

Aujourd'hui, fin 2014, arrive le premier trailer pour l'Episode VII !!!! Non, Star Wars au cinéma n'est pas mort et reviendra en Décembre 2015 si tout se passe bien.

Voir le trailer de l'episode VII

Xen + libvirt is an interesting choice of toolstack, it makes network-management and guest installation easier and enables graphical remote management of the VMs. However, Debian Wheezy has several issues, I have never been able to boot something using xen + virt-manager, so I strongly recommend Jessie which is pretty stable. In this howto, I use two servers : xen-01 (for Xen + libvirt, headless) and xen-console (for virt-manager, with Xfce desktop). You can use virtual or physical machines but I had issues with VMware because Xen keeps freezing when you try to boot a domU. However, Virtualbox works fine.

Lire la suite de Debian 8 + Xen + Virt-manager HOWTO

Qu'est-ce que la vérification SPF ?

Un nom domaine (example.com) est enregistré sur un DNS et comporte plusieurs valeurs : A (hôte ipv4), AAAA (hôte ipv6), MX (serveur où les mails doivent être remis), TXT (divers), etc. Le champ TXT permet de définir des arguments relatifs à la messagerie. Dans notre cas, SPF consiste à indiquer quel serveur a le droit d'envoyer du courrier en utilisant ce domaine comme identité. Concrètement on peut définir que seul le serveur 1.2.3.4 a le droit d'envoyer un mail en tant que @example.com.

Une vérification SPF permet donc à un serveur qui reçoit du courrier de vérifier que celui qui envoie est bien ce qu'il prétend être. On évite ainsi pas mal de spam, usurpation d'identité, phishing et autres joyeusetés. Voici étape par étape comment ça fonctionne :

• Un mail arrive, comme expéditeur il est indiqué machin@example.com
• Le serveur qui reçoit vérifie ce qui est indiqué en SPF dans l'enregistrement DNS de example.com
• Ce SPF dit que seuls les serveurs 1.2.3.4 et 5.6.7.8 sont autorisés à envoyer du courrier pour le domaine example.com
• Le serveur vérifie donc l'IP du serveur expéditeur et rejette le message si cela ne correspond pas aux deux adresses précédentes

Le problème du mx backup

Comme je l'indiquais plus haut, un domaine peut contenir un champ MX qui indique à quel serveur le courrier doit être redirigé. Or on peut avoir plusieurs MX avec un ordre de priorité. Cela présente un intérêt pour assurer la continuité de service si le serveur principal tombe. Un serveur secondaire sera nommé mx backup dans cet article.

J'ai été confronté à un cas spécial. Comme l'ami Etenil j'ai un serveur de messagerie en ligne nous avons donc modifié nos configurations pour faire office de mx backup l'un l'autre. Donc si mon serveur se retrouve offline, les mails entrants seront redirigés vers le serveur de Etenil qui les conservera jusqu'à ce que je revienne online. Un problème s'est posé depuis que j'ai migré mon serveur sur Yunohost. En effet ce dernier fait une vérification SPF quand il reçoit un mail. Et dans le cas où c'est le mx backup qui me transmet un message, voilà ce qui se passe :

• Mon serveur est passé offline
• Un expéditeur machin@example.com m'envoie un mail
• Le mail arrive sur le mx backup (chez etenil) qui le stocke
• Mon serveur revient online
• Le mx backup (etenil) me transfère donc le mail
• Mon serveur fait une vérification SPF et compare avec l'IP du mx backup (etenil)
• Le message est rejeté car le champ SPF de example.com ne liste pas l'IP du mx backup (ce qui est normal)

La vérification SPF est donc problématique dans le cas où le message n'arrive pas directement mais transite par d'autres mx indépendants de l'expéditeur. Notez que par défaut Postfix ne fait pas de vérification SPF, cela est géré par un plugin. Mais YunoHost le propose par défaut.

La solution

Il faut définir une "spf whitelist" pour indiquer à Postfix de ne pas faire de vérification dans le cas où le serveur expéditeur est mon mx backup. J'ai trouvé la solution en lisant cette page de documentation.

Donc on édite notre /etc/postfix/main.cf puis on recherche la section suivante :

# Requirement for the recipient address
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_non_fqdn_recipient,
    reject_unknown_recipient_domain,
    reject_unauth_destination,
    check_policy_service unix:private/policy-spf
    check_policy_service inet:127.0.0.1:10023
    permit

On va donc y insérer la directive permit relay_addresses mx2.example.com :

# Requirement for the recipient address
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    permit relay_addresses mx2.example.com
    reject_non_fqdn_recipient,
    reject_unknown_recipient_domain,
    reject_unauth_destination,
    check_policy_service unix:private/policy-spf
    check_policy_service inet:127.0.0.1:10023
    permit

Ensuite on recharge Postfix :

# service postfix reload

Et voilà

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