Protéger un serveur Mordhau des attaques DDoS

Un serveur Mordhau qui perd tous ses joueurs d'un coup au milieu d'une partie Frontline, qui reste ensuite hors ligne quelques minutes et qui n'apparaît plus dans la liste des serveurs a rarement un problème de matériel. Dans la très grande majorité des cas, une attaque est en cours contre l'un des quatre ports UDP qu'un serveur dédié Mordhau doit tenir ouverts vers l'extérieur. Cet article montre d'abord ce que vous pouvez faire vous-même pour la protection DDoS de Mordhau, sans frais supplémentaires, ensuite où ces mesures s'arrêtent physiquement, et pour finir ce qui doit se passer dans le réseau, en amont du serveur.

Toutes les indications se rapportent au serveur dédié Mordhau officiel (Steam App ID 629800, Unreal Engine 4) 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 d'abord rien à la configuration et ne redémarrez pas le serveur, mais sauvegardez vos mesures (section 9), car après l'attaque elles auront disparu. Chez Mordhau s'ajoute une seconde raison, que beaucoup d'exploitants apprennent douloureusement : en s'arrêtant, le processus du serveur réécrit dans la Game.ini l'état qu'il conserve en mémoire vive. Qui modifie le fichier pendant que le serveur tourne perd ses changements au prochain arrêt.

Pourquoi les serveurs Mordhau ont besoin d'une protection DDoS et qui les attaque

Les serveurs Mordhau sont attaqués parce que leur adresse est publique, parce que tout le trafic de jeu passe par UDP et parce qu'une panne devient immédiatement visible pour tout le monde. L'entrée dans le navigateur de serveurs contient l'adresse IP et le port de jeu en clair, sans quoi les joueurs ne pourraient pas trouver le serveur. Les listes de serveurs publiques et les trackers récupèrent les mêmes données par le port de requête Steam et les publient une seconde fois. Votre adresse n'est donc pas un secret, c'est une caractéristique du produit.

S'y ajoute la technique du jeu. Unreal Engine 4 transmet les déplacements, les coups portés et les parades par UDP. UDP ne connaît aucun établissement de connexion que l'on pourrait exiger, et l'adresse source d'un paquet UDP se falsifie. Un attaquant n'a donc besoin ni d'entrer sur votre serveur ni de s'adresser correctement à lui pour produire de la charge. Chez Mordhau, cela pèse plus lourd que dans beaucoup d'autres jeux : un échange de coups se décide sur quelques dixièmes de seconde, et déjà 200 millisecondes de retard supplémentaire rendent le combat au corps à corps injouable, bien avant que le serveur ne tombe réellement. C'est exactement pour cela qu'une petite attaque suffit à détruire une partie. Ce qu'est une attaque DDoS en détail, l'article Qu'est-ce qu'une attaque DDoS ? l'explique.

Les déclencheurs habituels n'ont rien de spectaculaire : la concurrence entre communautés, des joueurs bannis, des duels perdus, une dispute sur Discord. Une attaque ne coûte au commanditaire ni compétence ni argent notable, parce que des services de booter loués font le travail. Les exploitants rapportent régulièrement que les attaques démarrent précisément quand le serveur est plein et cessent dès qu'il est vide. Ce n'est pas un hasard, c'est l'indice que quelqu'un surveille votre entrée dans le navigateur de serveurs et se sert du nombre de joueurs comme déclencheur.

Les ports dont il est réellement question chez Mordhau

Un serveur dédié Mordhau a besoin d'exactement quatre ports UDP vers l'extérieur : 7777, 7778, 15000 et 27015. Tout le reste est soit optionnel, soit n'a pas sa place sur le réseau ouvert. Les ports sont passés en paramètres au démarrage :

./MordhauServer.sh FFA_ThePit -log -Port=7777 -QueryPort=27015 -BeaconPort=15000 -RconPort=27020

Deux points sont régulièrement mal compris. Premièrement : le port beacon 15000 n'est pas un accessoire. Le beacon réserve le slot au moment où un joueur rejoint la partie, afin que celui-ci ne soit pas éjecté une fois la carte chargée. Si 15000 est bloqué ou saturé, les joueurs n'entrent plus, alors même que le port 7777 répond. Deuxièmement : chez Mordhau, RCON n'est pas préconfiguré. Il ne devient actif que lorsque vous définissez RconPassword et RconPort, et il passe alors par TCP, pas par UDP.

Les chiffres clés d'un serveur Mordhau en un coup d'œil :

Les schémas d'attaque que l'on rencontre chez Mordhau

