Protéger un serveur Minecraft Bedrock des attaques DDoS

Un serveur Minecraft Bedrock qui disparaît quelques minutes de la liste des serveurs le soir avant de revenir a rarement un problème de matériel. La plupart du temps, une attaque est en cours, et elle se produit précisément au moment où les joueurs sont les plus nombreux. Cet article montre comment protéger un serveur Minecraft Bedrock des attaques DDoS : d'abord ce que vous pouvez sécuriser vous-même sans frais supplémentaires, ensuite l'endroit où ces mesures s'arrêtent physiquement, et pour finir ce qui doit se passer dans le réseau, en amont du serveur.

Toutes les indications se rapportent à un Bedrock Dedicated Server, à PocketMine-MP ou à Nukkit 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 vous exploitez la Java Edition, les attaques de protocole qui lui sont propres sont décrites dans Protection DDoS Minecraft et protection nullping. L'installation pure et simple d'un serveur Bedrock est décrite dans Installer un serveur Minecraft Bedrock avec Nukkit.

Si l'attaque est en cours : ne modifiez rien à la configuration maintenant et ne redémarrez pas le serveur. Sauvegardez d'abord vos mesures (section « Collecter des mesures avant que ça casse »), après l'attaque elles auront disparu sans retour possible.

Pourquoi les serveurs Minecraft Bedrock sont si souvent la cible d'attaques DDoS

La Bedrock Edition est la version qui tourne sur consoles, smartphones, tablettes et Windows, et elle rassemble la plus grande base de joueurs de Minecraft. Là où se trouvent beaucoup de serveurs naît la plus forte incitation aux attaques : réseaux concurrents, joueurs bannis, conflits internes. Une attaque ne coûte à celui qui la déclenche ni compétence particulière ni argent notable, un server booter se vend par abonnement.

La raison technique se situe plus bas. Un serveur Bedrock parle UDP et non TCP, et il répond à quiconque l'interroge, bien avant que la moindre authentification ait eu lieu. Ce sont exactement ces deux caractéristiques qui font du port 19132 UDP une cible commode. Ce qu'est fondamentalement une attaque DDoS, l'article Qu'est-ce qu'une attaque DDoS ? l'explique en détail.

RakNet : un protocole UDP qui répond avant que quiconque se soit authentifié

RakNet est la bibliothèque réseau UDP par laquelle la Minecraft Bedrock Edition fait passer tout son trafic de jeu. UDP ne prévoit aucun établissement de connexion qu'un serveur pourrait exiger, et les adresses source se falsifient donc sans peine. RakNet construit sa propre couche de fiabilité par-dessus : numéros de séquence, accusés de réception (ACK) et accusés de réception négatifs (NAK), avec lesquels un client peut redemander les paquets perdus.

L'établissement de la connexion se compose de sept paquets, quatre du client et trois du serveur :

Client  -> Server   Open Connection Request 1
Server  -> Client   Open Connection Reply 1
Client  -> Server   Open Connection Request 2
Server  -> Client   Open Connection Reply 2
Client  -> Server   Connection Request
Server  -> Client   Connection Request Accepted
Client  -> Server   New Incoming Connection

Ce n'est qu'ensuite que le client envoie le paquet de login avec ses justificatifs Xbox Live. C'est la phrase décisive pour quiconque veut sécuriser son serveur Bedrock : le serveur a traité sept paquets, dépensé du temps de calcul et de la mémoire et répondu plusieurs fois, avant même d'apprendre qui frappe à la porte. Toute mesure qui agit au niveau de l'authentification n'intervient donc qu'une fois la charge déjà produite.

S'y ajoute un second point d'entrée, encore plus précoce. Pour qu'un serveur apparaisse dans la liste des serveurs d'un joueur avec son nom, sa version et son nombre de joueurs, il répond à l'Unconnected Ping (ID de paquet 0x01) par un Unconnected Pong (ID de paquet 0x1C). Cet échange a lieu avant l'établissement de connexion proprement dit, n'exige aucun justificatif et ne peut pas être désactivé sur le Bedrock Dedicated Server sans retirer le serveur de toutes les listes de serveurs.

L'Unconnected Ping comme vecteur d'amplification : les chiffres

Une attaque par amplification est une attaque dans laquelle l'attaquant envoie de petites requêtes avec une adresse source falsifiée à des serveurs tiers, afin que leurs réponses plus volumineuses atterrissent chez la victime. Le serveur Bedrock n'y est pas attaqué, il y est utilisé. Pour l'Unconnected Ping, le calcul se présente ainsi :

