Protéger un serveur Palworld des attaques DDoS

Un serveur Palworld qui éjecte tous les joueurs en même temps en pleine partie le soir, reste hors ligne quelques minutes, puis redevient joignable de lui-même, a rarement un problème de matériel. En règle générale, une attaque est en cours. Cet article montre comment protéger un serveur Palworld des attaques DDoS : d'abord ce que vous pouvez configurer vous-même sans frais supplémentaires, ensuite l'endroit où ces mesures s'arrêtent techniquement, et pour finir ce qui doit se passer dans le réseau, en amont du serveur, pour que celui-ci reste joignable.

Toutes les indications se rapportent au serveur dédié officiel de Pocketpair (ID d'application Steam 2394010) 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, un ordre s'impose : mesurer d'abord, modifier ensuite. Un redémarrage brutal sous charge annule tout ce qui s'est produit dans le monde depuis le dernier point de sauvegarde automatique, et les mesures de l'incident disparaissent elles aussi.

Pourquoi les serveurs Palworld sont ciblés et paralysés par des attaques DDoS

Un serveur Palworld, c'est un public restreint et fidèle à une adresse fixe. Le serveur dédié est limité à 32 joueurs, réglé par ServerPlayerMaxNum dont la plage valide va de 1 à 32. Qui héberge à la place depuis le menu du jeu arrive à quatre joueurs, et seulement tant que l'hôte est lui-même en ligne. De ces 32 places découle tout le reste : le groupe joue à des heures fixes le soir, ses membres se connaissent, et une panne à 20 heures ne touche pas une fraction des joueurs, mais tout le monde.

L'adresse du serveur n'est pas un secret pour autant. Palworld ne connaît aucune intermédiation par un service de l'éditeur : les joueurs saisissent l'adresse IP et le port dans le champ de connexion directe, et qui veut en plus faire figurer le serveur dans la liste des serveurs communautaires le démarre avec -publiclobby et laisse le port de requête répondre. Toute personne qui s'est connectée une fois connaît donc la cible. Un service de booter qui bombarde cette adresse pour quelques euros par mois n'exige de son commanditaire ni compétence ni effort.

S'y ajoute un point technique : l'ensemble du trafic de jeu passe par UDP. UDP ne prévoit aucun établissement de connexion que l'on pourrait exiger, et l'adresse source d'un paquet UDP se falsifie sans peine. Un attaquant n'a donc besoin ni d'entrer sur le serveur ni de s'adresser correctement à lui pour produire de la charge. Ce qui se passe techniquement lors d'une telle attaque, l'article Qu'est-ce qu'une attaque DDoS ? l'explique.

Les ports dont il est réellement question sur un serveur Palworld

Un serveur Palworld a besoin d'exactement un port ouvert : 8211 UDP. Tout le reste est optionnel, et même nuisible selon sa fonction, dès que cela se trouve sur Internet. Il en découle une distinction utile : une attaque DDoS sur le port 8211 touche toujours le trafic de jeu lui-même, une attaque sur le port 27015 UDP ne touche en revanche que l'entrée dans la liste des serveurs.

Tous les réglages correspondants tiennent dans un seul fichier : Pal/Saved/Config/LinuxServer/PalWorldSettings.ini, sous Windows Pal\Saved\Config\WindowsServer\PalWorldSettings.ini. Il commence par la ligne de section [/Script/Pal.PalGameWorldSettings], suivie d'une unique ligne OptionSettings=(...) qui contient l'intégralité des réglages sous forme de liste. Un saut de ligne à l'intérieur de la parenthèse rend toute la configuration invalide, et le serveur retombe sans un mot sur les valeurs par défaut. Le modèle DefaultPalWorldSettings.ini dans le répertoire du serveur ne se modifie pas, car il est écrasé à chaque mise à jour.

Le serveur Palworld en chiffres

Les valeurs suivantes sont la base de toute décision sur les règles de filtrage et les seuils.

Pourquoi le port de requête 27015 est le point le plus sensible

Le port de requête répond aux demandes de statut au format Steam A2S, c'est-à-dire la même requête que servent les serveurs Counter-Strike et ARK. Une requête A2S_INFO est un paquet UDP sans connexion de quelques dizaines d'octets, la réponse avec le nom du serveur, le monde, le nombre de joueurs et l'état de la partie en représente un multiple. Comme l'adresse source se falsifie en UDP, un attaquant peut interroger les ports de requête d'autrui et diriger les réponses, plus grandes, vers sa véritable cible. Votre serveur n'est dans ce cas pas la victime, mais l'amplificateur, et c'est son raccordement qui paie la facture.

Valve a pour cette raison complété A2S_INFO le 8 décembre 2020 par un challenge préalable : le serveur répond d'abord par S2C_CHALLENGE, le demandeur doit renvoyer le jeton et prouve ainsi qu'il ne falsifie pas son adresse source. Cela désamorce l'amplification, mais n'y met pas fin, et contre une simple vague de requêtes identiques provenant d'adresses réelles, elle n'a aucun effet.

Pour Palworld, il en découle un avantage important sur le moteur Source : le trafic de jeu et la requête serveur se trouvent sur des ports séparés. Sur Counter-Strike 2, les deux partagent le port 27015, et une limitation de débit grossière y éjecte les propres joueurs avec le reste. Sur Palworld, vous pouvez limiter durement 27015 UDP ou le fermer entièrement sans toucher au moindre trafic de jeu en cours sur 8211 UDP. Qui n'a pas besoin de l'entrée dans la liste supprime -publiclobby et le port de requête sans les remplacer, et retire ainsi du réseau une surface d'attaque complète.

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

Les étapes suivantes n'arrêtent aucune attaque volumétrique, aucun logiciel installé sur le serveur n'en est capable. Elles balaient en revanche tout ce qui se situe en dessous : scans de ports, vagues de requêtes, tentatives de prise de contrôle par les ports d'administration et occupation des 32 places par des inconnus. C'est la plus grande partie de ce qui perturbe un serveur Palworld au quotidien, et cela coûte une demi-heure.

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

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

ss -lntup

La colonne qui compte est celle de l'adresse locale. 0.0.0.0:8211 signifie « joignable depuis tout Internet », 127.0.0.1:8212 signifie « en local uniquement » et ne demande aucune règle de pare-feu. À côté du processus de jeu, on trouve souvent, sur un serveur qui a vécu, un panneau d'administration, un serveur web pour l'affichage de la carte et une base de données. Le point de vue de l'attaquant, lui, s'obtient par un scan de ports depuis l'extérieur :

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

2. N'ouvrir que ce dont Palworld a réellement besoin

Deux autorisations suffisent, et la seconde est optionnelle. 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 8211/udp comment 'Palworld trafic de jeu'
ufw allow 27015/udp comment 'Palworld requête Steam'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Laissez tomber la troisième ligne si votre serveur ne doit pas figurer dans la liste des serveurs communautaires. Vos joueurs se connectent alors toujours par l'adresse IP et le port 8211, le serveur disparaît simplement de la liste publique. Le guide complet, voie de secours comprise, se trouve dans Configurer le pare-feu UFW sans se bloquer l'accès SSH.

3. Retirer d'Internet RCON sur 25575 et l'API REST sur 8212

Les deux ports sont des accès d'administration avec un contrôle complet du serveur, et tous deux sont désactivés d'origine : RCONEnabled=False et RESTAPIEnabled=False. Qui les active devrait savoir ce qu'il publie.

L'API REST sur 8212 TCP s'authentifie par HTTP Basic Auth avec le nom d'utilisateur fixe admin et la valeur d'AdminPassword, et ce sur du HTTP non chiffré. Le mot de passe d'administration circule donc sur la ligne sous forme réversible à chaque requête. RCON sur 25575 TCP est un protocole en texte tout aussi peu chiffré, et Pocketpair l'a marqué comme obsolète au profit de l'API REST. Pour les nouvelles installations, l'API REST est le bon choix ; pour les deux vaut la même règle : pas sur le réseau ouvert.

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="une valeur longue et aléatoire"

Vous rendez l'interface joignable par une redirection de port SSH, puis vous travaillez localement contre 127.0.0.1:8212 :

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

Ne laissez jamais AdminPassword vide, car vide est le réglage par défaut. Une valeur issue d'openssl rand -base64 32 suffit. Il en va de même pour ServerPassword, nous y venons tout de suite.

4. Limiter le port de requête 27015 sans perdre l'entrée dans la liste

Les paquets Steam sans connexion commencent par quatre octets à un (0xffffffff), le trafic de jeu ordinaire n'a pas cet en-tête. On peut poser là-dessus une limitation de débit par adresse source qui freine les requêtes et conserve l'entrée dans la liste. Avec nftables, chargé par nft -f :

table inet palworld {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

La priorité -10 fait en sorte que la règle s'applique avant la chaîne de filtrage d'UFW, et @th,64,32 lit les quatre premiers octets derrière l'en-tête UDP. Avec iptables classique, la même séparation s'obtient par une comparaison sur la signature d'A2S_INFO :

iptables -A INPUT -p udp --dport 27015 \
  -m string --algo bm --hex-string "|ffffffff54536f7572636520456e67696e6520517565727900|" \
  -m hashlimit --hashlimit-name a2sflood --hashlimit-mode srcip \
  --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Dix requêtes par seconde et par adresse sont largement dimensionnées : un service de liste interroge d'ordinaire toutes les quelques minutes, pas plusieurs fois par seconde. L'important est seulement que cette règle porte sur 27015 et non sur 8211, faute de quoi vous touchez vos propres joueurs.

5. Limiter les débits de paquets sur 8211 UDP

Sur le port de jeu lui-même, un plafond par adresse source agit contre les petites vagues venant de quelques sources. Chez Palworld, cette limite se pose avec relativement peu de risque, parce que 32 joueurs au maximum sont connectés en même temps et que chacun d'eux occupe exactement une adresse source :

iptables -I INPUT -p udp --dport 8211 \
  -m hashlimit --hashlimit-name palworld_udp --hashlimit-mode srcip \
  --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

Le chiffre est une valeur de départ, pas une vérité. Un serveur plein avec 32 joueurs et de nombreuses bases produit nettement plus de paquets qu'une partie à quatre, et qui règle trop serré éjecte ses propres joueurs. Mesurez d'abord pendant une semaine en fonctionnement normal, puis fixez la limite au double de la valeur de pointe mesurée.

Les règles iptables seules disparaissent après un redémarrage. Sous Debian et Ubuntu, vous les enregistrez ainsi :

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

Sous UFW, de telles règles ont en plus leur place dans /etc/ufw/before.rules, faute de quoi elles disparaissent au prochain ufw reload. iptables -L INPUT -n -v montre si une règle est seulement atteinte : si les compteurs de correspondances restent à zéro, elle ne s'applique pas.

6. Mot de passe du serveur, liste de bannissement et les 32 places contre l'épuisement des slots

L'épuisement des slots est l'attaque la moins chère contre un serveur Palworld, et elle ne demande aucune bande passante. Un serveur dédié a 32 places au maximum, donc 32 connexions simultanées suffisent à exclure toute la communauté. Une attaque volumétrique coûte de l'argent au commanditaire, 32 sessions ne lui coûtent rien. Cela rend cette voie plus attrayante pour les petits serveurs que n'importe quelle vague de paquets.

Palworld n'a pas de liste blanche intégrée. Les outils de modération sont l'expulsion, le bannissement et un mot de passe de serveur, et c'est précisément le mot de passe du serveur qui est la mesure isolée la plus efficace contre l'épuisement des slots :

ServerPassword="une valeur que seul votre groupe connaît"
ServerPlayerMaxNum=32
bShowPlayerList=True
BanListURL="https://api.palworldgame.com/api/banlist.txt"

ServerPassword est vide d'origine, tout le monde entre donc avec l'adresse IP et le port. BanListURL pointe par défaut sur la liste entretenue par Pocketpair et peut être redirigé vers votre propre fichier texte si vous voulez tenir des bannissements propres au projet. Ne poussez pas ServerPlayerMaxNum au-delà de 32 : des valeurs plus élevées ne sont pas prises en charge et se retournent contre vous à la prochaine mise à jour au plus tard. Et une chose doit être claire : un mot de passe de serveur protège vos places, pas votre raccordement. Un attaquant qui inonde votre serveur ne cherche pas du tout à le rejoindre.

7. Soulager le suivi de connexions et agrandir les tampons

Ce point explique des pannes qui ressemblent à une attaque volumétrique sans en être une. Le noyau crée pour le trafic UDP des entrées dans le suivi de connexions (conntrack), et avec des adresses sources falsifiées, chaque adresse signifie une nouvelle entrée. Lorsque la table est pleine, le noyau rejette les paquets sans distinction, l'attaque et vos joueurs sortent ensemble, 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

L'étape la plus efficace consiste à ne pas faire suivre le trafic de jeu du tout, car Palworld gère lui-même ses sessions :

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport { 8211, 27015 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 8211, 27015 } notrack
    }
}

