FiveM RP : pourquoi les protections classiques ne suffisent plus en 2026 ?

La protection FiveM RP repose encore majoritairement sur des systèmes de liste noire IP, des rate-limit basiques ou des plugins communautaires non maintenus. En 2026, face à des attaques DDoS distribuées dépassant facilement 1 million de pps et exploitant la stack réseau au niveau 2/3, ces approches montrent leurs limites : latence induite, règles applicatives trop hautes dans la stack, absence de visibilité temps réel et conflits de configuration entre Docker, fail2ban et iptables. Cet article détaille pourquoi ces méthodes héritées ne suffisent plus, et comment une architecture kernel-level (XDP/eBPF + nftables stateful) offre une réponse adaptée aux besoins des serveurs de jeu multijoueurs modernes.

Les failles structurelles des protections FiveM RP classiques

La majorité des serveurs FiveM RP s'appuient encore sur trois approches de filtrage :

• Listes noires IP manuelles (iptables ou fail2ban) : temps de réaction long, absence de synchronisation entre serveurs, règles insérées en désordre dans des chaînes INPUT surchargées.
• Rate-limit applicatif (resources Lua, txAdmin) : traite les paquets après parsing par le moteur FiveM, donc déjà trop tard pour éviter la saturation CPU du userspace.
• Plugins communautaires (FiveM-ACL, protections anti-cheat) : conçus pour bloquer du comportement in-game, pas pour filtrer du trafic réseau volumétrique en amont.

Ces méthodes présentent un point commun critique : elles interviennent après que le noyau Linux a déjà alloué des structures sk_buff, déclenché l'analyse conntrack, et remonté les paquets vers l'espace utilisateur. En cas de flood UDP/ICMP ou SYN flood, le CPU passe l'essentiel de ses cycles à traiter des paquets malveillants avant même qu'une règle de filtrage ne soit évaluée. Le résultat : latence perceptible pour les joueurs légitimes, timeout connexion, et parfois crash complet du serveur de jeu.

Conflits de configuration : le piège du multi-couches non coordonné

Sur une distribution typique (Ubuntu 22.04, Debian 12), un serveur FiveM RP partage souvent la box avec :

• Docker (qui insère ses propres chaînes FORWARD et NAT dans iptables).
• fail2ban (qui insère dynamiquement des règles DROP dans la chaîne INPUT).
• iptables-persistent ou ufw (pour gérer les règles de pare-feu au boot).

Ajouter un nouveau système de blocage IP sans table isolée provoque régulièrement des collisions : règles DROP écrasées, conflits de priorité entre chaînes, ou pire, règles Docker qui laissent passer le trafic malveillant avant que fail2ban ne le bloque. Ces conflits nécessitent un audit manuel fastidieux et cassent régulièrement après une mise à jour du noyau ou un redémarrage.

Pourquoi XDP/eBPF + nftables stateful changent la donne

XDP (eXpress Data Path) traite les paquets avant l'allocation des structures sk_buff, directement dans le pilote NIC ou dans un hook générique. Un programme eBPF attaché en mode XDP peut décider en sub-microseconde si un paquet doit être :

• XDP_DROP : rejeté immédiatement, sans jamais remonter dans la stack.
• XDP_PASS : transmis au noyau pour traitement normal (conntrack, nftables, routing).
• XDP_TX : renvoyé directement sur la même interface (rare en contexte serveur de jeu).

Un programme XDP unique peut gérer jusqu'à 256 règles simultanées via des BPF maps (tableaux clé-valeur stockés dans le noyau). Chaque règle spécifie :

• Plage de ports (TCP/UDP), protocole (TCP, UDP, ICMP, ou any).
• Action : block (drop immédiat), rate_limit (compteur pps global + par port), allow_only (whitelist stricte).
• Tailles de paquet min/max (bloquer les paquets vides ou anormalement gros).

Pour un serveur FiveM RP exposant le port UDP 30120, une règle XDP typique pourrait ressembler à :

rule_id: 1
port_range: 30120-30120
protocol: UDP
rule_type: rate_limit
max_pps: 100000
max_port_pps: 5000
min_packet_size: 20
max_packet_size: 1400

Cette règle permet au programme eBPF de bloquer tout flood dépassant 5000 pps sur le port 30120, ou tout paquet UDP anormalement petit/gros, le tout avant que le noyau ne consomme la moindre ressource pour parser ces paquets. Le CPU reste disponible pour traiter le trafic légitime.