Deux conséquences en découlent immédiatement. Premièrement : un nom de serveur long agrandit la réponse et donc le facteur d'amplification que vous mettez à disposition d'attaquants tiers. Un nom court n'est pas de la cosmétique, c'est une mesure de protection. Deuxièmement : le facteur 4 de la configuration par défaut est assez petit pour que votre serveur reste inintéressant comme réflecteur, mais assez grand pour qu'une vague de pings charge votre propre lien sortant du quadruple de ce qui entre.

La faille d'amplification de 2024 montre à quel point cela peut mal tourner lorsque la couche de fiabilité elle-même est détournée. Dans la bibliothèque RakNet utilisée à l'époque, le paquet Connection Request Accepted était marqué comme fiable. Un attaquant pouvait dérouler l'établissement de connexion avec une adresse source falsifiée jusqu'à ce point, puis envoyer un unique accusé de réception négatif portant sur la plage 0 à 8191. Le serveur envoyait alors des milliers de paquets à l'adresse falsifiée, sans que l'attaquant ait à faire quoi que ce soit de plus. Le correctif a consisté à basculer le paquet en non fiable, à joindre dans Open Connection Reply 1 un cookie qu'un vrai client renvoie en miroir, et à introduire des limites de paquets : 120 paquets par adresse source et par cycle de 10 millisecondes, 1 000 paquets au total par cycle.

Bedrock Edition ou Java Edition : ce qui change pour la protection DDoS

Celui qui a déjà sécurisé un serveur Java transpose presque tout de travers. Les deux éditions partagent le nom, mais pas le protocole réseau :

La ligne sur les SYN cookies est la plus importante. Avec la Java Edition, le noyau Linux repousse une vague de SYN sans que le processus Minecraft s'en aperçoive. Avec la Bedrock Edition, cette aide n'existe pas : chaque paquet UDP est transmis jusque dans le processus serveur et y est évalué. Un serveur Bedrock n'a aucune protection intégrée au système d'exploitation contre un flood sur le port 19132, parce que UDP n'en connaît aucune.

La ligne sur l'absence d'enregistrement SRV a une conséquence pratique qui en surprend beaucoup : avec la Bedrock Edition, vous ne pouvez pas cacher le port derrière un enregistrement DNS. Les joueurs saisissent l'adresse et le port à la main. Qui déplace le port doit communiquer le nouveau port à chaque joueur.

Les ports dont il est réellement question

Un Bedrock Dedicated Server s'attache à exactement deux ports, et sur les deux en UDP. Dans le fichier server.properties :

server-port=19132
server-portv6=19133
enable-lan-visibility=true
online-mode=true
allow-list=false
max-players=10
player-idle-timeout=30
max-threads=8

Ce sont les réglages par défaut de Microsoft, consultables dans la référence du Bedrock Dedicated Server. Autour de ces deux ports gravitent d'autres services qui tournent selon le logiciel serveur utilisé :

La troisième et la quatrième ligne sont les erreurs évitables les plus fréquentes sur les serveurs Bedrock. Chez Nukkit et PocketMine-MP, enable-query est activé par défaut, et chez Nukkit un RCON allumé par inadvertance atterrit sur 19132 TCP, donc sur le même numéro de port que le jeu. Celui qui se contente de constater « 19132 est ouvert, c'est bon » passe à côté.

Une particularité du Bedrock Dedicated Server officiel a également sa place ici : il ne connaît aucune directive server-ip. PocketMine-MP et Nukkit en ont une (server-ip, et chez PocketMine en plus server-ipv6), le serveur officiel non. Il écoute donc toujours sur toutes les adresses du système, et le pare-feu est votre seul moyen de restreindre cela.

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 Bedrock proprement configuré encaisse par ses propres moyens les attaques petites et moyennes, quel que soit l'hébergeur chez qui il se trouve.

1. État des lieux : qu'est-ce qui écoute au juste sur 19132 ?

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

ss -lntup
ss -lnup sport = :19132

La colonne qui compte est celle de l'adresse locale. 0.0.0.0:19132 et [::]:19133 signifient « joignable depuis tout Internet ». Si une entrée TCP apparaît à côté sur le même numéro de port, c'est que RCON tourne. Le point de vue de l'attaquant, lui, s'obtient par un scan de ports depuis l'extérieur, en UDP avec -sU :

nmap -Pn -sU -p 19132,19133 ADRESSE.IP.DE.VOTRE.SERVEUR
nmap -Pn -p- --min-rate 1000 ADRESSE.IP.DE.VOTRE.SERVEUR

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