Avec iptables, l'équivalent est iptables -t raw -A PREROUTING -p udp --dport 8211 -j NOTRACK et la même ligne pour OUTPUT avec --sport. Les ports ont ensuite besoin d'une autorisation explicite, car sans suivi, plus aucune règle qui vérifie un état existant ne s'applique. Si les paquets arrivent plus vite que le processus serveur ne les récupère, le tampon de réception déborde en plus. Pour les joueurs, cela ressemble à de la perte de paquets alors que le raccordement est libre. Un complément sous /etc/sysctl.d/, activé avec sysctl -p :

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

Le noyau lui-même dit si ces valeurs sont nécessaires : si UdpRcvbufErrors augmente dans nstat -az, elles agissent. Si le compteur reste à zéro, l'ajustement ne change rien.

8. Collecter des mesures avant que la situation ne devienne sérieuse

L'étape la plus importante est celle que presque personne ne franchit à l'avance : constituer une base de comparaison tant que tout fonctionne normalement. Sans valeur de référence, vous ne pourrez pas dire après un incident si 40 000 paquets par seconde représentaient beaucoup, ou simplement un samedi soir. Avec apt-get install -y vnstat sysstat, la mesure tourne en permanence. Pendant un incident, quatre commandes suffisent :

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 -c 200 "udp port 8211 or udp port 27015"

