Protéger un serveur Project Zomboid des attaques DDoS

Qui veut protéger son serveur Project Zomboid des attaques DDoS doit d'abord savoir sur quoi un attaquant tire réellement. Un serveur dédié occupe exactement deux ports UDP, 16261 et 16262, et tous deux doivent être ouverts sur le réseau, faute de quoi personne ne peut se connecter. Cet article procède dans l'ordre qui compte le jour où cela arrive : d'abord ce que vous pouvez faire vous-même dans les dix prochaines minutes sans frais supplémentaires, ensuite l'endroit où ces mesures s'arrêtent techniquement, et pour finir ce qui doit se passer en amont, dans le réseau.

Toutes les indications se rapportent au serveur dédié (application Steam 380870) sous Debian 12, Debian 13, Ubuntu 22.04 LTS ou Ubuntu 24.04 LTS, pour la build 41 comme pour la build 42. Le fichier de configuration s'appelle servertest.ini et se trouve sous ~/Zomboid/Server/, les données du monde sous ~/Zomboid/Saves/Multiplayer/. 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 maintenant dans la servertest.ini et ne redémarrez pas le serveur. Sauvegardez d'abord vos mesures (section 9), après l'attaque elles auront disparu. Un redémarrage coûte en plus le temps dont le serveur a besoin pour charger le monde, et c'est précisément ce temps que l'attaquant veut vous prendre.

Pourquoi les serveurs Project Zomboid deviennent la cible d'attaques DDoS

Project Zomboid est un jeu à mort définitive dont le monde continue d'évoluer pendant des mois. Une coupure de connexion au milieu d'une situation dangereuse y coûte plus cher que dans presque tout autre genre : le personnage est perdu, et le monde s'en souvient. C'est exactement ce qui transforme une panne en arme. Une attaque à 20 heures touche une communauté fidèle, et elle la touche à l'endroit où elle a le plus à perdre.

S'y ajoute que l'attaque elle-même ne coûte rien et n'exige aucune compétence. Les services d'attaque à la demande, appelés booters ou stressers dans le milieu, se dirigent en quelques clics contre une adresse IP et un port, et chez Project Zomboid la cible est toujours la même : 16261 UDP. Qui est en conflit avec un joueur banni ou qui exploite une communauté concurrente tient là un outil pour lequel il n'a besoin ni de savoir ni d'argent notable.

S'y ajoute encore qu'un serveur de jeu doit publier son adresse. Si Public=true figure dans la servertest.ini, le serveur apparaît dans le navigateur du jeu, et un serveur relié à Steam est de toute façon visible dans le navigateur de serveurs Steam. La question n'est donc jamais de savoir si un attaquant trouvera votre adresse IP, mais seulement ce qui se passe quand il tire dessus.

Techniquement, la partie la plus désagréable vient à la fin : l'ensemble du trafic de jeu passe par UDP. UDP ne prévoit aucun établissement de connexion que l'on pourrait exiger, chaque paquet se suffit à lui-même, et l'adresse source 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. Ce qu'est une attaque DDoS en détail, l'article Qu'est-ce qu'une attaque DDoS ? l'explique.

Les ports dont un serveur Project Zomboid a réellement besoin

Un serveur Project Zomboid dédié a besoin d'exactement deux ports ouverts : 16261 UDP et 16262 UDP. La liste officielle des ports du jeu n'en nomme pas de troisième. Dans la servertest.ini, ils figurent comme deux directives distinctes, le second port ne découle pas automatiquement du premier :

DefaultPort=16261
UDPPort=16262
SteamPort1=8766
SteamPort2=8767
RCONPort=27015
RCONPassword=

La répartition des rôles est claire. 16261 UDP porte le trafic de jeu et l'établissement des connexions, et répond aux requêtes du navigateur de serveurs. 16262 UDP est le port de la connexion directe des clients. Si le premier manque, personne ne trouve le serveur ; si le second manque, vos joueurs voient l'entrée et n'entrent pourtant pas. C'est précisément de là que vient le message d'erreur le plus connu du jeu, indiquant que le port 16262 serait fermé.