Pour un serveur Bedrock, une seule autorisation vers l'extérieur suffit, deux avec IPv6. 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 19132/udp comment 'Bedrock IPv4'
ufw allow 19133/udp comment 'Bedrock IPv6'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Si vous n'avez pas de joueurs IPv6, supprimez la ligne pour 19133 et mettez en plus enable-ipv6=false chez PocketMine-MP. Chaque port que vous n'ouvrez pas est un port que vous n'avez pas à défendre. Le guide complet, voie de secours comprise, se trouve dans Configurer le pare-feu UFW sans se bloquer l'accès SSH.

3. Désactiver la visibilité LAN, sinon 19132 reste ouvert

C'est le piège dans lequel tombe presque tout le monde en voulant déplacer le port. La directive enable-lan-visibility vaut true par défaut et fait que le serveur répond aux requêtes de découverte sur le réseau local. Microsoft écrit expressément à ce sujet que le serveur s'attache de ce fait en plus aux ports par défaut 19132 et 19133, même si server-port et server-portv6 ont d'autres valeurs.

Celui qui déplace donc le port sur 19140 et se croit en sécurité écoute toujours sur 19132. Pour un serveur exposé sur Internet, il faut donc mettre dans le fichier server.properties :

enable-lan-visibility=false

Contrôlez ensuite avec ss -lnup que 19132 a réellement disparu. Accessoirement, ce même réglage résout le problème de deux serveurs Bedrock sur le même hôte qui se volent mutuellement le port.

4. Désactiver Query et RCON

PocketMine-MP et Nukkit embarquent le Query GS4, une requête de statut UDP calquée sur le protocole d'UT3, et ils répondent à ces requêtes sur le même port 19132 que celui du jeu. La réponse détaillée contient le nom du serveur, la version, le nom du monde, l'état de la whitelist, l'adresse et le port, le nombre de joueurs, les noms de tous les joueurs connectés et, chez PocketMine-MP, sur demande, la liste complète des plugins. C'est pratique pour les pages de statut et les bots Discord, mais cela indique précisément à un attaquant le moment où une attaque est rentable, et chaque requête coûte du temps de calcul.

enable-query=off
enable-rcon=off

Chez PocketMine-MP, les valeurs sont false au lieu de off, et la liste des plugins se désactive dans le fichier pocketmine.yml avec settings.query-plugins: false. Une mise en perspective que l'on lit rarement : le Query GS4 de PocketMine-MP vérifie un jeton salé avec l'adresse source. La réponse volumineuse ne peut donc pas être réfléchie vers une adresse falsifiée. La requête coûte malgré tout du temps de calcul, et les données publiées aident l'attaquant à choisir sa cible. Le Bedrock Dedicated Server officiel ne connaît ni Query ni RCON, ce point ne s'y applique pas.

Si vous avez réellement besoin de RCON, mettez impérativement chez Nukkit rcon.port sur une valeur propre et n'ouvrez ce port que pour votre propre adresse. Le repli sur server-port signifie sinon qu'une télécommande de votre serveur écoute sur 19132 TCP, donc sur le même numéro que celui que vous avez de toute façon noté partout comme « ouvert ».

5. Imposer l'authentification Xbox Live

L'authentification Xbox Live est la vérification qu'un joueur qui se connecte possède bien un vrai compte signé par Microsoft. Elle est activée par défaut dans les trois logiciels serveur et doit le rester.

Sur le Bedrock Dedicated Server, la directive s'appelle online-mode, chez PocketMine-MP et Nukkit elle s'appelle xbox-auth. Dans les deux cas, true est la valeur d'usine et la bonne valeur :

online-mode=true
xbox-auth=true

Microsoft formule à ce sujet une restriction importante : les clients qui se connectent à un serveur situé hors du réseau local ont de toute façon toujours besoin de l'authentification Xbox Live, indépendamment de ce réglage. Le justificatif est transmis sous forme de chaîne de jetons signés dans le paquet de login, avec l'identifiant Xbox (XUID) et le nom affiché.

Et maintenant la partie qui évite les malentendus : l'authentification Xbox Live protège votre logique de jeu, pas votre raccordement. Elle a lieu dans le paquet de login, donc après l'établissement complet de la connexion RakNet. Un attaquant qui inonde votre serveur ne cherche pas du tout à s'y connecter. 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.

6. Allowlist et limite de joueurs, et ce qu'elles ne font pas

