Protéger un serveur Hytale des attaques DDoS

Un serveur Hytale qui perd toutes ses connexions en même temps le soir, en pleine partie, reste injoignable quelques minutes puis repart 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 Hytale 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 Hypixel Studios, donc à HytaleServer.jar accompagné de Assets.zip sous Java 25, exploité sur 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. Hytale est en Early Access et évolue vite : c'est pourquoi, dans cet article, chaque affirmation sur le jeu porte une date, et tout ce qui n'est pas officiellement établi est expressément signalé comme une attente ou comme une source communautaire. Si l'attaque est en cours, un ordre s'impose en outre : mesurer d'abord, modifier ensuite. Un redémarrage brutal sous charge rejette tout ce qui s'est passé dans le monde depuis le dernier point de sauvegarde, et les mesures de l'incident auront elles aussi disparu.

Pourquoi les serveurs Hytale sont ciblément paralysés par des attaques DDoS

Un serveur Hytale est un public à une adresse fixe, et ce public est remplaçable. Qui n'arrive pas trois soirs de suite sur son serveur habituel s'en cherche un autre. C'est exactement là le modèle économique derrière les attaques contre les serveurs communautaires : il n'est question ni de données ni de chantage, mais de joueurs qui s'en vont. Un service de booter qui bombarde une adresse pour quelques euros par mois n'exige du donneur d'ordre ni compétence ni effort, et le dommage se reproduit à chaque panne.

S'y ajoute chez Hytale une particularité : le code du serveur est public. Hypixel Studios a annoncé en juin 2026 le programme Hytale Shared Source et met à disposition par ce biais le code complet du serveur, le protocole réseau et les assets via GitHub, accessibles à quiconque dispose d'une licence de jeu valide. Pour les exploitants de serveurs, c'est un gain, parce que les plugins se construisent sur de vraies interfaces. Pour le camp des attaquants, cela signifie que personne n'a plus besoin de deviner le protocole. Qui veut savoir à quel endroit l'établissement de connexion coûte du temps de calcul peut le lire. Ce qui se passe techniquement lors d'une telle attaque, l'article Qu'est-ce qu'une attaque DDoS ? l'explique.

L'état de Hytale au 27 septembre 2026

Hytale est en Early Access depuis le 13 janvier 2026, disponible pour Windows, macOS et Linux, et a dépassé le million de joueurs dans les jours qui ont suivi le lancement. Le chemin qui y a mené a été inhabituel, et il explique pourquoi les articles plus anciens sur Hytale sont souvent faux aujourd'hui.

La conséquence pratique de cette chronologie : un serveur Hytale d'aujourd'hui n'est pas un serveur de janvier. Avec l'Update 6, le protocole réseau est passé de hytale/2 à hytale/3, et selon les Patch Notes officielles du 27 août 2026, le serveur et les plugins doivent être reconstruits avant de pouvoir se connecter. Qui planifie sa disponibilité ne planifie donc pas seulement contre les attaques, mais aussi contre les changements de protocole.

Pourquoi le 12 octobre 2026 est la date critique

Les grandes mises à jour de contenu agissent comme un second lancement commercial. Elles ramènent les anciens joueurs, en attirent de nouveaux, et pendant quelques jours la joignabilité décide de quel serveur communautaire grandit avec cette vague et lequel la manque. Ce schéma est établi chez d'autres jeux : Palworld a atteint des millions de joueurs en quelques jours en janvier 2024, et les serveurs communautaires de cette phase de lancement ont été les plus attaqués précisément au moment où ils avaient le plus à perdre. La mécanique derrière tout cela est décrite en détail dans Protéger un serveur Palworld des attaques DDoS et se transpose telle quelle à Hytale.

Il en découle une vérité inconfortable sur le calendrier : une protection commandée le 12 octobre arrive trop tard. Un raccordement, une IP protégée, un jeu de règles par port et une mesure de référence en fonctionnement normal demandent du temps d'avance, parce qu'ils ne peuvent pas être réglés utilement sans données de comparaison. Qui commence deux semaines avant une grande mise à jour a assez de temps. Qui commence le jour de la mise à jour règle à l'aveugle.

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

