Attaque DDoS de forte intensité : que faire maintenant

Une attaque qui s'arrête au bout de dix minutes est agaçante. Une attaque qui revient depuis des jours, chaque soir à la même heure, est tout autre chose : votre serveur n'est alors plus une cible prise au hasard. Cet article montre ce qu'il faut faire maintenant, ce que vous pouvez sécuriser vous-même sans frais supplémentaires et où ces mesures s'arrêtent.

Toutes les commandes valent pour Debian 12, Debian 13, Ubuntu 22.04 LTS et Ubuntu 24.04 LTS et sont écrites pour root ; en utilisateur normal, faites-les précéder de sudo. Ce qu'est techniquement une attaque DDoS est expliqué dans l'article Qu'est-ce qu'une attaque DDoS ?.

Tant que l'attaque est en cours : ne redémarrez pas et ne refaites pas la moitié de la configuration. Un redémarrage efface précisément les compteurs dont vous avez besoin pour le signalement à votre hébergeur, et l'attaque revient ensuite à l'identique.

Pourquoi votre serveur est attaqué avec autant d'obstination

Les serveurs bombardés pendant des semaines présentent presque toujours les trois mêmes caractéristiques. D'abord, ils publient eux-mêmes leur adresse : dans une liste de serveurs, sur un Discord, via un enregistrement DNS. Ensuite, leur usage est lié à des horaires fixes, donc une panne à 20 heures est visible par le plus grand nombre. Enfin, il existe quelqu'un pour qui cette panne a une valeur : un projet concurrent, un joueur banni, un client mécontent.

S'y ajoute un point technique : beaucoup des services concernés fonctionnent en UDP. UDP ne connaît aucun établissement de connexion que l'on pourrait exiger, et les adresses d'expéditeur se falsifient. Un attaquant n'a donc besoin ni d'entrer dans votre service ni de s'y adresser correctement pour produire de la charge. Du côté des services TCP, ce sont des connexions à moitié ouvertes qui occupent les ressources sans jamais aboutir.

Les ports réellement concernés

Une attaque ne frappe pas « le serveur », mais un port. Le tableau suivant indique les ports par défaut des services les plus souvent visés et sert en même temps de liste de contrôle : tout ce qui n'y figure pas et reste malgré tout ouvert doit être fermé.

Un second groupe apparaît non pas comme cible, mais comme source : 53 (DNS), 123 (NTP), 389 (CLDAP), 1900 (SSDP), 11211 (memcached) et, là encore, 27015. Si ces ports source dominent, il s'agit d'une attaque par réflexion et amplification. Les expéditeurs sont alors des serveurs tiers mal configurés et étrangers à l'affaire, ce qui rend le blocage d'adresses individuelles totalement inutile.

Ce que vous pouvez faire vous-même avant de dépenser le moindre euro

Cette section est la plus longue, et ce n'est pas un hasard : un serveur proprement configuré encaisse par ses propres moyens les attaques petites et moyennes, et fournit en cas de coup dur les valeurs mesurées nécessaires au niveau suivant.

1. Les premières minutes : mesurer au lieu de bricoler

Avant de modifier quoi que ce soit, notez ce qui se passe à l'instant. Quatre valeurs suffisent : le taux de paquets entrants, la répartition des états des connexions, les messages du noyau et la question de savoir si le service répond encore en local.

IF=$(ip -o route get 1.1.1.1 | awk '{print $5}')
A=$(cat /sys/class/net/$IF/statistics/rx_packets) || exit 1; sleep 1; B=$(cat /sys/class/net/$IF/statistics/rx_packets); echo "$((B-A)) paquets/s entrants sur $IF"
ss -Htan | awk '{print $1}' | sort | uniq -c | sort -rn
dmesg -T | tail -50
curl -o /dev/null -s -w '%{time_total}\n' http://127.0.0.1/