L'allowlist (autrefois whitelist) est la liste des joueurs autorisés à rejoindre le serveur. Sur le Bedrock Dedicated Server, vous l'activez avec allow-list=true, les entrées figurent dans le fichier allowlist.json avec le nom, le XUID et le champ ignoresPlayerLimit. Chez Nukkit et PocketMine-MP, la directive s'appelle toujours white-list.

allow-list=true
max-players=60
player-idle-timeout=15

Un délai d'inactivité court via player-idle-timeout est efficace contre l'épuisement des places : les joueurs qui ne font qu'occuper une place sont éjectés après le nombre de minutes indiqué. La valeur 0 signifie que personne n'est jamais déconnecté pour inactivité, et c'est exactement ce dont profite un attaquant qui bloque vos places avec de vrais comptes.

Ici aussi vaut la limite de la section précédente, et c'est le point le plus souvent négligé de tous : l'allowlist n'est vérifiée qu'une fois le paquet de login traité. Elle empêche des arrivées, pas des paquets.

7. Limiter les taux de paquets par adresse source

Contre les petites attaques et les bots mal écrits, un plafond par adresse source fait le travail. Pour UDP, on travaille avec hashlimit et non avec connlimit, car UDP ne connaît pas de connexions :

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

La règle rejette les paquets UDP dès que la même adresse source envoie durablement plus de 400 paquets par seconde. Cette valeur est une valeur de départ, pas une vérité : un serveur plein avec 60 joueurs et une grande distance de rendu produit nettement plus de paquets qu'un serveur vide, et un réglage trop serré éjecte vos propres joueurs. Mesurez d'abord pendant une semaine en fonctionnement normal.

Vous pouvez en revanche serrer nettement plus fort sur l'Unconnected Ping, car un vrai client n'interroge le statut du serveur que tant que la liste des serveurs est ouverte, et alors au rythme d'une fois par seconde. Avec nftables, on peut viser précisément ce seul paquet, parce que l'ID de paquet est le premier octet après l'en-tête UDP :

nft add table inet bedrock
nft add chain inet bedrock prerouting '{ type filter hook prerouting priority -150 ; policy accept ; }'
nft add rule inet bedrock prerouting udp dport 19132 @th,64,8 0x01 limit rate over 500/second drop

L'expression @th,64,8 lit huit bits à partir du 64e bit de l'en-tête de transport, donc le premier octet de la charge utile UDP. La valeur 0x01 est l'ID de paquet de l'Unconnected Ping. Vous pouvez utiliser le même emplacement pour observer, avant de rejeter quoi que ce soit :

tcpdump -ni eth0 'udp dst port 19132 and udp[8] = 0x01' -c 200 -q
tcpdump -ni eth0 'udp src port 19132 and udp[8] = 0x1c' -c 200 -q

La première ligne compte les requêtes de statut entrantes, la seconde vos propres réponses. Si les deux se comptent par milliers chaque seconde alors que presque personne ne joue, vous avez sous les yeux une vague de pings et non vos joueurs.

Deux remarques sur la persistance. 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.

8. Soulager le suivi de connexions du noyau

Un goulot d'étranglement qui frappe bien plus tôt avec les jeux UDP qu'avec TCP : le noyau crée une entrée dans le suivi de connexions pour chaque paire de paquets UDP. Lors d'une vague avec des adresses source falsifiées, chaque paquet est une nouvelle adresse source et donc une nouvelle entrée. Lorsque la table est saturée, le serveur rejette aussi les paquets légitimes, et le journal indique « nf_conntrack: table full, dropping packet ».

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Si le compteur reste durablement proche de la limite, vous pouvez exclure le trafic de jeu du suivi. C'est efficace, mais pas sans conséquence, donc dans les deux sens et avec un test de connexion ensuite :

iptables -t raw -I PREROUTING -p udp --dport 19132 -j NOTRACK
iptables -t raw -I OUTPUT -p udp --sport 19132 -j NOTRACK

Ensuite, les règles fondées sur l'état ne s'appliquent plus à ce trafic. Votre autorisation pour 19132 UDP doit donc être une vraie ouverture de port et ne doit pas s'appuyer sur l'état ESTABLISHED. Après application, vérifiez avec conntrack -L | grep 19132 qu'aucune entrée n'est plus créée, et connectez-vous une fois avec le jeu avant d'enregistrer les règles de façon permanente.

9. Exploiter Geyser et Floodgate proprement

