Survivre à une attaque DDoS sur votre VPS

Il y a deux moments où l'on découvre comment fonctionne réellement la mitigation DDoS. Le premier est calme, au moment de l'achat, en lisant une liste de fonctionnalités qui annonce « protection DDoS incluse » et en supposant tranquillement que cette phrase couvre tout. Le second survient à trois heures du matin, quand le site est en panne, que les graphiques affichent quelque chose d'incompréhensible, et que cette protection incluse ne fait — à juste titre, et par conception — strictement rien.

Les deux moments concernent le même produit et la même vérité : un hébergeur filtre les attaques qui arrivent sous forme de volume brut, parce qu'il possède le tuyau par lequel transitent ces paquets, et vous non. Il ne peut pas filtrer les attaques qui arrivent sous forme de requêtes d'apparence ordinaire, parce que, du point de vue du réseau, ce sont des requêtes d'apparence ordinaire. Cette ligne — entre l'inondation que votre hébergeur absorbe et celle à laquelle vous devez survivre vous-même — est tout le sujet de ce guide. Tout ce qui suit consiste à déterminer de quel côté de cette ligne vous vous trouvez, et que faire dans chaque cas.

Deux attaques différentes qui partagent un seul nom

« DDoS » est un seul mot qui recouvre deux problèmes n'ayant presque rien en commun, à part le résultat. Ils sont arrêtés à des endroits différents, par des personnes différentes, avec des outils différents, et les confondre est la raison pour laquelle tant d'efforts de mitigation atterrissent dans la mauvaise couche.

Relisez les deux dernières lignes, car c'est là que se trouve le point pratique. Si l'interface est saturée, rien de ce que vous taperez sur le serveur n'aidera : les paquets ont déjà consommé le port, et la seule partie capable de les rejeter est celle qui possède le routeur en amont. Si l'interface est calme mais que le site est toujours en panne, c'est l'inverse qui est vrai — votre hébergeur ne voit rien d'anormal parce que, à son niveau, rien n'est anormal, et la correction vous revient entièrement.

Ce qu'achète réellement la « protection DDoS incluse »

La protection au niveau réseau est réelle, précieuse, et presque toujours mal comprise. Quand un hébergeur annonce un filtrage L3/L4, cela signifie que son réseau surveille le trafic destiné à votre adresse, et que lorsqu'une inondation est détectée, ce trafic est dérouté vers des équipements de filtrage qui éliminent la portion malveillante et transmettent ce qui ressemble à du trafic légitime. Cela se produit sans ticket de support et généralement sans que vous remarquiez plus qu'un bref accroc.

Cette seule phrase fait beaucoup de travail, et il vaut la peine de détailler ce qu'elle couvre et ce qu'elle ne couvre pas :

• Elle couvre les attaques que vous ne pouvez pas affronter seul. Une inondation par amplification de 200 Gbps contre un serveur avec un port à 1 Gbps n'est pas un problème de configuration. C'est de l'arithmétique. Le filtrage en amont est la seule réponse qui existe.
• Elle est sans état vis-à-vis de votre application. Le filtre ne sait pas lesquelles de vos URL sont coûteuses, quels visiteurs sont connectés, ou qu'une requête vers votre point de terminaison de recherche coûte quatre cents fois plus qu'une requête vers votre logo.
• Elle réagit à un seuil, pas à votre souffrance. La détection se déclenche sur le volume de trafic. Une attaque qui ne franchit jamais ce seuil ne le déclenche jamais, quelle que soit l'ampleur avec laquelle elle a mis votre site à terre.
• Elle peut brièvement null-router l'adresse dans les cas extrêmes. Chaque réseau a un plafond. Si une attaque menace une infrastructure partagée, l'adresse peut être null-routée pendant un moment — c'est une pratique standard et universelle, qu'il vaut mieux connaître avant que cela n'arrive plutôt que pendant.

