Protection DDoS cloud ou on-server : avantages et limites de chaque approche

La protection DDoS cloud et la protection on-server sont deux paradigmes antagonistes pour défendre vos infrastructures contre les attaques par déni de service. Alors que les solutions cloud promettent une absorption illimitée via scrubbing distant, la filtration kernel-level directement sur le serveur offre latence minimale et contrôle total. Ce comparatif technique 2026 détaille les forces, faiblesses et cas d'usage de chaque approche pour vous aider à choisir — ou à combiner — les deux stratégies.

Protection DDoS cloud : scrubbing distant et absorption massive

Principe de fonctionnement

Les solutions de protection DDoS cloud reposent sur un réseau mondial de points de présence (PoPs) qui analysent, nettoient et retransmettent le trafic légitime vers votre serveur d'origine. Le flux suit ce chemin : client → PoP scrubbing → serveur cible. Les paquets suspects sont abandonnés ou limités dans les datacenters du fournisseur, avant qu'ils n'atteignent votre bande passante. Cette architecture convient aux attaques volumétriques dépassant la capacité réseau de votre hébergement (floods UDP, amplifications DNS/NTP/SSDP, SYN floods à plusieurs centaines de Gbps).

Avantages techniques

• Capacité d'absorption théoriquement illimitée : les grands fournisseurs disposent de plusieurs Tbps de bande passante distribuée, capable d'éponger les attaques record.
• Pas de charge CPU sur votre serveur : le filtrage se fait en amont ; votre noyau Linux ne voit que le trafic propre.
• Mitigation L7 intégrée : certains services cloud offrent WAF, protection bot, challenge JavaScript/CAPTCHA pour les attaques applicatives (HTTP floods, Slowloris).
• Anycast DNS : répartition géographique automatique du trafic, réduction de la latence pour les utilisateurs finaux dans une utilisation normale.

Limites et contraintes

