Protéger un serveur Arma 3 des attaques DDoS

Qui veut protéger un serveur Arma 3 des attaques DDoS a affaire à exactement cinq ports UDP : 2302 à 2306. Un serveur dédié qui décroche le soir, en pleine opération et pour tous les joueurs à la fois, a rarement un problème de matériel. La plupart du temps, une attaque vise précisément ce bloc de ports, et elle survient au moment où la liste des serveurs affiche le plus grand nombre de joueurs. Cet article montre d'abord ce que vous pouvez sécuriser vous-même sans frais supplémentaires, ensuite où ces mesures s'arrêtent techniquement, et pour finir ce qui doit se passer dans le réseau, en amont du serveur.

Toutes les indications se rapportent à un serveur Arma 3 dédié (application SteamCMD 233780) sous Debian 12, Debian 13, Ubuntu 22.04 LTS ou Ubuntu 24.04 LTS. Les commandes sont écrites pour root ; en tant qu'utilisateur normal, faites-les précéder de sudo. Si l'attaque est en cours : ne modifiez rien à la configuration maintenant et ne redémarrez pas le serveur, sauvegardez d'abord les mesures de la section « Journaliser ». Après l'attaque, elles auront disparu.

Pourquoi les serveurs Arma 3 sont attaqués et quand une protection DDoS devient nécessaire

Arma 3 réunit plusieurs caractéristiques qui font d'un serveur une cible commode. D'abord, le serveur publie son adresse de lui-même : il s'enregistre auprès du serveur maître Steam par le port 2304 UDP et répond sur le port 2303 UDP aux requêtes avec le nom, la carte, le nombre de joueurs et la liste des mods. Sans ces deux ports, personne ne vous trouve ; avec eux, votre adresse IP figure dans chaque navigateur de serveurs et sur chaque page de statut qui interroge ce navigateur.

Ensuite, les joueurs se connectent à des horaires fixes. Les projets de jeu de rôle Life sur Altis et Tanoa, Exile, Antistasi et King of the Hill se remplissent le soir et le week-end, une panne à 20 heures est donc visible au maximum. Enfin, il existe une concurrence entre projets, des joueurs bannis et des conflits internes, et une attaque ne coûte à celui qui la lance ni compétence particulière ni argent notable.

S'y ajoute le point technique décisif : Arma 3 fonctionne entièrement en UDP, le jeu n'a besoin d'aucun port TCP pour son exploitation. UDP ne prévoit aucun établissement de connexion que l'on pourrait exiger, et les adresses d'expéditeur se falsifient sans peine. Un attaquant n'a donc besoin ni de rejoindre votre serveur ni de s'adresser correctement à lui pour produire de la charge. À cela s'ajoute que la boucle de simulation d'un serveur Arma 3 repose pour l'essentiel sur un seul cœur de calcul : celui qui envoie assez de paquets consomme le temps de calcul de ce cœur unique, quel que soit le nombre de cœurs dont dispose la machine par ailleurs. Ce qu'est précisément une attaque DDoS, l'article Qu'est-ce qu'une attaque DDoS ? l'explique en détail.

Les ports dont il est réellement question

Par défaut, un serveur Arma 3 occupe le bloc 2302 à 2306 UDP. Le paramètre de démarrage -port=2302 ne fixe que le premier port, les quatre autres en découlent de façon fixe, à savoir le port de jeu plus 1 jusqu'à plus 4. Qui exploite plusieurs instances sur la même machine laisse donc au moins 100 ports d'écart (2302, 2402, 2502), faute de quoi les instances se prennent mutuellement les ports suivants.

Sur ces huit lignes, trois exactement ont leur place sur l'Internet ouvert : 2302, 2303 et 2304 UDP. Tout le reste relève de l'administration, et les ports d'administration ouverts constituent l'erreur évitable la plus fréquente sur les serveurs Arma 3.

Ce que vous pouvez faire vous-même avant de dépenser de l'argent

Cette section est la plus longue, et c'est volontaire. Un serveur Arma 3 proprement configuré encaisse par ses propres moyens les attaques petites et moyennes, quel que soit l'hébergeur chez qui il se trouve.

1. État des lieux : qu'est-ce qui écoute sur le serveur ?

Avant d'écrire la moindre règle, regardez ce que votre serveur propose vers l'extérieur. Ne devinez pas, vérifiez :

ss -lntup