Pour tcpdump, une règle : limitez toujours avec -c, car une capture à pleine charge alourdit encore un serveur déjà surchargé. Palworld fournit en plus une grandeur de mesure qu'aucun autre outil n'offre. Si l'API REST est activée, le point d'accès de métriques renvoie notamment la fréquence d'images du serveur, le nombre de joueurs actuel et la durée de fonctionnement :

curl -s -u admin:VOTRE_MOT_DE_PASSE_ADMIN http://127.0.0.1:8212/v1/api/metrics

Ce seul chiffre sépare proprement les deux causes les plus fréquentes. Si la fréquence d'images du serveur s'effondre alors que les débits de paquets restent normaux, ce n'est pas une attaque, mais de la charge ou la hausse connue de la consommation mémoire du processus serveur. Si la fréquence d'images reste stable alors que les paquets entrants montent bien au-dessus de la valeur habituelle, c'est une attaque. La façon d'interpréter les valeurs réseau en détail 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. Les attaques contre les projets de serveurs de jeu se situent d'ordinaire entre 5 et 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 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 un raccordement à 1 Gbit/s. Selon le processeur 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 malgré tout paralyser votre serveur, parce que le temps de calcul part dans le rejet des paquets. Les exploitants vivent cela comme « la charge n'était même pas élevée, et pourtant tout avait disparu », et chez Palworld cela se manifeste d'abord par des pics de lag, et seulement ensuite par une rupture de connexion.