Deux points causent régulièrement des ennuis. Premièrement : chaque instance de serveur a besoin de deux ports UDP libres. Qui exploite un deuxième monde sur la même machine attribue pour cela une deuxième paire, par exemple 16274 et 16275, et inscrit les deux valeurs dans la servertest.ini de la deuxième instance. Deuxièmement : SteamPort1 et SteamPort2 figurent avec 8766 et 8767 dans le fichier de configuration, mais relèvent du raccordement à Steam et non du trafic de jeu. Ne les ouvrez que si votre serveur n'apparaît pas dans la liste Steam sans eux, et non par précaution.

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 proprement configuré encaisse par ses propres moyens les attaques petites et moyennes, quel que soit l'hébergeur chez qui il se trouve. Il ne vous épargne aucune attaque volumétrique, mais il fait en sorte que les attaques bon marché restent sans effet et que vous disposiez de chiffres plutôt que de suppositions le jour venu.

1. État des lieux : qu'est-ce qui écoute réellement

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:16261 et [::]:16261 signifient « joignable depuis tout Internet », 127.0.0.1:27015 signifie « en local uniquement » et ne demande aucune autorisation. Comparez le résultat à votre configuration au lieu de vous fier aux valeurs par défaut :

grep -E "^(DefaultPort|UDPPort|SteamPort1|SteamPort2|RCONPort|Public|Open|MaxPlayers|MaxAccountsPerUser)=" ~/Zomboid/Server/servertest.ini

Le point de vue de l'attaquant s'obtient par un scan de ports depuis l'extérieur. Comme Project Zomboid n'utilise que de l'UDP, il faut pour cela le scan UDP : un simple scan TCP ne montre pas du tout le port de jeu :

nmap -Pn -sU -p 16261,16262,8766,8767 ADRESSE.IP.DE.VOTRE.SERVEUR
nmap -Pn -p- --min-rate 1000 ADRESSE.IP.DE.VOTRE.SERVEUR

2. Ne laisser ouverts que 16261 et 16262

Deux autorisations 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 16261/udp comment "Project Zomboid"
ufw allow 16262/udp comment "Project Zomboid connexion directe"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Remplacez 203.0.113.10 par votre propre adresse. L'ordre au moment de l'activation décide si vous vous bloquez vous-même ou non. Il figure, avec la voie de retour, dans l'article Configurer le pare-feu UFW sans se bloquer l'accès SSH. Si cela arrive malgré tout : sur les serveurs root KVM et les serveurs dédiés de KernelHost, vous atteignez le système par la console VNC dans l'espace client, qui fonctionne indépendamment du réseau du système invité.

Un mot sur les bases de données et les services annexes : Project Zomboid n'en a besoin d'aucun. Ce qui écoute sur 0.0.0.0 à côté du jeu provient d'une installation antérieure ou d'un panneau d'administration, et doit être soit attaché à 127.0.0.1, soit désactivé.

3. Retirer d'Internet RCON sur le port 27015

RCON est le contrôle à distance du serveur et tourne chez Project Zomboid sur 27015 TCP. Dans la servertest.ini livrée, RCONPassword= figure sans valeur. Qui utilise RCON définit un long mot de passe aléatoire, car le protocole transmet en clair, et un port RCON joignable avec un mot de passe faible livre le serveur en entier sans qu'un seul paquet de trafic d'attaque soit nécessaire.

La voie sûre consiste à ne pas ouvrir le port vers l'extérieur et à l'atteindre par une redirection de port via SSH. Vous dialoguez ensuite localement avec 127.0.0.1:27015 :

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

Qui n'a pas besoin de RCON laisse le champ du mot de passe vide et le port fermé. Un service qui n'est pas joignable ne peut être ni forcé ni inondé.

4. Limiter les débits de paquets par adresse source

Contre les petites attaques et les bots mal écrits, un plafond par adresse source fait le travail. Comme les deux ports de jeu sont voisins, une seule règle suffit pour la plage :

iptables -I INPUT -p udp --dport 16261:16262 -m hashlimit --hashlimit-name pz_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP
iptables -L INPUT -n -v