La colonne qui compte est celle de l'adresse locale. 0.0.0.0:2302 signifie « joignable depuis tout Internet », 127.0.0.1:3306 signifie « en local uniquement » et ne demande aucune règle de pare-feu. À côté du jeu, on trouve régulièrement sur un serveur Life MariaDB, un serveur web pour la page de la faction, un service TeamSpeak ou vocal et un panel oublié. Le point de vue de l'attaquant, lui, s'obtient par un scan de ports depuis l'extérieur :

nmap -Pn -sU -p 2300-2320 ADRESSE.IP.DE.VOTRE.SERVEUR
nmap -Pn -p- --min-rate 1000 ADRESSE.IP.DE.VOTRE.SERVEUR

La première commande montre le bloc UDP du jeu, la seconde tout ce qui est ouvert en TCP. Pour son exploitation, un serveur Arma 3 n'a besoin d'aucun port TCP ouvert.

2. Ne laisser ouverts que les ports dont Arma 3 a réellement besoin

Trois ports UDP vers l'extérieur suffisent, tout le reste est restreint. Avec UFW, cela donne ceci, et exactement dans cet ordre, pour ne pas vous bloquer vous-même :

ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'SSH'
ufw allow 2302:2304/udp comment 'Arma 3 jeu, requete Steam, master Steam'
ufw allow from 203.0.113.10 to any port 2306 proto udp comment 'BattlEye RCon'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Remplacez 203.0.113.10 par votre propre adresse. Le port 2305 reste fermé, parce que Bohemia le classe comme réservé et actuellement inutilisé. La ligne ufw default allow outgoing est importante : BattlEye établit depuis le serveur une connexion vers arma31.battleye.com et a besoin pour cela des ports sortants 2344 en TCP et UDP ainsi que 2345 en TCP. Qui bloque le trafic sortant en bloc bloque son propre anti-triche. Après la modification, vérifiez par une connexion réelle que BattlEye laisse toujours passer vos joueurs. Le guide complet, voie de secours comprise, se trouve dans Configurer le pare-feu UFW sans se bloquer l'accès SSH.

La base de données n'a en aucun cas sa place sur le réseau ouvert. Altis Life et les autres frameworks Life communiquent avec une base MySQL via l'extension extDB3, et les identifiants y figurent en clair dans @extDB3/extdb3-conf.ini. Vérifiez dans /etc/mysql/mariadb.conf.d/50-server.cnf que la ligne suivante est bien présente :

bind-address = 127.0.0.1

3. Désamorcer le port de requête Steam sans disparaître du navigateur de serveurs

Le port 2303 UDP est le point le plus sensible d'un serveur Arma 3 public. Il répond aux requêtes A2S, c'est-à-dire à la requête standard du navigateur de serveurs Steam : A2S_INFO livre le nom, la carte et le nombre de joueurs, A2S_PLAYERS la liste des joueurs, A2S_RULES la liste des mods et des signatures. Une requête est un petit paquet UDP, la réponse en est un multiple. L'US-CERT attribue au protocole Steam, dans son alerte TA14-017A, un facteur d'amplification de bande passante de 5,5, et chez Arma 3 la réponse est particulièrement volumineuse parce que la liste complète des mods y est jointe.

Deux conséquences en découlent. Premièrement, votre serveur peut être détourné en amplificateur contre des tiers lorsqu'un attaquant envoie des requêtes avec une adresse d'expéditeur falsifiée. Deuxièmement, et c'est plus important pour vous, chaque requête coûte du temps de calcul sur le cœur unique qui porte la simulation. Bohemia suit un ticket à ce sujet depuis 2015 (T83469) : des paquets UDP falsifiés envoyés au port de jeu ou au port de requête Steam poussaient le CPU à 100 pour cent et gelaient le serveur, et 4 Mbit/s suffisaient déjà pour une attaque réussie par le port de requête. C'est la raison pour laquelle, chez Arma 3, le taux de paquets est plus dangereux que la bande passante.

Le premier levier est la taille de la réponse. La directive steamProtocolMaxDataSize dans server.cfg détermine combien d'octets le serveur a le droit de placer dans sa réponse de requête. Les exploitants de grandes listes de mods la montent à 2048 ou davantage, faute de quoi l'avertissement « Query data overflow, Mods/Signatures will not be correctly received by clients » apparaît dans le journal. Or chaque augmentation agrandit précisément la réponse qu'un attaquant amplifie. Réglez donc la valeur aussi bas que votre liste de mods le permet encore, et sortez les mods inutilisés de la commande de démarrage :