Quatre schémas couvrent pratiquement tout ce qui est lancé contre un serveur Mordhau, et chacun touche un port différent.

• UDP flood sur le port de jeu 7777. C'est l'attaque standard d'un booter : le plus grand nombre possible de paquets falsifiés vers le port qui figure dans le navigateur de serveurs. Elle vise la bande passante et le taux de paquets, pas une faille, et se manifeste d'abord par des pics de lag, bien avant que quelqu'un ne perde la connexion.
• Flood de requêtes sur le port de requête 27015. Une requête A2S_INFO fait 25 octets, la réponse avec le nom du serveur, la carte, le mode de jeu et le nombre de joueurs en est un multiple. L'attaquant investit donc peu et vous impose du calcul et du trafic sortant.
• Réflexion par votre propre port de requête. Ici, votre serveur n'est pas la cible, il est l'outil : l'attaquant envoie des requêtes avec une adresse source falsifiée, et votre serveur répond à la victime. Vous le remarquez à un trafic sortant inexplicablement élevé sur 27015 et à un signalement d'abus de votre hébergeur.
• Épuisement des connexions et des slots par le port beacon 15000. Au lieu de brûler de la bande passante, des connexions automatisées occupent les slots réservés. Le serveur continue de tourner, mais il est plein, et les vrais joueurs n'entrent plus.

S'y ajoute un cinquième schéma dès que RCON est ouvert sur le réseau : des tentatives de connexion à la seconde contre le port RCON. C'est rarement volumétrique, mais cela coûte du temps de calcul, et c'est le seul des cinq cas où une réussite vous retire complètement la main sur le serveur.

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 Mordhau 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 au juste sur le serveur ?

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 :

ss -lntup

La colonne qui compte est celle de l'adresse locale. 0.0.0.0:7777 et [::]:7777 signifient « joignable depuis tout Internet », 127.0.0.1:27020 signifie « en local uniquement » et ne demande aucune règle de pare-feu. À côté du jeu, on y trouve souvent un panneau web, un service de base de données et un service vocal oublié depuis longtemps. Le point de vue de l'attaquant s'obtient par un scan depuis l'extérieur, pour UDP avec une courte liste de ports, car un scan UDP complet est très lent :

nmap -Pn -sU -p 7777,7778,15000,27015 ADRESSE.IP.DE.VOTRE.SERVEUR
nmap -Pn -p- --min-rate 1000 ADRESSE.IP.DE.VOTRE.SERVEUR

2. Ne laisser ouverts que les quatre ports dont Mordhau a réellement besoin

Pour Mordhau, quatre autorisations UDP vers l'extérieur suffisent, tout le reste est restreint 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 7777/udp comment 'Mordhau jeu'
ufw allow 7778/udp comment 'Mordhau Steam'
ufw allow 15000/udp comment 'Mordhau Beacon'
ufw allow 27015/udp comment 'Mordhau Query'
ufw allow from 203.0.113.10 to any port 27020 proto tcp comment 'Mordhau RCON'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Remplacez 203.0.113.10 par votre propre adresse. Ce qui compte, c'est ce qui ne figure pas ici : aucune autorisation pour un panneau web, aucune pour une base de données, aucune pour un serveur de fichiers. Chaque port ouvert en plus est une cible supplémentaire qui n'a rien à voir avec le jeu. Le guide complet, voie de secours comprise, se trouve dans Configurer le pare-feu UFW sans se bloquer l'accès SSH.

3. Limiter le port de requête 27015 sans disparaître de la liste des serveurs

Le port de requête, vous avez le droit de le limiter, mais pas de le fermer. Si 27015 UDP est fermé, votre serveur disparaît du navigateur de serveurs, parce que le nombre de joueurs, le nom de la carte et le nom du serveur sont justement demandés par ce port. Un plafond par adresse source résout le problème sans coûter la visibilité :

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name mh_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Un navigateur de serveurs normal interroge votre serveur quelques fois par minute, pas quelques fois par seconde. Dix requêtes par seconde et par adresse source sont donc généreuses pour chaque joueur et serrées pour chaque bot. Vérifiez ensuite au compteur de correspondances si la règle s'applique bien :

iptables -L INPUT -n -v | head -20
tcpdump -ni eth0 udp port 27015 -c 200 -q

C'est ici que se trouve aussi la réponse à la question de la réflexion. Lors d'une réflexion, votre serveur n'est pas attaqué, il est détourné comme amplificateur : les requêtes arrivent avec une adresse source falsifiée, et vos réponses frappent une victime étrangère. Une limitation de débit par adresse source est la mesure locale la plus efficace contre cela, parce qu'une adresse source falsifiée ne sert que tant que votre serveur répond docilement et sans limite.