Sur un serveur Palworld s'ajoute un rapport défavorable. Un serveur plein avec 32 joueurs n'occupe qu'une fraction d'un raccordement à 1 Gbit/s. L'attaque n'a donc pas besoin d'être grande pour atteindre un multiple du fonctionnement normal, et c'est exactement pour cela que des attaques qui passeraient inaperçues sur une grande plateforme suffisent ici.

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 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 comprise dans chaque pack 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. Palworld fait partie des jeux dotés d'un profil de protection propre ; les autres titres et protocoles couverts sont listés dans Protection DDoS des serveurs de jeu en temps réel.

Advanced DDoS Protection pour les projets Palworld 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 8211 UDP et ce qui l'est 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, par exemple limiter temporairement le port de requête plus durement et laisser le port de jeu intact.
• Un profil de protection adapté au jeu, pour Palworld comme pour vos propres applications sur n'importe quel port TCP ou UDP.

L'Advanced DDoS Protection s'adresse aux serveurs hébergés chez KernelHost. Qui exploite actuellement son projet Palworld ailleurs et se fait attaquer en continu le transfère chez KernelHost, et les deux niveaux agissent alors dès la mise en service.

Les deux niveaux comparés

Pour la plupart des serveurs Palworld, 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 sur les serveurs Palworld et leurs solutions