steamProtocolMaxDataSize = 2048;

Le second levier est une limitation de débit par adresse source, qui ne touche que le port de requête. Ne bloquez pas 2303 UDP en bloc : sans réponse de requête, votre serveur disparaît du navigateur de serveurs et de chaque page de statut, et les nouveaux joueurs ne le trouvent plus. Un navigateur de serveurs légitime interroge quelques fois par minute, pas des centaines de fois par seconde.

4. Retirer BattlEye RCon du réseau ouvert

BattlEye est l'anti-triche d'Arma 3 et s'active dans server.cfg avec BattlEye = 1;. La télécommande associée, BattlEye RCon, est un protocole UDP distinct et se configure dans BattlEye/beserver_x64.cfg (le fichier portant le suffixe _x64 vaut pour arma3server_x64, le serveur courant aujourd'hui) :

RConPassword IhrAlphanumerischesPasswort
RConPort 2306
RConIP 127.0.0.1
MaxPing 350
RestrictRCon 0

Trois points sont décisifs. Le mot de passe RCon doit être purement alphanumérique : les caractères spéciaux déroutent silencieusement l'analyseur de protocole de BattlEye, et un accès RCon qui échoue en silence est un accès dont vous ne disposez pas le jour venu. RConIP détermine sur quelle adresse RCon écoute : si 127.0.0.1 y figure, l'interface n'est joignable qu'en local, et votre outil RCon l'atteint par une redirection SSH. Et RConPort doit se situer au-dessus du bloc de jeu, l'usage étant le port de jeu plus 4, donc 2306. Qui doit ouvrir RCon vers l'extérieur n'autorise le port que pour l'adresse fixe de son équipe d'administration.

Une chose doit être claire : BattlEye est un anti-triche, pas une protection DDoS. Il vérifie les joueurs qui sont connectés. Un attaquant qui inonde votre serveur ne cherche pas du tout à le rejoindre.

5. Attacher fermement le Headless Client

Un Headless Client est une seconde instance d'Arma 3 sans affichage graphique, qui se connecte au serveur comme un joueur et lui retire le calcul de l'IA. Sur les grandes missions, c'est le gain de performance le plus important qui soit, car l'IA repose sinon sur le même cœur que la simulation. Il s'autorise dans server.cfg :

headlessClients[] = {"127.0.0.1"};
localClient[] = {"127.0.0.1"};

Sans ces entrées, le serveur n'accepte aucune connexion de Headless Client, c'est la bonne nouvelle. La mauvaise : localClient[] accorde à l'adresse inscrite une bande passante illimitée et pratiquement aucun contrôle de latence. N'y inscrivez que 127.0.0.1 ou l'adresse fixe de votre propre machine Headless Client, jamais une plage d'adresses entière. Le client se lance avec -client -connect=127.0.0.1 -port=2302 -password=..., et il occupe un emplacement pris sur maxPlayers. Prévoyez-le donc, sinon vos joueurs se retrouveront devant un serveur plein.

6. Durcir la connexion, les signatures et les votes

Ces réglages ne protègent pas votre raccordement, mais ils ferment tout ce qui emprunte le chemin de connexion normal : clients manipulés, exécution de scripts en jeu et abus de vote. Les lignes suivantes ont leur place dans chaque server.cfg d'un serveur public :

verifySignatures = 2;
BattlEye = 1;
kickDuplicate = 1;
allowedFilePatching = 0;
maxPlayers = 64;
disconnectTimeout = 30;
maxPing = 200;
maxDesync = 150;
maxPacketLoss = 50;
kickClientsOnSlowNetwork[] = {1, 1, 1, 1};
voteThreshold = 1.5;
voteMissionPlayers = 100;
onUnsignedData = "kick (_this select 0)";
onHackedData = "kick (_this select 0)";