Un serveur Hytale a besoin d'exactement un port ouvert : 5520 UDP. Le trafic de jeu passe par QUIC, donc par UDP, et TCP n'est pas nécessaire au trafic de jeu. Qui n'ouvre que TCP voit le même tableau qu'avec un pare-feu fermé : les joueurs tombent dans une expiration de délai. L'attache par défaut est 0.0.0.0:5520, un autre port se définit au démarrage avec --bind.

Ce tableau est plus court que chez la plupart des autres jeux, et c'est là la différence la plus importante. Un serveur Counter-Strike répond aux requêtes de statut au format Steam A2S, un serveur Minecraft Bedrock répond à un Unconnected Ping, un serveur Palworld tient un port de requête propre ouvert. Pour Hytale, aucun autre port que 5520 UDP n'est décrit dans la documentation publique : pas de port de requête, pas de port RCON, pas d'interface REST à l'état de livraison. Tout ce qu'un serveur Hytale propose vers l'extérieur se trouve sur un seul port UDP.

Le serveur Hytale en chiffres

Les valeurs suivantes sont la base de toute décision sur les règles de filtrage et les valeurs limites. La provenance est indiquée à chaque fois, parce que c'est elle qui décide de la solidité.

Ce que QUIC change à la surface d'attaque

QUIC est un protocole de transport qui établit des connexions sécurisées sur UDP et qui intègre en dur la mise en place du chiffrement selon TLS 1.3. Il n'existe pas de QUIC non chiffré. Pour un exploitant de serveur, cela signifie deux choses qui se contredisent, et les deux sont importantes.

La première est une véritable amélioration. Parce que UDP n'impose aucun établissement de connexion et que les adresses d'expéditeur peuvent être falsifiées, les services UDP sans connexion sont les amplificateurs classiques des attaques contre des tiers. QUIC limite cela dans le standard. La RFC 9000 prescrit en section 8.1 qu'un serveur ne doit pas envoyer plus du triple du volume d'octets reçu avant la vérification de l'adresse d'expéditeur, et la section 14.1 exige qu'un client complète son premier datagramme jusqu'à 1200 octets au minimum. Ensemble, ces deux règles ramènent le facteur d'amplification d'un service QUIC à trois au maximum, alors qu'un port de requête Steam ou un Unconnected Ping Bedrock atteint plusieurs fois cette valeur. Un serveur Hytale qui fonctionne correctement est donc pratiquement sans intérêt comme amplificateur de réflexion. C'est un avantage structurel par rapport à presque tous les autres jeux à trafic UDP, et la comparaison avec les serveurs Minecraft Bedrock le fait nettement ressortir.

La seconde est le prix à payer. Un établissement de connexion QUIC coûte du temps de calcul au serveur, car il comprend une négociation TLS 1.3 avec de la cryptographie asymétrique. Un seul paquet falsifié ne peut pas forcer un établissement de connexion, mais un flot de véritables tentatives de connexion venant d'un botnet, oui. L'attaquant paie lui aussi du temps de calcul, et c'est précisément ce rapport qui décide : tant que le serveur fournit plus de travail par tentative de connexion que l'attaquant, l'attaque est rentable. Un flot de tentatives de connexion ne charge donc pas le raccordement, mais le processeur, et il ne se voit pas dans les statistiques de bande passante. C'est le même mécanisme que celui connu chez Minecraft sous le nom de Nullping et de flot de handshakes, décrit en détail dans l'article Protection DDoS et protection Nullping pour Minecraft.

Ce qui est surtout exploitable en pratique là-dedans, c'est la règle des 1200 octets. Une nouvelle tentative de connexion doit arriver sous forme de datagramme de 1200 octets au minimum, sinon, selon le standard, ce n'est pas un établissement de connexion valide. Le trafic de jeu courant se compose en revanche majoritairement de petits paquets. Cette distinction peut être coulée dans une règle de filtrage, et nous y venons tout de suite.

Ce qui n'est pas documenté publiquement à propos de Hytale

Cette liste a sa place dans un article honnête, parce qu'elle fixe les endroits où vous ne devez pas vous fier à des chiffres. Tout ce qui suit n'est pas officiellement établi au 27 septembre 2026 :