La règle rejette les paquets UDP dès que la même adresse source envoie durablement plus de 400 paquets par seconde. La valeur est une valeur de départ, pas une vérité : un serveur avec 30 joueurs dans la même ville produit nettement plus de trafic qu'un serveur avec quatre joueurs dispersés aux quatre coins de la carte, et qui règle trop serré éjecte ses propres joueurs. Mesurez d'abord pendant une semaine en fonctionnement normal, puis fixez la limite à plusieurs fois la valeur de pointe.

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

Et sous UFW, de telles règles ont leur place dans /etc/ufw/before.rules, faute de quoi elles disparaissent au prochain ufw reload. Vérifiez avec les compteurs de correspondances d'iptables -L INPUT -n -v si la règle est seulement atteinte. Si les compteurs restent à zéro, elle est au mauvais endroit.

5. Soulager le suivi de connexions

Un goulot d'étranglement souvent négligé se situe dans le noyau. Le suivi de connexions crée aussi pour l'UDP une entrée par adresse source et par port, et un flood aux expéditeurs falsifiés remplit cette table en quelques secondes. Lorsqu'elle déborde, 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

Le trafic de jeu de Project Zomboid n'a besoin d'aucun suivi d'état, parce qu'UDP n'a pas d'état. Vous pouvez donc tenir les deux ports de jeu hors de la table :

iptables -t raw -I PREROUTING -p udp --dport 16261:16262 -j NOTRACK

Cela soulage sensiblement le noyau. Important : la règle ne convient que tant que le serveur reçoit les paquets directement. Qui exploite une traduction d'adresses en amont, par exemple dans un montage en conteneurs avec transfert de ports, ne doit pas la poser, car le sens retour n'est alors plus attribué.

6. Sécuriser l'arrivée des joueurs et les slots

Les lignes suivantes ne coûtent rien et agissent contre tout ce qui emprunte la voie d'arrivée normale :

Password=UN-LONG-MOT-DE-PASSE-ALEATOIRE
Open=false
MaxAccountsPerUser=1
MaxPlayers=32
DenyLoginOnOverloadedServer=true

Password est le mot de passe commun du serveur, distinct du compte de chaque joueur. Open=false signifie que seuls les comptes créés au préalable par un administrateur peuvent se connecter, c'est la liste blanche du jeu. MaxAccountsPerUser limite le nombre de comptes qu'un seul utilisateur Steam peut créer sur votre serveur, la valeur par défaut 0 signifiant illimité. MaxPlayers est à 32 d'origine, et au-delà la documentation met expressément en garde contre un mauvais rechargement de la carte et de la désynchronisation.

PingLimit est le piège à cet endroit. La directive éjecte les joueurs à partir d'une latence exprimée en millisecondes et vaut 0 d'origine, donc désactivée. Sous une attaque, la latence de vos propres joueurs monte en premier : une valeur serrée expulse donc exactement les gens que vous voulez garder. Laissez cette limite désactivée ou fixez-la largement.

Et une chose doit être claire : une liste blanche protège votre logique de jeu, 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.

7. La vérification des mods à la connexion est la seconde la plus coûteuse de votre serveur

Project Zomboid vérifie plus qu'un mot de passe au moment de la connexion. La liste des mods du serveur tient dans deux lignes de la servertest.ini : WorkshopItems contient les identifiants numériques du Workshop, Mods les identifiants de chargement des mods, les deux séparés par des points-virgules. À l'arrivée, le client compare cette liste, télécharge automatiquement via Steam les contenus Workshop manquants, et ne reçoit qu'ensuite les données du monde en flux. De plus, avec DoLuaChecksum=true, le serveur compare les sommes de contrôle des fichiers de jeu et éjecte les clients dont les fichiers ne correspondent pas aux siens.