D'abord, déterminez s'il s'agit bien d'une attaque

Une part impressionnante des incidents pris pour des DDoS sont en réalité autre chose déguisé, et les corrections ne sont pas interchangeables. Avant de limiter quoi que ce soit en débit, passez deux minutes à écarter les imposteurs — une erreur de diagnostic ici vous coûte une heure et, parfois, vos vrais utilisateurs.

• Vous êtes devenu populaire. Un lien sur un grand agrégateur produit une forme de trafic qui ressemble exactement à une inondation de couche 7, sauf que les référents sont réels et que les requêtes portent sur des pages qu'un humain voudrait consulter. C'est un problème de capacité avec une cause heureuse ; le limiter en débit revient à se faire du tort à soi-même.
• Un robot d'indexation a perdu ses manières. Des scrapers agressifs et des robots d'entraînement d'IA peuvent trivialement dépasser les capacités d'un petit serveur. Le user-agent le trahit généralement, et la correction passe par robots.txt plus une limite ciblée, pas une limite générale.
• Vous avez cassé quelque chose. Un déploiement qui a désactivé la mise en cache, une tâche cron devenue incontrôlable, une base de données qui a perdu un index — tout cela se présente comme « une charge soudaine, sans cause évidente ». Si le moment correspond à un changement que vous avez fait, croyez ce changement.
• Votre propre supervision est l'inondation. Rare, gênant, et bien plus fréquent que quiconque ne l'admet. Une boucle de health-check qui retente sans backoff peut générer un débit de requêtes véritablement impressionnant.

La question qui permet de distinguer les deux est simple : ce trafic veut-il quelque chose ? Une charge réelle — même une charge réelle d'apparence hostile — a une forme. Elle frappe des pages qui existent, suit des liens, charge des ressources, et provient d'une répartition plausible de réseaux. Une attaque, en général, ne s'embête pas avec tout cela.

Lire l'attaque depuis le serveur lui-même

Vous n'avez pas besoin d'un tableau de bord pour classifier ce qui se passe. Quatre commandes, exécutées dans l'ordre, vous diront en moins d'une minute dans quelle couche vous vous battez — et le savoir détermine tout ce que vous ferez ensuite.

Le tuyau est-il plein ? Surveillez les compteurs d'interface. Si le débit est collé près du plafond du port, vous êtes dans une attaque volumétrique et votre travail consiste à ouvrir un ticket de support, pas à changer une configuration :

• vnstat -tr 10 — débit moyen sur dix secondes, la lecture honnête la plus rapide de la saturation.
• cat /proc/net/dev exécuté deux fois à une seconde d'intervalle — deltas de paquets et d'octets par interface, sans outillage particulier.

S'agit-il d'une inondation SYN ? Les connexions semi-ouvertes s'accumulent en SYN-RECV. Une poignée est normale ; des milliers ne le sont pas :

• ss -s — la ligne de résumé, le nombre de connexions par état en un coup d'œil.
• ss -tn state syn-recv | wc -l — le chiffre précis qui compte.

S'agit-il de la couche 7 ? Si la bande passante est banale mais que tout est lent, comptez les requêtes par client dans votre journal d'accès. Une seule adresse avec des dizaines de milliers de coups est un amateur ; cent mille adresses avec trois coups chacune, c'est du sérieux :

• tail -n 100000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30
• Remplacez $1 par $7 pour classer les chemins demandés à la place. Si un point de terminaison coûteux domine, vous avez trouvé la cible et la moitié de la solution.

Qu'est-ce qui est réellement épuisé ? Le load average ne vous dit pas grand-chose à lui seul. Cherchez le plafond précis que vous avez atteint : processus PHP-FPM tous occupés, connexions à la base de données à leur limite, descripteurs de fichiers épuisés, ou workers bloqués en état D en attente du disque. C'est ce plafond — pas le trafic — qui a mis le site à terre, et le relever est souvent plus rapide que de filtrer quoi que ce soit.

