Protéger un serveur Unturned des attaques DDoS

Un serveur Unturned qui disparaît de la liste des serveurs pendant quelques minutes le soir et éjecte au passage tous les joueurs avec un dépassement de délai a rarement un problème de matériel. La plupart du temps, une attaque est en cours, et précisément au moment où il y a le plus de monde. 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 dans le réseau, en amont du serveur.

Toutes les indications se rapportent au serveur dédié Unturned (U3DS, App ID SteamCMD 1110390) 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 changez d'abord rien à la configuration et ne redémarrez pas le serveur : sauvegardez les mesures (section 10), après l'attaque elles auront disparu.

Pourquoi ce sont justement les serveurs Unturned qui sont attaqués

Les serveurs Unturned sont attaqués parce que leur adresse est publique, parce que le trafic de jeu passe par UDP et parce qu'une attaque ne coûte à celui qui la lance ni compétence particulière ni argent notable. Ces trois points valent ici plus fortement que pour la plupart des autres jeux.

Un serveur Unturned public publie son adresse IP de lui-même. Il doit le faire, sans quoi personne ne le trouverait : le navigateur de serveurs Steam l'interroge directement, et les listes tierces comme unturned-servers.net ou BattleMetrics affichent l'adresse IP et le port en clair. unturned-servers.net vérifie pour cela, selon ses propres indications, toutes les cinq minutes si le serveur accepte des connexions UDP sur le port du serveur. Pour un attaquant, ce n'est pas du travail, c'est un formulaire.

S'y ajoute le public du jeu. Unturned est gratuit, la barrière à l'entrée est nulle, et il existe entre les projets roleplay et survie une véritable concurrence pour les mêmes joueurs. Un joueur banni, un ancien administrateur vexé ou un projet voisin n'a besoin d'aucun accès à votre serveur pour le rendre inutilisable pendant une heure. Ce qu'est techniquement une attaque DDoS et pourquoi les adresses source falsifiées la rendent si difficile à remonter, l'article Qu'est-ce qu'une attaque DDoS ? l'explique.

Les ports dont il est réellement question

Un serveur Unturned occupe exactement deux ports UDP consécutifs : la valeur définie dans la Commands.dat et cette valeur plus un. Par défaut, il s'agit de 27015 et 27016. La documentation officielle de Smartly Dressed Games décrit ainsi la répartition : le premier port porte les requêtes de la liste des serveurs, le second le trafic de jeu. Seul le premier se définit, le second en découle automatiquement.

Name Mon serveur Unturned
Port 27015
MaxPlayers 24
Map PEI
Mode Normal
Perspective Both
Owner 76561198000000000

Le fichier Commands.dat se trouve sous U3DS/Servers/<Instance>/Server/Commands.dat. Son format est particulier et constitue une source d'erreurs fréquente : une commande par ligne, pas de signe égal, la valeur séparée par une espace, et les commandes sont sensibles à la casse. Les lignes qui commencent par // sont des commentaires.

Le point le plus important pour le pare-feu est le suivant : le port 27017 n'est plus nécessaire depuis la version 3.21.30.0 du 21 novembre 2021. Auparavant, un serveur Unturned exigeait trois ports, parce que la requête Steam se trouvait sur le port plus deux. Avec cette mise à jour, la requête partage le port avec le serveur lui-même, et le troisième port a disparu. Les guides de routeur, les wikis d'hébergeurs et les messages de forum citent pourtant 27017 aujourd'hui encore. Un 27017 ouvert ne vous apporte plus aucun avantage, c'est de la surface d'attaque et rien d'autre.

Autre point important : Unturned n'a pas de port RCON intégré. La documentation officielle ne connaît que l'entrée et la sortie console, que l'on peut remplacer par l'interface ICommandInputOutput. Toute commande à distance que vous voyez sur un serveur Unturned provient d'un plugin et apporte son propre port TCP. C'est à vous de trouver ce port et de le restreindre, car personne ne l'a sécurisé pour vous.

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 Unturned 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 vraiment

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

