Comment le filtrage fonctionne

01. Routage et transit

L'infrastructure UnioHost est raccordée au réseau d'un opérateur partenaire, lui-même multi-homé sur 3 transitaires. Nous n'exploitons pas encore notre propre numéro d'AS — la démarche est en cours, et cette page sera mise à jour quand l'annonce sera effective.

En attendant, la propriété qui compte pour vous existe bien : plusieurs liens de transit distincts portent le trafic. Si l'un sature ou tombe, les autres prennent le relais, sans intervention et sans coupure.

C'est également ce qui rend le bouclier volumétrique possible : une attaque qui vise à saturer un lien se répartit sur plusieurs entrées au lieu de tout concentrer sur une seule.

Ce que nous opérons en propre, en revanche, commence à la machine : le tri XDP, les règles de pare-feu et les seuils par protocole décrits plus bas sont les nôtres, et c'est là que se joue l'essentiel du filtrage au quotidien.

02. Tri au niveau du pilote réseau

Sur chaque machine, un programme XDP s'exécute au plus près de la carte réseau, avant que le noyau n'alloue une structure de paquet ou n'ouvre une entrée de suivi de connexion. C'est ce qui permet de rejeter à très haut débit sans consommer de processeur.

Ce qui est écarté là : les combinaisons de drapeaux TCP impossibles, les paquets dont l'adresse source ne peut pas être légitime sur l'interface concernée, et les réponses UDP provenant de ports connus pour l'amplification — DNS, NTP, memcached, SSDP, CLDAP, chargen. Personne ne vous envoie spontanément une réponse DNS que vous n'avez pas demandée.

La table de suivi de connexion est la ressource qui sature en premier, bien avant le processeur. Tout ce qui est jeté avant elle est du répit gagné pour le trafic légitime.

03. Pare-feu à état

Ce qui survit au tri arrive sur un jeu de règles nftables. Le mécanisme central est le SYN proxy : sur les ports de service, la poignée de main TCP est menée jusqu'au bout par le pare-feu avant que le serveur ne réserve la moindre ressource. Une inondation de SYN se heurte donc au pare-feu, pas à l'application.

S'y ajoutent des compteurs par adresse : un plafond de connexions simultanées, une cadence maximale de nouvelles connexions, et une mise à l'écart temporaire quand ces seuils sont franchis. Temporaire, et pas définitive : les adresses résidentielles tournent, et un bannissement permanent finit toujours par bloquer un client légitime.

Le noyau lui-même est réglé pour la charge : dimensionnement de la table de suivi, délais d'attente raccourcis sur les connexions à moitié ouvertes, cookies SYN en filet de sécurité, refus des paquets à source invraisemblable.

04. Protections par protocole — sur demande

Ce qui suit n'est pas actif par défaut : c'est l'Anti-DDoS Jeu, une couche qu'on active gratuitement sur demande plutôt qu'automatiquement — la raison est expliquée juste après, à la section suivante.

Sur Minecraft, la cadence de connexion et les requêtes de statut sont plafonnées par adresse, et le serveur de jeu n'est joignable que par le proxy quand vous en utilisez un. Sur FiveM, le point de terminaison est masqué côté client et les connexions entrantes sont limitées.

Le moteur Source, qui fait tourner Garry's Mod, demande un traitement particulier : sa requête de statut A2S renvoie une réponse bien plus grosse que la question, ce qui permet de s'en servir comme amplificateur contre un tiers. Le débit de ces requêtes est donc plafonné, et le port de requête séparé du port de jeu. Pour Hytale, le principe est prêt à être appliqué dès l'ouverture des offres — il n'y a pas encore de trafic réel sur lequel le caler.

Côté web, en revanche, un pare-feu applicatif filtre les requêtes malveillantes, une limitation de débit s'applique par adresse, et les tentatives répétées d'authentification déclenchent un bannissement automatique — ça, c'est actif partout, sans demande à faire : le trafic web n'a pas le même profil de faux positif que les reconnexions en masse d'un serveur de jeu.

05. Pourquoi cette couche n’est pas automatique

Le redémarrage d'un serveur Minecraft peuplé — cent joueurs qui se reconnectent en quelques secondes depuis autant d'adresses — ressemble beaucoup à une attaque distribuée du point de vue d'un compteur de connexions par adresse. Une couche qui regarde ce genre de motif peut donc, par nature, se tromper sur du trafic parfaitement légitime.

C'est le compromis : plus une protection est précise sur le comportement d'un service, plus le risque de faux positif augmente si le seuil n'est pas calé sur votre trafic réel. Plutôt que de l'imposer partout et de risquer de bloquer vos propres joueurs sans prévenir, on la propose à la demande — gratuitement, sur Discord — pour les serveurs qui se font cibler.

Vous ne trouverez pas non plus sur cette page les valeurs chiffrées des seuils, une fois la couche activée. C'est délibéré : publier « nous rejetons au-delà de N connexions par seconde » revient à indiquer à quiconque le veut comment rester juste en dessous. Ces seuils ne sont d'ailleurs pas universels — ils se calent sur le trafic réel de chaque serveur.

Si vous administrez votre propre infrastructure et que la démarche vous intéresse, écrivez-nous : on parle volontiers méthode, à défaut de chiffres.

06. Détection et réaction

La détection repose sur l'analyse des flux réseau : au-delà d'un certain débit de paquets ou d'un certain volume vers une adresse, une alerte est levée et les règles se durcissent automatiquement sur la cible.

Cette alerte arrive dans un salon d'équipe, pas dans le Discord public — la cible d'une attaque en cours est une information qu'on ne diffuse pas. Les métriques suivies en continu incluent le taux de remplissage de la table de suivi, les paquets rejetés par règle, et le débit par interface.

Reste la part humaine. Une attaque applicative bien imitée passe les couches automatiques : c'est là qu'un signalement client accélère tout, et c'est pour ça que le Discord est le canal recommandé.