• La question de savoir si le serveur emploie le QUIC Retry pour la vérification d'adresse. La RFC 9000 autorise en section 8.1.2 un paquet Retry avec jeton, par lequel un serveur vérifie l'adresse d'expéditeur avant d'engager des ressources. Si Hytale le fait, et à partir de quelle charge, n'est pas documenté. Partez du principe que vous ne pouvez pas vous y fier.
• Les valeurs par défaut des blocs RateLimit et ConnectionTimeouts dans config.json. Que ces deux blocs existent est cohérent sur plusieurs sources. Les chiffres cités se contredisent cependant : une source indique des valeurs limites concrètes, une autre décrit les blocs comme présents mais sans effet. C'est pourquoi aucun de ces chiffres ne figure dans cet article, et c'est pourquoi vous ne devriez pas compter sur ces blocs comme défense.
• Les noms et les valeurs par défaut des modes d'authentification. La documentation communautaire du code serveur publié décrit trois modes, définis via --auth-mode, avec authenticated par défaut ainsi que offline et insecure pour les environnements privés et le développement. Cela n'est pas confirmé officiellement. La règle qui en découle est malgré tout sans ambiguïté : ne changez pas le mode sur un serveur public.
• Les détails de la mise en place de TLS. La documentation communautaire du protocole, qui repose sur le code serveur publié, décrit un certificat bilatéral, un certificat de serveur auto-émis généré au démarrage dont l'empreinte SHA-256 parvient aux clients via le service de session, ainsi qu'un 0-RTT désactivé. C'est plausible et cohérent avec TLS 1.3, mais ce n'est pas confirmé officiellement, et cela ne change rien aux mesures décrites plus bas.
• Les tailles d'attaque spécifiquement dirigées contre des serveurs Hytale. Il n'existe aucun chiffre public à ce sujet. Les 5 à 50 Gbit/s cités dans le tableau sont une valeur d'expérience tous projets de serveurs de jeu confondus et expressément pas une statistique Hytale.
• Les taux de paquets par joueur en fonctionnement normal. Là non plus il n'existe aucune publication solide. C'est pourquoi cet article ne contient aucune valeur limite que vous pourriez reprendre sans vérification, mais un guide pour la mesurer vous-même.

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 sur le serveur n'en est capable. Elles balaient en revanche tout ce qui se situe en dessous : scans de ports, flots de tentatives de connexion venant de quelques sources, tentatives de prise de contrôle via des interfaces d'administration installées en plus et occupation de toutes les places par des inconnus. C'est la plus grande part de ce qui perturbe un serveur Hytale au quotidien, et cela coûte une bonne 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:5520 signifie « joignable depuis tout Internet », 127.0.0.1:8080 signifie « en local uniquement » et ne demande aucune ouverture. À côté du processus Java du serveur, on trouve souvent sur une machine qui a vécu un panel 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 5520 ADRESSE.IP.DE.VOTRE.SERVEUR
nmap -Pn -p- --min-rate 1000 ADRESSE.IP.DE.VOTRE.SERVEUR

Le second appel est le plus important. Il montre ce qui est ouvert par ailleurs, et en pratique c'est presque toujours plus que prévu.

2. Ne laisser ouvert que 5520 UDP, fermer tout le reste

Deux ouvertures suffisent. 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 5520/udp comment 'Hytale QUIC'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Une ouverture TCP sur 5520 ne vous est pas nécessaire. Si vous exploitez le serveur sur un port différent, l'ouverture doit correspondre à la valeur de --bind, sinon le démarrage se déroule normalement et les joueurs n'arrivent malgré tout pas. Le guide complet, voie de secours comprise, se trouve dans Configurer le pare-feu UFW sans se bloquer l'accès SSH.

Pour tout ce que vous avez installé en plus pour l'administration, la même règle vaut que pour n'importe quel autre jeu : ne pas le placer sur le réseau ouvert, mais le rendre joignable par une redirection de port SSH, puis travailler localement contre 127.0.0.1 :

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

3. Démarrer le serveur comme il est prévu

Le démarrage consiste en une seule commande. Vous obtenez les fichiers du serveur via le téléchargeur Hytale officiel ou depuis votre propre installation du jeu :

