Protéger un serveur DayZ des attaques DDoS

Un serveur DayZ qui éjecte tous ses joueurs en pleine partie le soir venu et disparaît ensuite du navigateur de serveurs pendant plusieurs minutes a rarement un problème de matériel. La plupart du temps, une attaque est en cours, et précisément au moment où les joueurs sont les plus nombreux ou quand le redémarrage planifié approche. Qui veut protéger son serveur DayZ des attaques DDoS a donc besoin des deux : une ouverture de ports propre sur le serveur et un filtrage dans le réseau en amont. 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 alors se passer devant le serveur.

Toutes les indications se rapportent à un serveur dédié DayZ avec sa propre serverDZ.cfg, qu'il tourne sous Windows Server ou sous Debian et Ubuntu au moyen d'une couche de compatibilité. Bohemia Interactive ne livre pas de programme serveur Linux natif prêt pour la production sur la branche stable, et la version Linux expérimentale n'accepte que des clients expérimentaux. Les commandes Linux 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 serverDZ.cfg maintenant et ne redémarrez pas le serveur. Un redémarrage de DayZ recharge les mods et l'économie centrale et vous coûte plusieurs minutes pendant lesquelles le serveur est hors ligne à coup sûr. Sauvegardez d'abord vos mesures (voir la section « Journaliser »), après l'attaque elles auront disparu.

Pourquoi les serveurs DayZ sont si souvent la cible d'attaques DDoS

DayZ réunit plusieurs caractéristiques qui font d'un serveur une cible commode. D'abord, un serveur communautaire publie son adresse de lui-même : pour apparaître dans le navigateur de serveurs du jeu et dans le DZSA Launcher, il doit répondre aux requêtes Steam, et cette réponse contient l'adresse IP et le port en clair. Un attaquant n'a donc rien à découvrir, il lui suffit de lire une liste.

Ensuite, le déroulement d'une journée sur un serveur DayZ est public. Pratiquement tous les projets redémarrent automatiquement toutes les trois à quatre heures, l'annoncent par message dans le chat et inscrivent le calendrier sur leur Discord. Une attaque qui tombe exactement dans cette fenêtre agit doublement : le serveur est de toute façon injoignable à ce moment, et les joueurs qui patientent dans la file d'attente vont voir ailleurs.

Troisièmement, l'enjeu est élevé pour les joueurs. Dans DayZ, une panne à la mauvaise minute ne signifie pas seulement de la frustration, mais de l'équipement perdu, des raids interrompus et une base laissée sans protection dans le monde. C'est précisément pour cela que les joueurs bannis, les groupes rivaux et les projets concurrents sont les commanditaires les plus fréquents. Une attaque passant par l'un des services booter habituels ne coûte à celui qui la lance ni compétence particulière ni argent notable.

Quatrièmement, tout le trafic de DayZ passe par UDP. UDP ne prévoit aucun établissement de connexion que l'on pourrait exiger, et l'adresse d'expéditeur se falsifie. Un attaquant n'a donc besoin ni de rejoindre votre serveur ni de s'adresser correctement à lui pour produire de la charge. Que même le développeur en soit touché, février 2025 l'a montré : les services en ligne de Bohemia Interactive pour DayZ et Arma Reforger ont subi des attaques DDoS pendant plus d'une semaine, confirmées le 3 février 2025 et toujours pas terminées le 6 février 2025, et les serveurs communautaires ont été touchés avec eux. 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 d'un serveur DayZ : tableau des faits

Un serveur DayZ parle exclusivement UDP. Il n'existe pas de port de jeu TCP. La seule valeur réellement fixe chez DayZ est 2302/UDP comme port de jeu, tout le reste est configurable et varie selon l'hébergeur. Vérifiez donc dans votre propre ligne de démarrage et dans votre propre serverDZ.cfg au lieu de vous fier à une valeur par défaut.