verifySignatures = 2 impose la vérification de signature version 2 pour tous les addons et constitue l'exigence minimale de tout serveur public avec des mods. allowedFilePatching = 0 refuse la connexion aux clients lancés avec -filePatching (la valeur 1 ne l'autorise qu'aux Headless Clients, la valeur 2 à tout le monde). kickDuplicate = 1 expulse la seconde connexion portant le même identifiant. kickClientsOnSlowNetwork[] décide entrée par entrée si les quatre seuils issus de maxPing, maxPacketLoss, maxDesync et disconnectTimeout sont seulement journalisés (0) ou appliqués (1). disconnectTimeout accepte des valeurs de 5 à 90 secondes. Un voteThreshold supérieur à 1 rend les votes inatteignables et ferme ainsi la voie la plus prisée pour perturber un serveur sans un seul paquet d'attaque : le changement de mission par vote.

7. Limiter le taux de paquets et de connexions par adresse source

Contre les petites attaques et les bots mal écrits, un plafond par adresse source fait le travail. Comme Arma 3 fonctionne en UDP pur, on travaille avec hashlimit, et le port de requête reçoit une limite nettement plus serrée que le port de jeu :

iptables -I INPUT -p udp --dport 2303 -m hashlimit --hashlimit-name a3_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 2302 -m hashlimit --hashlimit-name a3_game --hashlimit-mode srcip --hashlimit-above 900/sec --hashlimit-burst 1200 -j DROP
iptables -I INPUT -p udp --dport 2302:2306 -m length --length 0:27 -j DROP

La première règle rejette les requêtes venant de la même source à partir de plus de dix par seconde en continu, la deuxième les paquets de jeu à partir de plus de 900 par seconde en continu, la troisième les paquets UDP sans charge utile exploitable. Ces trois chiffres sont des valeurs de départ, pas des vérités : un serveur Life plein avec 80 joueurs produit nettement plus de paquets qu'une partie d'Antistasi à six, et un réglage trop serré éjecte vos propres joueurs. Mesurez d'abord pendant une semaine en fonctionnement normal.

Deux remarques à ce sujet. Les règles iptables seules disparaissent après un redémarrage ; sous Debian et Ubuntu, on les enregistre ainsi :

apt-get install -y iptables-persistent
netfilter-persistent save

Sous UFW, de telles règles ont leur place dans /etc/ufw/before.rules, faute de quoi elles disparaissent au prochain ufw reload. Un goulot d'étranglement souvent négligé est par ailleurs le suivi de connexions du noyau : UDP y crée lui aussi des entrées, et un flood de requêtes provenant de nombreuses adresses falsifiées remplit la table en quelques secondes. Lorsqu'elle est saturée, le serveur rejette aussi les paquets légitimes, et le journal indique « nf_conntrack: table full ». La valeur actuelle et la limite s'affichent avec :

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

8. basic.cfg : bande passante, tailles de paquets et fichiers additionnels

Le second fichier de configuration d'un serveur Arma 3 s'appelle basic.cfg et se charge avec -cfg=, tandis que -config= charge server.cfg. Il pilote le comportement réseau et contient exactement une valeur qui touche directement à la sécurité :

MaxMsgSend = 1024;
MaxSizeGuaranteed = 512;
MaxSizeNonguaranteed = 256;
MinBandwidth = 15000000;
MaxBandwidth = 100000000;
MinErrorToSend = 0.001;
MinErrorToSendNear = 0.01;
MaxCustomFileSize = 0;
class sockets { maxPacketSize = 1400; };

MaxCustomFileSize est la taille maximale, en octets, des fichiers de visage et de son que les joueurs apportent et que le serveur distribue à tous les autres. La valeur 0 désactive cette distribution. Cela supprime une voie par laquelle un seul client occupe la bande passante de votre serveur sans la moindre infrastructure d'attaque. MinBandwidth est la bande passante que le serveur considère comme acquise, l'ordre de grandeur étant le nombre de joueurs multiplié par 256 kbit/s, soit environ 16 Mbit/s pour 64 emplacements. Des valeurs trop optimistes augmentent la charge et la désynchronisation, parce que le serveur produit des messages qu'il rejette ensuite. MaxMsgSend limite les paquets par pas de simulation et constitue le premier levier contre la désynchronisation, la valeur par défaut de 128 étant trop basse pour les serveurs actuels.

9. Journaliser, pour ne pas avoir à deviner pendant une attaque

L'étape la plus importante est celle que presque personne ne franchit à l'avance : constituer une base de comparaison pendant que tout fonctionne normalement. Sans valeur de référence, vous ne pourrez pas dire après un incident si 40 000 paquets par seconde représentaient beaucoup, ou simplement un samedi soir. Avec apt-get install -y vnstat sysstat, la mesure tourne en permanence, et logFile = "arma3server.log"; dans server.cfg vous donne en plus le point de vue du serveur. Pendant un incident, quatre commandes suffisent :

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 udp portrange 2302-2306 -c 200 -q