Le nom de l'interface provient de la route par défaut, car eth0 n'existe tout simplement pas sur beaucoup de serveurs KVM (elle s'y appelle ens3 ou enp1s0) et un nom mal saisi annonce tranquillement zéro paquet. Un gros bloc en SYN-RECV est la signature d'un SYN flood. Si le service répond rapidement via 127.0.0.1 alors qu'il est injoignable depuis l'extérieur, le problème se situe dans le réseau. Et retenez ceci : sur le serveur, vous ne mesurez que ce qui est passé, derrière un filtrage vous ne voyez qu'une fraction du volume. La méthode complète est décrite dans Détecter une attaque DDoS.

Si vous ne passez plus en SSH, ce n'est pas une raison de redémarrer : c'est la conséquence d'une liaison saturée. L'accès se fait alors par la console VNC dans l'espace client, qui fonctionne indépendamment du raccordement réseau.

2. État des lieux : qu'est-ce qui écoute vers l'extérieur ?

ss -lntup
nmap -Pn -p- --min-rate 1000 ADRESSE.IP.DE.VOTRE.SERVEUR

La première commande montre votre propre point de vue, la seconde, lancée depuis une autre machine, celui de l'attaquant. Ce qui compte, c'est l'adresse locale : 0.0.0.0:3306 signifie « joignable depuis tout Internet », 127.0.0.1:3306 signifie « en local uniquement » et n'a besoin d'aucune règle de pare-feu. On y découvre régulièrement des services oubliés : une instance de test, un panneau d'administration, une base de données sans liaison locale.

3. Ne laisser ouvert que ce dont le service a réellement besoin

L'ordre est important, faute de quoi vous vous coupez vous-même l'accès : d'abord les autorisations, ensuite la politique par défaut, et seulement après l'activation.

ufw allow 22/tcp comment 'SSH'
ufw allow 80,443/tcp comment 'Web'
ufw allow 25565/tcp comment 'Port de jeu'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Vérifiez ensuite, avec une seconde session que vous venez d'ouvrir, que vous entrez toujours : les connexions existantes survivent à l'activation même quand la règle correspondante manque. Le guide complet, avec la voie de secours, se trouve dans Configurer le pare-feu UFW sans se bloquer l'accès SSH.

La base de données n'a rien à faire sur le réseau ouvert : /etc/mysql/mariadb.conf.d/50-server.cnf doit contenir bind-address = 127.0.0.1. Les interfaces d'administration non plus. Sans adresse IP fixe permettant une autorisation ciblée, laissez le port fermé et atteignez-le par un tunnel SSH.

ssh -N -L 8443:127.0.0.1:8443 root@ADRESSE.IP.DE.VOTRE.SERVEUR

Les ports de conteneur publiés contournent les chaînes UFW. Liez-les en local, donc -p 127.0.0.1:8080:80 au lieu de -p 8080:80, et faites passer l'accès par un reverse proxy.

4. Sécuriser le port de requête sans le fermer

Outre le port principal, beaucoup de services en ont un second qui délivre des informations d'état : 27015 UDP pour les jeux basés sur Steam, le port Query pour Minecraft, l'interface ServerQuery sur 10011 TCP pour TeamSpeak. Ils répondent sans authentification, et la réponse est plus volumineuse que la requête, ce qui les rend exploitables pour amplifier une attaque contre des tiers. Les fermer n'est généralement pas une option, car votre serveur disparaîtrait alors de la liste des serveurs. Limitez-les plutôt par adresse source :

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Dix requêtes par seconde et par adresse suffisent aux vrais joueurs comme à votre monitoring, mais rejettent une source qui envoie des milliers de requêtes par seconde. Sous Minecraft, enable-query=false dans server.properties désactive complètement le port Query sans que le serveur disparaisse de la liste. enable-status=false supprime en plus la réponse au ping de la liste, mais votre serveur apparaît alors comme hors ligne. Quant à l'interface ServerQuery de TeamSpeak, liez-la à 127.0.0.1.

5. Limiter les taux de connexion et de paquets

iptables -I INPUT -p tcp --dport 443 --syn -m connlimit --connlimit-above 40 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 7777 -m hashlimit --hashlimit-name game_udp --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

La première règle rejette les nouvelles connexions TCP dès qu'une adresse en a plus de quarante ouvertes en même temps ; la seconde rejette les paquets UDP à partir de plus de 600 paquets par seconde soutenus depuis la même source. Ces deux valeurs sont des points de départ, pas des vérités : régler trop serré revient à éjecter vos propres utilisateurs. Vérifiez avec iptables -L INPUT -n -v que les compteurs de correspondances augmentent. S'ils restent à zéro, c'est que la règle n'est jamais atteinte.

Les règles iptables ajoutées directement disparaissent après un redémarrage ; on les conserve avec apt-get install -y iptables-persistent et netfilter-persistent save. Sous UFW, elles doivent aller dans /etc/ufw/before.rules, sinon elles s'évaporent au prochain ufw reload. Et voici la limite de fond : les limites par adresse source n'agissent que tant qu'il existe des sources qui se distinguent. Si chacune des 200 000 adresses impliquées envoie exactement un paquet, aucune ne ressort.

6. Préparer le noyau à un grand nombre de petits paquets

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sysctl -w net.core.somaxconn=4096
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Les SYN cookies répondent à l'établissement de connexion sans occuper de mémoire et sont actifs d'origine. Les deux files d'attente sont les premières à déborder quand les tentatives de connexion simultanées se multiplient. Pour rendre ces valeurs permanentes, placez-les dans un fichier sous /etc/sysctl.d/ et appliquez-les avec sysctl --system. La dernière ligne affiche le suivi de connexions, qui n'existe qu'avec un pare-feu actif : si sa table se remplit, le serveur rejette aussi les paquets légitimes et signale nf_conntrack: table full, dropping packet.

7. Couche applicative : rate limits, whitelist, plugins et anti-cheat

Les attaques qui saturent non pas la liaison, mais l'application, ont une tout autre allure : peu de paquets, mais des paquets coûteux. Un HTTP flood sur la fonction de recherche d'une boutique n'a pas besoin d'un gigabit. Sur un serveur web, une limitation par adresse est donc la mesure la plus efficace, dans nginx au niveau du bloc http, puis dans le bloc server ou location :

limit_req_zone $binary_remote_addr zone=web:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=webconn:10m;

limit_req zone=web burst=20 nodelay;
limit_conn webconn 20;

Contre les tentatives de connexion répétées, Fail2ban complète utilement le dispositif ; sa mise en place est décrite dans Configurer fail2ban. Sur les serveurs de jeu, trois éléments agissent contre tout ce qui emprunte la voie d'accès normale : une whitelist (sous Minecraft whitelist=true avec enforce-whitelist=true), une limite réaliste de joueurs simultanés et des événements réseau vérifiés côté serveur.

Ce que les plugins et les systèmes anti-cheat ne savent pas faire mérite d'être dit tout aussi clairement : les deux tournent dans le même processus que le jeu et ne contrôlent qu'au moment où un paquet est déjà traité. Si le processus est à l'arrêt, la logique de protection l'est avec lui. Il en va de même pour la whitelist, car celui qui inonde votre serveur ne cherche pas du tout à s'y connecter.

8. Liste des serveurs, DNS et votre propre adresse IP

Mieux vaut ici l'honnêteté que les vœux pieux : votre adresse IP ne peut pas rester secrète. Quiconque s'est connecté une fois la connaît, et une entrée dans une liste de serveurs la publie de toute façon. Deux habitudes aident malgré tout : ne jamais publier vous-même l'adresse brute, pas plus sur un canal Discord que via un bot de statut, et faire connecter vos utilisateurs par un hostname, afin qu'un changement d'adresse ne casse pas toutes les références.

Lors du changement lui-même, les vieux enregistrements DNS sont le grand classique : un enregistrement A oublié, un sous-domaine hérité d'une page de statut, un enregistrement MX qui pointe vers le même serveur. Et même dans ce cas, changer d'adresse fait gagner du temps sans rien résoudre.

9. Documenter tant que l'incident est en cours

Sans valeur de référence, vous ne pourrez pas dire après coup si 40 000 paquets par seconde représentaient beaucoup ou simplement un mardi soir. Avec apt-get install -y vnstat sysstat, la mesure tourne en permanence en arrière-plan. Pendant l'incident, collectez ceci :

mkdir -p /root/incident && cd /root/incident
date -u > 01-heure.txt
ss -s > 02-sockets.txt
ip -s link > 03-interfaces.txt
sar -n DEV 1 10 > 04-taux-paquets.txt
dmesg -T | tail -100 > 05-kernel.txt
tcpdump -ni "$IF" -s 96 -c 500 -q > 06-echantillon.txt

Limitez toujours tcpdump avec -c : une capture illimitée sur une liaison saturée charge encore davantage le serveur. Le ticket doit ensuite contenir l'heure avec le fuseau horaire, l'adresse IP concernée avec son port, le taux de paquets mesuré avec le sens du trafic, la répartition des protocoles et les ports source qui se distinguent. Avec ces éléments, un signalement est traité immédiatement ; avec « le serveur était lent », il faut s'attendre à des questions en retour.

Là où ces mesures s'arrêtent

Vient maintenant la partie qu'aucun fichier de configuration ne résout. Toutes les mesures évoquées jusqu'ici agissent au bout de la liaison. Une règle de pare-feu décide du sort d'un paquet qui a déjà parcouru le câble : vous pouvez le rejeter, mais pas faire qu'il n'ait jamais été envoyé.

Faites le calcul une fois. Un raccordement à 1 Gbit/s transporte 125 mégaoctets par seconde et il est plein dès que quelqu'un envoie davantage. Avec les plus petits paquets possibles, cela correspond à environ 1,49 million de paquets par seconde, et à environ 14,9 millions en 10 Gbit/s. Selon le CPU et la carte réseau, un noyau de serveur en traite quelques centaines de milliers avant de commencer à rejeter. Une attaque qui ne remplit même pas un tiers de votre liaison peut donc quand même vous paralyser, parce que le temps de calcul part dans le rejet des paquets.

Pour situer les ordres de grandeur réels : sur des serveurs KernelHost, nous avons notamment filtré en temps réel une attaque de plus de 473,4 Gbit/s à plus de 41,5 millions de paquets par seconde contre un serveur vocal (9987 UDP), ainsi qu'un UDP flood de plus de 112,2 Gbit/s contre un serveur de jeu (7777 UDP). Le premier cas représente environ 473 fois ce qu'une liaison à 1 Gbit/s peut transporter au total. Les attaques volumétriques doivent s'arrêter dans le réseau, en amont du serveur, sinon elles s'arrêtent dans votre liaison.

Ce que KernelHost oppose à cela

La protection permanente incluse sur chaque serveur

La protection DDoS de KernelHost repose sur deux niveaux et reste active en permanence, sans que vous ayez quoi que ce soit à commander, à activer ou à configurer :

• Niveau 1 : 17 Tbps de capacité de mitigation dans le réseau de scrubbing mondial. Les attaques volumétriques sont nettoyées au plus près de leur source, avant d'atteindre le centre de données.
• Niveau 2 : filtrage Arbor en temps réel à 3,2 Tbps sur place à Francfort-sur-le-Main. Juste devant le serveur, les schémas propres à chaque protocole sont identifiés et rejetés, paquet par paquet.

Deux caractéristiques sont décisives en cas de coup dur. La protection fonctionne en permanence et n'a pas besoin de réagir d'abord à une attaque : il n'y a donc pas de premières minutes pendant lesquelles le serveur est injoignable. Et aucun null-routing n'est utilisé : votre adresse IP reste dans le réseau, seuls les paquets malveillants sont rejetés. À l'inverse, quand un hébergeur retire du réseau l'adresse attaquée, le résultat est pour vous exactement le même qu'une attaque réussie. Le centre de données est maincubes à Francfort-sur-le-Main, en Allemagne ; l'exploitant est KernelHost GmbH, dont le siège se trouve à Vienne, en Autriche. La protection est comprise sans supplément dans chaque pack serveur, du serveur root KVM au serveur dédié.

Advanced DDoS Protection pour les projets attaqués en continu

Certains projets ne sont pas touchés de temps à autre, mais visés de façon ciblée et pendant des semaines. Pour ces cas, il existe l'Advanced DDoS Protection à partir de 50,00 € par mois, en PrePaid et sans durée minimale. La différence ne tient pas à une capacité supérieure, mais au contrôle :

• Une IP protégée dédiée issue du cœur de réseau de Francfort, vers laquelle votre serveur est basculé au sein de notre propre réseau. Aucune modification n'est nécessaire de votre côté.
• Des règles de protection par port et par protocole, que vous gérez vous-même dans l'espace client, sans ouvrir de ticket : le port de jeu reçoit d'autres règles que le port de requête.
• Les changements s'appliquent en temps réel, vous pouvez donc affiner les réglages en pleine attaque.
• Un profil de protection adapté au jeu concerné, auquel s'ajoutent des profils pour les applications maison ou modifiées sur n'importe quel port TCP ou UDP.

Les deux niveaux comparés

Pour la plupart des projets, la protection permanente incluse suffit, associée à une configuration serveur propre. L'Advanced DDoS Protection est la réponse au cas où quelqu'un en fait une affaire personnelle.

Erreurs fréquentes et solutions

« J'ai redémarré le serveur et ensuite tout a refonctionné un moment » : c'était l'attaque qui procède par vagues, pas le redémarrage. Les redémarrages effacent les compteurs dont vous auriez eu besoin pour le signalement.

« J'ai changé d'adresse IP et deux heures plus tard j'étais de nouveau hors ligne » : la nouvelle adresse est venue de la même source que l'ancienne, le plus souvent une entrée dans une liste de serveurs, un bot de statut ou un ancien enregistrement DNS.

« Je bloque les adresses suspectes et il en arrive toujours de nouvelles » : lors d'une attaque distribuée, elles se comptent par dizaines de milliers, et lors d'attaques par réflexion vous ne bloquez de toute façon que des tiers étrangers à l'affaire.

« Mes règles de pare-feu ne s'appliquent pas » : trois causes reviennent souvent. Les règles se trouvent derrière les chaînes UFW, elles avaient disparu après le dernier redémarrage, ou bien l'attaque est volumétrique et la règle travaille correctement sur une liaison déjà pleine.

« La charge était faible et pourtant le service avait disparu » : voilà une attaque typique menée sur le taux de paquets. La bande passante paraît inoffensive, le nombre de paquets non. Mesurez les paquets par seconde, pas les mégabits.

« Dans tcpdump, je ne vois rien d'anormal » : si le trafic est filtré en amont dans le réseau, il est normal que rien n'arrive sur le serveur. Si en revanche la liaison est saturée, il se peut que même la session SSH ne vous parvienne plus. Utilisez dans ce cas la console VNC dans l'espace client.

En résumé

Mesurez d'abord, modifiez seulement ensuite. Fermez tout ce dont le service n'a pas besoin, limitez le port de requête, les connexions et les taux de paquets par adresse source, et collectez des relevés tant que l'incident est en cours. Vous êtes ainsi armé contre tout ce qui se passe de bande passante notable. Au-delà, seul le réseau placé en amont du serveur décide.

Si votre projet tourne déjà chez KernelHost, le filtrage est actif sans que vous ayez quoi que ce soit à faire. Si vous constatez malgré tout des anomalies, ouvrez un ticket de support afin que les règles de filtrage soient affinées pour votre adresse IP. Pendant une attaque en cours, vous pouvez également nous joindre via le chat d'urgence WhatsApp au +43 650 8209883.