Geyser est une passerelle qui permet aux clients Bedrock de jouer sur un serveur Java Edition : il accepte les connexions Bedrock sur 19132 UDP, traduit le protocole et parle de l'autre côté avec le serveur Java sur 25565 TCP. Floodgate est le complément qui permet à ces joueurs Bedrock de rejoindre le serveur sans compte Java. Pour la protection DDoS, cela signifie trois choses.

Premièrement : tenez Geyser à jour. C'est précisément cette passerelle qui a été deux fois à l'origine d'attaques documentées. En mars 2024, la faille d'amplification décrite plus haut dans la bibliothèque RakNet a été largement exploitée, corrigée à partir du build 478. En juillet 2025 a suivi un second cas : un paquet envoyé de façon répétée pour confirmer les packs de ressources créait plusieurs sessions par joueur, et des clients déconnectés pouvaient continuer à envoyer des paquets parce que le canal réseau n'était pas fermé. Corrigé à partir du build 897. Les deux cas ont été publiés par le projet lui-même avec leur chronologie.

Deuxièmement : le serveur Java n'a pas sa place sur le réseau ouvert. Dans la configuration de Geyser, remote.address pointe sur auto ou 127.0.0.1 et remote.port sur 25565. Attachez le serveur Java localement en conséquence et n'ouvrez pas 25565 TCP vers l'extérieur. Sinon, vous avez deux surfaces d'attaque au lieu d'une, et la seconde est celle pour laquelle vous n'avez jamais réfléchi à des règles.

Troisièmement : le fichier key.pem est un secret. C'est la clé avec laquelle Floodgate contourne l'authentification Java pour les comptes Bedrock. Celui qui le dépose dans un dépôt public, le copie dans un ticket de support ou le montre sur une capture d'écran a offert l'authentification de son serveur. Le projet met expressément en garde contre cela.

10. Collecter des mesures avant que ça casse

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.

sar -n DEV 1 10
ip -s link show eth0
ss -lunp sport = :19132
nstat -az | grep -E 'UdpInDatagrams|UdpNoPorts|UdpInErrors|UdpRcvbufErrors'
dmesg -T | tail -50

Trois de ces valeurs sont particulièrement parlantes sur un serveur Bedrock. Un Recv-Q durablement différent de zéro sur le socket UDP de 19132 signifie que le processus serveur ne récupère plus assez vite les paquets entrants. UdpRcvbufErrors compte précisément les paquets rejetés pour cette raison et constitue la preuve la plus solide que le goulot d'étranglement n'est pas le raccordement mais le processus. UdpNoPorts augmente lorsque quelqu'un bombarde des ports sur lesquels rien n'écoute, une image typique lors d'un scan de ports largement étalé précédant l'attaque proprement dite.

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 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. Votre raccordement est saturé dès que quelqu'un envoie plus de 125 mégaoctets par seconde. Une attaque de 5 à 50 Gbit/s représente cinq à cinquante fois cela. La qualité de votre règle hashlimit placée derrière n'a alors plus aucune importance, car les paquets de vos joueurs ne passent déjà plus en amont.

La deuxième grandeur est le taux de paquets, et sur un serveur Bedrock c'est presque toujours lui qui frappe en premier. Tout le trafic de jeu se compose de nombreux petits paquets UDP, et c'est précisément dans cette discipline qu'un attaquant est le moins cher. Une attaque qui ne remplit même pas un tiers de votre raccordement peut donc quand même paralyser votre serveur, parce que le temps de calcul part dans l'évaluation et le rejet des paquets. Les exploitants vivent cela comme ceci : « la charge n'était même pas élevée, et pourtant tout le monde était dehors ». Dans le jeu, la même chose se manifeste par des pics de lag, des effets d'élastique et des déconnexions en pleine construction.

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 contre les serveurs Bedrock

La protection permanente incluse avec 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. Cela vaut aussi pour les schémas UDP sur 19132 qui ne présentent aucun comportement RakNet.

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'attaquant. Le site est Francfort-sur-le-Main. Les jeux et protocoles couverts sont listés dans Protection DDoS des serveurs de jeu en temps réel.

Advanced DDoS Protection pour les 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 et sans durée minimale. 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 19132 UDP, ce qui l'est sur 19133 UDP, et ce qui l'est sur un port différent si vous avez déplacé votre serveur.
• Les changements s'appliquent en temps réel, vous pouvez donc affiner les réglages pendant une attaque en cours au lieu d'attendre une fenêtre de maintenance.
• Un profil de protection adapté au jeu concerné. Pour Minecraft, des profils prêts à l'emploi existent, tout comme pour les applications modifiées ou maison sur n'importe quel port TCP ou UDP, donc aussi pour Nukkit, PocketMine-MP ou une instance Geyser sur un port de votre choix.