Deux valeurs sèment régulièrement la confusion, voici donc la réponse. Le port de requête Steam : la configuration d'exemple livrée par Bohemia met steamQueryPort = 2305;, tandis qu'une grande partie des hébergeurs utilise 27016/UDP. Les deux valeurs sont valides, seule compte celle qui figure dans votre fichier. Le port BattlEye RCon : là, il n'existe aucun standard contraignant. La règle empirique répandue est le port de jeu plus trois, donc 2305, d'autres hébergeurs mettent 2310. Depuis DayZ 1.13, BattlEye exploite de façon fiable le paramètre RConPort dans la BEServer_x64.cfg, avant cela le port était difficile à prévoir.

Il en découle un piège qui touche beaucoup d'exploitants : ne mettez jamais steamQueryPort et RConPort sur la même valeur. Si votre configuration prévoit 2305 pour la requête Steam, RCon doit aller sur un autre port, par exemple 2310.

Pourquoi le port de requête Steam est le port le plus sensible

Le port de requête Steam répond aux trois requêtes A2S_INFO, A2S_PLAYERS et A2S_RULES. A2S_INFO livre le nom du serveur, la carte, le nombre de joueurs et la version, A2S_PLAYERS les noms des joueurs connectés, A2S_RULES les variables serveur définies. Chacune de ces réponses est nettement plus volumineuse que la requête qui l'a déclenchée, et c'est exactement ce qui rend ce port doublement dangereux.

Pour vous, en tant que cible, cela signifie : un attaquant peut occuper votre port de requête avec quelques octets par demande, pendant que votre serveur assemble et expédie à chaque fois une réponse complète. Pour des tiers, cela signifie : un attaquant peut interroger votre serveur avec une adresse d'expéditeur falsifiée et diriger les réponses vers sa véritable cible. Votre serveur n'est alors pas seulement une victime, il devient un amplificateur. Valve a pour cette raison complété A2S_INFO en décembre 2020 par une requête de challenge : le serveur répond d'abord par un nombre aléatoire que le demandeur doit renvoyer. Cela désamorce l'amplification sans la supprimer, car toutes les requêtes ne passent pas par ce chemin.

DayZ présente ici une particularité que d'autres jeux n'ont pas : deux listes de serveurs distinctes vous interrogent, le navigateur de serveurs communautaire intégré et le très répandu DZSA Launcher. Fermer simplement le port de requête n'est donc pas une option, car votre projet disparaîtrait alors des deux listes, alors même que la connexion directe continuerait de fonctionner. Limiter plutôt que fermer, voilà la bonne réponse.

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 DayZ 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 : quels ports votre serveur DayZ ouvre réellement

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

ss -lnup
ss -lntup

Sous Windows Server, l'invite de commandes donne la même image :

netstat -ano -p UDP | findstr "2302 2303 2304 2305 27016"

Ce qui compte est la colonne de l'adresse locale. 0.0.0.0:2302 signifie « joignable depuis tout Internet », 127.0.0.1:2310 signifie « en local uniquement » et ne demande aucune ouverture. Ensuite, lisez les valeurs réelles directement dans vos fichiers de configuration, au lieu de vous fier à un guide :

grep -iE "steamQueryPort|maxPlayers|password|enableWhitelist|verifySignatures" serverDZ.cfg
grep -iE "RConPort|RestrictRCon" battleye/BEServer_x64.cfg

Le point de vue de l'attaquant s'obtient par un scan de ports UDP depuis l'extérieur, exécuté depuis une autre machine :

nmap -Pn -sU -p 2302-2310,27015-27020 ADRESSE.IP.DE.VOTRE.SERVEUR

2. N'ouvrir que ce dont la ligne de démarrage et la serverDZ.cfg ont réellement besoin

Pour DayZ, deux ouvertures vers l'extérieur suffisent : le bloc du port de jeu et le port de requête. Tout le reste est restreint à votre propre adresse ou n'est tout simplement jamais publié. Avec UFW, cela donne ceci, et exactement dans cet ordre, pour ne pas vous bloquer vous-même :