ss -lnup
ss -lntp

La première commande affiche les sockets UDP en écoute, la seconde les sockets TCP. La colonne qui compte est celle de l'adresse locale. 0.0.0.0:27015 et [::]:27015 signifient « 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 y trouve souvent un plugin RCON, un panneau web, une base de données et un vieux serveur de test sur 27017 dont plus personne ne se sert. Le point de vue de l'attaquant s'obtient par un scan de ports depuis l'extérieur, pour Unturned explicitement en UDP :

nmap -Pn -sU -p 27000-27050 ADRESSE.IP.DE.VOTRE.SERVEUR
nmap -Pn -p- --min-rate 1000 ADRESSE.IP.DE.VOTRE.SERVEUR

2. Ne laisser ouverts que 27015 et 27016

Pour Unturned, deux autorisations UDP vers l'extérieur suffisent. Le jeu lui-même n'a besoin d'aucun port TCP : la documentation officielle exige explicitement UDP pour les deux ports, et la couche réseau du jeu (Steam Networking Sockets, réglage par défaut depuis une mise à jour) fonctionne exclusivement en UDP. Qui ouvre en plus du TCP suit un guide obsolète.

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'Unturned A2S'
ufw allow 27016/udp comment 'Unturned jeu'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

L'ordre est important, sans quoi vous vous bloquez vous-même. Le guide complet, voie de secours comprise, se trouve dans Configurer le pare-feu UFW sans se bloquer l'accès SSH. Si vous exploitez plusieurs instances, respectez l'écart recommandé de deux (27015, 27017, 27019) et n'ouvrez par instance que les deux ports qu'elle occupe réellement.

Un panneau web, une base de données ou un plugin RCON n'ont pas leur place sur le réseau ouvert. Restreignez le port concerné à votre propre adresse avec ufw allow from 203.0.113.10 to any port 8080 proto tcp, ou atteignez l'interface par une redirection SSH locale avec ssh -N -L 8080:127.0.0.1:8080 root@ADRESSE.IP.DE.VOTRE.SERVEUR. La base de données, elle, s'attache à 127.0.0.1.

3. Sécuriser le port de requête sans sortir de la liste des serveurs

Le port de requête est le point le plus sensible d'un serveur Unturned. C'est par lui que le serveur répond aux requêtes Steam A2S_INFO, A2S_PLAYERS et A2S_RULES. Si vous le bloquez complètement, le serveur disparaît de toutes les listes de serveurs, même s'il tourne parfaitement.

Une réponse A2S est nettement plus grande que la requête. Dans son aperçu des attaques par amplification UDP (TA14-017A), l'US-CERT attribue au protocole Steam un facteur d'amplification de bande passante de 5,5. Concrètement, cela signifie qu'un attaquant envoie des requêtes avec une adresse source falsifiée à des serveurs de jeu tiers et dirige les réponses, environ cinq fois et demie plus grandes, vers sa véritable cible. Votre serveur n'est alors pas la victime, mais l'amplificateur contre un tiers. Dans l'autre sens, une inondation de requêtes suffit à faire disparaître le serveur du navigateur de serveurs sans qu'un seul joueur soit éjecté. Les exploitants signalent exactement cela : le serveur tourne, les joueurs connectés ne remarquent rien, mais il n'est plus trouvable.

Contre les petites inondations de requêtes, un plafond par adresse source fait le travail. Les requêtes légitimes sont rares : le navigateur Steam interroge une fois par affichage, les services de statut toutes les quelques minutes.

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name unturned_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name unturned_game --hashlimit-mode srcip --hashlimit-above 300/sec --hashlimit-burst 500 -j DROP

Le second chiffre découle directement du jeu : Unturned limite un joueur à 50 paquets par seconde d'origine (Max_Packets_Per_Second). 300 paquets par seconde et par adresse source laissent donc largement de la marge à un seul raccordement, même si plusieurs joueurs se trouvent derrière la même adresse. Ces deux valeurs sont des valeurs de départ, pas des vérités. Mesurez d'abord une semaine de fonctionnement normal, sinon vous éjectez vos propres joueurs.

