Protéger un serveur ARK contre les attaques DDoS

Un cluster ARK tombe rarement à un moment quelconque. Si vous exploitez des serveurs PvP, vous connaissez le schéma : juste avant qu'une base adverse ne tombe, le serveur devient injoignable, tous les joueurs sont éjectés, et quand il revient, le raid est terminé. Cet article montre d'abord ce que vous pouvez régler sur le serveur lui-même, ensuite où ces mesures s'arrêtent techniquement, et pour finir ce que KernelHost place en amont.

Pourquoi ARK est attaqué de façon aussi ciblée

Sur la plupart des jeux, une panne de serveur est simplement agaçante. Sur ARK: Survival Evolved et ARK: Survival Ascended, c'est un coup joué. Les pertes en jeu sont définitives, une fenêtre de raid ne dure que quelques minutes, et toute protection contre les raids hors ligne ne vaut que tant que le serveur reste joignable. Celui qui met les défenseurs hors jeu pendant dix minutes gagne des ressources et des créatures. L'attaque a donc un bénéfice concret et un horaire planifié, et elle se répète dès qu'elle a fonctionné une fois.

S'y ajoute la façon dont un cluster est construit. Plusieurs cartes tournent en général sur la même machine, derrière la même adresse IP. Une attaque ne touche donc pas un serveur, mais The Island, Ragnarok, Aberration et le transfert entre les deux en même temps. Les joueurs qui restent bloqués en plein transfert perdent, dans le pire des cas, leur personnage et leurs objets. Ce qui se passe techniquement lors d'une attaque DDoS est décrit dans l'article Qu'est-ce qu'une attaque DDoS ?.

Les ports concernés

ARK fait transiter la totalité du trafic de jeu par UDP. C'est la raison pour laquelle beaucoup de guides de pare-feu ne servent à rien ici : ils ouvrent du TCP.

Survival Evolved occupe en plus le port situé juste au-dessus du port de jeu, parce que le moteur y ouvre un second socket UDP. Survival Ascended n'a plus besoin de ce second port. Le port de requête répond aux demandes de statut au format Steam (nom du serveur, carte, nombre de joueurs, temps de jeu) et c'est le port le plus intéressant pour un attaquant.

Dans un cluster, les ports s'attribuent par pas de deux pour que le second socket n'entre pas en conflit avec l'instance suivante : 7777 et 7778 pour la première carte, 7779 et 7780 pour la deuxième, avec 27015 et 27016 comme ports de requête.

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

Les étapes qui suivent ne coûtent rien et agissent contre les cas les plus fréquents : petites vagues ciblées venant de quelques sources, ports de requête détournés et tentatives de prise de contrôle via RCON. Elles restent utiles même lorsqu'un filtre réseau travaille déjà en amont.

1. N'ouvrir que ce dont le cluster a réellement besoin

Un hôte ARK a vite plus de ports ouverts qu'on ne l'imagine : panneau de contrôle, base de données, un serveur web pour la carte, et les instances de jeu par-dessus. Chacun d'eux est une cible pour des paquets. Le jeu de règles nftables suivant, destiné à /etc/nftables.conf, laisse passer ce dont un cluster à deux cartes a besoin et rejette le reste.

#!/usr/sbin/nft -f

flush ruleset