java -Xms2G -Xmx4G -jar HytaleServer.jar --assets Assets.zip --bind 0.0.0.0:5520

Au premier démarrage, le serveur crée config.json, le répertoire logs/ et le répertoire de monde universe/. Vous le connectez ensuite une fois à son compte, afin que l'authentification des joueurs fonctionne. Cela passe par un code d'appareil dans la console du serveur :

/auth login device
/auth status

Ne réglez pas -Xmx sur la totalité de la mémoire vive de la machine. Le système d'exploitation, le cache du système de fichiers et la consommation de la machine virtuelle Java hors du tas ont eux aussi besoin de place, et un serveur qui part en mémoire d'échange sous charge ressemble exactement à une attaque pour vos joueurs.

4. Whitelist, mot de passe serveur et plafond de joueurs contre l'épuisement des slots

L'épuisement des slots est l'attaque la moins chère contre un serveur communautaire et n'a besoin d'aucune bande passante. Qui établit assez de connexions simultanées occupe toutes les places et exclut ainsi la communauté elle-même, sans acheter un seul gigabit. Hytale dispose pour cela, contrairement à certains autres jeux, des bons outils à l'état de livraison : une whitelist dans whitelist.json, une liste de bannissement dans bans.json, des droits dans permissions.json et, dans config.json, les clés Password et MaxPlayers.

{
  "ServerName": "Mon serveur Hytale",
  "MOTD": "",
  "Password": "une valeur que seul votre groupe connaît",
  "MaxPlayers": 40,
  "MaxViewRadius": 12
}

Password est vide par défaut, tout le monde entre donc avec l'adresse et le port. Pour un serveur fermé, un mot de passe défini est la mesure isolée la plus efficace contre l'épuisement des slots ; pour un serveur public, c'est la whitelist pendant une vague d'attaques. Et une chose doit être claire : un mot de passe serveur protège vos places, pas votre raccordement. Un attaquant qui inonde votre serveur ne cherche pas du tout à le rejoindre.

Ne modifiez ces fichiers que serveur arrêté. Le processus serveur en cours garde son propre état en mémoire et peut écraser sans le signaler les modifications que vous écrivez pendant ce temps dans le fichier, au moment de son arrêt. Pour les modifications en fonctionnement, utilisez les commandes de console plutôt que l'éditeur.

5. Laisser l'authentification sur sa valeur par défaut

Le mode par défaut exige de chaque joueur un compte Hytale valide. C'est plus qu'une vérification de licence : c'est un filtre d'accès qui rend les comptes de masse coûteux. Un attaquant qui veut occuper des places a besoin de comptes valides pour cela, et ils coûtent de l'argent. Ne retirez pas ce filtre.

La documentation communautaire décrit, à côté du mode par défaut, deux autres modes pour les environnements privés et pour le développement, avec lesquels on peut se connecter sans vérification de compte. Pour un serveur public, ce sont les pires réglages possibles, parce qu'ils font passer l'épuisement des slots d'une question d'argent à une question de script. Si vous basculez pour tester, faites-le sur une machine qui n'est pas sur Internet, et revenez ensuite en arrière.

6. Limiter les nouvelles tentatives de connexion, et précisément avec la règle des 1200 octets

C'est maintenant que l'avantage structurel de QUIC devient pratique. Un établissement de connexion valide arrive, selon la RFC 9000, sous forme de datagramme de 1200 octets au minimum. Le trafic de jeu courant est nettement plus petit. Avec le suivi de connexions, vous pouvez donc distinguer les nouveaux flux de ceux qui existent déjà et rejeter tout ce qui est nouveau et trop petit. Avec nftables, chargé via nft -f :

table inet hytale {
    chain input {
        type filter hook input priority -10; policy accept;

        ct state new udp dport 5520 udp length < 1208 drop

        ct state new udp dport 5520 \
            meter hyconn { ip saddr limit rate over 5/second burst 10 packets } drop
    }
}