C'est précisément ce qui intéresse un attaquant, car le travail a lieu avant la participation effective à la partie. Chaque tentative de connexion coûte au serveur du temps de calcul pour la version, la somme de contrôle, la liste des mods et les données de la carte, y compris la tentative qui finit par être rejetée. Une longue liste de mods rend chacune de ces tentatives plus coûteuse. Un flood de connexions est donc plus efficace sur un serveur fortement modifié que sur un serveur d'origine, et il lui faut pour cela une fraction de la bande passante d'une attaque volumétrique. Le jeu apporte contre cela deux freins intégrés :

DenyLoginOnOverloadedServer=true
LoginQueueEnabled=true
LoginQueueConnectTimeout=60

DenyLoginOnOverloadedServer refuse les nouvelles connexions tant que le serveur est surchargé, au lieu d'emporter la partie en cours avec lui. LoginQueueEnabled place les arrivants dans une file d'attente au lieu de les traiter simultanément, et LoginQueueConnectTimeout définit la durée maximale d'une arrivée, par défaut 60 secondes, les valeurs autorisées allant de 20 à 1200.

Un détail mérite d'être mentionné, parce qu'il est souvent mal résolu : sur les serveurs Linux, il existe un bogue documenté où DoLuaChecksum déclenche de fausses alertes et n'admet pas les joueurs. Des exploitants désactivent donc la vérification. C'est compréhensible, mais cela retire un contrôle qui tient à distance les clients aux fichiers de jeu modifiés. Qui doit la désactiver devrait d'autant plus durcir le mot de passe du serveur, la liste blanche et la limite de comptes.

8. Liste des serveurs, UPnP et votre propre adresse

Ici, mieux vaut l'honnêteté que la pensée magique : votre adresse IP ne peut pas rester secrète. Public=true montre le serveur dans le navigateur du jeu, et un serveur relié à Steam est, selon la documentation, de toute façon visible dans le navigateur de serveurs Steam. Public=false vous prive donc de visibilité auprès des nouveaux joueurs sans vous rendre invisible.

Public=true
PublicName=Mon serveur Zomboid
UPnP=false
server_browser_announced_ip=

UPnP vaut true d'origine et laisse le serveur tenter d'ouvrir lui-même un port sur une passerelle Internet. Sur un serveur loué, une telle passerelle n'existe pas, la tentative n'aboutit à rien et doit être désactivée. server_browser_announced_ip reste vide, sauf si votre serveur a plusieurs adresses et doit apparaître sous l'une d'elles en particulier. C'est exactement ce champ que vous retrouverez plus tard, lorsque vous basculerez sur une IP protégée dédiée.

Deux habitudes aident plus que n'importe quel réglage. Ne publiez nulle part vous-même l'adresse IP brute, donc ni dans le canal Discord ni sur la page du projet, et donnez un nom d'hôte à vos joueurs. Le grand classique lors d'un changement d'adresse reste les anciens enregistrements DNS : un enregistrement A oublié qui pointe vers l'adresse précédente rend tout changement inopérant.

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 tout est calme. 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
tcpdump -ni eth0 "udp port 16261 or udp port 16262" -c 200 -q
journalctl -u zomboid --since "-15 min" | tail -50

Les deux premières montrent le débit de paquets et les compteurs de rejets de l'interface, la troisième un court échantillon du trafic, la quatrième les messages du serveur, pour autant qu'il tourne comme service systemd (adaptez le nom du service). 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.

Où ces mesures s'arrêtent : bande passante et débit 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. La deuxième grandeur est le débit 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 1 Gbit/s, alors qu'un noyau de serveur normal n'en traite, selon le processeur et la carte réseau, que quelques centaines de milliers avant de commencer à rejeter. Une attaque qui ne remplit même pas un tiers de votre raccordement peut donc paralyser votre serveur. Les exploitants vivent cela comme « la charge n'était même pas élevée, et pourtant tout avait disparu ».

Les attaques habituelles contre les communautés de serveurs de jeu se situent entre 5 et 50 Gbit/s, soit cinq à cinquante fois un raccordement normal. 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 aux attaques DDoS sur les serveurs de jeu

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. 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é, vous inscrivez simplement la nouvelle adresse là où vos joueurs trouvent le serveur.
• Des règles de protection par port et par protocole, que vous gérez vous-même dans l'espace client : vous définissez ce qui est autorisé sur 16261 et 16262 UDP, et tout le reste reste fermé, 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.
• Un profil de protection adapté. Pour les jeux courants, des profils prêts à l'emploi existent ; pour les applications modifiées ou maison, vous posez vous-même les règles par port et par protocole. Project Zomboid se laisse d'ailleurs délimiter très précisément, parce que l'ensemble du trafic de jeu passe par deux ports UDP voisins.