4. Retirer RCON du réseau ouvert

Chez Mordhau, RCON n'a en aucun cas sa place sans restriction sur Internet. L'accès s'active dans la Game.ini, dans la section [/Script/Mordhau.MordhauGameSession] :

[/Script/Mordhau.MordhauGameSession]
ServerName=Mon serveur Mordhau
MaxSlots=64
ServerPassword=
AdminPassword=UnLongMotDePasseAleatoire
RconPassword=UnAutreLongMotDePasseAleatoire
RconPort=27020

Mordhau parle le protocole Source RCON, donc TCP, et fonctionne de ce fait avec tous les outils RCON courants. C'est précisément ce dont profitent aussi les scripts qui essaient des identifiants en série. Trois règles couvrent ce cas. Premièrement : RconPassword et AdminPassword sont deux mots de passe différents, longs et aléatoires, et non des variantes du nom du serveur. Deuxièmement : vous limitez l'autorisation du port RCON à votre propre adresse, comme dans le bloc UFW plus haut. Troisièmement, si vous n'avez pas d'adresse fixe : laissez le port fermé vers l'extérieur et atteignez-le par une redirection de port SSH, puis connectez-vous en local sur 127.0.0.1:27020 :

ssh -N -L 27020:127.0.0.1:27020 root@ADRESSE.IP.DE.VOTRE.SERVEUR

Si RCON doit malgré tout rester ouvert, limitez au moins les connexions simultanées par adresse source. Un outil RCON a besoin d'une connexion, un script de force brute en ouvre des centaines :

iptables -I INPUT -p tcp --dport 27020 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP

5. Protéger le port beacon 15000 contre les vagues de connexions

Le port beacon est le point d'attaque sous-estimé d'un serveur Mordhau. C'est par lui que le jeu réserve le slot d'un joueur qui rejoint la partie, tant que celui-ci charge encore. Un bot qui déclenche des connexions en rafale occupe ainsi des slots sans jamais arriver dans le jeu. Le serveur reste en ligne et paraît malgré tout plein. Un plafond par adresse source intercepte cela, parce qu'un vrai joueur n'émet exactement qu'un beacon par connexion, et non vingt par seconde :

iptables -I INPUT -p udp --dport 15000 -m hashlimit --hashlimit-name mh_beacon --hashlimit-mode srcip --hashlimit-above 20/sec --hashlimit-burst 40 -j DROP
iptables -I INPUT -p udp --dport 7777 -m hashlimit --hashlimit-name mh_game --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

La seconde règle vise le port de jeu et demande de la mesure. Avec une tickrate de 60, le serveur échange avec chaque joueur connecté de l'ordre de 60 paquets par seconde et par sens. Une limite de 400 paquets par seconde et par adresse source laisse donc largement de la marge à chaque vrai joueur et touche malgré tout toute source qui inonde de façon manifeste. Mesurez d'abord une semaine en fonctionnement normal avant de resserrer : qui règle trop serré éjecte ses propres joueurs et prend ensuite cela pour une attaque.

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.

6. Game.ini et Engine.ini : ce qui apporte vraiment quelque chose

Mordhau a deux fichiers de configuration, et tous deux se trouvent sous Linux dans Mordhau/Saved/Config/LinuxServer/, sous Windows dans Mordhau\Saved\Config\WindowsServer\. La Game.ini règle le nom du serveur, les slots, les mots de passe, la liste des administrateurs, la rotation des cartes et les identifiants de mods issus de mod.io, la Engine.ini règle le comportement réseau. Ne modifiez les deux que serveur arrêté, sinon le processus du serveur écrase vos changements à l'arrêt avec l'état qu'il conserve en mémoire vive.

Trois réglages sont réellement pertinents pour la surface d'attaque. Premièrement un ServerPassword : il tient à l'écart tous ceux qui ne sont pas invités, mais il coûte la découvrabilité publique et n'aide en rien contre une vague sur le port 7777, parce que l'attaquant ne cherche pas du tout à rejoindre la partie. Deuxièmement un nombre MaxSlots réaliste : Mordhau est prévu pour 64 joueurs au maximum, et chaque slot supplémentaire est une source de paquets supplémentaire que votre CPU doit servir. Troisièmement la tickrate dans la Engine.ini :

[/Script/OnlineSubsystemUtils.IpNetDriver]
NetServerMaxTickRate=60
LanServerMaxTickRate=60

[IpDrv.TcpNetDriver]
NetServerMaxTickRate=60