ufw allow 22/tcp comment 'SSH'
ufw allow 2302:2305/udp comment 'DayZ port de jeu'
ufw allow 27016/udp comment 'DayZ Steam Query'
ufw allow from 203.0.113.10 to any port 2310 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 et 27016 par la valeur qui figure réellement dans votre ligne steamQueryPort. Le guide complet, voie de secours comprise, se trouve dans Configurer le pare-feu UFW sans se bloquer l'accès SSH. Sur un serveur Windows, le même principe s'applique : une règle entrante par groupe de ports, le Bureau à distance limité à votre propre adresse, tout le reste bloqué.

3. Limiter le port de requête Steam au lieu de le fermer

Un plafond par adresse source sépare les vraies listes de serveurs des floods de requêtes. Un navigateur de serveurs vous interroge à la seconde, un attaquant à la milliseconde :

iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name dayz_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 2302 -m hashlimit --hashlimit-name dayz_game --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

La première règle rejette les requêtes Steam à partir de plus de dix par seconde en continu depuis la même source, la seconde les paquets de jeu à partir de plus de 600 par seconde. Ces deux chiffres sont des valeurs de départ, pas des vérités. Un serveur plein avec 60 joueurs produit nettement plus de paquets qu'un serveur vide, et un réglage trop serré éjecte vos propres joueurs ou vous fait sortir de la liste des serveurs. Mesurez d'abord pendant une semaine en fonctionnement normal.

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. La bibliothèque serveur de Steam dispose en outre de son propre frein pour les paquets sans connexion : la variable d'environnement STEAM_GAMESERVER_RATE_LIMIT_200MS rejette tous les paquets A2S d'une adresse dès qu'il en arrive plus que la valeur définie dans une fenêtre de 200 millisecondes.

Le troisième point ne coûte rien du tout : si votre bot Discord ou la page de votre projet affiche le nombre de joueurs, n'interrogez pas le serveur depuis le navigateur du visiteur, mais mettez le résultat en cache à intervalle fixe. Une page de statut très fréquentée produit alors une requête par intervalle au lieu d'une par visiteur.

4. Retirer BattlEye RCon du réseau ouvert

BattlEye est le composant anti-cheat de DayZ et s'active dans la serverDZ.cfg avec BattlEye = 1;. L'administration à distance se trouve en revanche dans un fichier à part, la BEServer_x64.cfg du répertoire BattlEye situé à côté de BEServer_x64.dll, répertoire que la ligne de démarrage définit avec -BEpath= :

RConPassword UnLongMotDePasseAleatoire
RConPort 2310
RestrictRCon 0

Trois règles à ce sujet. Premièrement : le port RCon est en UDP, pas en TCP. Une règle de pare-feu qui indique par inadvertance proto tcp ne filtre rien et laisse en même temps les outils d'administration tourner dans le vide. Deuxièmement : restreignez le port aux adresses de vos administrateurs. Qui n'a pas d'adresse fixe laisse le port complètement fermé depuis l'extérieur et lance l'outil d'administration directement sur le serveur, accessible par SSH ou par le Bureau à distance. Troisièmement : RestrictRCon 1 limite les commandes exécutables par RCon et constitue le bon réglage dès que plus d'une personne y a accès.

Un port RCon ouvert, c'est deux choses à la fois : une invitation à essayer des mots de passe et un port UDP de plus que l'on peut inonder. Les deux disparaissent dès que l'ouverture ne vaut plus que pour une poignée d'adresses.

5. File d'attente de connexion, liste blanche et saturation des slots

DayZ ne traite pas toutes les connexions en même temps, mais par une file d'attente. Cinq valeurs de la serverDZ.cfg la pilotent :

maxPlayers = 60;
loginQueueConcurrentPlayers = 5;
loginQueueMaxPlayers = 100;
guaranteedSlots = 10;
maxPing = 200;

