TeamSpeak 3 et DDoS
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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | root@xxxxxxx:~# tcpdump -n udp dst port 9987 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 19:32:26.951945 IP yyy.yyy.yyy.yyy.63025 > xx.xxx.xxx.xx.9987: UDP, length 13 19:32:26.954988 IP yyy.yyy.yyy.yyy.4214 > xx.xxx.xxx.xx.9987: UDP, length 86 19:32:26.956298 IP yyy.yyy.yyy.yyy.53087 > xx.xxx.xxx.xx.9987: UDP, length 196 19:32:26.959345 IP yyy.yyy.yyy.yyy.53087 > xx.xxx.xxx.xx.9987: UDP, length 194 19:32:26.962196 IP yyy.yyy.yyy.yyy.55401 > xx.xxx.xxx.xx.9987: UDP, length 98 19:32:26.963638 IP yyy.yyy.yyy.yyy.55401 > xx.xxx.xxx.xx.9987: UDP, length 86 19:32:26.975075 IP yyy.yyy.yyy.yyy.4214 > xx.xxx.xxx.xx.9987: UDP, length 106 19:32:26.985299 IP yyy.yyy.yyy.yyy.53087 > xx.xxx.xxx.xx.9987: UDP, length 193 19:32:26.989263 IP yyy.yyy.yyy.yyy.55401 > xx.xxx.xxx.xx.9987: UDP, length 90 19:32:26.995130 IP yyy.yyy.yyy.yyy.4214 > xx.xxx.xxx.xx.9987: UDP, length 104 root@xxxxxxx:~# iptables -A INPUT -p udp --dport 9987 -m length --length 600:65535 -j DROP |
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:
1 2 3 4 5 6 7 | philippe@home:~$ traceroute xxx.xxx.xxx.xxx [...] 10 vac1-0-a9.fr.eu.vaccum (178.33.100.149) 46.545 ms 46.644 ms 46.719 ms 11 vac1-1-n7.fr.eu.firewall (178.33.100.152) 48.421 ms 48.434 ms 48.598 ms 12 vac1-2-n7.fr.eu.tilera (37.187.36.245) 48.656 ms 48.765 ms 36.985 ms 13 vac1-3-n7.fr.eu.arbor (37.187.36.254) 37.102 ms 37.186 ms 37.277 ms [...] |
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:
1 2 3 | 2014-04-28 18:06:21.073612|ERROR | | | TS3ANetwork::Connect failed error: 110 2014-04-28 18:06:21.073679|ERROR | | | Unable to connect to primary address, trying secondary 2014-04-28 18:07:24.305594|ERROR | | | TS3ANetwork::Connect failed error: 110 |
Au bout de 24 heures sans pouvoir vérifier la licence, le serveur TeamSpeak décide de s’arrêter:
1 2 3 4 5 6 7 | 2014-04-28 23:17:04.017614|ERROR | | | TS3ANetwork::Connect failed error: 110 2014-04-28 23:17:04.017686|ERROR | | | Unable to connect to primary address, trying secondary 2014-04-28 23:18:07.121615|ERROR | | | TS3ANetwork::Connect failed error: 110 2014-04-28 23:18:07.121692|ERROR |Accounting | | Could not connect to accounting server after multiple attempts, shutting down server 2014-04-28 23:19:12.785617|ERROR | | | TS3ANetwork::Connect failed error: 110 2014-04-28 23:19:12.785690|ERROR | | | Unable to connect to primary address, trying secondary 2014-04-28 23:20:15.889594|ERROR | | | TS3ANetwork::Connect failed error: 110 |
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:
1 2 3 4 5 6 7 | 2014-04-29 10:51:14.069321|ERROR |Accounting | | Unable to connect to accounting server 2014-04-29 10:51:14.069355|INFO |Accounting | | Licensing Information 2014-04-29 10:51:14.069378|INFO |Accounting | | type : Non-profit 2014-04-29 10:51:14.069433|INFO |Accounting | | starting date : Fri Nov 1 00:00:00 2013 2014-04-29 10:51:14.069459|INFO |Accounting | | ending date : Tue May 6 00:00:00 2014 2014-04-29 10:51:14.069479|INFO |Accounting | | max virtualservers: 10 2014-04-29 10:51:14.069499|INFO |Accounting | | max slots : 512 |
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:
1 2 3 4 5 6 7 8 | root@serveur:~# telnet accounting.teamspeak.com 2008 -b IP-A Trying 80.190.145.215... telnet: Unable to connect to remote host: Connection timed out root@serveur:~# telnet accounting.teamspeak.com 2008 -b IP-B Trying 80.190.145.215... Connected to accounting.teamspeak.com. Escape character is '^]'. ^CConnection closed by foreign host. |
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:
1 2 3 4 5 6 | root@serveur:~# iptables -t nat -A POSTROUTING -s IP-A -d 80.190.145.215/32 -j SNAT --to-source IP-B root@serveur:~# telnet accounting.teamspeak.com 2008 -b IP-A Trying 80.190.145.215... Connected to accounting.teamspeak.com. Escape character is '^]'. ^CConnection closed by foreign host. |
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:
1 2 3 4 5 6 7 8 | 2014-05-01 21:39:47.197797|INFO | | | License expired, but there is a new one available.. retrieving 2014-05-01 21:39:47.321675|INFO |Accounting | | Your license was updated by the licensing server 2014-05-01 21:39:47.444187|INFO |Accounting | | Licensing Information 2014-05-01 21:39:47.444232|INFO |Accounting | | type : Non-profit 2014-05-01 21:39:47.444264|INFO |Accounting | | starting date : Thu May 1 00:00:00 2014 2014-05-01 21:39:47.444288|INFO |Accounting | | ending date : Thu Nov 6 00:00:00 2014 2014-05-01 21:39:47.444318|INFO |Accounting | | max virtualservers: 10 2014-05-01 21:39:47.444338|INFO |Accounting | | max slots : 512 |
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!