Les règles iptables seules disparaissent après un redémarrage. Sous Debian et Ubuntu, on les enregistre avec apt-get install -y iptables-persistent et 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.

S'y ajoute une habitude qui ne coûte rien : si votre site ou votre bot Discord affiche le nombre de joueurs, n'interrogez pas le serveur depuis le visiteur, mais mettez le résultat en cache à intervalle fixe. Sinon, une page de statut très fréquentée produit une requête par visiteur au lieu d'une par intervalle.

4. Régler les limites intégrées dans la Config.json

Unturned apporte dans la Config.json, située dans le même dossier Server que la Commands.dat, une section plus importante pour la défense que son nom ne le laisse supposer. Les valeurs par défaut sont les suivantes :

"Server": {
    "VAC_Secure": true,
    "BattlEye_Secure": true,
    "Max_Ping_Milliseconds": 750,
    "Timeout_Queue_Seconds": 15.0,
    "Timeout_Game_Seconds": 30.0,
    "Max_Packets_Per_Second": 50.0,
    "Join_Rate_Limit_Window_Seconds": 40.0,
    "Rate_Limit_Kick_Threshold": 10,
    "Use_FakeIP": false
}

Max_Packets_Per_Second limite un joueur connecté à 50 paquets par seconde. Join_Rate_Limit_Window_Seconds et Rate_Limit_Kick_Threshold éjectent une connexion qui dépasse la limite plus de dix fois en 40 secondes. VAC_Secure et BattlEye_Secure exigent les deux systèmes anti-cheat côté joueur et tiennent ainsi à l'écart la plus grande partie des clients jetables.

Une chose doit être claire : ces limites agissent contre les clients qui rejoignent réellement le serveur ou tentent de le faire. Elles n'agissent pas contre un flood avec des adresses source falsifiées, parce qu'aucune session n'y voit le jour. Elles restent importantes, parce qu'elles interceptent le cas particulier le plus fréquent : un unique client manipulé qui surcharge le serveur à lui seul. Laisser Max_Ping_Milliseconds à 750 est judicieux ; réglé plus bas, le serveur éjecte la moitié d'une partie au moindre à-coup du réseau.

5. Soulager le suivi de connexions

Ce point passe presque toujours inaperçu et explique des pannes qui ressemblent à une attaque volumétrique sans en être une. Le noyau crée aussi pour le trafic UDP des entrées dans le suivi de connexions (conntrack), et avec des adresses source falsifiées, chaque nouvelle adresse signifie une nouvelle entrée. Une fois la table pleine, le noyau jette les paquets sans faire de différence : l'attaque et vos joueurs sortent ensemble. Le journal système contient alors nf_conntrack: table full, dropping packet.

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

L'action la plus efficace consiste à ne pas faire suivre du tout le trafic Unturned. Le jeu gère lui-même ses sessions et n'a besoin d'aucun suivi d'état dans le noyau :

iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK
iptables -t raw -A PREROUTING -p udp --dport 27016 -j NOTRACK

Veillez à ce que vos autorisations pour ces deux ports ne passent alors plus par ESTABLISHED,RELATED, mais figurent comme règles d'acceptation propres. Ce n'est qu'ensuite qu'il vaut la peine d'augmenter nf_conntrack_max. Qui agrandit d'abord la table ne repousse le problème que de quelques minutes et consomme de la mémoire vive pour cela.

Si les paquets arrivent plus vite que le processus serveur ne les récupère, le tampon de réception du socket déborde en plus. Pour les joueurs, cela ressemble à de la perte de paquets, alors que la liaison est libre :

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Déposez ces valeurs sous /etc/sysctl.d/ et activez-les avec sysctl --system. Le noyau vous dit lui-même si elles sont nécessaires : si UdpRcvbufErrors augmente dans nstat -az ou s'il reste en permanence quelque chose dans la file de réception affichée par ss -lunp, alors elles servent. Si les deux restent à zéro, le réglage ne change rien. C'est une réserve, pas une protection.