Les dix premières minutes

Sous pression, les gens saisissent le plus gros levier disponible, et c'est généralement le mauvais. Voici l'ordre qui limite les dégâts, à peu près du plus rapide et plus sûr au reste :

1. Classifiez avant d'agir. Interface saturée signifie volumétrique ; interface calme avec des workers occupés signifie couche 7. Trente secondes passées ici vous évitent de corriger la mauvaise couche pendant une heure.
2. Si c'est volumétrique, ouvrez immédiatement un ticket en incluant l'adresse de destination, l'heure de début, et vos compteurs d'interface. Puis arrêtez de taper quoi que ce soit sur le serveur — vous ne pouvez pas corriger cela depuis l'intérieur.
3. Si c'est la couche 7, mettez en cache d'abord. Activer une mise en cache agressive de pages entières pour les visiteurs anonymes est le moyen le plus rapide de transformer une panne en simple haussement d'épaules, et c'est la seule mesure qui aide aussi contre du trafic réel.
4. Puis limitez le débit — d'abord le point de terminaison ciblé, tout le reste ensuite. Commencez prudemment. Une limite qui met hors service vos propres utilisateurs est une continuation auto-infligée de l'attaque.
5. Ne bloquez que ce qui est sans ambiguïté. Une douzaine d'adresses avec cent mille requêtes chacune, un user-agent manifestement faux, un pays où vous n'avez aucun utilisateur. Résistez à l'envie d'écrire des règles élaborées sous le feu ; vous ne vous en souviendrez plus le mois prochain.
6. Délestez la charge délibérément si nécessaire. Servir une page statique « en maintenance » aux visiteurs non authentifiés maintient la machine en vie, maintient votre API disponible, et vous achète du temps de réflexion. Décider quoi sacrifier vaut mieux que de le laisser décider à votre place.
7. Notez ce que vous avez fait. Chaque règle temporaire que vous ajoutez est un piège que vous laissez à votre futur vous. Les règles qui ont aidé deviennent permanentes ; le reste ressort demain.

Des limites de débit qui tiennent, et l'erreur que tout le monde commet

La limitation de débit est l'instrument principal pour la couche 7, et nginx s'en tire bien avec deux directives qui résolvent deux problèmes véritablement différents. limit_req plafonne le débit des requêtes — la fréquence à laquelle un client peut demander. limit_conn plafonne la concurrence — le nombre de connexions qu'un client peut maintenir ouvertes à la fois. Les inondations demandent la première ; les attaques Slowloris, qui maintiennent des milliers de connexions quasi inactives pour épuiser votre pool de workers, demandent la seconde. N'en déployer qu'une seule vous couvre contre la moitié du problème.

Trois détails séparent une limite qui fonctionne d'une limite décorative :

• Utilisez un burst, et utilisez nodelay. Les vrais navigateurs fonctionnent par rafales — une seule vue de page déclenche une douzaine de requêtes de ressources quasi simultanées. Une limite sans marge étrangle les visiteurs authentiques pendant qu'un attaquant qui se cale juste sous le seuil passe sans encombre.
• Limitez séparément les points de terminaison coûteux. Votre page de recherche, votre formulaire de connexion, la réinitialisation de mot de passe, et tout point de terminaison qui écrit dans la base de données méritent un budget bien plus serré que vos ressources statiques. Les attaquants les trouvent sans effort, parce que ce sont ceux qui font mal.
• Renvoyez 429, pas 503. Le code de statut signale aux clients bien élevés et aux moteurs de recherche qu'il s'agit d'une limitation et non d'une panne — et cela évite qu'un mauvais après-midi ne se transforme en problème de classement.

La mise en cache est la mitigation la moins chère que vous déploierez jamais