nftables stateful : le complément indispensable pour le suivi de connexion

XDP est stateless par conception : il ne garde aucun état entre deux paquets. Impossible donc de faire du rate-limit par connexion TCP ou de valider des flags TCP (SYN, ACK, RST). C'est ici qu'intervient nftables, avec une table isolée inet pakkt qui cohabite sans conflit avec Docker, fail2ban ou ufw.

Exemple de règle nftables complémentaire pour FiveM (port TCP 30120) :

nft add rule inet pakkt input tcp dport 30120 ct state new limit rate 100/second burst 20 accept
nft add rule inet pakkt input tcp dport 30120 ct state established,related accept
nft add rule inet pakkt input tcp dport 30120 tcp flags syn tcp flags != syn,ack drop

Cette séquence :

1. Limite les nouvelles connexions (SYN) à 100/seconde avec burst de 20 (protège contre les SYN floods).
2. Autorise le trafic des connexions déjà établies (ESTABLISHED, RELATED).
3. Drop les paquets TCP avec flags invalides (par exemple SYN sans ACK en milieu de connexion).

Grâce à conntrack, nftables maintient l'état de chaque flux TCP, ce que XDP ne peut pas faire. Les deux couches se complètent : XDP filtre le volumétrique brut en amont, nftables affine le filtrage stateful en aval.

Architecture de déploiement : agent léger + panel centralisé

Déployer manuellement des règles XDP et nftables sur plusieurs serveurs FiveM RP (ex. plusieurs maps RP avec des instances séparées) devient rapidement ingérable. Une approche centralisée permet de piloter l'ensemble des agents depuis un panel unique, avec visibilité temps réel et audit complet des modifications.

Agent Go : empreinte minimale, mTLS natif

Un agent kernel-level efficace pour serveur de jeu doit respecter trois contraintes :

• Empreinte CPU/RAM négligeable : moins de 1 % CPU en moyenne, moins de 5 Mo de RAM. Sur un serveur FiveM RP avec 128 joueurs simultanés, chaque Mo compte.
• Heartbeat fiable : ping toutes les 30 secondes vers le panel, avec reconnexion automatique en cas de perte réseau.
• Mise à jour automatique : self-update SHA256 vérifié, sans redémarrage manuel. Le panel pousse la nouvelle version, l'agent valide le hash, remplace le binaire et redémarre proprement.

La communication agent ↔ panel utilise mTLS (certificat client + serveur), ce qui garantit l'authenticité des deux parties. Chaque agent expose un ID unique, et le panel ne peut modifier les règles XDP/nftables que si le token mTLS correspond. Pas de risque qu'un tiers injecte une règle DROP malveillante depuis Internet.

Panel : dashboard temps réel, GeoIP, métriques par port

Le panel centralisé fournit :

• Dashboard temps réel : affichage du trafic pps/port, nombre de paquets droppés, règles actives, état conntrack nftables.
• GeoIP : carte monde des IPs sources, top pays, top IPs. Pratique pour repérer une attaque depuis un ASN ou une région spécifique et ajouter un bloc CIDR.
• Métriques historiques (TimescaleDB) : évolution du trafic par port sur 7/30/90 jours, pics d'attaque, corrélation avec les règles déployées.
• Audit log : chaque modification de règle (ajout, suppression, modification) est horodatée, avec l'utilisateur qui l'a déclenchée. Indispensable pour la traçabilité.

Pour un collectif de serveurs RP (par exemple 5 instances FiveM réparties sur 3 VPS dédiés), le panel unifie la vue : un seul endroit pour voir quelle instance reçoit une attaque, déployer une règle XDP rate_limit sur tous les agents en un clic, ou whitelister une IP légitime qui s'est fait bloquer par erreur.

Intégrations Pterodactyl, API publique, templates communautaires

Beaucoup de serveurs FiveM RP utilisent Pterodactyl pour gérer les instances de jeu (allocation ports, console, backup). PAKKT s'intègre nativement avec Pterodactyl v1.x : le panel PAKKT récupère automatiquement la liste des allocations (ports UDP/TCP), et propose des templates de règles XDP pré-configurés pour FiveM (port 30120 UDP, rate-limit 5000 pps, taille paquet 20-1400 octets). L'administrateur n'a plus qu'à activer le template sur l'agent cible.

Une API publique (authentification par clé API) permet d'automatiser la gestion des règles depuis un script externe (par exemple, ajouter automatiquement une IP en blacklist depuis un bot Discord modération). Documentation OpenAPI disponible, avec exemples curl et Python.