La première règle travaille sur la longueur UDP, donc 8 octets d'en-tête plus 1200 octets de charge utile, soit 1208 ensemble. Elle ne touche que les paquets qui veulent ouvrir un nouveau flux et qui sont trop petits pour cela, et elle ne peut pas toucher les joueurs connectés. La seconde règle limite le nombre de nouvelles connexions qu'une seule adresse source peut ouvrir par seconde. Cinq par seconde, c'est généreux : un vrai joueur établit une connexion et la garde. La priorité -10 fait en sorte que les deux règles agissent avant la chaîne de filtrage d'UFW.

Un plafond du taux de paquets par adresse source sur le port de jeu lui-même est la troisième règle pertinente, et ici cela vaut expressément : la valeur chiffrée est une valeur de départ, pas une vérité.

iptables -I INPUT -p udp --dport 5520 \
  -m hashlimit --hashlimit-name hytale_udp --hashlimit-mode srcip \
  --hashlimit-above 800/sec --hashlimit-burst 1200 -j DROP

Mesurez d'abord pendant une semaine en fonctionnement normal, puis réglez la limite au double du pic mesuré. Pour Hytale, il n'existe aucun chiffre de référence publié à ce sujet, et les valeurs dépendent fortement du nombre de joueurs et de la distance de vue. Qui règle trop serré éjecte ses propres joueurs, et d'abord ceux qui ont le plus mauvais raccordement.

Des 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 en plus leur place dans /etc/ufw/before.rules, faute de quoi elles disparaîtront au prochain ufw reload. Qu'une règle soit atteinte ou non, iptables -L INPUT -n -v le montre : si les compteurs de correspondances restent à zéro, elle n'agit pas.

7. Régler correctement le suivi de connexions du noyau

Ce point explique des pannes qui ressemblent à une attaque volumétrique sans en être une. Le noyau crée des entrées dans le suivi de connexions pour le trafic UDP, et avec des adresses d'expéditeur 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

Chez la plupart des jeux, la meilleure réponse est de ne pas faire suivre le trafic de jeu du tout. Chez Hytale, c'est un véritable arbitrage, car la règle des 1200 octets de l'étape 6 a besoin du suivi de connexions. Sans lui, le filtre ne sait pas quel paquet ouvre un nouveau flux. La recommandation est donc la suivante : garder le suivi, agrandir la table, garder l'expiration de délai UDP courte. Un complément sous /etc/sysctl.d/, activé avec sysctl --system :

net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 120
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Qui veut malgré tout désactiver le suivi, par exemple sur une machine avec un très grand nombre de joueurs simultanés, place udp dport 5520 notrack dans la table raw et renonce ainsi à la règle des 1200 octets. Les deux ensemble ne fonctionnent pas. Pour un serveur Hytale isolé, la règle vaut plus que les entrées de table économisées.

Si les paquets arrivent plus vite que le processus Java ne les récupère, le tampon de réception débordera en plus. Pour les joueurs, cela ressemble à une perte de paquets, alors que le raccordement est libre. Le noyau vous dira lui-même si les réglages de tampon ci-dessus sont nécessaires : si UdpRcvbufErrors augmente dans nstat -az, alors ils agissent. Si le compteur reste à zéro, l'ajustement ne change rien.

8. Choisir la distance de vue et le nombre de joueurs en fonction du raccordement

Cette étape n'est pas une mesure de sécurité, mais elle décide de la quantité d'attaque que vous pouvez encaisser. Hypixel Studios l'a formulé clairement dans les exigences matérielles officielles du 1er décembre 2025 : si vous doublez la distance de vue, vous quadruplez la quantité de monde autour du joueur. La recommandation officielle est de 12 chunks au maximum, soit 384 blocs, définis via MaxViewRadius. Côté client, les mêmes exigences citent 2 Mbit/s comme minimum et 8 Mbit/s comme recommandation par joueur pour le jeu multijoueur.

Faites le calcul une fois pour votre serveur. Un serveur avec 40 joueurs et une distance de vue généreuse déplace en fonctionnement normal quelques centaines de mégabits. C'est la valeur à laquelle votre raccordement doit se mesurer, et c'est en même temps la valeur qu'une attaque doit dépasser pour se remarquer. Qui remplit un tiers d'un raccordement à 1 Gbit/s en fonctionnement normal a moins de réserve que celui qui se situe à cinq pour cent. Une distance de vue plus petite n'est donc pas seulement une question de performance, mais aussi une question de robustesse.

