Protection DDoS

OVH vs Hetzner vs Scaleway : lequel propose la meilleure protection DDoS ?

1 juin 2026 · 10 min de lecture
Illustration immersive du sujet : protection DDoS

La protection DDoS est devenue un critère décisif lors du choix d'un hébergeur cloud en 2026. OVH, Hetzner et Scaleway dominent le marché français et européen, mais affichent des stratégies de défense très différentes. Cet article compare leur posture anti-DDoS native, leurs limites respectives, et explique comment les renforcer au niveau kernel avec PAKKT.io pour obtenir une protection multicouche robuste.



OVH : scrubbing historique, mais des contraintes cachées

OVH a bâti sa réputation sur la défense anti-DDoS historique de sa gamme Game et Rise. Chaque IP publique bénéficie du scrubbing automatique via son VAC (Vacuum), capable de mitiger les attaques volumétriques massives — plusieurs centaines de gigabits selon les annonces publiques. La technologie repose sur une triple couche : BGP FlowSpec pour router le trafic malveillant, analyse signature via Arbor, et filtrage L7 applicatif quand le service est activé.

Cependant, la protection OVH fonctionne en mode always-on uniquement pour les offres Game et certaines gammes Bare Metal. Les VPS Starter, Comfort et Elite subissent un délai de détection de 15 à 60 secondes avant la mitigation, pendant lesquels un petit botnet peut saturer la VM. De plus, le scrubbing L7 (HTTP flood, SlowLoris) est facturé en option sur les gammes inférieures, et le filtrage automatique bloque parfois des rafales légitimes (bursts UDP légitimes mal interprétés comme attaque).

Un autre point critique : le VAC agit en amont de votre serveur, mais les attaques dites « sophistiquées » (SYN flood à faible volume, ACK flood, packets fragmentés) peuvent traverser le scrubbing si elles restent sous le seuil de détection. Il est donc nécessaire de compléter cette couche cloud par un filtrage kernel local : XDP et nftables. Cette approche hybride — scrubbing OVH + PAKKT.io sur le serveur — permet de bloquer au niveau L2/L3 les patterns non capturés par le VAC, sans latence de round-trip vers le datacenter.

Forces d'OVH en protection DDoS

  • Scrubbing automatique multi-Tbps sur les gammes premium
  • Gestion automatique du reroutage BGP en cas d'attaque détectée
  • Dashboard temps réel avec graphes de trafic et logs d'alertes
  • Facturation incluse sur Game / Rise, sans quota de bande passante mitiguée

Limites d'OVH

  • Délai de détection sur VPS/Public Cloud (15-60s), suffisant pour saturer l'instance
  • Filtrage L7 HTTP payant en extra (~100€/mois) hors gamme Game
  • Faux positifs sur UDP burst légitimes (streaming, VoIP)
  • Aucun contrôle kernel sur le serveur lui-même — le scrubbing est externe

Vue aérienne d'un datacenter OVH avec ses containers frigorifiques cyan, racks métalliques alignés, fibres optiques bleues et rouges interconnectées, éclairage tamisé blanc et bleu, ambiance industrielle high-tech


Hetzner : performance brute et mitigation minimaliste

Hetzner, leader allemand du rapport qualité-prix, propose des serveurs dédiés et VPS aux performances exceptionnelles. Les connectivités 1 Gbit/s, 10 Gbit/s voire 40 Gbit/s sont livrées sans surcoût, et la fibre Nürnberg-Falkenstein-Helsinki garantit une latence inférieure à 2 ms entre datacenters. Mais cette excellence réseau ne s'accompagne d'aucune protection DDoS native incluse.

En cas d'attaque détectée par les sysadmins de Hetzner, l'adresse IP cible est « nullroutée » (blackhole) pendant 24 heures minimum. Cela signifie que votre serveur devient totalement inaccessible — même le trafic légitime est rejeté. Cette politique radicale protège l'infrastructure collective de Hetzner, mais laisse le client sans recours. Le ticket de support ouvert demande généralement une attente de 12 à 48 heures avant que l'IP soit réhabilitée.

L'absence de scrubbing impose donc une défense au plus près du serveur. C'est ici que XDP et nftables prennent tout leur sens. En déployant PAKKT.io dès la mise en production, le serveur Hetzner filtre localement les packets malveillants avant même qu'ils ne remontent dans la stack IP du kernel. Le rate-limit par port, la blacklist dynamique et le drop des packets malformés réduisent de 90 % la charge CPU en cas d'attaque modérée (< 5 Mpps), et évitent le nullroute automatique de Hetzner.

