Sécuriser un VPS OVH contre les attaques DDoS : checklist 2026

Protéger un VPS OVH contre les attaques DDoS impose une approche multicouche combinant filtrage kernel, firewall stateful et surveillance continue. Dans ce guide 2026, nous détaillons une checklist exhaustive pour sécuriser VPS OVH DDoS en exploitant XDP/eBPF et nftables, deux technologies natives Linux capables d'absorber plusieurs millions de paquets par seconde avec une latence ajoutée négligeable. Que vous hébergiez des serveurs de jeu, des APIs critiques ou des sites web à fort trafic, cette stratégie vous permettra de maintenir disponibilité et performances même sous attaque volumétrique.

Pourquoi les VPS OVH sont-ils particulièrement visés par les attaques DDoS ?

Les VPS hébergés chez OVH concentrent trois facteurs de risque majeurs. Premièrement, la bande passante généreuse (de 250 Mbps à plusieurs Gbps selon les gammes) et la connectivité internationale de l'opérateur font de ces machines des cibles de choix pour les attaquants cherchant à saturer un lien réseau. Deuxièmement, la popularité d'OVH dans l'industrie du jeu vidéo (Minecraft, FiveM, Rust, ARK) attire les DDoS de type "rage quit" ou extorsion. Troisièmement, un VPS partagé ne bénéficie pas du même niveau de scrubbing en amont qu'un serveur dédié Game équipé du service VAC (VAC OVH ne s'applique pas aux VPS standard).

Contrairement aux solutions de scrubbing cloud qui filtrent le trafic en amont du datacenter, la protection kernel-level intervient directement sur la carte réseau du VPS. XDP (eXpress Data Path) intercepte les paquets IP au niveau du driver réseau, avant qu'ils ne soient copiés en mémoire par la pile TCP/IP du noyau. Cette architecture confère une capacité de filtrage sub-microseconde par paquet, idéale pour rejeter les floods UDP/TCP SYN sans solliciter le CPU applicatif.

Vecteurs d'attaque typiques sur VPS OVH

• UDP flood (port 27015 Source Engine, 19132 Bedrock, 30120 FiveM) : millions de paquets vides ou à payload aléatoire saturant le buffer NIC.
• TCP SYN flood : épuise la table de connexion du noyau (net.ipv4.tcp_max_syn_backlog) en laissant des half-open sockets.
• Amplification DNS/NTP/SSDP : fragments spoofés rebondissant vers la cible via des réflecteurs publics.
• Application-layer flood (HTTP GET, requêtes Minecraft status) : submerge le processus applicatif ; nécessite une mitigation L7 que XDP seul ne couvre pas.

Pour quantifier l'impact, un VPS OVH VLE (2 vCore, 4 GB RAM, 500 Mbps) peut absorber environ 80 000 paquets par seconde avant saturation CPU avec un firewall iptables classique. Avec un programme XDP optimisé, ce même VPS franchit aisément plusieurs centaines de milliers de pps en conservant moins de 5 % de charge CPU.

Checklist de durcissement kernel et réseau : les fondations

Avant de déployer un système de filtrage avancé, sécuriser le noyau Linux contre les vecteurs classiques reste indispensable. Cette section regroupe les paramètres sysctl critiques et la configuration réseau de base à appliquer immédiatement après provisioning du VPS OVH.

1. Désactiver les fonctionnalités inutiles et dangereuses

# /etc/sysctl.d/99-pakkt-hardening.conf
# Désactive le routage IP (inutile sur un serveur applicatif)
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0

# Refuse les redirects ICMP (vecteur de man-in-the-middle)
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0

# Refuse les source routes (attaque de spoofing)
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# Active la protection contre le SYN flood
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 2

# Reverse path filtering strict (anti-spoofing)
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Limite les logs de paquets martiens
net.ipv4.conf.all.log_martians = 1

Appliquez immédiatement ces changements avec sysctl -p /etc/sysctl.d/99-pakkt-hardening.conf. Ces paramètres réduisent la surface d'attaque sans impacter les performances légitimes.

2. Augmenter les buffers réseau pour absorber les pics de trafic

# Augmente la taille des ring buffers TX/RX de la carte réseau
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.core.netdev_max_backlog = 5000

# Optimise les buffers TCP pour les connexions à haute latence
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864

Un netdev_max_backlog de 5000 permet au noyau de mettre en file jusqu'à 5000 paquets en attente de traitement par la pile réseau. Durant une attaque DDoS, ce buffer absorbe les bursts pendant que XDP rejette les paquets malveillants en parallèle.

3. Configurer les limites de connexions et timeouts

# Réduit la durée de vie des connexions TIME_WAIT
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1

# Limite le nombre de requêtes SYN en attente par socket
net.core.somaxconn = 1024

# Protège contre l'épuisement de la table de connexions
net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_tcp_timeout_established = 600

Vérifiez que le module nf_conntrack est chargé avec lsmod | grep nf_conntrack. Si absent, ajoutez nf_conntrack dans /etc/modules et redémarrez.

Déploiement de la couche XDP/eBPF pour le filtrage ultra-rapide

XDP (eXpress Data Path) exécute des programmes eBPF directement dans le driver réseau du noyau, avant toute allocation de sk_buff. Cette approche stateless permet de prendre une décision (XDP_DROP, XDP_PASS, XDP_TX) en quelques cycles CPU, typiquement sub-microseconde par paquet. Pour sécuriser VPS OVH DDoS efficacement, XDP constitue la première ligne de défense.

Architecture d'un programme XDP modulaire

Un programme XDP professionnel expose ses règles de filtrage via des BPF maps, structures de données partagées entre l'espace utilisateur et le code eBPF. PAKKT.io implémente cette architecture en maintenant un programme XDP unique par interface (le PAKKT Engine), capable de gérer jusqu'à 256 règles simultanées. Chaque règle définit :

• Plage de ports (port_min, port_max) pour couvrir par exemple 25565–25575 (cluster Minecraft).
• Protocole : TCP, UDP, ICMP ou any (tous protocoles IP).
• Action : block (XDP_DROP), rate_limit (compteur pps par port), allow_only (whitelist).
• Limites : max_pps global, max_port_pps, taille de paquet min/max pour rejeter les fragments pathologiques.

La décision est prise en consultant plusieurs maps BPF :

// Pseudo-code simplifié du PAKKT Engine XDP
int xdp_pakkt_main(struct xdp_md *ctx) {
    void *data_end = (void *)(long)ctx->data_end;
    void *data = (void *)(long)ctx->data;
    struct ethhdr *eth = data;
    
    // Parse Ethernet + IP + TCP/UDP headers
    struct iphdr *iph = data + sizeof(*eth);
    __u32 src_ip = iph->saddr;
    __u16 dport = extract_dport(iph); // helper inliné
    
    // Lookup blacklist
    if (bpf_map_lookup_elem(&pakkt_blacklist, &src_ip))
        return XDP_DROP;
    
    // Lookup rule matching dport
    struct rule *r = bpf_map_lookup_elem(&pakkt_rules, &dport);
    if (!r) return XDP_PASS;
    
    // Rate-limit per-port
    __u64 *pps = bpf_map_lookup_elem(&pakkt_pps_counters, &dport);
    if (pps && *pps > r->max_port_pps)
        return XDP_DROP;
    
    // Update counter
    __sync_fetch_and_add(pps, 1);
    return XDP_PASS;
}

Ce modèle garantit une logique de filtrage évolutive sans recompilation du programme eBPF : l'agent utilisateur met simplement à jour les maps BPF via bpf_map_update_elem.

Déploiement et attachement XDP

Une fois le programme compilé en bytecode eBPF (fichier .bpf.o), l'attachement se fait avec ip link ou bpftool :

# Attacher le programme XDP à l'interface eth0 en mode natif (driver XDP)
ip link set dev eth0 xdp obj pakkt_engine.bpf.o sec xdp

# Vérifier l'attachement
ip link show eth0
# Sortie : xdp/id:42 (si ID présent, XDP actif)

# Dumper le contenu d'une map BPF pour debug
bpftool map dump name pakkt_rules

Le mode natif (XDP_DRV) offre les meilleures performances, car le code s'exécute directement dans le driver NIC (mlx5, i40e, ixgbe, virtio_net pour les VPS KVM). Sur un VPS OVH avec driver virtio_net récent (noyau 5.10+), le mode natif fonctionne sans modification.

Limites du rate-limit XDP stateless

XDP étant stateless, le rate-limit se fait par paquet (pps), pas par byte. Pour un rate-limit en bande passante (Mbps), il faut combiner XDP avec nftables ou tc-bpf. Le PAKKT Engine implémente un compteur pps par port avec fenêtre glissante (BPF ring buffer + timestamp), suffisant pour absorber 99 % des floods UDP. Pour des cas d'usage nécessitant un rate-limit byte/s précis, référez-vous à la section nftables ci-dessous.

Compléter XDP avec un firewall nftables stateful

XDP excelle dans le rejet massivement parallèle de paquets malformés ou hors-profil, mais ne maintient aucun état de connexion. Pour bloquer les TCP SYN floods avancés, limiter le taux de connexions par IP source, ou filtrer sur les flags TCP (ACK sans SYN, XMAS scan), un firewall stateful nftables est indispensable. PAKKT déploie automatiquement une table nftables inet pakkt isolée, garantissant zéro conflit avec Docker, fail2ban ou iptables-persistent.

Créer la table pakkt et activer conntrack

# /etc/nftables.conf ou inclusion dans /etc/nftables.d/pakkt.nft
table inet pakkt {
    # Blacklist IP synchronisée avec la BPF map XDP
    set blacklist_ipv4 {
        type ipv4_addr
        flags dynamic,timeout
        timeout 1h
    }
    
    # Rate-limit par IP source (connexions TCP)
    set conn_rate {
        type ipv4_addr . inet_service
        size 65535
        flags dynamic
    }
    
    chain input {
        type filter hook input priority filter; policy accept;
        
        # Drop blacklist (redondance avec XDP pour sécurité)
        ip saddr @blacklist_ipv4 counter drop
        
        # Accepte les connexions établies/reliées
        ct state established,related counter accept
        
        # Accepte le loopback
        iif lo accept
        
        # Rate-limit SYN flood : max 20 SYN/s par IP source
        tcp flags syn ct state new \
            limit rate over 20/second burst 40 packets \
            counter drop
        
        # Bloque les scans TCP (flags invalides)
        tcp flags & (fin|syn|rst|ack) == fin|syn counter drop
        tcp flags & (fin|syn|rst|ack) == 0x0 counter drop
        
        # Rate-limit par port avec meter
        tcp dport 25565 ct state new \
            meter minecraft_rate { ip saddr limit rate 10/second burst 20 } \
            accept
        tcp dport 25565 counter drop
        
        # Accepte le reste (politique permissive, ajuster selon besoins)
        counter accept
    }
}

Chargez cette configuration avec nft -f /etc/nftables.d/pakkt.nft puis systemctl enable nftables pour persistance.

Synchronisation automatique blacklist XDP ↔ nftables

L'agent PAKKT maintient la cohérence entre la BPF map pakkt_blacklist et le set nftables @blacklist_ipv4. Lorsqu'une IP est ajoutée via le panel centralisé, l'agent :

1. Appelle bpf_map_update_elem pour l'insérer dans la map XDP (filtrage sub-µs).
2. Exécute nft add element inet pakkt blacklist_ipv4 { 203.0.113.42 } pour bloquer aussi au niveau stateful (couverture des paquets non-IP ou protocoles exotiques non gérés par XDP).
3. Enregistre l'événement dans le log d'audit avec timestamp, agent_id, raison (manual / auto-detect).

Cette double couche garantit qu'aucun paquet malveillant ne franchit le noyau, même si une mise à jour du programme XDP provoque un bref détachement.

Meter nftables pour rate-limit fin par connexion

La directive meter de nftables maintient un compteur par clé (ici ip saddr) avec fenêtre glissante. Exemple pour limiter chaque IP à 10 nouvelles connexions TCP/s sur le port 25565 avec burst de 20 :

tcp dport 25565 ct state new \
    meter minecraft_rate { ip saddr limit rate 10/second burst 20 } \
    accept
tcp dport 25565 counter drop

Le burst autorise une salve initiale (important pour les reconnexions légitimes après timeout), puis applique la limite stricte. Ce mécanisme complète le rate-limit pps global de XDP en ciblant les comportements applicatifs (connexions, pas paquets bruts).

Surveillance continue et réponse automatique aux incidents

Un système de protection DDoS sans monitoring temps réel reste aveugle. Pour sécuriser VPS OVH DDoS durablement, il faut collecter, agréger et visualiser les métriques kernel, puis automatiser les actions correctives (blacklist dynamique, escalade de règles).

Métriques XDP et nftables à surveiller

Métrique	Source	Seuil d'alerte
Paquets droppés XDP (/s)	Compteur BPF map pakkt_stats	> 100k pps soutenu > 60s
Paquets rejetés nftables (/s)	nft list ruleset -a | grep counter	> 50k pps soutenu > 60s
Connexions actives (conntrack)	conntrack -C	> 80% de nf_conntrack_max
Top 10 IPs sources (volume paquets)	BPF map percpu pakkt_src_stats	1 IP > 30% du trafic total
Latence ajoutée XDP (p99)	Timestamp eBPF + perf events	> 10 µs (indicateur de surcharge CPU)

L'agent PAKKT collecte ces métriques toutes les 5 secondes et les envoie (mTLS) au backend centralisé où elles sont stockées dans TimescaleDB (extension PostgreSQL optimisée pour séries temporelles). Le dashboard affiche en temps réel :

• Carte monde GeoIP des sources d'attaque (basée sur MaxMind GeoLite2).
• Top 10 IPs sources avec volume pps, protocole, port de destination.
• Top 10 pays sources (utile pour géo-bloquer des ASN entiers si nécessaire).
• Timeline des événements : règles déclenchées, IPs blacklistées, pics de trafic.

Auto-blacklist basée sur des seuils comportementaux

Le moteur de détection PAKKT analyse les métriques remontées et applique des heuristiques configurables :

# Exemple de règle de détection (pseudo-code agent)
if src_ip.pps > 10000 AND src_ip.packets_dropped_ratio > 0.8:
    blacklist(src_ip, duration=3600, reason="flood_detected")
    log_audit(agent_id, src_ip, "auto_blacklist", "pps=10k drop_ratio=80%")

L'IP est ajoutée simultanément dans la BPF map XDP et le set nftables. Un timeout de 1h (3600s) est appliqué par défaut ; passé ce délai, l'IP est automatiquement retirée de la blacklist sauf récidive.

Intégration avec Pterodactyl et logs applicatifs

PAKKT s'intègre nativement à Pterodactyl v1.x, le panel de gestion de serveurs de jeu open-source le plus utilisé. Cette intégration permet :

• D'afficher dans le panel Pterodactyl un onglet "Protection DDoS" par serveur (node), avec graphiques temps réel de paquets filtrés.
• De créer automatiquement des règles XDP/nftables lors de l'allocation d'un nouveau port (par exemple, un serveur Minecraft provisionné sur le port 25570 reçoit instantanément une règle rate_limit 5000 pps).
• De corréler les logs applicatifs (crash serveur, timeout connexion) avec les événements de filtrage (pic de trafic détecté 30s avant le crash).

L'intégration Pelican (fork de Pterodactyl) et WHMCS sont en cours de développement pour 2026. L'API publique PAKKT permet néanmoins de créer des intégrations sur-mesure via clé API et webhooks.

Conseils d'hébergement et architecture réseau pour maximiser la résilience

Choisir le bon hébergeur et dimensionner correctement l'infrastructure réseau restent des prérequis pour sécuriser VPS OVH DDoS avec succès. Voici les critères techniques à privilégier lors de la sélection ou migration d'un VPS.

Critères hébergeur pour absorption DDoS

• Bande passante garantie : privilégier 1 Gbps minimum, idéalement 2 Gbps ou plus pour absorber les attaques volumétriques (100–500 Gbps nécessitent un scrubbing cloud en amont, PAKKT protège ensuite le trafic légitime restant).
• Uplink redondant : double uplink vers des backbones distincts (par exemple, Cogent + Level3 chez OVH) limite les risques de saturation lien unique.
• Datacenter géographiquement proche de votre audience principale : réduit la latence et facilite le troubleshooting (ping, traceroute).
• Support kernel récent : noyau Linux 5.10 LTS ou supérieur garantit un driver XDP stable (virtio_net XDP natif depuis 5.9).
• Isolation réseau : VLAN privé ou VPC pour segmenter les serveurs backend inaccessibles depuis Internet (base de données, cache Redis).

OVH propose plusieurs gammes de VPS adaptées. Pour un serveur de jeu hébergeant 50–100 joueurs simultanés, un VPS Comfort (4 vCore, 8 GB RAM, 500 Mbps) constitue un bon compromis coût/performance. Pour des audiences supérieures ou des applications critiques, migrer vers un serveur dédié Game avec VAC offre une résilience accrue, bien que PAKKT reste pertinent pour filtrer au plus près du kernel.

Architecture recommandée pour serveurs de jeu multi-instances

┌─────────────────────────────────────────────────────┐
│               Internet (attaquants inclus)           │
└────────────────────┬────────────────────────────────┘
                     │
         ┌───────────▼──────────────┐
         │  Scrubbing Cloud (opt.)  │  ← OVH VAC, CloudFlare, etc.
         │  Filtrage volumétrique   │
         └───────────┬──────────────┘
                     │
         ┌───────────▼──────────────┐
         │   VPS OVH eth0 (publique)│
         │   XDP (PAKKT Engine)     │  ← Drop flood packets < 1 µs
         └───────────┬──────────────┘
                     │
         ┌───────────▼──────────────┐
         │   nftables (pakkt table) │  ← Stateful, conntrack, rate-limit
         └───────────┬──────────────┘
                     │
    ┌────────────────┴───────────────────┐
    │                                    │
┌───▼────────┐                  ┌────────▼───┐
│ Container  │                  │ Container  │
│ Minecraft  │                  │ FiveM      │
│ :25565     │                  │ :30120     │
└────────────┘                  └────────────┘

Cette architecture en cascade garantit que seuls les paquets légitimes atteignent l'application. XDP rejette les floods massifs, nftables assure le suivi de connexion et rate-limit fin, les containers hébergent les applications isolées. L'agent PAKKT orchestre l'ensemble via heartbeat 30s (mTLS) et synchronise les règles en temps réel.

Cas d'usage : migration d'un serveur Minecraft saturé

Un hébergeur de serveurs Minecraft communautaires subissait des attaques UDP flood de 200k pps quotidiennes, rendant les serveurs injouables (timeouts connexion, TPS < 10). Après déploiement de PAKKT :

1. Création de règles XDP par cluster de ports (25565–25570 rate_limit 5000 pps par port).
2. Blacklist automatique des IPs dépassant 10k pps avec drop_ratio > 80%.
3. Meter nftables limitant chaque IP à 5 nouvelles connexions TCP/s (anti-bot login spam).

Résultat : 98 % des paquets malveillants rejetés en XDP (CPU < 8%), serveurs stables à 20 TPS, aucune plainte joueurs depuis 6 mois. Coût : 3€/agent/mois pour 1 VPS protégeant 6 instances Minecraft.

Checklist finale : déploiement en production étape par étape

Récapitulons la séquence complète pour sécuriser VPS OVH DDoS avec une approche kernel-level professionnelle.

Phase 1 : Préparation système (15 min)

1. Vérifier la version du noyau : uname -r (minimum 5.10 recommandé).
2. Installer les outils eBPF/nftables : apt install linux-headers-$(uname -r) clang llvm bpftool nftables (Debian/Ubuntu) ou dnf install kernel-devel clang llvm bpftool nftables (RHEL/Rocky).
3. Appliquer les paramètres sysctl de durcissement (section 2.1 ci-dessus).
4. Rebooter si changement de noyau nécessaire.

Phase 2 : Déploiement agent PAKKT (5 min)

1. Créer un compte sur pakkt.io (essai gratuit 7 jours sur le premier agent).
2. Générer une clé d'enrôlement depuis le panel (section "Agents" → "Add Agent").
3. Exécuter le script d'installation one-liner fourni : curl -sSL https://pakkt.io/install.sh | sudo bash -s -- --token=VOTRE_CLE.
4. L'agent télécharge le binaire Go obfusqué (garble), vérifie le hash SHA256, démarre le service systemd pakkt-agent.
5. Vérifier le heartbeat dans le panel (LED verte sous 30s).

Phase 3 : Configuration règles XDP et nftables (10 min)

1. Depuis le panel PAKKT, créer une règle XDP pour votre application : port 25565, protocole UDP, rule_type rate_limit, max_port_pps 5000.
2. Créer une seconde règle pour TCP 25565 : rule_type allow_only (whitelist mode si vous avez une liste d'IPs fixes), ou rate_limit 1000 pps.
3. Appliquer la config : l'agent met à jour la BPF map pakkt_rules en 2–3 secondes.
4. Importer la table nftables PAKKT (fichier fourni par le panel ou via API) : nft -f /etc/nftables.d/pakkt.nft.
5. Activer la persistance : systemctl enable nftables.

Phase 4 : Tests et validation (10 min)

1. Simuler un flood UDP léger avec hping3 --udp -p 25565 --flood VOTRE_IP depuis une machine tierce (attention : n'attaquez jamais une IP qui ne vous appartient pas).
2. Observer le dashboard PAKKT : compteur "Packets Dropped XDP" doit augmenter rapidement, CPU reste stable.
3. Vérifier les logs agent : journalctl -u pakkt-agent -f affiche les règles appliquées et les IPs blacklistées automatiquement si seuil franchi.
4. Tester la connectivité légitime : connexion depuis votre client de jeu (Minecraft, FiveM) doit fonctionner normalement (latence +0,1–0,3 ms ajoutée par XDP, imperceptible).

Phase 5 : Monitoring continu et ajustements

1. Configurer des alertes dans le panel PAKKT (email ou webhook Discord/Slack) pour événements critiques : règle déclenchée > 50k pps, IP blacklistée auto, agent offline.
2. Analyser les rapports hebdomadaires (CSV export) pour identifier les patterns d'attaque récurrents (plages IP, horaires, vecteurs).
3. Affiner les seuils rate_limit en fonction des métriques réelles : si 5000 pps s'avère trop strict (joueurs légitimes parfois rejetés), passer à 7000 pps.
4. Ajouter des règles de géo-blocage si 90 % des attaques proviennent d'un pays spécifique (fonction disponible via l'API PAKKT).

Cette checklist couvre 99 % des cas d'usage de protection VPS OVH. Pour des besoins spécifiques (IPv6, VLAN privé, intégration CI/CD), consultez la documentation API sur pakkt.io/blog ou contactez le support technique.

En production, un VPS OVH correctement durci avec XDP/eBPF et nftables peut absorber des attaques de plusieurs centaines de milliers de pps sans impact utilisateur perceptible. La clé réside dans la combinaison filtrage ultra-rapide stateless (XDP) + suivi de connexion stateful (nftables) + surveillance temps réel (PAKKT panel). Cette approche kernel-level, déployable en 30 minutes, offre une résilience comparable aux solutions d'entreprise pour une fraction du coût.

FAQ

Le programme XDP PAKKT Engine est-il compatible avec tous les VPS OVH ?

Oui, à condition que le VPS utilise un noyau Linux 5.10 ou supérieur avec le driver réseau virtio_net (standard sur les VPS KVM OVH depuis 2021). Vérifiez avec uname -r et ethtool -i eth0 | grep driver. Si le driver est virtio_net et le noyau ≥ 5.10, XDP natif fonctionne immédiatement. Les VPS OpenVZ/LXC ne supportent pas XDP (limitation kernel) ; privilégiez un VPS KVM.

Puis-je utiliser PAKKT en parallèle de fail2ban ou Docker sans conflit de règles firewall ?

Absolument. La table nftables inet pakkt est isolée avec une priorité filter qui s'exécute dans la chaîne standard, sans interférer avec les règles Docker (table nat, priorité -100) ou fail2ban (généralement table filter iptables legacy, convertie en nftables via iptables-nft). L'agent PAKKT ne touche jamais aux autres tables. Assurez-vous simplement que la politique par défaut de la chaîne input reste accept dans la table pakkt, pour laisser les autres règles s'appliquer normalement.

Comment dimensionner le seuil max_port_pps pour un serveur Minecraft avec 100 joueurs simultanés ?

Un joueur Minecraft génère en moyenne 50–150 paquets/seconde (pps) en jeu actif (mouvement, combat, chunks loading). Pour 100 joueurs, comptez 5000–15 000 pps légitimes. Ajoutez une marge de 50 % pour les pics (rejoins massifs, events), soit ~22 000 pps. Un seuil max_port_pps = 25000 constitue un bon compromis. Activez également un meter nftables limitant chaque IP à 200 pps (rate_limit par source) pour bloquer les bots flood sans pénaliser les joueurs légitimes. Ajustez en observant les métriques PAKKT pendant une semaine ; si des joueurs légitimes sont parfois rate-limités, augmentez progressivement le seuil.