La comparaison des ports est parlante. Si la charge repose presque entièrement sur 2303, il s'agit d'un flood de requêtes, et il frappe le temps de calcul. Si elle se répartit régulièrement sur 2302 à 2306 avec des adresses d'expéditeur toujours nouvelles, il s'agit d'un flood UDP falsifié, et il frappe le raccordement. Pour tcpdump, une règle : limitez toujours avec -c, car une capture à pleine charge alourdit encore un serveur déjà surchargé. La façon d'interpréter ces valeurs est expliquée dans Détecter une attaque DDoS. La manière d'installer et de mettre à jour proprement le serveur est décrite dans Installer un serveur de jeu avec SteamCMD.

Où ces mesures s'arrêtent

Vient maintenant la partie qu'aucun fichier de configuration ne peut résoudre. Toutes les mesures précédentes s'exécutent sur votre serveur, donc au bout du raccordement. 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 vous ne pouvez pas faire qu'il n'ait jamais été envoyé.

Faites le calcul une fois. Un serveur de jeu classique est raccordé à 1 Gbit/s, soit 125 mégaoctets par seconde, et le raccordement est saturé dès que quelqu'un envoie davantage. La deuxième grandeur est le taux de paquets, et chez Arma 3 il frappe presque toujours en premier. Avec de petits paquets de 64 octets, environ 1,49 million de paquets par seconde tiennent dans un raccordement à 1 Gbit/s. Selon le CPU et la carte réseau, un noyau de serveur normal en traite quelques centaines de milliers avant de commencer à rejeter, et la simulation d'Arma 3 dépend en plus d'un seul cœur.

La ligne des 4 Mbit/s est la plus désagréable. Chez Arma 3, une attaque n'a pas besoin d'être grosse pour agir : il lui suffit d'envoyer assez de paquets au bon port. Les exploitants vivent cela comme ceci : « la charge n'était même pas élevée, et pourtant tout avait disparu ». À l'inverse, pour les attaques volumétriques, la physique est simple : à 473,4 Gbit/s, tout réglage local est sans objet, parce que les paquets de vos joueurs ne passent déjà plus en amont. Les attaques volumétriques doivent s'arrêter dans le réseau, en amont du serveur.

Ce que KernelHost oppose à cela

La protection permanente incluse avec chaque serveur

La protection DDoS de KernelHost repose sur deux niveaux et reste active en permanence, sans que vous ayez quoi que ce soit à activer, à commander 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 à 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. 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. Retirer l'adresse IP du réseau aboutit, de votre point de vue, exactement au même résultat que l'attaquant. Les jeux et protocoles couverts sont listés dans Protection DDoS des serveurs de jeu en temps réel.

Advanced DDoS Protection pour les projets attaqués en continu

Certains projets ne sont pas attaqués de temps à autre, mais de façon ciblée et pendant des semaines. Un serveur Life avec une communauté stable et une scène concurrente est à cet égard la règle, pas l'exception. Pour ces cas, il existe l'Advanced DDoS Protection à partir de 50,00 € par mois, en PrePaid, sans durée minimale et sans frais de mise en service. 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 : vous définissez séparément ce qui est autorisé sur 2302 UDP et ce qui l'est sur 2303 UDP, et vous pouvez ainsi mener le port de requête bien plus serré que le port de jeu.
• Les changements s'appliquent en temps réel, vous pouvez donc affiner les réglages pendant une attaque en cours au lieu d'attendre une fenêtre de maintenance.
• Un profil de protection adapté au jeu concerné, tout comme pour les applications modifiées ou maison sur n'importe quel port TCP ou UDP.

Les deux niveaux comparés

Pour la plupart des projets Arma 3, la protection permanente incluse suffit, à condition que la configuration du serveur soit 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 déplacé le port de 2302 vers 2402, l'attaque a continué » : c'est à prévoir. Le serveur déclare lui-même son nouveau port auprès du serveur maître Steam, et la liste des serveurs le publie aussitôt. Un changement de port n'agit que contre quelqu'un qui se sert d'une ancienne adresse tirée d'une vieille capture d'écran.