« J'ai bloqué 27015 et le serveur a maintenant disparu de la liste communautaire » : c'est le comportement attendu, car le port de requête porte l'entrée dans la liste. Ne le bloquez pas en bloc, limitez plutôt les paquets sans connexion par adresse source, comme à l'étape 4. Si vous n'avez de toute façon pas besoin de l'entrée dans la liste, laissez le port fermé, supprimez -publiclobby et donnez à vos joueurs l'adresse IP et le port 8211 pour la connexion directe.

« 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. Chez Palworld, c'est presque toujours l'une de trois voies : un joueur qui a de toute façon l'adresse dans son champ de connexion directe, un bot Discord affichant le statut qui la republie, ou un ancien enregistrement A dans le DNS qui pointe vers l'adresse précédente. Un changement d'adresse fait gagner du temps, ce n'est pas une solution.

« Le serveur a des pics de lag, mais le raccordement est calme » : chez Palworld, c'est plus souvent de la charge qu'une attaque. Le processus serveur occupe régulièrement plus de mémoire au fil de son exécution, raison pour laquelle un redémarrage planifié fait partie du fonctionnement normal et n'est pas à comprendre comme un expédient. Vérifiez la fréquence d'images du serveur par le point d'accès de métriques et la consommation mémoire du processus. Si sar -n DEV 1 10 reste normal pendant ce temps, ce n'était pas une attaque DDoS.

« Les 32 places sont occupées, mais on ne voit personne en jeu » : c'est l'épuisement des slots, et il touche la logique du jeu, pas le raccordement. Définissez un ServerPassword, bannissez les comptes suspects par la liste de bannissement et limitez les paquets par adresse source sur 8211 UDP.

« L'API REST est restée joignable de l'extérieur pendant quelques jours » : alors votre mot de passe d'administration est compromis, car HTTP Basic Auth sur du HTTP non chiffré le transmet sous forme réversible à chaque requête. Changez AdminPassword, fermez 8212 TCP vers l'extérieur et n'atteignez plus l'interface que par une redirection de port SSH.

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

« 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 Palworld a besoin d'exactement un port ouvert : 8211 UDP. Le port de requête 27015 UDP n'est nécessaire que pour l'entrée dans la liste des serveurs communautaires.
• RCON sur 25575 TCP et l'API REST sur 8212 TCP n'ont jamais leur place sur le réseau ouvert, car tous deux transmettent leurs identifiants en clair. RCON est en outre marqué comme obsolète par Pocketpair.
• Parce que le trafic de jeu et la requête serveur se trouvent sur des ports séparés chez Palworld, 27015 UDP se laisse limiter durement sans toucher au trafic de jeu en cours sur 8211 UDP.
• Le serveur dédié est limité à 32 places, ce qui fait de l'épuisement des slots l'attaque la moins chère. Un ServerPassword défini est la mesure isolée la plus efficace contre cela, car Palworld n'a pas de liste blanche intégrée.
• Les mesures locales s'arrêtent au raccordement : 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 y tiennent. Tout ce qui dépasse doit s'arrêter dans le réseau, en amont du serveur.
• Chez KernelHost, la protection permanente à deux niveaux est comprise dans chaque pack serveur sans supplément et active dès la mise en service, sans null-routing. L'Advanced DDoS Protection, avec IP protégée dédiée et règles par port gérées par vos soins, débute à 50,00 € par mois.

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