loginQueueConcurrentPlayers définit combien de joueurs sont admis en même temps (valeur par défaut 5), loginQueueMaxPlayers limite la file d'attente elle-même (valeurs courantes entre 100 et 500). C'est exactement là qu'intervient la saturation des slots : un attaquant n'a pas besoin de bande passante, il lui suffit d'assez de comptes ou de tentatives de connexion pour occuper la file d'attente. Les vrais joueurs ne passent alors plus, alors même que le serveur fonctionne techniquement sans le moindre défaut. guaranteedSlots réserve des places pour votre équipe, afin que vous puissiez encore accéder vous-même au serveur dans exactement cette situation.

La liste blanche intégrée (whitelist) y répond. Elle s'active avec enableWhitelist = 1; et lit ensuite le fichier profiles/whitelist.txt, une Steam64 ID par ligne. Toute ID non listée est refusée à la connexion. Le fichier est lu au démarrage du serveur, les modifications exigent donc un redémarrage. Un password supplémentaire dans la serverDZ.cfg agit de façon comparable, mais reste plus faible, car un mot de passe se transmet et une Steam64 ID non.

Une chose doit être claire : une liste blanche protège vos places de joueurs, pas votre raccordement. Un attaquant qui inonde votre serveur ne cherche pas du tout à le rejoindre. Ses paquets sont refusés, mais ils sont malgré tout arrivés, et c'est précisément là que se situe le problème.

6. Mods, vérification des signatures et la fenêtre après le redémarrage

Chez DayZ, les mods ne sont pas seulement une question de confort, ils font partie de la surface d'attaque. Quatre réglages de la serverDZ.cfg doivent être définis dans tous les cas :

verifySignatures = 2;
forceSameBuild = 1;
allowFilePatching = 0;
BattlEye = 1;

verifySignatures = 2 vérifie chaque fichier PBO par rapport à la signature .bisign correspondante et a besoin pour cela des fichiers .bikey adéquats dans le dossier keys. forceSameBuild = 1 exige exactement la même version du jeu que celle du serveur. allowFilePatching = 0 refuse les clients qui démarrent avec des fichiers de jeu modifiés. Aucun de ces réglages n'arrête une attaque volumétrique, mais tous les trois ferment le chemin par lequel un client manipulé déstabilise votre serveur.

Le second point est le plus important et il est presque toujours négligé : la phase de démarrage. Au démarrage, un serveur DayZ charge d'abord sa liste de mods depuis la ligne de démarrage, puis l'économie centrale avec toutes les tables de loot. Sur un serveur fortement modifié, cela représente facilement plusieurs minutes pendant lesquelles le serveur ne répond à aucune requête Steam :

./DayZServer -config=serverDZ.cfg -port=2302 -profiles=./profiles -BEpath=./battleye -mod=@CF;@VotreMod;@UnAutreMod -cpuCount=4 -dologs -adminlog -netlog -freezecheck

Comme pratiquement chaque projet redémarre toutes les trois à quatre heures et annonce même ce calendrier, la fenêtre est triviale à viser pour un attaquant. Trois contre-mesures sont efficaces et ne coûtent rien. Gardez la liste de mods aussi courte que possible, chaque mod supplémentaire allonge précisément cette fenêtre. Placez les heures de redémarrage sur des valeurs décalées plutôt que sur l'heure pleine. Et mesurez une fois combien de temps votre démarrage dure réellement, au lieu d'estimer : avec timeStampFormat = "Full"; et un logFile défini, la durée figure ensuite dans le journal.

7. Suivi de connexions, tampons de réception et paramètres du noyau

Un goulot d'étranglement souvent négligé est le suivi de connexions du noyau. UDP ne connaît certes pas de connexions, mais le noyau crée malgré tout une entrée pour chaque paire d'adresses source et destination. Lorsque la table 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

Pour un pur serveur de jeu, la solution propre consiste à ne pas laisser suivre le trafic de jeu du tout, et à agrandir en plus les tampons de réception et la file d'attente de la carte réseau :

