Comment protéger un serveur FiveM contre les attaques DDoS en 2026 ? Guide XDP complet

La protection DDoS FiveM est devenue un enjeu critique pour les propriétaires de serveurs GTA V Roleplay. Les attaques par déni de service visent à saturer votre serveur de paquets malveillants, rendant l'expérience injouable pour vos joueurs légitimes. Ce guide technique 2026 vous explique comment mettre en œuvre une défense kernel-level basée sur XDP/eBPF et nftables, directement sur votre machine Linux.

FiveM, le mod multijoueur de GTA V, repose sur une architecture UDP sensible aux attaques volumétriques. Un serveur non protégé peut être mis hors ligne par quelques milliers de paquets par seconde seulement. Contrairement aux solutions de scrubbing cloud (OVH VAC, CloudFlare Magic Transit) qui filtrent le trafic en amont, la protection kernel agit sur le serveur lui-même, offrant une réactivité sub-microseconde et une maîtrise totale de vos règles de filtrage.

Comprendre les attaques DDoS spécifiques aux serveurs FiveM

Les serveurs FiveM subissent trois types d'attaques principales :

• UDP flood : saturation du port de jeu (30120 par défaut) avec des milliers de paquets UDP aléatoires ou mal formés. L'objectif est d'épuiser la bande passante et les ressources CPU du serveur.
• SYN flood : si votre serveur expose un panel web ou une API HTTP (ports 30121, 40120), les attaquants envoient des connexions TCP incomplètes pour saturer la table de connexions.
• Amplification DNS/NTP/SSDP : l'attaquant usurpe votre IP source et envoie des requêtes à des services publics mal configurés, qui vous répondent avec des paquets 10 à 100 fois plus gros.

Le kernel Linux standard traite chaque paquet reçu en remontant la stack réseau complète : interruption matérielle, traitement softirq, allocation de skb (socket buffer), parsing IP/UDP, passage par netfilter (iptables/nftables), puis remise au processus utilisateur. Sur une attaque à 500 000 pps, cette cascade devient le goulot d'étranglement.

XDP (eXpress Data Path) court-circuite cette stack : le programme eBPF s'exécute directement dans le driver réseau, avant même l'allocation du skb. Un paquet malveillant peut être dropé en quelques nanosecondes, sans consommer de CPU utilisateur. C'est la différence entre un serveur qui tient à 2 millions de pps et un serveur qui crash à 50 000 pps.

La protection DDoS FiveM efficace repose donc sur une double couche : XDP stateless pour le filtrage brut et ultra-rapide (DROP instantané des paquets hors whitelist ou dépassant un seuil PPS), puis nftables stateful pour les règles avancées (conntrack, rate-limit par connexion TCP, gestion des flags SYN/ACK).

Architecture de défense kernel : XDP + nftables pour FiveM

Couche 1 : Programme XDP pour le filtrage haute performance

Le PAKKT Engine charge un unique programme XDP par interface réseau (généralement eth0). Ce programme eBPF consulte des BPF maps pour appliquer jusqu'à 256 règles simultanées, définies depuis le panel centralisé PAKKT.io. Chaque règle spécifie :

• Port range : 30120-30121 pour FiveM (UDP game + HTTP txAdmin).
• Protocole : TCP, UDP, ICMP ou any.
• Type de règle : block (DROP), rate_limit (DROP si PPS dépassé), allow_only (DROP tout sauf whitelist).
• max_pps global : seuil de paquets par seconde sur l'ensemble du range de ports.
• max_port_pps : seuil par port individuel (ex : 30120 UDP limité à 100 000 pps).
• min/max packet size : rejeter les paquets trop petits (< 20 bytes) ou trop gros (> 1500 bytes si suspicion de fragmentation).

Exemple de règle appliquée via l'API ou le panel PAKKT :

{
  "port_start": 30120,
  "port_end": 30121,
  "protocol": "udp",
  "rule_type": "rate_limit",
  "max_pps": 150000,
  "max_port_pps": 80000,
  "min_packet_size": 28,
  "max_packet_size": 1400
}

Cette règle autorise jusqu'à 150 000 pps UDP sur l'ensemble du range 30120-30121, avec un plafond de 80 000 pps par port. Les paquets UDP inférieurs à 28 bytes (header UDP + au moins 8 bytes de payload) ou supérieurs à 1400 bytes sont rejetés. Le compteur PPS est réinitialisé chaque seconde par un timer eBPF.

Couche 2 : nftables stateful pour les connexions TCP et les exceptions

XDP est stateless : il ne garde aucune trace des flux. Pour gérer les connexions TCP (txAdmin sur 40120, panel web sur 30121), on déploie des règles nftables dans la table inet pakkt, isolée pour éviter tout conflit avec Docker, fail2ban ou iptables-persistent.