Les deux niveaux comparés

Pour la plupart des serveurs Project Zomboid, 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

« Mes joueurs reçoivent le message indiquant que le port 16262 est fermé » : ce n'est pas une attaque, mais une autorisation manquante. Le serveur a besoin des deux ports, 16261 UDP et 16262 UDP, et ce en règle UDP. Une autorisation TCP sur les mêmes numéros ne produit aucun effet. Vérifiez avec ufw status verbose et un scan UDP depuis l'extérieur que les deux sont bien ouverts.

« 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 l'entrée dans la liste des serveurs, un bot Discord affichant le statut ou un ancien enregistrement DNS. Chez Project Zomboid, le changement coûte en plus : les clients déposent les données de la carte localement sous l'adresse et le port, dans un dossier du type 123.45.0.12_16261_... sous Zomboid/Saves. Après un changement, chaque joueur retélécharge la carte explorée depuis le serveur. Un changement d'adresse fait donc gagner du temps à un coût supplémentaire, ce n'est pas une solution.

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

« Des joueurs sont éjectés à la connexion, mais le serveur continue de tourner normalement » : c'est presque toujours la vérification, et non une attaque. Les causes sont un écart de version entre client et serveur, une entrée Workshop manquante ou obsolète, ou une somme de contrôle qui ne correspond pas. Le client nomme en général les mods qui ne concordent pas. Comparez WorkshopItems et Mods ligne par ligne.

« Des pics de lag toutes les quelques minutes, puis cela repart » : c'est le schéma habituel des attaques courtes, qui ne durent que le temps nécessaire pour que les joueurs abandonnent, excédés. Regardez d'abord les compteurs réseau, pas la charge du processeur. Si sar -n DEV 1 10 et les compteurs de rejets restent normaux, ce n'était pas une attaque, mais de la charge : trop de joueurs dans la même cellule, un mod coûteux ou trop peu de mémoire vive pour l'instance Java.

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

En résumé

• Un serveur Project Zomboid dédié a besoin d'exactement deux ports ouverts : 16261 UDP (DefaultPort) et 16262 UDP (UDPPort). Les deux figurent comme directives distinctes dans la servertest.ini.
• RCON tourne sur 27015 TCP et est inscrit d'origine sans mot de passe. Ce port n'a pas sa place sur l'Internet ouvert : il doit être restreint à votre propre adresse ou fermé.
• La vérification des mods à la connexion est l'endroit le plus coûteux : version, somme de contrôle, liste Workshop et données de carte consomment du temps de calcul, y compris à chaque tentative rejetée. DenyLoginOnOverloadedServer et la file d'attente d'arrivée sont les freins intégrés contre cela.
• Le mot de passe du serveur, Open=false et MaxAccountsPerUser=1 protègent la logique de jeu. Contre un raccordement saturé, aucun de ces réglages n'agit.
• La limite physique est fixe : 1 Gbit/s, c'est 125 mégaoctets par seconde et, avec des paquets de 64 octets, environ 1,49 million de paquets par seconde. Les attaques habituelles contre les serveurs de jeu se situent entre 5 et 50 Gbit/s.
• Les attaques volumétriques doivent s'arrêter dans le réseau, en amont du serveur. Chez KernelHost, ce sont 17 Tbps de capacité de mitigation dans le réseau de scrubbing mondial et un filtrage Arbor en temps réel à 3,2 Tbps à Francfort-sur-le-Main, sans supplément et sans null-routing.
• Qui se fait attaquer en continu pilote le filtrage lui-même avec l'Advanced DDoS Protection : IP protégée dédiée, règles par port et par protocole, changements en temps réel, à partir de 50,00 € par mois.

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