table inet ark {
    set adminips {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.10 }
    }

    set queryflood {
        type ipv4_addr
        size 65535
        flags dynamic,timeout
        timeout 1m
    }

    chain input {
        type filter hook input priority 0; policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid drop

        ip saddr @adminips tcp dport { 22, 27020 } accept

        udp dport { 7777-7780 } accept

        udp dport { 27015-27016 } add @queryflood { ip saddr limit rate over 10/second burst 20 packets } drop
        udp dport { 27015-27016 } accept

        icmp type echo-request limit rate 5/second accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept

        counter drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Renseignez votre adresse IP fixe sous adminips avant de charger le jeu de règles, sinon vous vous coupez vous-même l'accès SSH.

nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list ruleset

nft -c ne vérifie que la syntaxe et ne modifie rien. Seule la deuxième commande charge le jeu de règles et le rend persistant au redémarrage. Si vous préférez travailler avec UFW, la marche à suivre est décrite dans Configurer le pare-feu UFW. Attention : flush ruleset supprime aussi les règles d'UFW et de Docker. Si l'un des deux tourne, omettez cette ligne.

2. Limiter le port de requête plutôt que le fermer

Le port de requête est le seul port sur lequel votre serveur renvoie à n'importe quel inconnu une réponse nettement plus grosse que la minuscule requête reçue. Il en découle deux problèmes. Premièrement, votre serveur peut être détourné en amplificateur : l'attaquant falsifie l'adresse d'expéditeur, votre serveur répond à une victime tierce, et votre liaison porte le trafic sortant. Deuxièmement, chaque réponse consomme du temps de calcul dans le processus même qui fait tourner le jeu. Une vague de paquets sur 27015 se manifeste donc souvent par des saccades et non par une coupure de connexion.

Fermer le port n'est pas une solution, car le serveur disparaît alors de la liste des serveurs. La règle ci-dessus limite plutôt par adresse source : dix requêtes par seconde avec un tampon de vingt paquets suffisent aux joueurs et au monitoring, tandis qu'une source qui envoie des milliers de requêtes par seconde est rejetée. Pour voir quelles adresses sont limitées à l'instant présent :

nft list set inet ark queryflood

3. Retirer RCON d'Internet

RCON donne le contrôle total : celui qui a le mot de passe expulse des joueurs, arrête le serveur et intervient dans le monde de jeu. Le port est en TCP, le mot de passe figure en clair dans la configuration, et la connexion peut être tentée autant de fois qu'on le souhaite. C'est pourquoi il n'est ouvert, dans le jeu de règles ci-dessus, que pour l'adresse de l'administrateur.

[ServerSettings]
RCONEnabled=True
RCONPort=27020
ServerAdminPassword=<mot de passe aléatoire long>

Le fichier GameUserSettings.ini se trouve sous ShooterGame/Saved/Config/ dans le répertoire du serveur. Pour générer un mot de passe correct :

openssl rand -base64 24

Si un panneau web installé sur la même machine utilise RCON, un accès via 127.0.0.1 suffit et le port reste fermé de l'extérieur. Si le panneau tourne ailleurs, son adresse a sa place dans adminips et nulle part ailleurs.

4. Soulager le suivi de connexions

Un flood UDP ne met généralement pas un serveur Linux à genoux par la bande passante, mais par le suivi de connexions. Le noyau crée une entrée pour chaque paquet UDP entrant, la table se remplit, et ensuite il rejette aussi les paquets des vrais joueurs, ce que trahit nf_conntrack: table full, dropping packet dans le journal système. Pour le trafic de jeu, ce suivi ne sert à rien. Retirez donc les ports de jeu :

table inet arkraw {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        udp dport { 7777-7780, 27015-27016 } notrack
    }

    chain output {
        type filter hook output priority -300; policy accept;
        udp sport { 7777-7780, 27015-27016 } notrack
    }
}

Les deux sens sont nécessaires, sinon des entrées incomplètes apparaissent pour le trafic sortant. À cela s'ajoutent quelques paramètres noyau dans /etc/sysctl.d/90-ark.conf :

net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_udp_timeout = 15
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216
net.ipv4.tcp_syncookies = 1

sysctl --system
cat /proc/sys/net/netfilter/nf_conntrack_count

Si la seconde valeur grimpe vers le maximum pendant une attaque, le goulet d'étranglement était le suivi de connexions et non la liaison.

5. Liste blanche et mot de passe du serveur

Si votre cluster sert de toute façon un groupe fermé, une liste d'accès est la mesure la plus efficace contre les fauteurs de troubles. ARK la fournit d'origine, le serveur se lance pour cela avec -exclusivejoin :

./ShooterGameServer "TheIsland?listen?SessionName=MonCluster?Port=7777?QueryPort=27015?RCONEnabled=True?RCONPort=27020" -server -log -exclusivejoin

Les joueurs autorisés figurent ensuite, un identifiant par ligne, dans PlayersExclusiveJoinList.txt, dans le répertoire du binaire du serveur. En exploitation, vous entretenez la liste depuis la console du serveur ou via RCON :

AllowPlayerToJoinNoCheck <identifiant du joueur>
DisallowPlayerToJoinNoCheck <identifiant du joueur>

Un mot de passe de serveur défini via ServerPassword a un effet comparable, mais l'expérience montre qu'il circule vite. Les deux ont la même limite dure : la vérification a lieu dans le processus de jeu, donc seulement une fois le paquet arrivé. Contre une vague de paquets, une liste blanche ne sert à rien ; contre le joueur qui commence par espionner votre cluster, elle est en revanche très utile.

6. Ce que l'anti-cheat et les plugins apportent, et ce qu'ils n'apportent pas

Les deux titres embarquent d'origine un système anti-cheat, auquel s'ajoutent des plugins serveur passant par l'API serveur correspondante. Les deux sont utiles, mais résolvent un autre problème. L'anti-cheat vérifie si un client connecté a été manipulé, un plugin peut compter les tentatives de connexion ou déconnecter un joueur au comportement suspect. Toutes ces vérifications tournent dans le même processus que le jeu et n'interviennent qu'au moment où le paquet est traité. Si le processus est saturé, la logique de protection tombe avec lui. C'est pour cette raison qu'un plugin capable de repousser des attaques DDoS ne peut pas exister. Ce qui aide malgré tout : garder les fichiers du serveur et les mods à jour et limiter leur nombre, car une bonne partie des plantages dans les clusters ARK vient de mods défectueux et non d'attaques.