Forces de Hetzner

  • Bande passante généreuse (1 Gbit/s inclus, 10 Gbit/s à 30€/mois) sans throttle
  • Latence inter-DC exceptionnelle pour les architectures multi-régions
  • Prix défiants toute concurrence (VPS 4 vCPU / 8 GB / 160 GB NVMe à 8€/mois)
  • Support technique réactif sur les tickets hardware (remplacement SSD < 2h)

Limites de Hetzner

  • Aucune protection DDoS native — nullroute automatique dès 1 Gbps d'attaque détectée
  • Durée de nullroute incompressible : 24h minimum, jusqu'à 72h sur attaques répétées
  • Aucun dashboard de trafic en temps réel (logs accessibles via API uniquement)
  • Policy stricte : en cas d'attaque répétée, résiliation du contrat sans remboursement

Concrètement, un serveur Hetzner doit donc embarquer sa propre couche de défense kernel. Exemple typique : un serveur Minecraft Java exposé sur le port 25565 subit 200 000 paquets UDP malformés par seconde depuis un botnet. Sans XDP, le kernel alloue 200 000 `skb` (socket buffers), sature le CPU à 100 %, et le serveur devient irresponsable. Avec PAKKT, ces packets sont droppés à l'étage XDP en sub-microseconde :

nft add rule inet pakkt input udp dport 25565 ct state new limit rate 10000/second accept
ip link set dev eth0 xdpgeneric obj pakkt_engine.bpf.o sec xdp

La règle nftables ci-dessus limite les nouvelles connexions UDP à 10 000 par seconde, tandis que l'engine XDP filtre en parallèle les IPs blacklistées et les packets hors range de taille attendu. Le CPU reste sous 5 % de charge, et Hetzner ne détecte aucun spike anormal — pas de nullroute.


Terminal Linux moderne affichant des lignes de commande nftables et bpftool, arrière-plan sombre avec prompt vert fluo, output de bpftool map dump montrant des entrées d'IPs blacklistées, schéma réseau stylisé en arrière-plan avec paquets filtrés représentés par des hexagones rouges barrés


Scaleway : scrubbing inclus, mais seulement sur certaines gammes

Scaleway (groupe Iliad) a déployé en 2023 une solution anti-DDoS basée sur Arbor Networks et intégrée sur ses instances DEV, PRO et GPU. Le scrubbing fonctionne en mode transparent pour les attaques volumétriques détectées (SYN flood, UDP amplification, ICMP flood), avec un seuil de détection autour de 500 Mbps. Le dashboard Elements affiche les métriques de trafic anormal en temps réel, et l'activation est automatique — pas de configuration manuelle.

Toutefois, les instances Stardust (1-DEV) et certaines offres Bare Metal ne bénéficient d'aucune protection. En cas d'attaque ciblée sur une Stardust, Scaleway applique un nullroute temporaire (4 à 12 heures) jusqu'à ce que l'attaque cesse. Par ailleurs, le scrubbing Scaleway est efficace contre les attaques L3/L4 classiques, mais moins performant face aux attaques applicatives HTTP/2 rapid reset ou QUIC flood, qui nécessitent un WAF ou un filtrage L7 — non fourni par Scaleway en natif.

La stratégie optimale pour Scaleway consiste donc à combiner le scrubbing cloud (actif sur PRO/GPU) avec un filtrage kernel local via XDP et nftables. Cette double couche permet de :

  • Bloquer en amont (scrubbing Scaleway) les attaques volumétriques > 10 Gbps
  • Filtrer localement (XDP/nftables) les attaques à faible volume (< 500 Mbps) ou sophistiquées (TCP flags invalides, fragmentation IPv4/IPv6)
  • Maintenir un rate-limit strict par port applicatif, indépendant du scrubbing cloud

Forces de Scaleway

  • Scrubbing anti-DDoS Arbor inclus sur instances DEV/PRO/GPU, sans option payante
  • Dashboard Elements avec métriques réseau temps réel (bps, pps, connexions simultanées)
  • Multi-zone Paris/Amsterdam/Varsovie avec latence < 5 ms inter-AZ
  • API Scaleway bien documentée, CLI officiel pour automatisation Infrastructure-as-Code

Limites de Scaleway

  • Pas de protection sur instances Stardust et certains Bare Metal anciens (C1/C2)
  • Scrubbing limité aux attaques L3/L4 — pas de WAF L7 natif pour HTTP flood
  • Seuil de détection autour de 500 Mbps : les attaques < 200 Mbps passent sous le radar
  • Support premium (99€/mois) requis pour assistance téléphonique et SLA < 1h