Le marketplace de templates (à venir) permettra aux administrateurs de partager leurs configurations XDP/nftables : par exemple, un template "FiveM RP anti-DDoS standard" avec 10 règles pré-testées, ou un template "Rust protect port 28015" pour les serveurs Rust. Chaque template est versionné, avec description, auteur, nombre de déploiements.

Cas d'usage concret : serveur FiveM RP 200 joueurs sous attaque UDP flood

Contexte : serveur FiveM RP hébergé sur un dédié OVH (8 cœurs, 32 Go RAM, Debian 12, noyau 6.1). Port UDP 30120 exposé. Attaque détectée : 800 000 pps UDP, taille paquet 64 octets, sources distribuées (botnet résidentiel). Sans protection kernel, le serveur sature en moins de 2 minutes : CPU 100 % sur interruptions réseau, latence joueurs > 500 ms, timeout connexion.

Étape 1 : activation règle XDP rate_limit sur le port 30120

Depuis le panel PAKKT, l'administrateur crée une règle XDP :

rule_id: 10
port_range: 30120-30120
protocol: UDP
rule_type: rate_limit
max_pps: 100000
max_port_pps: 5000
min_packet_size: 20
max_packet_size: 1400

Déploiement sur l'agent en moins de 5 secondes. L'agent charge le programme eBPF, met à jour la BPF map pakkt_rules, et attache le programme XDP sur l'interface eth0. Commande équivalente manuelle :

ip link set dev eth0 xdp obj pakkt_engine.bpf.o sec xdp
bpftool map update name pakkt_rules key 10 value "30120 30120 17 2 100000 5000 20 1400"

Résultat immédiat : les paquets UDP dépassant 5000 pps sur le port 30120 sont droppés avant allocation sk_buff. Le CPU chute à 20 %, latence joueurs redescend sous 50 ms. L'attaque continue, mais le noyau ne la traite plus.

Étape 2 : ajout règle nftables pour limiter les nouvelles connexions TCP (panel web txAdmin)

FiveM expose également un panel web txAdmin sur le port TCP 40120. Pour éviter un SYN flood, l'administrateur ajoute via PAKKT une règle nftables complémentaire :

nft add rule inet pakkt input tcp dport 40120 ct state new limit rate 50/second burst 10 accept
nft add rule inet pakkt input tcp dport 40120 ct state established,related accept

Cette règle n'est pas gérée par XDP (qui est stateless), mais par nftables avec conntrack. Elle cohabite sans conflit avec les règles Docker (table nat) et fail2ban (table filter), car PAKKT utilise une table isolée inet pakkt.

Étape 3 : whitelist IPs staff + blacklist ASN attaquant

Depuis le panel GeoIP, l'administrateur identifie que 60 % du trafic provient de l'ASN AS12345 (botnet résidentiel connu). Il ajoute un bloc CIDR en blacklist :

Blacklist IP: 203.0.113.0/24

PAKKT synchronise automatiquement cette blacklist sur deux couches :

• BPF map XDP : l'IP est ajoutée dans une map pakkt_blacklist, le programme eBPF drop tout paquet source matchant.
• Règle nftables : nft add element inet pakkt blacklist_v4 { 203.0.113.0/24 }, pour garantir le drop même si XDP n'est pas attaché (failover).

En parallèle, il whitelist les IPs fixes du staff (3 IPs) pour garantir que même en cas de rate-limit global, le staff conserve l'accès. Ces IPs sont ajoutées dans une BPF map pakkt_whitelist, évaluée en premier dans le programme XDP.

Résultat final : serveur stable, 0 % de paquets légitimes perdus

Après 48 heures, le serveur FiveM RP tourne avec :

• 0 timeout connexion joueur légitime.
• Latence moyenne 30 ms (contre 15 ms sans attaque, surcoût négligeable).
• 99,7 % des paquets malveillants droppés par XDP, le reste par nftables.
• CPU serveur à 35 % en moyenne (contre 100 % sans protection kernel).

L'attaquant abandonne au bout de 72 heures, faute de résultat. Le coût total de la protection : 3 €/mois pour l'agent PAKKT (essai gratuit 7 jours sur le premier agent). Pour plus de détails sur la tarification, consultez les tarifs PAKKT.

Recommandations pour les administrateurs FiveM RP en 2026