7. Votre adresse figure dans la liste des serveurs

Un serveur ARK listé publiquement publie son adresse IP et son port de requête, sinon personne ne pourrait le trouver, et ces listes sont interrogées et archivées en permanence de façon automatisée. Votre adresse est donc connue dès l'instant où le serveur a été listé une seule fois. Se cacher n'est pas une option, car qui ne se liste pas ne grandit pas. Restent les chemins secondaires par lesquels une adresse fuit en plus :

• Les anciennes entrées DNS. Un enregistrement A qui pointe encore vers le serveur précédent trahit l'ancienne adresse. De telles entrées doivent être supprimées.
• Les autres services sur la même adresse. Site web, carte interactive, panneau, serveur vocal et base de données constituent chacun une seconde voie pour atteindre le cluster.
• Votre propre Discord. Les bots de statut, les captures d'écran de la console et les guides de connexion contiennent souvent l'adresse en clair.

8. Mesurer plutôt que deviner

L'erreur la plus fréquente au milieu d'un incident est le mauvais diagnostic. Un mod qui plante, un système de fichiers plein et une véritable attaque produisent la même sensation chez les joueurs. On peut pourtant les distinguer en une minute. D'abord le débit de paquets sur la carte réseau :

r1=$(cat /sys/class/net/eth0/statistics/rx_packets)
sleep 1
r2=$(cat /sys/class/net/eth0/statistics/rx_packets)
echo "$((r2-r1)) paquets par seconde"

Un cluster avec cinquante joueurs se situe normalement dans le bas de la plage à cinq chiffres, des valeurs à six ou sept chiffres signalent une attaque. Ensuite les compteurs de la pile réseau :

nstat -az UdpInDatagrams UdpNoPorts UdpRcvbufErrors
ss -ulnp | grep -E '7777|27015'

UdpNoPorts augmente lorsque des paquets arrivent sur des ports où rien n'écoute, signe typique d'un flood dispersé à l'aveugle. UdpRcvbufErrors augmente lorsque le processus serveur ne récupère plus les paquets assez vite. Pour finir, le journal du jeu :

tail -n 200 ShooterGame/Saved/Logs/ShooterGame.log

Si un rapport de plantage y figure alors que les compteurs de paquets restent normaux, ce n'était pas une attaque. Renoncez à tcpdump pendant un incident, la capture consomme du temps de calcul sur un système qui n'en a justement plus. D'autres signes distinctifs sont énumérés dans l'article Détecter une attaque DDoS sur le serveur.

Là où ces mesures s'arrêtent

Tout ce qui précède agit sur le serveur, et c'est précisément là que se situe la limite. Une règle de pare-feu ne peut rejeter que ce qui est déjà arrivé. Or le goulet d'étranglement se trouve en amont, sur la liaison.

Les chiffres sont sans ambiguïté. Un raccordement à 1 Gbit/s est saturé, avec les plus petits paquets possibles, à partir d'environ 1,49 million de paquets par seconde, quoi que le serveur compte en faire. Un flood UDP réel contre un serveur de jeu ARK chez KernelHost, sur le port 7777, a atteint plus de 112,2 Gbit/s et plus de 8,7 millions de paquets par seconde, soit une moyenne d'environ 1,6 kilooctet par paquet. C'est 112 fois une liaison à 1 Gbit/s et encore plus de onze fois une liaison à 10 Gbit/s.

Le deuxième goulet d'étranglement est atteint tout aussi vite : avec un jeu de règles ordinaire, un cœur CPU rejette quelques centaines de milliers de paquets par seconde selon le matériel. À 8,7 millions, le compte n'y est plus, même avec beaucoup de cœurs. La règle s'applique correctement et le serveur est malgré tout hors ligne.

Les attaques volumétriques doivent donc être filtrées dans le réseau, en amont du serveur. Sur le serveur lui-même, le problème n'a pas de solution, ni avec plus de matériel ni avec un meilleur jeu de règles.

Ce que KernelHost place en amont

La protection permanente incluse sur chaque serveur

Sur chaque serveur de KernelHost tourne une protection DDoS permanente à deux niveaux, sans commande et sans configuration. Le premier niveau est un réseau de scrubbing mondial doté de 17 Tbps de capacité de mitigation : les attaques volumétriques sont interceptées au plus près de leur source, bien avant d'atteindre le centre de données. Le deuxième niveau est un filtrage Arbor en temps réel de 3,2 Tbps directement sur place, dans le datacenter maincubes de Francfort-sur-le-Main, en Allemagne. Il assure le travail de précision sur les couches 3, 4 et 7 et connaît les schémas de protocole des serveurs de jeu courants.