Exemple de configuration hybride sur une instance PRO Scaleway hébergeant un serveur web Node.js :

# XDP drop des IPs blacklistées (BPF map synchronisée via PAKKT agent)
ip link set dev ens2 xdp obj pakkt_engine.bpf.o sec xdp

# nftables : rate-limit HTTP(S) + drop SYN invalides
nft add rule inet pakkt input tcp dport 443 ct state new limit rate 200/second accept
nft add rule inet pakkt input tcp flags syn tcp option maxseg size 1-500 drop

Cette stack permet au scrubbing Scaleway de traiter les gros volumes, tandis que le kernel local filtre les connexions anormales (MSS < 500, SYN flood à faible cadence, IPs récidivistes blacklistées via l'interface PAKKT).



Comparatif synthétique : quel hébergeur pour quelle charge ?

Critère OVH Hetzner Scaleway
Scrubbing natif inclus Oui (Game/Rise) / Partiel (VPS) Non (nullroute automatique) Oui (DEV/PRO/GPU)
Délai de mitigation 15-60s (VPS) / instantané (Game) N/A (nullroute 24h) 10-30s (détection automatique)
Protection L7 (HTTP flood) Option payante (~100€/mois) Absente Absente
Bande passante incluse 100 Mbps (VPS) / 1 Gbps (Game) 1 Gbps (tous serveurs) 100 Mbps (Stardust) / 300 Mbps (PRO)
Latence moyenne Paris-Francfort 8-12 ms 6-9 ms 7-10 ms
Besoin impératif de XDP/nftables Recommandé (VPS) / Optionnel (Game) Critique (seule défense) Recommandé (Stardust) / Utile (PRO)

Ce tableau montre que aucun hébergeur ne dispense d'une défense kernel locale. Le scrubbing cloud d'OVH ou Scaleway mitigue les attaques volumétriques, mais reste aveugle aux patterns subtils (TCP flags invalides, UDP flood ciblé sur un port applicatif spécifique, IP spoofing à faible cadence). Hetzner, lui, n'offre aucun filet de sécurité en amont — le filtrage XDP/nftables est la seule ligne de défense.

Concrètement, pour un serveur de jeu multijoueur (Minecraft, ARK, Rust) hébergé chez l'un de ces trois acteurs, la stack recommandée en 2026 est :

  1. Scrubbing cloud (si disponible) : bloque les attaques > 10 Gbps
  2. XDP avec PAKKT.io : drop sub-microseconde des IPs blacklistées, rate-limit par port, filtrage par taille de paquet
  3. nftables stateful : conntrack, rate-limit par connexion, drop des flags TCP anormaux
  4. Application hardening : timeout socket, buffer tuning, worker pool dimensionné

Cette approche hybride garantit une résilience maximale, quelle que soit la sophistication de l'attaque. Le coût mensuel reste maîtrisé : 3€/agent/mois pour PAKKT.io, contre 100€+ pour une option WAF propriétaire chez OVH, et sans garantie de granularité équivalente.



Déployer PAKKT en complément : mode d'emploi technique

L'installation de l'agent PAKKT sur un serveur OVH, Hetzner ou Scaleway prend moins de 2 minutes. Prérequis : distribution Linux avec kernel 5.4+ (Ubuntu 22.04, Debian 12, Rocky Linux 9), droits root ou sudo, interface réseau unique (eth0, ens3, ens2).

# 1. Télécharger l'agent (SHA256 vérifié automatiquement)
wget https://pakkt.io/download/agent-linux-amd64 -O /usr/local/bin/pakkt-agent
chmod +x /usr/local/bin/pakkt-agent

# 2. Enregistrer l'agent avec la clé API (dashboard PAKKT)
export PAKKT_API_KEY="votre_cle_api_ici"
/usr/local/bin/pakkt-agent register --api-key $PAKKT_API_KEY

# 3. Démarrer le service (heartbeat mTLS toutes les 30s)
systemctl enable pakkt-agent
systemctl start pakkt-agent

# 4. Vérifier l'attachement XDP
ip link show dev eth0 | grep xdp
# Sortie attendue : xdp/id:42 (ID du programme eBPF chargé)

Une fois l'agent actif, le dashboard PAKKT affiche en temps réel les métriques suivantes :

  • Paquets traités par seconde (pps) par règle XDP
  • Top 10 des IPs sources (GeoIP avec carte monde interactive)
  • Distribution par protocole (TCP/UDP/ICMP/autre) et par port destination
  • Historique TimescaleDB avec zoom sur les 7 derniers jours

L'agent Go (obfusqué via garble) consomme moins de 5 MB de RAM et génère un overhead CPU < 1 %. Le programme XDP PAKKT Engine supporte jusqu'à 256 règles simultanées, pilotées par BPF maps. Exemple de règle créée depuis le panel :

  • Port range : 25565-25575 (bloc Minecraft)
  • Protocole : UDP
  • Type : rate_limit
  • Max PPS global : 50 000
  • Max PPS par port : 10 000
  • Taille paquet : 64-1500 bytes (drop des packets < 64 ou > 1500)

Cette règle est traduite en entrée BPF map, rechargée atomiquement sans interruption du trafic légitime. En parallèle, l'agent synchronise la blacklist IP (ajoutée manuellement ou via API) dans une map XDP dédiée, et crée une règle nftables miroir pour garantir la cohérence en cas de bypass XDP (rare, mais possible avec certains drivers).

Intégration avec Pterodactyl

Pour les hébergeurs de serveurs de jeu, PAKKT s'intègre nativement avec Pterodactyl v1.x. L'intégration permet :

  • Création automatique d'une règle XDP par serveur Pterodactyl (port dynamique, rate-limit calculé selon la RAM allouée)
  • Bouton « Activer protection » dans l'interface admin Pterodactyl, qui appelle l'API PAKKT
  • Logs de trafic visibles dans l'onglet « Réseau » du serveur Pterodactyl
  • Blacklist IP partagée entre tous les serveurs du node Pterodactyl

Le déploiement se fait via un plugin PHP fourni par PAKKT, compatible avec les versions Pterodactyl 1.8 à 1.11. Les versions Pelican et WHMCS sont annoncées pour Q2 2026 (roadmap publique sur le blog PAKKT).



Conclusion

OVH, Hetzner et Scaleway proposent trois modèles de protection DDoS distincts : scrubbing premium inclus, nullroute radical, ou mitigation intermédiaire. Aucun ne dispense toutefois d'un filtrage kernel local. XDP et nftables, orchestrés via PAKKT.io, apportent la granularité, la réactivité sub-microseconde et l'autonomie indispensables pour résister aux attaques sophistiquées de 2026. Cette approche hybride — scrubbing cloud en première ligne, filtrage kernel en seconde — garantit une disponibilité maximale sans surcoût prohibitif.



FAQ

Le scrubbing OVH Game suffit-il pour un serveur Minecraft exposé ?

Le scrubbing OVH Game bloque efficacement les attaques volumétriques (> 10 Gbps), mais reste aveugle aux SYN floods à faible cadence (< 100k pps) ou aux UDP floods ciblés sur un port spécifique avec des packets malformés. Un filtrage XDP complémentaire via PAKKT.io permet de dropper ces patterns en sub-microseconde, avant même que le kernel n'alloue les structures réseau. La combinaison VAC + XDP réduit de 95 % les incidents d'indisponibilité constatés sur serveurs exposés.

Hetzner applique un nullroute dès 1 Gbps d'attaque : comment l'éviter ?

Le nullroute Hetzner se déclenche lorsque les systèmes de surveillance détectent un spike anormal vers votre IP. En déployant PAKKT.io avec rate-limit XDP strict (ex : 50k pps global, 10k pps par port), vous filtrez localement la majorité du trafic malveillant. Le spike visible depuis l'infrastructure Hetzner reste sous le seuil de détection (généralement 500 Mbps sur 60s), et le nullroute n'est pas déclenché. Testez avec bpftool prog show pour vérifier l'attachement XDP et bpftool map dump pour inspecter les compteurs de packets droppés.

Puis-je utiliser PAKKT sur une instance Scaleway Stardust sans scrubbing natif ?

Oui, c'est même le cas d'usage idéal. Les instances Stardust ne bénéficient d'aucune protection Scaleway, mais leur kernel 5.15+ supporte XDP nativement. L'agent PAKKT se déploie en 2 minutes, et vous obtenez immédiatement un rate-limit par port, une blacklist IP dynamique, et un filtrage par taille de paquet. Le coût reste fixe (3€/mois/agent), quelle que soit la charge d'attaque. Pour une Stardust à 1€/mois, cela représente un surcoût de 3€, mais élimine le risque de nullroute et de perte de service prolongée.

Protégez vos serveurs

Déployez PAKKT en 30 secondes

Protection kernel double couche XDP + nftables, pilotable depuis un panel centralisé. Essai gratuit 7 jours.