Si vous gérez un ou plusieurs serveurs FiveM RP, voici les critères à vérifier pour une protection kernel moderne :

• Noyau Linux 5.x ou supérieur : XDP natif, support eBPF complet. Évitez les noyaux 4.x qui nécessitent des backports.
• Hébergeur avec débit non bridé : même avec un filtrage XDP parfait, si votre lien réseau est saturé à 1 Gbps, vous ne pourrez pas absorber une attaque à 10 Gbps. Privilégiez un dédiés avec 10 Gbps ou un VPS avec protection DDoS scrubbing en amont (OVH VAC, Hetzner DDoS, etc.) en complément de la protection kernel.
• Table nftables isolée : ne mélangez jamais vos règles de pare-feu avec celles de Docker ou fail2ban. Créez une table inet pakkt (ou équivalent) et définissez la priorité des hooks.
• Blacklist/Whitelist synchronisées : une IP bloquée en XDP doit aussi l'être en nftables, pour garantir le drop même si le programme XDP est détaché (maintenance, reboot).
• Monitoring temps réel obligatoire : sans visibilité pps/port, vous pilotez à l'aveugle. Un dashboard centralisé avec GeoIP et métriques historiques est indispensable pour affiner les règles et identifier les patterns d'attaque.

Pour les collectifs multi-serveurs (5+ instances FiveM RP), privilégiez une architecture avec agent léger sur chaque box et panel centralisé. Cela évite de SSH manuellement sur chaque serveur pour ajouter une règle, et garantit la cohérence des configurations. PAKKT.io propose une solution SaaS B2B exactement sur ce modèle, avec intégration Pterodactyl, API publique et marketplace de templates communautaires.

Enfin, rappelez-vous que la protection kernel (XDP + nftables) est complémentaire d'un scrubbing cloud en amont, pas une alternative. Si votre hébergeur propose un anti-DDoS scrubbing (type OVH VAC, Arbor, Cloudflare Spectrum), activez-le : il absorbera les très grosses attaques volumétriques (> 100 Gbps) avant qu'elles n'atteignent votre serveur. La protection kernel se charge ensuite des attaques plus subtiles (flood applicatif, SYN flood, paquets malformés) que le scrubbing cloud laisse passer.

Conclusion

Les protections FiveM RP historiques (listes noires IP manuelles, rate-limit applicatif, plugins communautaires) montrent leurs limites face aux attaques DDoS modernes, avec latence induite, conflits de configuration et absence de visibilité temps réel. Une architecture kernel-level combinant XDP (filtrage stateless sub-microseconde) et nftables stateful (conntrack, validation TCP flags) offre une défense robuste, à faible surcoût CPU/RAM, tout en cohabitant sans conflit avec Docker, fail2ban ou iptables-persistent. Pour les administrateurs gérant plusieurs instances RP, un agent léger mTLS couplé à un panel centralisé (dashboard, GeoIP, métriques historiques, intégrations Pterodactyl, API publique) simplifie radicalement le déploiement et le monitoring des règles. En 2026, la protection FiveM RP passe par le kernel.

FAQ

Puis-je combiner XDP et nftables sur le même serveur FiveM RP sans casser Docker ou fail2ban ?

Oui, à condition d'utiliser une table nftables isolée (par exemple inet pakkt) avec une priorité de hook bien définie. Docker insère ses règles dans la table nat, fail2ban dans filter. En créant une table séparée pour vos règles XDP/nftables, vous évitez tout conflit. Le programme XDP s'attache directement sur l'interface réseau (eth0) et ne touche pas aux chaînes iptables existantes.

Le rate-limit XDP compte-t-il les paquets (pps) ou les octets (bps) ?

XDP dans PAKKT rate-limite en paquets par seconde (pps), car le programme eBPF est stateless et traite chaque paquet indépendamment. Pour un rate-limit en octets (bps), utilisez nftables avec limit rate X mbytes/second. Les deux approches se complètent : XDP bloque les floods volumétriques bruts, nftables affine le contrôle de bande passante par flux TCP.

Que se passe-t-il si je redémarre le serveur : les règles XDP et nftables sont-elles persistantes ?

Par défaut, les règles XDP et nftables en mémoire ne survivent pas à un reboot. L'agent PAKKT se relance automatiquement au boot (systemd unit) et recharge les règles depuis le panel centralisé. Vous pouvez également exporter vos règles nftables dans /etc/nftables.conf et activer le service nftables.service pour garantir la persistance même si l'agent tarde à redémarrer.