6. Flood de connexions, file d'attente et liste blanche

Un flood de connexions est une attaque dans laquelle l'attaquant emprunte le chemin de connexion normal pour consommer des places et du temps de calcul au lieu de remplir la liaison. Unturned apporte contre cela quatre outils, tous situés dans la Commands.dat :

• Queue_Size 32 définit la file d'attente. Le réglage par défaut est de 8 places, le maximum de 64. Une file trop grande aide un attaquant, une file trop petite fait perdre de vrais joueurs à chaque redémarrage.
• Whitelisted fait passer le serveur en liste d'accès. L'inscription se fait par la console avec permit <SteamID64>, la suppression avec unpermit <SteamID64>.
• Password VotreMotDePasse exclut tout ce qui ne connaît l'adresse que par une liste.
• Filter refuse les joueurs dont le nom contient des caractères interdits, MaxPlayers 24 maintient le nombre de places à ce que le matériel supporte réellement.

Une liste blanche protège votre logique de jeu, pas votre liaison. 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.

7. RocketMod, OpenMod et le côté plugins

Unturned dispose de deux plateformes de plugins répandues, et toutes deux tournent dans le même processus que le serveur. RocketMod est la plus ancienne : les mainteneurs d'origine en ont arrêté l'entretien le 20 décembre 2019 et ont placé le code source sous licence MIT. Smartly Dressed Games entretient depuis lors le dérivé Legally Distinct Missile (LDM), déjà livré avec le serveur dédié : il suffit de copier Rocket.Unturned du dossier Extras vers le dossier Modules. Les développeurs recommandent ce dérivé de façon explicite, parce qu'il corrige d'anciens problèmes de Rocket comme les erreurs de threading et les exploits de téléportation.

OpenMod est le successeur plus récent, développé par l'un des mainteneurs d'origine de Rocket. Il ne remplace pas RocketMod, il tourne à côté et peut reprendre les plugins Rocket existants par une intégration. Pour la défense, cela signifie deux choses.

Premièrement : chaque plugin est une surface d'attaque dans le processus principal. Un plugin qui déclenche une requête en base de données à chaque message de chat ou à chaque événement de jeu est un déni de service fait maison. Un seul joueur qui déclenche un événement en boucle paralyse alors le serveur sans la moindre bande passante. Gardez la liste des plugins courte, privilégiez les plugins à code source ouvert et mesurez la fréquence d'images du serveur après chaque ajout.

Deuxièmement : comme Unturned n'a pas de port RCON propre, toute commande à distance provient d'un plugin. Après l'installation, vérifiez avec ss -lntp quel port TCP il a ouvert, et restreignez-le à votre propre adresse. Un port de commande à distance ouvert avec un mot de passe faible n'est pas un problème de DDoS, c'est un problème de prise de contrôle.

8. Les contenus du Workshop et le processus de connexion

Les contenus du Workshop rendent la connexion coûteuse, et cela influe directement sur votre exposition. Tout se pilote par la WorkshopDownloadConfig.json, dans le même dossier Server :

{
    "File_IDs": [],
    "Ignore_Children_File_IDs": [],
    "Query_Cache_Max_Age_Seconds": 600,
    "Max_Query_Retries": 2,
    "Use_Cached_Downloads": true,
    "Should_Monitor_Updates": true,
    "Shutdown_Update_Detected_Timer": 600
}

File_IDs contient les identifiants Workshop des cartes et des mods. Au démarrage, le serveur les télécharge avec leurs dépendances, et chaque joueur les récupère automatiquement en se connectant. Trois conséquences sont à connaître. Premièrement, la connexion est longue avec de grandes listes de mods, et après une attaque tous les joueurs reviennent en même temps, ce qui sollicite le serveur une deuxième fois. Deuxièmement, Should_Monitor_Updates arrête le serveur dès qu'un fichier du Workshop est mis à jour : le Shutdown_Update_Detected_Timer par défaut de 600 secondes conduit alors à un redémarrage que les exploitants prennent régulièrement, en pleine attaque, pour un succès de l'attaquant. Troisièmement, chaque mod est du code étranger sur votre serveur.