« J'ai bloqué 2303 complètement, maintenant plus personne ne nous trouve » : c'est exactement ce qui arrive. Sans réponse sur le port de requête Steam, l'entrée manque dans le navigateur de serveurs, et chaque page de statut comme chaque bot Discord affiche le serveur hors ligne. La bonne approche est une limitation de débit par adresse source, pas un blocage.

« Le journal indique NetServer::SendMsg: cannot find channel » : ce message apparaît lorsque le serveur veut écrire vers une connexion qui n'existe plus. Il accompagne en règle générale des connexions de joueurs qui se rompent et des chutes de performance (Bohemia suit cela sous T83936), pas nécessairement une attaque. Vérifiez d'abord si le taux de paquets de l'interface présente vraiment une anomalie.

« Mes règles iptables ne s'appliquent pas » : trois causes sont fréquentes. Les règles se trouvent derrière les chaînes UFW et ne sont jamais atteintes ; elles ont disparu au dernier redémarrage (netfilter-persistent save ou une entrée dans /etc/ufw/before.rules y remédient) ; ou bien l'attaque est volumétrique et la règle travaille correctement sur un raccordement déjà saturé. Vérifiez avec iptables -L INPUT -n -v si les compteurs de correspondances augmentent. S'ils restent à zéro, c'est que la règle n'est jamais atteinte.

« Depuis le nouveau pare-feu, BattlEye expulse tous les joueurs » : le serveur n'atteint plus arma31.battleye.com. Les ports sortants 2344 en TCP et UDP ainsi que 2345 en TCP doivent rester ouverts, faute de quoi la connexion anti-triche du serveur se rompt.

« Mon hébergeur précédent a bloqué mon adresse IP » : c'est du null-routing. L'hébergeur protège ainsi son propre réseau ; pour vous, le résultat est identique à une attaque réussie, et le plus souvent pendant encore des heures. En cas de doute, demandez si le trafic est filtré ou si l'adresse est simplement retirée du réseau. La réponse pèse davantage sur votre disponibilité que n'importe quelle fiche technique.

« Dans tcpdump, je ne vois rien d'anormal » : si le trafic est déjà filtré dans le réseau en amont, rien n'arrive sur le serveur, et c'est bien ce à quoi il faut s'attendre. C'est le cas normal quand le filtrage fonctionne. À l'inverse : si le raccordement est saturé, il se peut que même la session SSH avec laquelle vous vouliez mesurer ne vous parvienne plus. Utilisez alors la console VNC dans l'espace client, qui fonctionne indépendamment du réseau du système invité.

En résumé

• Un serveur Arma 3 a besoin d'exactement trois ports UDP vers l'extérieur : 2302 pour le jeu et la voix, 2303 pour la requête Steam et 2304 pour l'enregistrement auprès du serveur maître Steam. Le jeu n'a besoin d'aucun port TCP.
• Le port 2306 UDP porte BattlEye et l'interface RCon et n'a sa place que sur vos propres adresses d'administration, définies via RConPort et RConIP dans beserver_x64.cfg.
• Le port de requête Steam 2303 est le point le plus sensible : selon l'US-CERT TA14-017A, le protocole Steam a un facteur d'amplification de 5,5, et chaque requête coûte du temps de calcul sur le cœur qui porte la simulation. Limiter plutôt que bloquer.
• Garder steamProtocolMaxDataSize aussi bas que la liste des mods le permet et placer MaxCustomFileSize = 0; dans basic.cfg : les deux réduisent le volume de données que votre serveur livre sans qu'on le lui demande.
• Chez Arma 3, c'est le taux de paquets qui décide, pas la bande passante. Bohemia documente depuis 2015 sous T83469 que 4 Mbit/s sur le port de requête suffisaient déjà à geler un serveur.
• Les mesures locales s'arrêtent au raccordement. À partir de 1 Gbit/s de volume d'attaque ou de quelques centaines de milliers de paquets par seconde, seul le filtrage dans le réseau en amont du serveur est déterminant.
• Chez KernelHost, la protection permanente à deux niveaux est comprise dans chaque pack serveur sans supplément et active dès la mise en service, sans null-routing. L'Advanced DDoS Protection la complète à partir de 50,00 € par mois par une IP protégée dédiée et des règles par port que vous gérez vous-même.

Si votre projet est déjà hébergé 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 ajusté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.