Quand je parlais des abrutis qui pratiquent le DDoS dans un précédent post, je ne pensais pas être tombé sur un cas. Mon serveur subit maintenant un DDoS depuis le 28 avril!!
Pour résumer rapidement, l’abruti en question s’est fait bannir du serveur TeamSpeak par les admins (hasard) et pas de chance pour lui, son IP étant statique, il ne peut vraiment plus revenir. Estimant que sa présence ne pouvait que nous manquer, il en est rapidement venu aux menaces de DDoS si son ban n’était pas levé. Les menaces étant sans résultats, il a décidé de nous démontrer ses compétences techniques… et utiliser son compte paypal pour payer un site tel que Titanium et nous « punir ».

TeamSpeak 3 vs DDoS

Honnêtement, les forums TeamSpeak proposent assez peu de conseils pour limiter un DDoS à part de prendre un fournisseur avec une infra anti-ddos et passer le paramètre suivant « instanceedit serverinstance_pending_connections_per_ip=2 ».
Le problème est que TeamSpeak utilise essentiellement l’UDP comme protocole qui est « connection-less », il est donc très facile pour un bot-DDoS d’envoyer de nombreux paquets avec une IP source « spoofée » et de tailles différentes, etc. A l’inverse, il est difficile d’établir des règles iptables génériques, c’est au cas par cas et en fonction de l’applicatif ciblé. A la limite, si l’attaquant utilise une technique d’amplification, on peut mettre en place des règle qui imposent un rate-limiting sur les nouvelles « connections » ou filtrent sur la taille des paquets. Par exemple, un tcpdump sur du trafic teamspeak légitime semble montrer que la taille des paquets UDP ne dépasse pas les 600 octets.

Bref, une bonne analyse du DDoS permet d’atténuer l’impact sur le serveur, mais dans tous les cas…

Une Infra anti-DDoS est Essentielle

Le serveur physique est quand même assez solide, Xeon E3-1225v2, 1Gbps de capacité. Mais à 150 Mbps de DDoS, le teamSpeak subit des pertes de paquets. Ce ne sont pas tant le CPU ou la RAM, dont la conso reste négligeable, que les buffers UDP qui sautent… On peut essayer de mitiger comme expliqué ou de jouer avec les paramètres UDP (voir man 7 udp), mais de toutes façons

• Si le trafic DDoS approche le 1 Gbps, il n’y a plus rien à faire côté serveur
• L’infra anti-ddos d’OVH s’active en moins de 2 mins !

Bilan, personnel, pendant 1 semaine, de nombreux DDoS, et une gêne sans conséquence de moins de 2 mins à chaque fois, les seuls symptômes durables se limitent au traceroute:

Mais des Effets Secondaires

Une infra anti-ddos avec ses analyseurs etc. offre donc une très bonne solution. Malheureusement, elle présente aussi quelques inconvénients désagréables qui ont abouti à l’arrêt du serveur TeamSpeak. En effet, ce dernier a besoin de se connecter au serveur de licences pour en vérifier la validité. Pour cela, il établit une session TCP vers le serveur accounting.teamspeak.com sur le port 2008. Session que le firewall de l’infra anti-ddos bloque… On retrouve alors dans les logs TeamSpeak cette série de lignes toutes les 30 à 60 minutes pendant la durée du DDoS:

Au bout de 24 heures sans pouvoir vérifier la licence, le serveur TeamSpeak décide de s’arrêter:

24h sans s’arrêter ce n’est pas si mal? Bof, et au redémarrage, la tolérance du serveur n’est plus que de 3 heures. Et si vous n’êtes plus qu’à quelques jours de l’expiration/renouvellement de votre licence Non-Profit, vous risquez tout simplement de la perdre:

Pour résumer, l’abruti, voyant que sont DDoS était sans effet, nous disposons d’un TeamSpeak Viewer sur le site web, a décidé de payer plus cher pour nous DDoS encore plus longtemps. C’était stupide, mais sans le savoir, il a joué sur un filtrage un peu trop brutal de l’infrastructure anti-ddos d’OVH. Moins de 24 heures et le DDoS était sans conséquence, le TeamSpeak reprenant contact avec le serveur de licence à temps, plus longtemps et il forçait indirectement le serveur à s’arrêter. Pire, un DDoS de 10 jours allait me faire perdre ma licence Non-Profit alors qu’il est aujourd’hui difficile de s’en procurer une.

Comment s’en Sortir ?

Disposant de plusieurs IPs sur le serveur, j’ai rapidement pu constater que seul le trafic à destination de l’IP utilisée par le TeamSpeak passait dans l’infra anti-DDos. Pour simplifier, appelons la IP-A. Une bonne astuce pour le vérifier est de passer les commandes suivantes avec les différentes IPs dont dispose le serveur:

Pour traduire, ces commandes telnet montent une session tcp sur le port 2008 du serveur accounting.teamspeak.com, le -b précise d’utiliser l’adresse IP-A ou IP-B comme source.
Si une de vos IP (ici IP-B) permet la connexion au serveur de licence, vous êtes bon. Il ne reste plus qu’à jouer avec iptables pour faire passer les connections du serveur TeamSpeak avec pour source l’IP qui fonctionne. 80.190.145.215 étant l’adresse du serveur de licence, il vous suffit de passer:

Mais si vous ne disposez que d’une seule IP sur votre serveur que faire ? N’importe qu’elle solution qui redirigera le trafic en dehors de l’infra anti-ddos devrait faire l’affaire. Par exemple, une autre solution que je n’ai pas testée, consiste à passer par un serveur tiers avec un tunnel SSH. Même votre ligne ADSL à la maison peut suffire. En gros,

• Ajouter dans le /etc/hosts la ligne 127.0.0.1 accounting.teamspeak.com
• passez la commande ssh username@serveur_tier -L 2008:accounting.teamspeak.com:2008

La ligne dans le /etc/hosts va faire croire au TeamSpeak que l’IP du serveur de licence est le localhost. Le tunnel SSH va, lui, rediriger les requêtes sur le localhost vers le serveur de licence en passant par le serveur tiers. Cette solution n’est vraiment pas stable mais, en cas d’urgence, elle est rapide à implémenter et tant qu’elle fonctionne une fois par jour, elle peut vous sauver:

Le DDoS la Plaie du Net

Tout est bien qui fini bien en tous cas pour mon serveur, et sans avoir eu à céder au chantage ce qui était hors de question quoi qu’il arrive.
Mais pour les malheurs de tous, Les DDoS deviennent de plus en plus fréquents et volumineux sur Internet. On peut remercier les dernières techniques d’amplifications comme celle qui a touché Cloudflare avec 400 Gbps ! Le pire est que ces techniques ne fonctionnent que grâce à la masse des serveurs DNS et NTP mal configurés disponibles à travers le net, il n’est même plus besoin de les hacker. Il est donc essentiel de comprendre qu’administrer un serveur n’est pas qu’un jeu, la bonne santé d’internet en dépend, sans compter que tout ces DDoS finissent par avoir un coût non négligeable:

• en terme de temps perdu à les atténuer
• en infrastructure VAC ou autres à mettre en place
• en bande passante perdue, la capacité de transit coûte quand même au minimum $1 par Mbps par mois!