La tickrate par défaut d'un serveur Mordhau est 60. La porter à 120 double le taux de paquets par joueur ainsi que la charge CPU, et c'est exactement ce dont vous n'avez pas besoin sous attaque. Un serveur de 64 slots avec une tickrate de 120 produit déjà en fonctionnement normal de l'ordre de 8 000 paquets par seconde et par sens. Qui est visé en permanence tourne nettement plus stablement avec 60 qu'avec 120.

7. Soulager le suivi de connexions et les tampons de réception

Un goulot d'étranglement souvent négligé est le suivi de connexions du noyau. Il tient une entrée propre pour chaque flux UDP, et une vague issue de dizaines de milliers d'adresses sources 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 ». L'état et la limite s'affichent avec :

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
dmesg -T | grep -i conntrack | tail -20

Deux choses aident contre cela. Soit vous relevez la limite, soit vous excluez complètement les ports de jeu du suivi. Sur un serveur de jeu, la seconde voie est généralement la meilleure, parce qu'UDP n'a de toute façon aucun état à suivre :

iptables -t raw -I PREROUTING -p udp --dport 7777 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 15000 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 27015 -j NOTRACK

Des tampons de réception plus grands et une file d'attente plus profonde sur la carte réseau sont également utiles, pour que de courtes pointes n'entraînent pas immédiatement des rejets :

sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=4194304
sysctl -w net.core.netdev_max_backlog=5000

De façon permanente, ces valeurs ont leur place dans un fichier sous /etc/sysctl.d/, par exemple 99-gameserver.conf. Point important à comprendre : des tampons plus grands n'augmentent pas votre résistance face à une grande attaque, ils évitent seulement qu'une courte pointe coûte déjà des paquets.

8. Votre adresse figure dans la liste des serveurs, et cela ne peut pas changer

Ici, mieux vaut l'honnêteté que la pensée magique : l'adresse IP d'un serveur Mordhau public ne peut pas rester secrète. Elle figure dans l'entrée du navigateur de serveurs, elle figure dans les listes de serveurs publiques de tiers qui lisent régulièrement le port de requête, et chaque joueur qui s'est connecté une fois la connaît. Un changement d'adresse procure donc des heures, rarement des jours, parce que l'attaquant trouve la nouvelle adresse par le même chemin que l'ancienne.

Trois habitudes sont efficaces pour cela. Ne publiez jamais vous-même l'adresse IP brute, donc ni dans le canal Discord ni sur la page du projet. Faites passer vos joueurs par un nom d'hôte, afin qu'un changement d'adresse ne casse pas toutes les références le jour venu. Et nettoyez les anciens enregistrements DNS, car un enregistrement A oublié pointant vers l'adresse précédente rend tout changement inopérant. Cela vaut aussi pour les serveurs de test : tout serveur secondaire joignable publiquement sur la même machine trahit l'adresse du serveur principal.

9. Mesurer tant que tout fonctionne normalement

L'étape la plus importante est celle que presque personne ne franchit à l'avance : constituer une base de comparaison tant que le serveur tourne tranquillement. 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. 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 7777 or udp port 15000 or udp port 27015' -c 200 -q

Pour tcpdump, une règle : limitez toujours avec -c, car une capture à pleine charge alourdit encore un serveur déjà surchargé. Faites particulièrement attention aux compteurs de rejet issus de ip -s link. Des valeurs dropped qui montent alors que le CPU reste calme sont l'indice le plus net que le problème vient du taux de paquets et non de la puissance de calcul. La façon d'interpréter ces valeurs est expliquée dans Détecter une attaque DDoS. La manière d'installer proprement le serveur avec SteamCMD et de le tenir à jour est décrite dans Installer un serveur de jeu avec SteamCMD.

Où ces mesures s'arrêtent : 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 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. Un serveur Mordhau plein avec 64 slots n'en utilise qu'une fraction : avec une tickrate de 60, le trafic de jeu se situe de l'ordre de 4 000 paquets par seconde et par sens. Un booter loué fournit en revanche sans difficulté 5 à 50 Gbit/s, soit cinq à cinquante fois votre raccordement. La qualité de votre règle iptables placée derrière n'a alors plus aucune importance, car les paquets de vos joueurs ne passent déjà plus en amont.

La deuxième grandeur est le taux de paquets, et il frappe souvent plus tôt que la bande passante. 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. Une attaque qui ne remplit même pas un tiers de votre raccordement peut donc quand même paralyser votre serveur Mordhau, 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 avait disparu ».