iptables -t raw -A PREROUTING -p udp --dport 2302 -j NOTRACK
iptables -t raw -A OUTPUT -p udp --sport 2302 -j NOTRACK
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=1048576
sysctl -w net.core.netdev_max_backlog=5000
sysctl -w net.netfilter.nf_conntrack_max=524288

Attention : NOTRACK et les règles à état s'excluent mutuellement. Qui soustrait le port de jeu au suivi ne doit plus utiliser pour ce port aucune règle avec -m conntrack --ctstate, sinon l'ouverture ne fonctionne plus. De façon durable, les valeurs sysctl ont leur place dans /etc/sysctl.d/, faute de quoi elles auront disparu au prochain redémarrage.

8. Votre adresse IP figure dans le navigateur de serveurs

Ici, mieux vaut l'honnêteté que la pensée magique : l'adresse IP d'un serveur DayZ public ne peut pas rester secrète. Tout joueur qui s'est connecté une fois la connaît, le navigateur de serveurs la publie, et le DZSA Launcher la met en cache. Un changement d'adresse vous fait gagner des heures, rarement des jours.

Deux habitudes sont plus efficaces. Ne publiez nulle part en plus l'adresse IP brute, donc ni dans le message épinglé sur Discord ni sur la page du projet. Et faites le ménage dans vos enregistrements DNS : un enregistrement A oublié qui pointe vers l'adresse précédente rend tout changement inopérant, et c'est exactement là que échouent la plupart des changements. Qui laisse encore tourner un service de statut sur l'ancien serveur livre la nouvelle adresse par la même occasion.

9. Journaliser, pour ne pas avoir à deviner pendant l'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. Côté serveur, vous activez pour cela les journaux intégrés :

timeStampFormat = "Short";
logAverageFps = 300;
logPlayers = 300;
logFile = "server_console.log";

logAverageFps est la valeur la plus honnête que DayZ fournit. Si la fréquence d'images du serveur s'effondre alors que le nombre de joueurs reste le même, c'est un problème de mod ou d'économie centrale. Si elle reste stable pendant que des joueurs se font éjecter, cela vient du réseau. Côté système, les mesures tournent en permanence avec apt-get install -y vnstat sysstat, et pendant un incident quatre commandes suffisent :

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

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 sur le serveur.

Où l'autoprotection s'arrête : bande passante et taux de paquets

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 pas faire qu'il n'ait jamais été envoyé.

Chez DayZ, le taux de paquets frappe souvent plus tôt que la bande passante, et cela tient à une raison simple : le trafic de jeu se compose de nombreux petits paquets UDP, et non de quelques gros. Une attaque qui ne remplit même pas un tiers de votre raccordement peut donc quand même paralyser votre serveur, parce que le temps de calcul part dans le rejet des paquets. Les exploitants vivent cela comme ceci : « la charge n'était même pas élevée, et pourtant tout le monde avait des pics de lag et se faisait éjecter les uns après les autres ».

Les attaques volumétriques doivent s'arrêter dans le réseau, en amont du serveur. Ce n'est pas un argument produit, c'est de la physique.

Protection DDoS DayZ : ce que KernelHost oppose à cela

La protection permanente qui tourne sur 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. Pour ces cas, il existe l'Advanced DDoS Protection à partir de 50,00 € par mois, en PrePaid et sans durée minimale. 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, ce qui l'est sur le port de requête et ce qui l'est sur le port RCon. C'est précisément cette séparation qui fait levier chez DayZ, parce que le trafic de jeu et le trafic de requête ne se ressemblent en rien.
• Les changements s'appliquent en temps réel, vous pouvez donc affiner les réglages pendant une attaque en cours au lieu d'attendre un ticket.
• Un profil de protection adapté au jeu concerné, y compris pour les serveurs fortement modifiés et les applications maison sur n'importe quel port TCP ou UDP.

Les deux niveaux comparés