En pratique : gardez la liste aussi courte que possible, vérifiez après chaque redémarrage inattendu d'abord le journal du serveur à la recherche du message sur la mise à jour du Workshop, et ne désactivez Should_Monitor_Updates que si vous planifiez les mises à jour vous-même.

9. Liste des serveurs, code de serveur et fonction Fake IP

Votre adresse IP ne peut pas rester secrète tant que le serveur est listé publiquement. Tout joueur qui s'est connecté une fois la connaît, et les listes tierces la publient de toute façon. Deux habitudes aident malgré tout : ne publiez nulle part l'adresse brute vous-même, et 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 grand classique reste l'enregistrement A oublié qui pointe vers l'ancienne adresse et rend tout changement inopérant.

Pour une exploitation sur Internet, vous avez de toute façon besoin d'un Game Server Login Token (GSLT) issu de la gestion des serveurs Steam pour l'App ID 304930. Il fait en outre que le code de serveur de votre serveur reste identique d'un redémarrage à l'autre, au lieu d'être régénéré à chaque démarrage.

Unturned propose par ailleurs une fonction Fake IP. Elle s'active avec "Use_FakeIP": true dans la Config.json, et la commande de console CopyFakeIP fournit l'adresse que vous publiez ensuite. Le trafic passe alors par le réseau de relais Steam Datagram Relay, les adresses attribuées se situent dans la plage 169.254.0.0 à 169.254.255.255, et la véritable adresse du serveur n'est plus montrée aux joueurs. Valve décrit ce trafic comme authentifié, chiffré et limité en débit.

Le prix à payer est élevé et rarement mentionné : l'adresse et le port changent à chaque redémarrage, un nom de domaine ne peut pas pointer dessus sans scripts maison, et les listes Steam « Favoris » et « Historique » ne fonctionnent pas ainsi, seule la fonction de signet reste utilisable. Surtout, la fonction ne protège que le chemin de jeu. Votre serveur conserve sa véritable adresse, et SSH, le panneau web, la base de données et le site restent joignables par elle. Qui connaît l'adresse par un ancien enregistrement DNS, par une page de statut ou par une connexion antérieure l'attaque toujours directement. La fonction Fake IP ne remplace donc pas un filtrage dans le réseau en amont du serveur, elle réduit seulement le nombre de personnes qui connaissent votre adresse.

10. 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 vendredi 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 portrange 27015-27016 -c 200 -q

Pour tcpdump, une règle : limitez toujours avec -c, une capture à pleine charge alourdit encore un serveur déjà surchargé. La façon d'analyser ces valeurs et de distinguer une attaque d'une erreur logicielle est expliquée dans Détecter une attaque DDoS sur son serveur.

Où ces mesures s'arrêtent

Toutes les mesures précédentes s'exécutent sur votre serveur, donc au bout de la liaison. 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 la liaison est pleine dès que quelqu'un envoie davantage. Le fonctionnement normal reste bien en dessous : avec 24 joueurs et les 50 paquets par joueur et par seconde autorisés d'origine, il arrive environ 1 200 paquets par seconde. Un service de booter produit sans la moindre préparation plusieurs fois ce volume.

La deuxième grandeur est le taux de paquets, et il frappe presque toujours plus tôt que la bande passante. Avec de petits paquets de 64 octets, environ 1,49 million de paquets par seconde tiennent dans une liaison à 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 liaison 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 avait disparu ».

Pour situer les ordres de grandeur qui se produisent réellement : sur des serveurs KernelHost ont notamment été filtrés une attaque de plus de 473,4 Gbit/s à plus de 41,5 millions de paquets par seconde contre un serveur vocal et un flood UDP 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, de votre point de vue, exactement au même résultat que l'attaque elle-même. 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 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, 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 27015 UDP (les requêtes) et sur 27016 UDP (le trafic de jeu), 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, par exemple resserrer les requêtes et laisser le trafic de jeu intact.
• Un profil de protection adapté au jeu, tout comme pour les applications modifiées et maison sur n'importe quel port TCP ou UDP, donc aussi pour un plugin doté de son propre port.