Une limite de débit rejette du travail. Un cache fait que le travail n'existe pas. Pour tout ce qu'un visiteur anonyme voit, la mise en cache de pages entières change l'économie de toute l'attaque : une requête qui aurait coûté un aller-retour en base de données, un rendu de template et un worker PHP devient une lecture de fichier mesurée en microsecondes. Le même serveur qui s'effondrait à quatre cents requêtes dynamiques par seconde en servira des dizaines de milliers en cache sans même le remarquer.

Ce qui compte quand vous l'activez dans l'urgence :

• Ne mettez en cache que pour les visiteurs anonymes. Contournez le cache sur un cookie de session. Servir la page d'un utilisateur connecté à un autre est un incident bien pire que la panne que vous étiez en train de corriger.
• Servez du contenu périmé, délibérément. Le proxy_cache_use_stale de nginx associé à updating error timeout fait que, quand votre backend peine, les visiteurs reçoivent une page légèrement ancienne plutôt qu'une erreur. Pendant une attaque, c'est la différence entre un site qui a l'air d'aller bien et un site qui a l'air mort.
• Fusionnez les miss de cache identiques. proxy_cache_lock garantit que mille requêtes simultanées pour la même page non mise en cache produisent une seule requête vers le backend, pas mille. Sans cela, une attaque de contournement du cache traverse le cache directement et atterrit sur votre base de données à pleine puissance.
• Neutralisez les chaînes de requête qui cassent le cache. L'astuce classique consiste à ajouter ? suivi d'une valeur aléatoire pour que chaque requête soit une clé unique et rate le cache indéfiniment. Normalisez votre clé de cache pour ignorer les paramètres de requête que votre application n'utilise pas réellement.

Il y a ici une asymétrie agréable qu'il vaut la peine d'intérioriser : chaque heure passée sur la mise en cache rend aussi le site plus rapide les bons jours, moins coûteux à faire tourner, et meilleur pour survivre au succès. Presque aucune autre ligne de défense ne verse un dividende quand tout va bien.

Les plafonds qui décident si le serveur s'effondre

La plupart des serveurs ne meurent pas parce qu'ils manquent de CPU. Ils meurent parce qu'ils heurtent un plafond invisible que personne n'a fixé délibérément — une valeur par défaut vieille de dix ans qui avait du sens sur du matériel que plus personne n'utilise. Sous attaque, voici ce qui casse réellement en premier :

• Les workers applicatifs. Le pm.max_children de PHP-FPM, votre nombre de workers Python, la taille de votre cluster Node. C'est la vraie limite de concurrence de votre site. Quand ils sont tous occupés, chaque visiteur supplémentaire fait la queue, et le site est en panne, peu importe à quel point le CPU semble inactif. Ne l'augmentez que dans la limite que la mémoire permet — le swap est pire que la file d'attente.
• La file d'acceptation. net.core.somaxconn et votre backlog d'écoute décident combien de connexions peuvent attendre d'être acceptées. Un petit backlog transforme une rafale survivable en connexions refusées.
• Les cookies SYN. net.ipv4.tcp_syncookies permet au noyau de répondre à une inondation SYN sans allouer d'état pour des connexions qui ne s'achèveront jamais. Les noyaux modernes l'activent par défaut ; vérifiez-le plutôt que de le supposer, car cela ne coûte rien et vous épargne l'inondation la plus courante qui soit.
• Les descripteurs de fichiers. Chaque connexion est un descripteur. La limite nofile par défaut est fréquemment inférieure au nombre de connexions que vous essayez de servir, et le mode de défaillance — des accepts qui échouent alors que tout semble sain — est authentiquement déroutant à trois heures du matin.
• Les connexions à la base de données. Augmenter votre nombre de workers sans augmenter le pool de connexions ne fait que déplacer la file d'attente vers un endroit plus difficile à observer. Ces deux chiffres doivent être ajustés ensemble.