nft add table inet pakkt
nft add chain inet pakkt input { type filter hook input priority 0 \; policy accept \; }
nft add rule inet pakkt input ct state established,related accept
nft add rule inet pakkt input tcp dport 40120 ct state new limit rate 20/second accept
nft add rule inet pakkt input tcp dport 40120 tcp flags syn tcp flags \& \(fin\|syn\|rst\|ack\) \= syn limit rate 10/second accept

La première règle autorise le trafic des connexions déjà établies (conntrack). La deuxième limite les nouvelles connexions TCP sur le port 40120 à 20 par seconde (limite globale). La troisième filtre spécifiquement les paquets SYN pour contrer les SYN floods : maximum 10 SYN/s.

Pour un rate-limit plus granulaire, on utilise un meter nftables (rate-limit par IP source) :

nft add rule inet pakkt input tcp dport 40120 meter http_meter { ip saddr limit rate 5/second burst 10 packets } accept
nft add rule inet pakkt input tcp dport 40120 drop

Chaque IP source peut ouvrir jusqu'à 5 nouvelles connexions par seconde avec un burst de 10 paquets. Au-delà, le paquet est rejeté (dernière règle DROP).

Double couche Blacklist / Whitelist

PAKKT synchronise automatiquement les listes IP dans deux emplacements : une BPF map XDP (ipv4_blacklist, ipv4_whitelist) pour le DROP précoce, et un set nftables pour les règles stateful. Exemple d'ajout d'IP en blacklist :

bpftool map update name ipv4_blacklist key 192.0.2.42 value 1
nft add element inet pakkt blacklist_v4 { 192.0.2.42 }

L'agent PAKKT (Go, mTLS, obfuscation garble) applique ces modifications en moins de 100 ms après validation sur le panel centralisé. Le heartbeat 30s garantit la cohérence de l'état.

Déploiement pas à pas d'une protection DDoS FiveM avec XDP

Prérequis système

Votre serveur Linux doit remplir les conditions suivantes :

• Kernel 5.x ou supérieur avec support XDP natif (vérifiez uname -r).
• Distribution : Ubuntu 20.04/22.04, Debian 11/12, Rocky Linux 8/9, ou toute distro récente avec systemd.
• Driver réseau compatible XDP : la plupart des drivers modernes (ixgbe, i40e, ice, mlx5, virtio_net) supportent XDP. Vérifiez avec ethtool -i eth0 | grep driver.
• Dépendances : clang, llvm, libbpf-dev, nftables (>= 0.9.6). Sur Ubuntu : apt install -y clang llvm libbpf-dev nftables.

Étape 1 : Installation de l'agent PAKKT

L'agent PAKKT est un binaire Go unique, sans dépendance runtime. Téléchargez-le depuis le panel après création de compte (essai gratuit 7 jours sur le premier agent) :

curl -o /usr/local/bin/pakkt-agent https://pakkt.io/download/agent/latest
chmod +x /usr/local/bin/pakkt-agent

Créez un fichier de configuration /etc/pakkt/agent.yaml avec votre clé d'agent (fournie par le panel) :

agent_key: "YOUR_AGENT_KEY_HERE"
api_endpoint: "https://api.pakkt.io"
interface: "eth0"
log_level: "info"

Lancez l'agent en service systemd :

cat > /etc/systemd/system/pakkt-agent.service <

ip link show eth0 | grep xdp
# Sortie attendue : prog/xdp id 123

bpftool prog show
# Vous devez voir un programme XDP type "xdp" attaché à eth0

nft list ruleset | grep "table inet pakkt"
# La table pakkt doit apparaître

nft add rule inet pakkt input tcp dport 40120 meter txadmin_meter { ip saddr limit rate 3/minute burst 5 packets } accept
nft add rule inet pakkt input tcp dport 40120 drop

journalctl -u pakkt-agent -f

bpftool map dump name pakkt_stats
# Affiche les compteurs de paquets par action (XDP_DROP, XDP_PASS, XDP_ABORTED)

#!/bin/bash
# /opt/fivem/update_whitelist.sh
LOGFILE="/opt/fivem/server-data/cache/fxserver.log"
WHITELIST_MAP="ipv4_whitelist"

grep "Authenticated player" "$LOGFILE" | awk '{print $NF}' | sort -u | while read IP; do
  bpftool map update name "$WHITELIST_MAP" key "$IP" value 1 2>/dev/null || true
done

cat >> /etc/sysctl.conf <

ethtool -L eth0 combined 8
# Puis configurez irqbalance ou épinglez manuellement les IRQ

nft add rule inet pakkt input udp dport 30120 limit rate 100 mbytes/second accept
nft add rule inet pakkt input udp dport 30120 drop