9. Garder un œil sur les mods, les plugins et les changements de protocole

Hytale est moddable côté serveur : les mods se placent sous forme de .zip ou de .jar dans le répertoire mods/, et les plugins s'adressent directement à l'interface du serveur. C'est commode, parce que les joueurs n'ont rien à installer, et c'est en même temps un risque de disponibilité qui n'a rien à voir avec les attaques. Un plugin qui travaille cher à chaque événement réseau est un amplificateur installé chez vous.

S'y ajoute le changement de protocole. Avec l'Update 6, le protocole réseau est passé selon les Patch Notes officielles du 27 août 2026 de hytale/2 à hytale/3, et le serveur ainsi que les plugins doivent être reconstruits avant de pouvoir se connecter. Pour la disponibilité, cela signifie : tenez une liste de vos mods avec leur version, vérifiez-les avant chaque mise à jour sur une seconde instance, et prévoyez une fenêtre de maintenance avant le 12 octobre 2026. Un serveur qui ne démarre plus après une mise à jour est indiscernable d'une attaque pour vos joueurs.

10. Collecter des mesures avant que cela devienne sérieux

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

sar -n DEV 1 10
ip -s link show eth0
conntrack -C
nstat -az | grep -i -E 'udp|drop'
tcpdump -ni eth0 -c 200 "udp port 5520"

Pour tcpdump, une règle : limitez toujours avec -c, car une capture à pleine charge alourdit encore un serveur déjà surchargé. Comme le serveur Hytale tourne sur Java, il vous faut une seconde vérification qui exclut la fausse alerte la plus fréquente. Une pause du ramasse-miettes ressemble exactement à une attaque pour les joueurs : tout le monde se fige en même temps, puis cela repart. La différence est dans les chiffres.

jcmd $(pgrep -f HytaleServer.jar) GC.heap_info
tail -n 200 logs/latest.log

L'interprétation est simple. Si les paquets entrants montent bien au-delà de la valeur normale alors que le processus Java travaille à peine, c'est une attaque. Si le taux de paquets reste discret alors que le tas se remplit ou que le journal montre de longues pauses, c'est de la charge. La façon d'interpréter en détail les valeurs réseau figure dans Détecter une attaque DDoS sur le serveur.

11. Sauvegarde, plan de repli et répétition avant la grande date

Un concept de protection qui n'a jamais été testé est une supposition. Avant une date comme le 12 octobre 2026, quatre choses doivent être réglées : une sauvegarde du répertoire universe/ et de config.json placée hors de la machine, un retour vérifié à la version de serveur précédente, une seconde instance sur laquelle vous appliquez d'abord la mise à jour, et un test de charge unique qui déclenche vos propres règles de filtrage.

Le test de charge est le point où la plupart des exploitants s'arrêtent, et c'est le plus important. Ne vérifiez pas si vos règles repoussent les attaques, mais si elles laissent passer vos propres joueurs. Pour cela, il suffit d'observer les compteurs de correspondances pendant que vingt vrais joueurs se connectent en même temps. Si les compteurs des règles de rejet augmentent à cette occasion, votre limite est réglée trop serré, et vous l'auriez appris le jour de la mise à jour, dans les pires conditions.

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, cela correspond à 125 mégaoctets par seconde, et le raccordement est saturé dès que quelqu'un envoie davantage. Les attaques contre des projets de serveurs de jeu se situent habituellement entre 5 et 50 Gbit/s, donc entre cinq et cinquante fois votre raccordement. La qualité de votre règle nftables derrière ne joue alors plus aucun rôle, 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. Un noyau de serveur normal en traite, selon le processeur et la carte réseau, 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 passe dans le rejet. Les exploitants vivent cela comme ceci : « la charge n'était même pas élevée, et pourtant tout avait disparu ».

