Comment fonctionne la protection DDoS, étape par étape

Ce qui survit à l'absorption, c'est du trafic qui veut au moins ouvrir une connexion. C'est le niveau des flots SYN : des quantités énormes de tentatives de connexion, souvent usurpées, conçues pour épuiser l'état de suivi de connexions plutôt que la bande passante. Le filtrage a lieu dans le noyau, sur notre propre réseau (AS216013), avant que quoi que ce soit n'atteigne l'espace utilisateur, avec des limites de débit par source et des budgets de connexion.

La couche 4 sait qu'une connexion est arrivée. Elle ne sait pas ce que la connexion a dit — elle ne peut pas distinguer un joueur d'un bot, car à ce niveau ni l'un ni l'autre n'a encore parlé. Tout ce qui passe est une connexion TCP d'apparence légitime, et à partir d'ici les questions cessent de porter sur le volume.

Maintenant le trafic est lu. Une grande partie de ce qui termine un handshake ne parle pas Minecraft du tout : scanners à l'échelle d'Internet, flots HTTP génériques visant tout ce qui répond, et déchets malformés espérant faire planter quelque chose. Rien de tout cela ne survit au contact d'un analyseur qui attend le protocole Minecraft et reçoit autre chose.

C'est la première couche avec laquelle un boîtier générique de "protection de jeu" peine, car elle exige d'implémenter réellement le protocole plutôt que de faire correspondre des formes de paquets. C'est aussi là que le volume chute suffisamment pour que le trafic restant soit véritablement dangereux — tout ce qui passe ce point parle la langue de votre jeu.

Tout ce qui bouge encore parle désormais couramment Minecraft : handshakes valides, pseudonymes plausibles, versions de protocole correctes, en provenance de milliers d'adresses résidentielles et de centres de données. C'est l'attaque qui tue réellement les serveurs Minecraft, et elle est invisible pour toutes les couches précédentes — chaque connexion est individuellement indiscernable d'un vrai joueur qui se connecte.

• Conscience du nom d'hôte — une connexion qui demande un nom d'hôte que vous ne servez pas n'est pas un joueur qui a fait une faute de frappe, et elle est rejetée avant que quoi que ce soit d'autre ne s'exécute.
• Limites de cadence de connexion avec auto-UAM — des budgets par IP et globaux qui se resserrent automatiquement quand la cadence combinée de pings et de connexions grimpe, si bien que la réponse s'adapte à l'attaque au lieu d'être configurée à l'avance.
• Score de risque — pays d'origine, ASN, plage de centre de données, comportement protocolaire et historique se combinent en un verdict avant que la connexion ne soit autorisée à continuer.
• Gestion des pings et du MOTD — les flots de statut sont servis depuis le cache de l'edge au lieu d'être transmis à votre serveur, qui devrait y répondre plusieurs milliers de fois par seconde.

Dans l'exemple, cette couche retire 96 % de ce qui l'atteint — 26 Gb/s de trafic qui serait autrement arrivé au backend sous forme de tentatives de connexion d'apparence réelle. C'est le même moteur décrit en détail dans comment Cryo atténue une attaque.

Un bot bien écrit étudie l'antibot. Il cadence ses connexions, utilise des noms plausibles, se connecte depuis des proxys résidentiels et ne fait rien qui soit scoré comme anormal — parce qu'il a été construit précisément pour cela. Le score seul ne peut pas l'attraper, et ce résidu est ce que les gens appellent les bots de contournement.

La dernière couche cesse donc de scorer et se met à demander. Les connexions suspectes sont déroutées vers CryoLimbo, un monde limbo léger, et doivent démontrer qu'elles sont un vrai client — des mouvements qui obéissent à la physique du jeu, des réponses correctes à l'état du serveur, un comportement qu'un bot headless doit véritablement implémenter plutôt que simplement imiter. Réussir coûte peu à un joueur et cher à un attaquant, et c'est tout le principe. Les vrais joueurs pris ici réussissent et poursuivent vers votre serveur, en général sans s'en apercevoir.

400 Mb/s de joueurs. Votre serveur voit les connexions qu'il aurait vues un jour calme, avec les vraies IP clientes livrées via le protocole PROXY, si bien que les bannissements, la détection d'alts et les plugins par IP se comportent exactement comme sur une connexion directe. Depuis l'intérieur du serveur, l'attaque n'est pas un problème plus petit — elle n'est pas visible du tout, raison pour laquelle le premier signe qu'en a un exploitant est généralement une alerte Discord plutôt qu'un pic de lag.

Les proportions méritent qu'on s'y arrête. La couche volumétrique a retiré 94 % du flot et les deux dernières couches en ont retiré moins de 0,4 % à elles deux — et pourtant ce sont ces deux-là qui décident si le serveur tient, car ce sont les seules capables de distinguer un bot d'un joueur. La capacité vous achète le droit d'avoir le problème intéressant. Elle ne le résout pas.

Chaque couche ci-dessus s'exécute avant votre matériel, et c'est là le point structurel, pas un détail d'implémentation. Un plugin peut faire une version du travail de la couche 5, et certains le font bien — mais il s'exécute après que la connexion a déjà été acceptée, allouée et analysée par votre machine, il se bat donc du mauvais côté du lien. Ce compromis est développé dans antibot en edge vs antibot en plugin, et c'est pourquoi l'arrangement sensé est un edge devant avec un plugin derrière comme seconde couche, et non l'un à la place de l'autre.