Les deux niveaux comparés

Pour la plupart des projets Unturned, 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

« Mon guide dit que je dois ouvrir 27015 à 27017 » : ce guide est antérieur à novembre 2021. Depuis la version 3.21.30.0, un serveur Unturned n'a plus besoin que de deux ports, parce que la requête Steam ne se trouve plus sur le port plus deux. Fermez 27017, sauf si une deuxième instance y tourne.

« Le serveur tourne, mais il n'apparaît plus dans aucune liste de serveurs » : c'est l'image typique d'une inondation de requêtes ou d'une règle personnelle trop stricte sur 27015 UDP. Vérifiez avec iptables -L INPUT -n -v si votre propre règle compte des correspondances. Si les compteurs montent fortement, c'est que vous filtrez vous-même vos entrées de liste. Ne bloquez jamais complètement 27015.

« Tous les joueurs sont éjectés en même temps avec un dépassement de délai » : regardez d'abord si le suivi de connexions a débordé (dmesg -T | grep -i conntrack). Une fois la table pleine, le noyau jette les paquets sans distinction. Timeout_Game_Seconds vaut 30 secondes d'origine : qui revient dans ce laps de temps garde sa place.

« Le serveur redémarre en plein fonctionnement » : c'est rarement une attaque. Cherchez dans le journal le message signalant une mise à jour du Workshop détectée. Should_Monitor_Updates arrête le serveur après le délai par défaut de 600 secondes.

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

« J'ai activé la fonction Fake IP et je suis attaqué malgré tout » : elle masque l'adresse aux nouveaux joueurs, mais elle ne la retire pas au serveur. Qui la connaît par une ancienne entrée de liste, une page de statut ou une connexion antérieure atteint toujours directement votre serveur, tout comme SSH et n'importe quel panneau web installé dessus.

« 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 la liaison est saturée, il se peut que même la session SSH avec laquelle vous vouliez mesurer ne vous parvienne plus. Utilisez alors la console VNC de l'espace client, qui fonctionne indépendamment du réseau du système invité.

En résumé

• Un serveur Unturned a besoin d'exactement deux ports UDP ouverts : le Port défini dans la Commands.dat (27015 par défaut) et cette valeur plus un (27016). Le jeu lui-même n'a pas besoin de TCP.
• Le port 27017 est superflu depuis la version 3.21.30.0 du 21 novembre 2021, parce que la requête Steam ne se trouve plus sur le port plus deux. Qui le laisse encore ouvert suit un guide obsolète.
• Unturned n'a pas de port RCON intégré. Toute commande à distance provient d'un plugin, apporte son propre port TCP et doit être restreinte par vos soins.
• Le port de requête 27015 est le point le plus sensible : une inondation de requêtes rend le serveur invisible dans la liste des serveurs sans toucher un seul joueur, et le protocole Steam a, selon US-CERT TA14-017A, un facteur d'amplification de 5,5.
• Les limites de la Config.json (Max_Packets_Per_Second 50,0, Rate_Limit_Kick_Threshold 10 par 40 secondes) n'agissent que contre les clients qui rejoignent réellement le serveur, pas contre des adresses source falsifiées.
• Une liaison à 1 Gbit/s est pleine à 125 mégaoctets par seconde, et déjà à environ 1,49 million de paquets par seconde avec des paquets de 64 octets. Le fonctionnement normal avec 24 joueurs se situe autour de 1 200 paquets par seconde. Au-delà, c'est le réseau en amont du serveur qui décide, pas votre pare-feu.
• Chez KernelHost, la protection permanente à deux niveaux est comprise sans supplément dans chaque pack serveur et active dès la mise en service, sans null-routing. Qui veut piloter lui-même les règles de filtrage y ajoute l'Advanced DDoS Protection à partir de 50,00 € par mois.

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.