Chez Hytale s'ajoute une troisième grandeur, qui n'existe pas chez la plupart des jeux : le temps de calcul de l'établissement de connexion. Un flot de tentatives de connexion valides venant d'un botnet ne remplit aucun raccordement et ne produit aucun taux de paquets remarquable, il occupe le processeur avec de la cryptographie. De telles attaques sont invisibles dans les statistiques de bande passante et nettes dans la charge processeur du processus Java, et ni une limitation de débit par adresse source ni un tampon de réception plus grand n'y fait quoi que ce soit lorsque les sources sont assez nombreuses.

Pour situer les ordres de grandeur qui existent réellement : sur les serveurs KernelHost ont été filtrés, entre autres, 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. Aucun réglage local n'agit contre cela. Les attaques volumétriques doivent s'arrêter dans le réseau, en amont du serveur.

Ce que KernelHost oppose aux attaques DDoS contre les serveurs Hytale

La protection permanente incluse 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. Qui retire l'adresse IP du réseau obtient pour vous le même résultat que l'attaquant. Quels titres et protocoles sont couverts par des profils de protection propres, cela est listé dans Protection DDoS des serveurs de jeu en temps réel.

Advanced DDoS Protection pour les projets Hytale attaqués en continu

Certains projets ne sont pas attaqués de temps à autre, mais de façon ciblée et pendant des semaines, et pour un jeu en Early Access cela touche particulièrement les serveurs qui sont en train de grandir. 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 ce qui est autorisé sur 5520 UDP, séparément de tout le reste, et vous n'avez pas besoin de ticket pour cela.
• Les changements s'appliquent en temps réel, vous pouvez donc affiner les réglages pendant une attaque en cours, par exemple limiter brièvement les nouvelles connexions plus durement et laisser le trafic de jeu courant intact.
• Un jeu de règles adapté au protocole, pour QUIC sur UDP tout comme pour vos propres applications sur n'importe quel port TCP ou UDP.

L'Advanced DDoS Protection s'adresse aux serveurs qui se trouvent chez KernelHost. Qui exploite actuellement son projet Hytale ailleurs et subit des attaques permanentes le transfère pour cela chez KernelHost, et les deux niveaux agissent alors dès la mise en service.

Les deux niveaux comparés

Pour la plupart des serveurs Hytale, 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.

Ce que l'on peut transposer d'autres jeux à Hytale

Comme Hytale est encore jeune et qu'il n'existe aucun chiffre public sur les attaques contre des serveurs Hytale, le chemin le plus rapide vers un savoir solide est le regard porté sur des jeux comparables. Ce qui se transpose n'est pas le numéro de port, mais le schéma.

• Le lancement explosif et ce qu'il déclenche : Palworld montre comment une vague de nouveaux joueurs et une vague d'attaques se superposent dans le temps, et pourquoi ce sont justement les serveurs en croissance qui deviennent des cibles.
• La différence entre requête et trafic de jeu : Minecraft Bedrock explique, à partir de l'Unconnected Ping, comment fonctionne l'amplification via UDP. C'est exactement cette voie d'attaque que Hytale n'a pas grâce à QUIC, et c'est là que la différence se comprend le mieux.
• L'établissement de connexion comme cible : Protection DDoS et protection Nullping pour Minecraft décrit les flots de handshakes, qui se contentent de presque aucune bande passante. C'est le plus proche parent du flot de connexions QUIC.
• Petits effectifs de joueurs et épuisement des slots : Project Zomboid et Conan Exiles montrent le peu d'efforts qu'il faut pour exclure un groupe fixe, et le rôle que la whitelist et le mot de passe jouent à cet égard.
• L'exploitation sous charge permanente : Terraria montre comment un processus serveur unique, avec sa charge monocœur, réagit aux attaques. Le serveur Hytale est un processus Java, le problème de fond est comparable.

Erreurs fréquentes sur les serveurs Hytale et leur solution

« J'ai ouvert le port 5520 TCP et les joueurs n'entrent toujours pas » : le trafic de jeu passe par QUIC, donc par UDP. Une ouverture TCP n'apporte rien au trafic de jeu. Ouvrez 5520 UDP et vérifiez-le depuis l'extérieur avec nmap -Pn -sU -p 5520. Si vous avez placé le serveur sur un autre port avec --bind, l'ouverture doit nommer ce port.