Les deux niveaux comparés

Pour la plupart des projets Bedrock, 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. Si vous exploitez actuellement votre serveur ailleurs, la solution la plus efficace est un déménagement : le filtrage agit dans le réseau en amont du serveur, et ce réseau doit nous appartenir.

Erreurs fréquentes et solutions

« J'ai changé le port pour 19140, 19132 est quand même ouvert » : c'est enable-lan-visibility=true. Le Bedrock Dedicated Server s'attache alors en plus à 19132 et 19133, quelle que soit la valeur de server-port. Mettez la directive à false, redémarrez le serveur, contrôlez avec ss -lnup.

« J'ai modifié allowlist.json et je n'arrive plus à entrer moi-même » : deux causes sont fréquentes. Un ancien fichier whitelist.json traîne encore dans le répertoire et le serveur le lit à la place, ou bien l'entrée XUID manque ou est erronée. Le nom seul ne suffit pas de façon fiable lorsque l'authentification Xbox Live est active.

« Mon hébergeur a bloqué mon serveur alors que c'est moi qui étais attaqué » : vérifiez si votre serveur a lui-même émis des paquets. C'est exactement ce qui s'est produit avec la faille d'amplification RakNet de 2024 : les serveurs concernés envoyaient des milliers de paquets vers des adresses tierces, et les signalements d'abus mentionnaient le port 19132 comme source. Avec tcpdump -ni eth0 'udp src port 19132' -c 200 -q, vous voyez à qui votre serveur répond. Un build à jour élimine la cause.

« 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. S'ils restent à zéro, c'est que la règle n'est jamais atteinte.

« Le serveur figure dans la liste, mais personne n'arrive à entrer » : si l'entrée affiche le nom et le nombre de joueurs, l'Unconnected Pong fonctionne, donc le port est joignable sur le principe. Si l'arrivée échoue malgré tout, cela tient le plus souvent à l'authentification Xbox Live ou à l'allowlist. Si ce sont au contraire seulement les joueurs IPv6 qui n'entrent pas, c'est l'ouverture de 19133 UDP qui manque.

« Le serveur tourne, mais tout le monde a des pics de lag » : c'est plus souvent un plugin qu'une attaque. Regardez d'abord si Recv-Q augmente sur le socket UDP et si UdpRcvbufErrors monte. Si les deux restent calmes et que sar -n DEV 1 10 ne montre rien d'anormal, ce n'était pas une attaque DDoS, mais le processus serveur lui-même. Sur le Bedrock Dedicated Server, les watchdogs de scripts aident alors à avancer, leurs seuils figurant dans le fichier server.properties sous script-watchdog-hang-threshold et script-watchdog-slow-threshold.

« 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 Minecraft Bedrock a besoin d'exactement un port ouvert vers l'extérieur : 19132 UDP, plus 19133 UDP uniquement pour les joueurs IPv6. Le Query, le RCON, le débogueur de scripts sur 19144 TCP et un serveur Java derrière Geyser sur 25565 TCP n'ont pas leur place sur le réseau ouvert.
• Qui déplace le port doit mettre enable-lan-visibility=false, sinon le Bedrock Dedicated Server continue de s'attacher en plus à 19132 et 19133.
• L'authentification Xbox Live et l'allowlist n'interviennent que dans le paquet de login, donc après l'établissement complet de la connexion RakNet. Elles protègent votre logique de jeu et vos places, pas votre raccordement.
• L'Unconnected Ping est demandé avec 33 octets et répondu avec environ 131 octets, soit un facteur d'amplification d'environ quatre. Un nom de serveur court maintient ce facteur bas.
• Avec UDP, c'est hashlimit et non connlimit qui aide, et le suivi de connexions du noyau sature en premier lorsque les adresses source sont falsifiées. Vous devriez avoir mesuré les deux avant la première attaque.
• À partir d'environ 1 Gbit/s, votre raccordement est saturé, et avec des paquets de 64 octets il y tient environ 1,49 million de paquets par seconde. Au-delà, seul le filtrage dans le réseau en amont du serveur est déterminant.
• Chez KernelHost, la protection permanente à deux niveaux est comprise dans chaque pack serveur, active dès la mise en service et sans null-routing. L'Advanced DDoS Protection la complète par une IP protégée dédiée et des règles par port que vous gérez vous-même.

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