Réglez tout cela un jour calme, pas pendant un incident. L'intérêt de les connaître, c'est que lorsque le site s'effondre, vous pouvez nommer le plafond qu'il a heurté au lieu de deviner — et un plafond nommé est un plafond que l'on corrige.

Mettre quelque chose devant l'origine

Tout ce qui précède se passe sur le serveur. L'étape suivante consiste à décider si le serveur doit être la chose qui reçoit le trafic, tout simplement. Il existe trois options honnêtes, et la bonne réponse dépend bien plus de ce que vous hébergez que de ce que vous pouvez vous permettre.

Le nœud frontal auto-hébergé mérite plus d'attention qu'il n'en reçoit habituellement, en particulier pour quiconque a choisi l'hébergement offshore pour des raisons qu'un grand CDN pourrait ne pas partager. Le schéma n'a rien de spectaculaire : des nœuds proxy bon marché devant, une origine protégée par pare-feu qui n'accepte les connexions que de ces nœuds, un DNS qui pointe vers les façades. Si une façade est attaquée, vous la remplacez par une nouvelle adresse en quelques minutes et l'origine ne s'en aperçoit jamais. La version complète de cette architecture — y compris les six façons dont une adresse d'origine fuit quand même — fait l'objet de notre guide sur la dissimulation de l'IP de votre serveur d'origine.

Une origine cachée vaut mieux que n'importe quel filtre

Cela vaut la peine de le dire sans détour, car cela inverse la priorité habituelle : la mitigation DDoS la moins chère à votre disposition est une adresse que l'attaquant ne possède pas. Le filtrage, c'est ce que vous faites quand cela a déjà échoué.

Cela compte plus qu'il n'y paraît, car les adresses d'origine fuient constamment et discrètement. Les enregistrements DNS historiques d'avant la mise en place d'un proxy survivent au changement pendant des années. Le courrier envoyé directement depuis l'application porte l'adresse dans ses en-têtes. Un certificat TLS émis sur l'adresse brute est publié en permanence dans les journaux Certificate Transparency. Une page d'erreur, une redirection, ou un sous-domaine obscur qui n'a jamais été proxifié, tout cela la trahit. Si vous avez mis un CDN devant un serveur qui était auparavant exposé, partez du principe que l'ancienne adresse est connue tant que vous ne l'avez pas changée.

Choisir le matériel et l'emplacement pour qu'une attaque reste un non-événement

Une partie de tout cela se décide avant même qu'une attaque n'ait lieu, au moment où vous choisissez une offre. Trois propriétés comptent bien plus que ne le suggère la fiche technique :

• La bande passante illimitée. Sur une offre avec quota, une attaque n'est pas seulement une panne — c'est une facture. Un trafic que vous n'avez jamais demandé et que vous ne pouviez pas refuser compte quand même dans votre forfait. Le transfert illimité convertit un risque financier en un risque purement technique, ce qui est une bien meilleure catégorie de problème.
• Que le port vous appartienne ou non. Sur un hôte virtualisé partagé, un voisin sous attaque peut vous dégrader, et votre propre plafond de protection est partagé. Le matériel dédié avec son propre port supprime les deux effets. Pour un projet qui s'attend à une attention hostile, c'est la raison la plus nette de monter en gamme depuis un VPS — plus que les cœurs ou la RAM.
• L'emplacement du réseau. Un réseau européen bien connecté avec une réelle capacité de transit absorbe une inondation qu'un réseau avec un peering médiocre n'absorbera pas, et la juridiction que vous avez choisie pour des raisons légales a aussi ses propres caractéristiques réseau. Cela vaut la peine de vérifier les deux en choisissant parmi les localisations disponibles.

Il existe aussi un argument d'échelle qui favorise discrètement la simplicité. Un site statique derrière un cache sur un serveur modeste est extraordinairement difficile à mettre hors service ; le même contenu sur un CMS lourd avec un point de terminaison de recherche non mis en cache peut être cassé par une seule personne déterminée avec un script. Réduire ce qui est dynamique est une mitigation, et elle est gratuite. Si votre projet vit véritablement sous charge soutenue, nos notes sur l'hébergement à fort trafic couvrent le dimensionnement de la même question.

