Comment détecter une attaque DDoS sur son VPS en moins de 30 secondes ?

Détecter une attaque DDoS sur VPS est une compétence essentielle pour tout administrateur système qui veut maintenir son infrastructure en ligne face aux menaces modernes. Un VPS non surveillé peut succomber en quelques secondes sous une vague de trafic malveillant, entraînant indisponibilité, perte de revenus et dégradation de réputation. Ce guide 2026 vous montre comment identifier les signaux d'alerte d'une attaque DDoS en temps réel, analyser les vecteurs d'intrusion au niveau kernel, et mettre en place une détection automatisée avec XDP/eBPF et nftables pour réagir avant que votre serveur ne soit submergé.

Symptômes réseau : reconnaître une attaque DDoS sur VPS en cours

Une attaque DDoS se manifeste par des anomalies réseau caractéristiques. Le premier indicateur est une chute brutale des performances : latence qui explose (ping supérieur à 200 ms alors qu'il est habituellement sous 10 ms), timeouts sur les connexions SSH ou HTTP, impossibilité d'établir de nouvelles sessions TCP. Si votre VPS devient lent ou inaccessible sans modification récente de configuration, suspectez immédiatement un flood.

Le deuxième symptôme clé est la saturation de la bande passante. Vérifiez la consommation réseau avec iftop, nload ou vnstat. Un trafic entrant soudainement multiplié par 10, 100 ou 1000 sans hausse proportionnelle du trafic sortant indique un flood volumétrique (UDP flood, ICMP flood, ou SYN flood avec spoofing). Les graphiques de monitoring montrent alors une courbe verticale anormale, souvent saturant la totalité du Gbit/s alloué par l'hébergeur.

# Vérifier le trafic en temps réel interface eth0
iftop -i eth0 -n -P

# Historique réseau sur 24h
vnstat -i eth0 -d

Le troisième signe est la multiplication des connexions semi-ouvertes (état SYN_RECV). Une attaque SYN flood inonde la table de connexions du kernel. Inspectez avec ss ou netstat : plusieurs milliers de connexions en SYN_RECV provenant d'IP sources aléatoires révèlent un flood TCP.

# Compter les connexions SYN_RECV
ss -tan state syn-recv | wc -l

# Afficher les top IP sources en SYN_RECV
ss -tan state syn-recv | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

Si vous observez plus de 1000 connexions SYN_RECV simultanées sur un VPS classique, vous êtes très probablement sous attaque. Un VPS standard gère rarement plus de quelques centaines de connexions légitimes en simultané.

Analyse kernel-level : identifier le vecteur d'attaque DDoS avec XDP et nftables

Une fois les symptômes confirmés, la phase d'analyse vise à identifier précisément le vecteur d'attaque : protocole (TCP, UDP, ICMP, autre), port cible, taille des paquets, distribution géographique des sources. Les outils kernel-level offrent une visibilité granulaire sans surcharge CPU excessive.

Capturer et analyser le trafic avec tcpdump

Lancez une capture ciblée pour échantillonner le trafic entrant sur l'interface physique. Limitez impérativement la durée pour ne pas saturer le disque ni ralentir davantage le système.

# Capturer 10 000 paquets sur eth0, tous protocoles
timeout 30 tcpdump -i eth0 -c 10000 -nn -q > /tmp/ddos_sample.txt

# Filtrer uniquement UDP pour détecter un UDP flood
timeout 30 tcpdump -i eth0 -c 10000 udp -nn -q > /tmp/udp_flood.txt

Analysez ensuite la sortie pour identifier les ports cibles les plus frappés et les IP sources dominantes. Un flood UDP classique cible souvent un port de service applicatif (query de jeu vidéo, DNS, NTP) avec des paquets de taille fixe.

Exploiter les compteurs nftables pour la détection en temps réel

nftables intègre des compteurs par règle. Si vous avez déjà une table inet pakkt avec des règles de rate-limit, consultez les stats pour voir quelle règle drop/limit le plus de paquets.

# Afficher les compteurs nftables avec détails
nft -a list table inet pakkt

# Réinitialiser les compteurs pour mesurer sur une fenêtre précise
nft reset counters table inet pakkt

Une règle qui drop des millions de paquets en quelques secondes confirme qu'elle intercepte le flux d'attaque. Notez le port et le protocole associés pour affiner votre réponse.

Inspecter les BPF maps XDP pour voir les règles actives

Si vous utilisez le moteur XDP de PAKKT.io, chaque règle est stockée dans une BPF map. Listez les maps actives et leurs contenus pour vérifier quelles règles XDP bloquent ou rate-limit le trafic.

# Lister les BPF maps chargées
bpftool map list

# Dumper le contenu de la map pakkt_rules (exemple ID 42)
bpftool map dump id 42

Vous verrez les entrées (port, protocole, rule_type, max_pps, etc.) et pourrez corréler avec les pics de drop observés. Le PAKKT Engine opère en sub-microseconde par paquet, offrant une détection quasi temps réel sans impacter les performances CPU.

GeoIP et répartition des sources d'attaque

Une attaque DDoS distribuée provient de milliers d'IP sources réparties mondialement (botnet). Extrayez les IP sources depuis tcpdump ou les logs applicatifs, puis passez-les dans une base GeoIP (MaxMind GeoLite2, IP2Location) pour cartographier l'origine.

# Extraire les IP sources depuis tcpdump, compter les occurrences
cat /tmp/ddos_sample.txt | awk '{print $3}' | cut -d'.' -f1-4 | sort | uniq -c | sort -rn | head -50 > /tmp/top_sources.txt

Le dashboard PAKKT intègre une carte monde GeoIP en temps réel, affichant la distribution géographique des paquets drop, les top pays sources et les top IP individuelles, sans nécessiter de parsing manuel.

Automatiser la détection : métriques, logs et alertes pour anticiper les attaques DDoS

La détection manuelle fonctionne en phase d'incident, mais une infrastructure résiliente repose sur une détection automatisée et des alertes proactives. Trois piliers assurent cette surveillance continue : métriques système, logs centralisés, et seuils d'alerte configurés.

Collecter les métriques kernel avec eBPF

eBPF permet de collecter des métriques réseau directement depuis le kernel sans overhead significatif. Le PAKKT Engine expose des compteurs par règle (paquets dropped, paquets rate-limited, paquets autorisés) dans des BPF maps, interrogeables via l'API ou le panel web. Ces métriques alimentent une base TimescaleDB pour historiser les tendances sur plusieurs mois.

Vous pouvez également déployer bpftrace ou bcc-tools pour capturer des événements réseau custom (ex. : nombre de paquets SYN par seconde, taille moyenne des paquets UDP entrants).

# Exemple bpftrace : compter les paquets SYN par seconde
bpftrace -e 'kprobe:tcp_v4_syn_recv_sock { @syn_count = count(); } interval:s:1 { print(@syn_count); clear(@syn_count); }'

Centraliser les logs avec rsyslog ou journald

Configurez nftables pour logger les drops suspects vers syslog. Créez une règle log avant drop dans la chaîne input de votre table inet pakkt.

nft add rule inet pakkt input ip saddr != @pakkt_whitelist tcp flags syn limit rate 100/second log prefix \"[PAKKT-DROP-SYN] \" drop

Les logs sont ensuite centralisés (rsyslog vers un SIEM, journald vers Loki/Grafana, ou exportés via l'agent PAKKT vers le panel). Une montée soudaine de logs [PAKKT-DROP-SYN] déclenche une alerte automatique.

Configurer des seuils d'alerte intelligents

Définissez des seuils adaptés à votre trafic normal. Par exemple, si votre VPS reçoit habituellement 5000 paquets/s, un seuil à 20 000 pps déclenche une alerte DDoS probable. Le panel PAKKT permet de définir des alertes email ou webhook (Discord, Slack, PagerDuty) sur plusieurs conditions : dépassement de seuil global pps, nombre de règles drop actives, nombre d'IP blacklistées en 5 minutes.

Métrique	Seuil nominal	Seuil alerte DDoS
Paquets/s entrants	< 10 000	> 50 000
Connexions SYN_RECV	< 200	> 2000
Bande passante entrant (Mbps)	< 100	> 800 (saturation Gbit/s)
Nombre d'IP sources uniques / minute	< 500	> 5000

Intégration avec l'écosystème existant

Si vous gérez plusieurs VPS via Pterodactyl, l'intégration PAKKT permet d'activer/désactiver des règles XDP directement depuis le panel Pterodactyl v1.x, et de consulter les métriques de chaque node en un coup d'œil. L'API publique PAKKT autorise également l'automatisation via scripts (ajout dynamique d'IP à la blacklist, création de règles temporaires pendant un événement, export des logs vers un SIEM tiers).

Réponse immédiate : mitigation kernel-level d'une attaque DDoS détectée

Une fois l'attaque identifiée, la réponse doit être immédiate et ciblée pour minimiser l'impact. La combinaison XDP + nftables offre une mitigation kernel-level sans redémarrage de service ni modification applicative.

Créer une règle XDP de blocage ultra-rapide

Supposons que vous détectez un UDP flood sur le port 19132 (serveur Minecraft Bedrock). Créez une règle XDP pour drop tous les paquets UDP vers ce port dépassant 10 000 pps au total, ou rate-limit à 500 pps par port pour autoriser un trafic légitime résiduel.

Avec PAKKT, cette règle se configure via le panel web ou l'API en moins de 10 secondes. Le PAKKT Engine la compile et l'injecte dans la BPF map sans interruption. Le filtrage s'applique immédiatement en XDP_DROP, rejetant les paquets malveillants avant même qu'ils n'atteignent la stack réseau du kernel.

Renforcer avec nftables stateful

Pour un SYN flood TCP, combinez rate-limit XDP global (ex. max 50 000 SYN/s total) et une règle nftables stateful qui limite les nouvelles connexions par IP source.

nft add rule inet pakkt input tcp flags syn ct state new meter syn_flood_meter { ip saddr limit rate 10/second burst 20 packets } accept
nft add rule inet pakkt input tcp flags syn ct state new drop

Cette règle autorise jusqu'à 10 nouvelles connexions SYN par seconde par IP source (burst 20 pour absorber les pics légitimes), et drop le reste. Le conntrack (ct state new) garantit que seules les nouvelles connexions sont rate-limitées, sans impacter les connexions établies.

Blacklister les IP sources malveillantes

Si l'analyse GeoIP révèle que 80 % du trafic provient de quelques ASN ou pays non légitimes pour votre service, blacklistez les plages IP correspondantes. PAKKT synchronise automatiquement la blacklist entre la BPF map XDP et un set nftables @pakkt_blacklist, assurant un drop cohérent sur les deux couches.

# Ajouter une IP à la blacklist via nftables (sync auto PAKKT)
nft add element inet pakkt pakkt_blacklist { 203.0.113.42 }

# Ajouter une plage CIDR
nft add element inet pakkt pakkt_blacklist { 198.51.100.0/24 }

La blacklist XDP drop les paquets en sub-microseconde, bien avant que nftables ou le firewall applicatif ne soient sollicités, économisant CPU et RAM.

Surveiller l'efficacité de la mitigation

Après activation des règles, surveillez les compteurs pour vérifier que le taux de paquets drop augmente et que la charge CPU/bande passante diminue. Le dashboard PAKKT affiche en temps réel les graphiques pps drop par règle, permettant de valider l'efficacité sous quelques secondes.

# Vérifier la charge CPU globale
top -bn1 | grep "Cpu(s)"

# Vérifier les paquets drop nftables
nft list chain inet pakkt input | grep counter

Si la mitigation fonctionne, le VPS redevient accessible en quelques dizaines de secondes. Si l'attaque persiste ou change de vecteur, ajustez les règles dynamiquement : augmentez le seuil de rate-limit, bloquez un nouveau port, ou activez une whitelist stricte (allow_only) pour n'autoriser que les IP connues.

Complémentarité avec le scrubbing cloud

Pour les attaques volumétriques dépassant plusieurs Gbps, la mitigation kernel-level sur le VPS seul ne suffit plus : la bande passante de l'hébergeur sature avant que XDP ne puisse traiter les paquets. Dans ce cas, combinez PAKKT avec une solution de scrubbing cloud en amont (Cloudflare Magic Transit, OVH Game DDoS, Arbor Networks). Le scrubbing filtre le gros du volume, PAKKT affine la protection au niveau kernel pour bloquer les attaques applicatives (L7) ou les floods de faible volume non détectés par le scrubbing. Les deux couches sont complémentaires, pas concurrentes.

Conclusion

Détecter une attaque DDoS sur VPS repose sur l'observation de symptômes réseau caractéristiques, l'analyse kernel-level des vecteurs d'intrusion avec XDP/eBPF et nftables, et l'automatisation de la surveillance via métriques et logs centralisés. La réponse immédiate par règles de blocage et rate-limit au niveau kernel minimise l'impact sans redémarrage applicatif. En combinant détection proactive, mitigation stateless XDP ultra-rapide et firewall stateful nftables, votre VPS reste résilient face aux attaques DDoS modernes, qu'elles soient volumétriques ou applicatives.

FAQ

Combien de temps faut-il pour détecter une attaque DDoS sur un VPS non surveillé ?

Sans monitoring automatisé, la détection dépend du moment où l'administrateur constate l'indisponibilité, généralement entre 5 et 30 minutes après le début de l'attaque. Avec des seuils d'alerte configurés sur les métriques kernel (pps, connexions SYN_RECV, bande passante), la détection intervient en quelques secondes, permettant une réponse avant saturation complète du VPS.

Les règles XDP peuvent-elles bloquer une attaque DDoS sans impacter le trafic légitime ?

Oui, en configurant des règles de rate-limit granulaires (max_pps global + max_port_pps par service) et en utilisant des whitelists pour les IP sources connues. Le PAKKT Engine permet jusqu'à 256 règles simultanées avec filtrage par port range, protocole et taille de paquet, autorisant un contrôle fin qui préserve le trafic légitime tout en bloquant les floods malveillants en sub-microseconde.

Quelle différence entre la détection DDoS au niveau kernel et au niveau applicatif ?

La détection kernel-level (XDP, nftables) analyse les paquets avant qu'ils ne traversent la stack TCP/IP complète, consommant très peu de CPU et permettant de drop les floods volumétriques avant saturation système. La détection applicative (WAF, IDS) intervient après traitement réseau, offrant une visibilité sur les attaques L7 (HTTP flood, requêtes SQL malveillantes) mais avec une latence et une charge CPU supérieures. Les deux couches sont complémentaires pour une défense en profondeur.