« Le serveur tourne, mais personne ne peut se connecter, et le journal ne mentionne aucune attaque » : vérifiez la connexion du serveur à son compte avec /auth status. Un serveur dont la connexion a expiré continue de tourner et refuse malgré tout les joueurs. Ce n'est pas un problème de réseau ni une règle de filtrage.

« Depuis la mise à jour, rien ne démarre plus » : ce n'est pas une attaque, mais le changement de protocole. Avec l'Update 6, le protocole réseau est passé de hytale/2 à hytale/3, et le serveur ainsi que les plugins ont besoin d'une nouvelle construction. Appliquez les mises à jour d'abord sur une seconde instance avant de les laisser toucher le serveur de production.

« Tous les joueurs se figent en même temps pendant deux secondes, puis cela repart » : il s'agit très probablement du ramasse-miettes de la machine virtuelle Java et pas d'une attaque. Vérifiez jcmd ... GC.heap_info et le journal du serveur. Si sar -n DEV 1 10 reste discret pendant ce temps, aucune attaque n'était en jeu, mais un tas trop juste ou une distance de vue trop grande.

« Ma règle contre les petits paquets a exclu les joueurs » : c'est que la condition des 1200 octets figure dans la chaîne sans ct state new. Le trafic de jeu courant se compose majoritairement de petits paquets, et une condition de longueur sans vérification d'état touche précisément ceux-là. La condition ne vaut que pour les flux nouvellement ouverts.

« 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. Chez Hytale, il s'agit le plus souvent d'un vieil enregistrement A dans le DNS, d'un bot Discord avec affichage de statut ou d'une entrée dans l'une des nombreuses listes de serveurs de tiers. Depuis l'Update 6, les adresses des serveurs sont masquées par défaut dans la liste des serveurs officielle, ce qui ferme la voie la plus commode, mais pas toutes. Un changement d'adresse fait gagner du temps, ce n'est pas une solution.

« Mes règles de filtrage 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 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 Hytale a besoin d'exactement un port ouvert : 5520 UDP pour QUIC. TCP n'est pas nécessaire au trafic de jeu, et la documentation publique ne décrit aucun autre port pour les requêtes, RCON ou la télécommande.
• Parce que QUIC ne doit, selon la RFC 9000, pas envoyer plus du triple du volume d'octets reçu avant la vérification d'adresse et qu'une première tentative de connexion doit mesurer 1200 octets au minimum, un serveur Hytale est pratiquement sans intérêt comme amplificateur de réflexion. Cela le distingue des serveurs à requête Steam ou à Unconnected Ping Bedrock.
• Cette même règle des 1200 octets est la meilleure règle de filtrage locale : ce qui veut ouvrir un nouveau flux sur 5520 UDP et qui est plus petit ne peut pas être un établissement de connexion valide et peut être rejeté sans toucher les joueurs connectés.
• La partie coûteuse d'un établissement QUIC est la cryptographie, pas la bande passante. Un flot de tentatives de connexion valides est invisible dans les statistiques de bande passante et ne se voit que dans la charge processeur et dans les compteurs de nouvelles connexions.
• Le mode par défaut avec obligation de compte est un filtre d'accès qui rend les comptes de masse coûteux. Pour un serveur public, il reste intact, et s'y ajoutent whitelist.json, bans.json et une valeur définie dans Password contre l'épuisement des slots.
• Les mesures locales s'arrêtent au raccordement : 1 Gbit/s représente 125 mégaoctets par seconde, et avec des paquets de 64 octets il y tient environ 1,49 million de paquets par seconde. Tout ce qui dépasse cela doit s'arrêter dans le réseau, en amont du serveur.
• Hytale est en Early Access depuis le 13 janvier 2026, le Chapter 1 est annoncé pour le 12 octobre 2026. Les grandes dates sont des dates d'attaque, et une protection commandée à la date même arrive trop tard.
• 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 que vous gérez vous-même, débute à 50,00 € par mois.

Si votre serveur Hytale est déjà hébergé 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.

Cet article est à jour au 27 septembre 2026. Hytale est en Early Access, et le protocole réseau a déjà changé une fois cette année. Il sera mis à jour après le Chapter 1 et après chaque mise à jour qui touche l'établissement de connexion, les ports ou la liste des serveurs.