Cinq choses à ne pas faire

Les modes d'échec ici sont assez constants pour être listés, et chacun a coûté un week-end à quelqu'un :

• Ne vous null-routez pas vous-même. Faire du blackholing sur votre propre adresse termine l'attaque de la façon la plus littérale possible — plus personne ne peut vous atteindre, y compris vos utilisateurs. C'est un outil de dernier recours pour votre hébergeur, pas une action que vous prenez volontairement.
• Ne considérez pas fail2ban comme une protection DDoS. C'est un bon outil contre les tentatives de force brute depuis un petit nombre d'adresses. Contre une inondation distribuée, il réagit en quelques minutes à quelque chose qui arrive en quelques secondes, et une règle qui bannit des milliers d'adresses peut coûter plus cher en traitement par le pare-feu que ce que l'attaque vous a coûté.
• Ne payez pas de rançon. L'écrasante majorité des e-mails d'extorsion menaçant d'une attaque dévastatrice viennent de gens sans aucune capacité qui envoient des milliers de messages identiques. La petite minorité qui peut mettre sa menace à exécution reviendra, parce que vous avez prouvé que vous payez.
• Ne ripostez pas. Au-delà du fait que c'est illégal à peu près partout, les sources sont des tiers compromis. Vous attaqueriez des victimes, et vous le feriez depuis une adresse qui est sans ambiguïté la vôtre.
• Ne migrez pas dans la panique. Changer d'hébergeur en pleine attaque signifie que la nouvelle adresse est publique en quelques minutes et que vous n'avez aucune configuration fonctionnelle. Stabilisez d'abord, déménagez délibérément ensuite — et si vous déménagez, notre guide sur la migration sans interruption de service existe précisément pour que le déménagement ne soit pas un second incident.

La version courte

Débarrassé du raisonnement, le modèle de fonctionnement tient en huit lignes :

1. Classifiez d'abord. Interface saturée signifie volumétrique et relève de votre hébergeur. Interface calme avec des workers épuisés signifie couche 7 et relève de vous.
2. Pour le volumétrique, ouvrez un ticket avec l'adresse, l'horodatage et vos compteurs — puis arrêtez de toucher au serveur.
3. Mettez en cache agressivement pour les visiteurs anonymes, servez du contenu périmé sous stress, et fusionnez les miss identiques. C'est le changement au plus fort effet de levier que vous puissiez faire.
4. Limitez le débit à la fois par fréquence de requêtes et par concurrence, le plus serré sur les points de terminaison qui coûtent le plus, et renvoyez 429.
5. Corrigez votre configuration de véritable IP avant tout le reste, sinon chaque limite par client derrière un proxy est soit inutile, soit catastrophique.
6. Connaissez vos plafonds — workers, backlog, descripteurs, connexions à la base de données — et relevez-les délibérément un jour calme.
7. Gardez l'adresse d'origine secrète et protégée par pare-feu, réservée à vos nœuds frontaux. Cela vaut plus que tous les filtres combinés.
8. Achetez de la bande passante illimitée pour qu'un trafic que vous n'avez pas demandé ne soit jamais aussi une facture.

Rien de tout cela ne vous rend immunisé, et quiconque vend l'immunité vend autre chose. Ce que cela fait, c'est vous faire sortir de la population qui se fait mettre hors ligne par un adolescent qui s'ennuie, pour entrer dans celle qui exige de véritables ressources et une véritable intention de nuire — ce qui, pour l'écrasante majorité des projets, est indiscernable de la sécurité. Le reste, c'est le même travail sans éclat qui rend un serveur bon en tout : durci dès le premier jour, restaurable le pire jour, et hébergé quelque part où votre trafic ne regarde que vous.