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.

En amont de nos machines, le trafic traverse en permanence une plateforme de mitigation dont la capacité est garantie à 1 Tbps et 1 Gpps. L'inspection est continue, pas déclenchée en urgence : le trafic ne change pas de route quand une attaque commence, et une attaque détectée est mitigée en moins de dix secondes en règle générale.

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. Filtres par protocole de jeu

Des filtres dédiés valident le trafic selon le protocole du jeu, sur de larges plages de ports : Minecraft Java 24565-26565, Minecraft Bedrock 18132-20132, FiveM 29120-31120 et Source/A2S 26015-28015. Un serveur dont le port tombe dans une de ces plages en bénéficie automatiquement.

Sur Minecraft, la cadence de connexion et les requêtes de statut sont plafonnées par adresse. Sur FiveM, le trafic qui ne ressemble pas au protocole du jeu est écarté avant d'atteindre le serveur.

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 un autre jeu, demandez-nous sur Discord : un filtre se cale sur le trafic réel.

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 — les règles du pare-feu applicatif couvrent les injections SQL, les XSS, l'exécution de code à distance, l'inclusion de fichiers et les failles connues (CVE), avec une mise à jour quotidienne.

05. Le mode strict 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.

D'où le mode strict : en temps normal, les filtres restent dans un réglage tolérant. Quand une attaque est détectée sur une adresse, ils se durcissent automatiquement — seuils resserrés, validation plus stricte — puis reviennent au réglage normal une fois la menace passée. Vos joueurs ne paient pas en permanence le prix d'une protection maximale.

Vous ne trouverez pas sur cette page les valeurs chiffrées des seuils. 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é.