• Latence ajoutée inévitable : chaque paquet transite par le PoP de scrubbing, ajoutant 5 à 50 ms selon la distance géographique et la qualité du peering. Rédhibitoire pour les jeux compétitifs (FPS, MOBA) ou trading haute fréquence.
• Coût récurrent élevé : modèle tarifaire par bande passante propre ou abonnement mensuel avec plafonds. Les attaques prolongées sur plusieurs jours font exploser la facture.
• Dépendance au fournisseur : si le service cloud subit une panne (DDoS sur l'infrastructure du fournisseur lui-même, erreur de routage BGP), votre service devient inaccessible.
• Faux positifs : les heuristiques automatiques peuvent bloquer du trafic légitime (burst de connexions légitimes lors d'un lancement de produit, protocoles propriétaires non reconnus).
• Transparence limitée : vous ne contrôlez pas les règles exactes appliquées ; les logs détaillés sont souvent payants ou incomplets.

Enfin, les solutions cloud nécessitent de router tout votre trafic via le provider (changement d'adresse IP ou de DNS), ce qui complexifie la migration et crée un point de défaillance unique.

Protection on-server : filtration kernel-level directe

Architecture XDP/eBPF + nftables

La protection on-server place la logique de filtrage directement sur le noyau Linux du serveur cible, en amont de la pile réseau. XDP (eXpress Data Path) s'exécute au niveau du driver NIC (L2), avant même l'allocation de skb (socket buffer), permettant de dropper ou rate-limiter des millions de paquets par seconde avec une latence sub-microseconde. Les règles sont stockées dans des BPF maps (tables de hachage kernel-space) et mises à jour à chaud, sans redémarrage. PAKKT.io implémente ce paradigme via un programme XDP unique par interface, capable de gérer jusqu'à 256 règles simultanées (port range, protocole, rate-limit par port, min/max packet size).

Complémentairement, nftables assure le filtrage stateful (conntrack, suivi TCP flags, rate-limit par connexion via meter/burst) dans une table isolée inet pakkt, sans conflit avec Docker, fail2ban ou iptables-persistent. La double couche XDP + nftables offre ainsi une défense en profondeur : XDP absorbe les floods volumétriques, nftables gère la granularité L4 et les règles complexes.

# Exemple de règle nftables PAKKT : rate-limit TCP SYN sur port 25565
nft add rule inet pakkt input tcp dport 25565 tcp flags syn ct state new limit rate 100/second accept

# Dump des règles XDP via BPF map
bpftool map dump name pakkt_rules

Avantages techniques

• Latence ajoutée négligeable : traitement au niveau driver, pas de hop réseau supplémentaire. L'overhead XDP est inférieur à 1 µs par paquet, invisible pour les utilisateurs finaux.
• Contrôle total : vous définissez les règles exactes, accédez aux logs en temps réel (métriques par port/règle dans TimescaleDB pour PAKKT), et auditez chaque changement de configuration.
• Coût prévisible : pas de surcoût par bande passante attaquée. PAKKT facture 3€/agent/mois quel que soit le volume de trafic bloqué.
• Zero trust réseau : whitelist/blacklist IP double couche (BPF map + règle nft) synchronisées automatiquement, idéal pour les infrastructures sensibles (B2B, API privées).
• Impact système minimal : agent Go obfusqué (garble) consommant moins de 1% CPU et moins de 5 MB RAM, mTLS, heartbeat 30s, self-update SHA256.

Limites et prérequis

• Capacité d'absorption limitée par le hardware : si l'attaque sature physiquement le port réseau (100 Gbps sur un lien 10 Gbps), les paquets sont droppés par le NIC avant même d'atteindre XDP. La protection on-server ne crée pas de bande passante supplémentaire.
• Exigences kernel : noyau Linux 5.x minimum avec support XDP. Pas de compatibilité Windows Server. Vérifier la prise en charge du driver NIC (la plupart des Intel/Mellanox récents supportent XDP native ou generic mode).
• Pas de mitigation L7 : XDP et nftables opèrent aux couches L2/L3/L4. Les attaques applicatives (HTTP floods, Slowloris, SQL injection) nécessitent une surcouche (reverse proxy, WAF) ou une solution cloud complémentaire.
• Administration Linux requise : bien que PAKKT propose une interface centralisée (panel, API publique, intégration Pterodactyl), la compréhension des concepts réseau (netfilter, conntrack, BPF) est un atout pour les configurations avancées.

La protection on-server brille sur les attaques L3/L4 de taille "moyenne" (10-100 Gbps) et les scénarios où la latence est critique : jeux compétitifs, streaming en direct, serveurs de messagerie temps réel, trading algorithmique.

Tableau comparatif : cloud vs on-server

Critère	Protection DDoS cloud	Protection on-server (XDP/nftables)
Capacité absorption	Plusieurs Tbps (scrubbing distribué)	Limitée par bande passante hébergeur
Latence ajoutée	5-50 ms (hop scrubbing)	< 1 µs (kernel-level)
Coût modèle	Par bande passante ou forfait mensuel élevé	Fixe par agent (~3€/mois)
Contrôle règles	Limité (heuristiques fournisseur)	Total (BPF maps, nftables)
Mitigation L7	Oui (WAF, challenge bot)	Non (L2/L3/L4 uniquement)
Dépendance externe	Forte (SPOF si panne fournisseur)	Nulle (autonomie complète)
Prérequis système	Aucun (routage DNS/BGP)	Linux kernel 5.x+, XDP-capable NIC
Transparence logs	Limitée (payante souvent)	Totale (métriques temps réel, audit log)

Stratégie hybride : combiner cloud et on-server

Défense en profondeur multi-couches

Les deux approches ne sont pas mutuellement exclusives. Une architecture optimale pour les infrastructures critiques consiste à superposer scrubbing cloud et filtration kernel :

• Couche 1 (cloud) : absorbe les attaques volumétriques massives (> 100 Gbps), protège contre les floods L7, distribue le trafic géographiquement via Anycast.
• Couche 2 (on-server) : rate-limite finement par port/protocole, applique des whitelists IP strictes, bloque les scans de ports, les paquets malformés, les patterns d'attaque spécifiques à votre application.

Cette combinaison garantit que même si le scrubbing cloud est contourné (attaque directe sur l'IP d'origine exposée accidentellement, leak DNS), la protection kernel reste active. À l'inverse, si l'attaque sature la bande passante de l'hébergeur, le scrubbing cloud absorbe l'excédent avant que le lien ne sature.

Cas d'usage recommandés par profil

Profil	Recommandation
Serveur de jeu compétitif (FPS, MOBA)	On-server uniquement (latence critique). Dimensionner la bande passante hébergeur en conséquence.
Site e-commerce haute disponibilité	Hybride : cloud pour L7 + on-server pour rate-limit API, protection login.
Infrastructure B2B (API privée, SaaS)	On-server avec whitelist IP stricte. Cloud optionnel si clients mondiaux nombreux.
Plateforme de streaming vidéo	Cloud (CDN + scrubbing intégré) pour distribution géographique, on-server pour serveur d'origine.
Serveur communautaire (Discord bot, Minecraft moddé)	On-server (budget contraint, attaques rarement > 50 Gbps).

Intégration opérationnelle

Si vous optez pour l'hybride, veillez à :

• Configurer le scrubbing cloud en mode transparent (proxy protocol, X-Forwarded-For préservé) pour que les règles on-server voient les vraies IPs sources.
• Synchroniser les listes IP : blacklist cloud doit être répliquée dans la BPF map on-server pour éviter la re-analyse de paquets déjà marqués suspects.
• Monitorer les deux couches indépendamment : le dashboard PAKKT agrège métriques kernel (pps par port, règle, pays) tandis que le portail cloud fournit les stats de scrubbing.
• Prévoir une procédure de failover : si le cloud tombe, basculer le DNS directement sur l'IP serveur (où la protection on-server reste active).

Enfin, testez régulièrement votre stack avec des attaques simulées (outils comme hping3, t50, ou services de stress test légitimes sur accord préalable de l'hébergeur) pour valider que les seuils de rate-limit et les règles XDP/nftables réagissent comme attendu.

# Simuler un SYN flood local (ATTENTION : hébergeur prévenu au préalable)
hping3 -S --flood -p 80 TARGET_IP

# Vérifier les drops XDP en temps réel
bpftool prog show
bpftool map dump name pakkt_stats

Pour les entreprises gérant plusieurs serveurs (clusters Kubernetes, fermes de jeux, plateformes SaaS multi-tenants), l'API publique PAKKT permet d'automatiser le déploiement et la synchronisation des règles via Terraform, Ansible ou CI/CD GitOps.

Conclusion

Le choix entre protection DDoS cloud et on-server dépend de trois variables : capacité d'absorption requise, sensibilité à la latence, et budget. Les infrastructures critiques à forte latence (gaming, finance) privilégieront la filtration kernel XDP/eBPF pour garder le contrôle et l'ultra-réactivité. Les plateformes publiques à fort trafic mondial opteront pour le scrubbing cloud. L'hybride reste l'optimum pour les environnements exposés nécessitant défense en profondeur et résilience maximale.

FAQ

Une protection on-server peut-elle vraiment bloquer une attaque de 500 Gbps ?

Non. Si votre lien réseau est 10 Gbps, les paquets excédentaires sont droppés par le NIC ou le routeur amont avant d'atteindre le kernel. La protection XDP/nftables excelle pour filtrer efficacement le trafic qui passe physiquement par le port, mais ne crée pas de bande passante supplémentaire. Pour absorber 500 Gbps, un scrubbing cloud avec capacité Tbps est indispensable.

Comment éviter que le scrubbing cloud ajoute trop de latence pour un serveur de jeu ?

Choisissez un fournisseur avec PoPs géographiquement proches de votre hébergement et de vos joueurs (peering direct si possible). Toutefois, même optimisé, le hop supplémentaire ajoute 5-15 ms incompressibles. Pour les jeux compétitifs où chaque milliseconde compte, privilégiez la protection on-server (XDP/nftables) et dimensionnez votre bande passante hébergeur en fonction des attaques historiques.

Peut-on combiner PAKKT avec une solution de scrubbing cloud existante ?

Oui, c'est même recommandé pour une défense hybride. Configurez le scrubbing cloud en mode transparent (proxy protocol activé) pour préserver les IPs sources réelles. Les règles XDP/nftables de PAKKT filtreront alors le trafic propre qui arrive après scrubbing, appliquant rate-limit granulaire, whitelists IP et règles métier spécifiques. Les deux couches fonctionnent en série sans interférence.