Pour la plupart des projets DayZ, la protection permanente incluse suffit dès lors que la configuration du serveur est propre. L'Advanced DDoS Protection est la réponse au cas où quelqu'un en fait une affaire personnelle. Qui exploite actuellement son serveur DayZ ailleurs ne peut pas ajouter cette protection après coup : elle fait partie du réseau et vaut pour les serveurs qui se trouvent chez KernelHost. Le chemin qui y mène est un déménagement, pas un produit supplémentaire.

Erreurs fréquentes et solutions

« Mon serveur a disparu du DZSA Launcher et du navigateur de serveurs, mais j'y accède par connexion directe » : dans la plupart des cas, ce n'est pas une attaque, mais le port de requête. Soit steamQueryPort contient une autre valeur que le pare-feu, soit une limitation de débit trop serrée rejette les requêtes de la liste des serveurs. Comparez les deux valeurs avant de supposer une attaque.

« RCon ne se connecte plus depuis que j'ai filtré les ports » : BattlEye RCon passe par UDP. Une ouverture avec proto tcp sur le même port ne produit aucun effet. Vérifiez en outre si RConPort et steamQueryPort ne sont pas par inadvertance sur la même valeur.

« J'ai changé d'adresse IP et deux heures plus tard j'étais de nouveau hors ligne » : l'attaquant a obtenu la nouvelle adresse par la même source que l'ancienne, le plus souvent le navigateur de serveurs, un bot Discord affichant le statut ou un ancien enregistrement DNS. Un changement d'adresse fait gagner du temps, ce n'est pas une solution.

« L'attaque arrive chaque jour exactement au redémarrage » : ce n'est pas un hasard. Le calendrier de redémarrage figure sur le Discord et est annoncé dans le jeu, et pendant que les mods et l'économie chargent, le serveur ne répond de toute façon pas. Une liste de mods plus courte, des heures de redémarrage décalées et un filtrage qui tourne en permanence au lieu de réagir d'abord à une attaque retirent à ce schéma son effet.

« Tous les joueurs ont des pics de lag, mais le réseau est calme » : alors ce n'était pas une attaque DDoS. Regardez d'abord dans logAverageFps si la fréquence d'images du serveur s'est effondrée, puis du côté de l'économie centrale et de la liste de mods. Si sar -n DEV 1 10 ne montre rien d'anormal, cela ne vient pas du réseau.

« 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.

« 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é

• Vers l'extérieur, un serveur DayZ a besoin d'exactement deux choses : le bloc du port de jeu à partir de 2302/UDP et le port de requête Steam issu de votre ligne steamQueryPort. Tout le reste doit être restreint ou fermé.
• Le port BattlEye RCon n'a aucun standard contraignant, passe par UDP et se définit dans la BEServer_x64.cfg avec RConPort. Il n'a jamais sa place sur le réseau ouvert et jamais la même valeur que le port de requête.
• Limiter le port de requête plutôt que le fermer : qui le ferme disparaît du navigateur de serveurs et du DZSA Launcher, alors même que la connexion directe continue de fonctionner.
• La liste blanche, guaranteedSlots et la file d'attente de connexion protègent vos places de joueurs contre la saturation des slots, mais pas votre raccordement contre la bande passante.
• La fenêtre la plus dangereuse d'un serveur DayZ est le redémarrage planifié toutes les trois à quatre heures, parce que les mods et l'économie centrale chargent pendant des minutes et que le moment est public.
• À partir d'environ 1 Gbit/s de volume d'attaque ou de quelques centaines de milliers de paquets par seconde, seul le réseau en amont du serveur décide, et non plus votre pare-feu.
• Chez KernelHost, la protection permanente à deux niveaux est comprise dans chaque pack serveur, sans supplément et sans null-routing. L'Advanced DDoS Protection à partir de 50,00 € par mois s'y ajoute lorsque vous voulez piloter vous-même les règles par port.

Si votre projet tourne déjà 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.