Trois caractéristiques sont décisives. La protection est active en permanence, il n'y a donc aucun délai de réaction pendant lequel une attaque devrait d'abord être détectée. Aucun null-routing n'est utilisé, l'adresse IP attaquée reste dans le réseau et seuls les paquets nuisibles disparaissent. Et elle ne coûte rien de plus. Ce que cela donne pour les serveurs de jeu est décrit dans l'article Protection DDoS des serveurs de jeu en temps réel.

Advanced DDoS Protection pour les projets attaqués en continu

Certains clusters ne sont pas touchés une seule fois, mais pendant des semaines, chaque soir à la même heure et avec des schémas changeants. Pour ces cas, il existe l'Advanced DDoS Protection à partir de 50,00 € par mois, en PrePaid et donc sans durée minimale, sans préavis de résiliation, sans contrat et sans frais de mise en service.

Vous recevez une adresse IP protégée dédiée issue du cœur de réseau de Francfort. Votre serveur y est basculé au sein du réseau de KernelHost, aucune modification n'est nécessaire de votre côté. La différence vient ensuite : les règles de protection, vous les gérez vous-même dans l'espace client, séparément par port et par protocole, et les changements s'appliquent en temps réel, sans ticket. Comme profil de protection, vous choisissez le titre desservi par le port concerné, disponible pour plus de 40 jeux, services et protocoles, dont ARK: Survival Evolved. Pour un cluster, cela signifie le profil du jeu sur les ports de jeu, une limite plus stricte sur le port de requête et une règle propre pour un panneau web, au lieu du même compromis partout.

Les deux niveaux comparés

Erreurs fréquentes et solutions

Seul le TCP est ouvert, le serveur tourne mais personne n'entre : le trafic de jeu d'ARK passe par UDP, une règle pour tcp dport 7777 n'y change rien. Vérifiez avec ss -ulnp et ouvrez les ports en udp dport.

Le serveur est joignable mais n'apparaît pas dans la liste des serveurs : le plus souvent, le port de requête est fermé ou la limite de débit est trop stricte. Ouvrez 27015 en UDP et relevez la limite. Pour contrôler, nft list set inet ark queryflood montre quelles adresses sont limitées.

Votre propre bot de statut signale le serveur hors ligne alors que des joueurs y jouent : un bot Discord interroge depuis une seule adresse source, souvent plusieurs fois par seconde et pour chaque carte séparément, et il tombe donc dans la même limite qu'un attaquant. Placez une exception pour cette adresse avant la règle de limitation.

Plus aucun accès SSH après le chargement du jeu de règles : l'adresse indiquée dans adminips était erronée, ou SSH écoute sur un autre port. Vous revenez sur le serveur par la console VNC de l'espace client, car il n'existe ni IPMI ni iDRAC sur les serveurs dédiés et les serveurs root KVM. Exécutez-y nft flush ruleset comme frein d'urgence, puis corrigez le fichier.

sysctl n'arrive pas à définir les valeurs conntrack : les paramètres sous net.netfilter n'existent qu'une fois le module chargé. Chargez-le avec modprobe nf_conntrack et relancez sysctl --system.

Une prétendue attaque n'est en réalité qu'un mod : si les compteurs de paquets sont normaux et qu'un rapport de plantage figure dans ShooterGame.log, la cause n'était pas le réseau. Après une mise à jour dans le Workshop, c'est l'explication la plus probable, surtout lorsque c'est toujours la même carte qui est touchée.

Tout le cluster tombe hors ligne en même temps : toutes les instances sont accrochées à la même adresse IP, une attaque frappe donc tout d'un coup, transferts compris. Une IP protégée dédiée résout exactement ce schéma, parce que le filtrage se place alors devant l'adresse et non sur le serveur situé derrière.

En résumé

N'ouvrez que les ports de jeu, le port de requête et l'accès réservé à votre propre adresse, limitez le port de requête par source, gardez RCON hors d'Internet et mesurez les débits de paquets avant de supposer une cause. Cela ne coûte rien et couvre le quotidien. Tout ce qui va au-delà ne se joue plus sur le serveur : la protection permanente incluse, avec 17 Tbps de capacité de mitigation dans le réseau de scrubbing mondial et 3,2 Tbps de filtrage Arbor en temps réel à Francfort-sur-le-Main, absorbe le reste sans supplément et sans null-routing. En cas de bombardement continu, l'Advanced DDoS Protection ajoute une IP protégée dédiée avec des règles que vous définissez vous-même. L'exploitant est KernelHost GmbH, dont le siège se trouve à Vienne, en Autriche.