Pour situer les ordres de grandeur qui se produisent réellement : sur des serveurs KernelHost, nous avons notamment filtré une attaque de plus de 473,4 Gbit/s à plus de 41,5 millions de paquets par seconde contre un serveur vocal, ainsi qu'un UDP flood de plus de 112,2 Gbit/s contre un serveur de jeu. Il n'existe aucun réglage local pour cela. 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 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, pour vous, exactement au même résultat que l'attaquant. Le site est Francfort-sur-le-Main. Les jeux et protocoles couverts sont listés dans Protection DDoS des serveurs de jeu en temps réel.

Advanced DDoS Protection pour les serveurs Mordhau visés en continu

Certains serveurs ne sont pas attaqués de temps à autre, mais de façon ciblée et pendant des semaines. Pour cela, 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 7777 UDP, sur 15000 UDP et sur 27015 UDP, sans avoir à ouvrir de ticket.
• 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. Pour les serveurs de jeu Unreal Engine sur UDP et pour les ports de requête Steam, des profils prêts à l'emploi existent, tout comme pour les applications modifiées ou maison sur n'importe quel port TCP ou UDP.

L'Advanced DDoS Protection s'adresse aux serveurs qui tournent chez KernelHost. Si votre serveur Mordhau se trouve actuellement ailleurs et qu'il est régulièrement mis hors ligne, le déménagement est la voie vers ce filtrage.

Les deux niveaux comparés

Pour la plupart des serveurs Mordhau, la protection permanente incluse suffit, à condition que la configuration 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 fermé le port 27015, et maintenant mon serveur ne figure plus dans la liste » : c'est la conséquence attendue. Le port de requête Steam fournit le nom, la carte et le nombre de joueurs au navigateur de serveurs. Sans lui, votre serveur n'apparaît plus ou est indiqué comme injoignable. La bonne réponse est une limitation de débit par adresse source, pas un blocage.

« Les joueurs n'entrent pas, alors que le serveur tourne » : vérifiez d'abord le port 15000 UDP. Le beacon réserve le slot pendant le chargement. S'il est bloqué, filtré trop strictement ou saturé, la connexion reste en suspens, alors même que le port 7777 répond et que le serveur figure dans le navigateur.

« Mes modifications dans la Game.ini ont de nouveau disparu après le redémarrage » : vous avez modifié le fichier pendant que le serveur tournait. En s'arrêtant, le processus du serveur Mordhau réécrit l'état qu'il conserve en mémoire vive et écrase ainsi votre version. Arrêter le serveur, modifier, démarrer, dans cet ordre.

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

« Le serveur tourne, mais tout le monde a des pics de lag et les coups arrivent trop tard » : regardez d'abord si le taux de paquets entrants monte alors que le CPU reste calme. C'est exactement le schéma d'une attaque. Si le taux de paquets reste normal et que le CPU est à 100 pour cent, ce n'est pas une attaque DDoS, mais le plus souvent une tickrate trop élevée, trop de slots ou un mod.

« Mon hébergeur signale un abus sortant depuis le port 27015 » : votre serveur a été détourné comme amplificateur pour une réflexion. Les requêtes arrivaient avec une adresse source falsifiée, et c'est votre serveur qui a répondu à une victime étrangère. Une limitation de débit sur 27015 UDP par adresse source met fin à cela.

« 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 dédié Mordhau a besoin d'exactement quatre ports UDP vers l'extérieur : 7777 (jeu), 7778 (Steam), 15000 (beacon) et 27015 (requête Steam). Tout le reste reste fermé.
• Chez Mordhau, RCON passe par TCP selon le protocole Source RCON et ne devient actif que par RconPassword et RconPort dans la Game.ini. Limitez le port à votre propre adresse.
• Le port 27015 UDP, vous avez le droit de le limiter, mais pas de le fermer : sans lui, votre serveur disparaît du navigateur de serveurs, parce que le nombre de joueurs, la carte et le nom sont demandés par ce port.
• Le port 15000 UDP est le port beacon et réserve le slot pendant le chargement. S'il est bloqué ou saturé, les joueurs n'entrent pas, alors même que le serveur tourne.
• Ne modifiez Game.ini et Engine.ini que serveur arrêté, parce que le processus du serveur réécrit à l'arrêt l'état qu'il conserve en mémoire vive.
• Les règles de pare-feu locales s'arrêtent à la bande passante : 1 Gbit/s, ce sont 125 mégaoctets par seconde, et avec des paquets de 64 octets environ 1,49 million de paquets par seconde. Au-delà, seul 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. Qui veut piloter le filtrage lui-même l'obtient avec l'Advanced DDoS Protection à partir de 50,00 € par mois.

Si votre serveur Mordhau 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.