DDoS record : 31,4 Tbps, le botnet AISURU pulvérise tous les records

Le 11 février 2026, Cloudflare a publié les détails d'une attaque DDoS d'une ampleur sans précédent : 31,4 térabits par seconde. Derrière cette offensive, le botnet AISURU, aussi connu sous le nom de Kimwolf, composé de millions d'appareils compromis. Ce record pulvérise le précédent plafond de 11,5 Tbps enregistré en septembre 2025. Pour les administrateurs système et les responsables d'infrastructure, cette escalade impose une remise à plat complète des stratégies de défense.

Anatomie de l'attaque record

Les chiffres clés

L'attaque s'est produite en novembre 2025 et a été rendue publique début février 2026 dans le rapport trimestriel de Cloudflare sur les menaces DDoS. Voici ce que l'on sait :

• Débit maximal : 31,4 Tbps en bande passante, avec un pic simultané de 200 millions de requêtes par seconde
• Durée : seulement 35 secondes, une attaque éclair conçue pour submerger les défenses avant toute réaction humaine
• Taille du botnet : entre 1 et 4 millions d'hôtes compromis, dont plus de 2 millions d'appareils Android (principalement des téléviseurs Android de marques secondaires)
• Cibles : des clients Cloudflare, mais aussi le tableau de bord et l'infrastructure propre de Cloudflare
• Mitigation : entièrement automatisée par le système de défense autonome de Cloudflare, sans intervention humaine

Pour mettre ce chiffre en perspective, 31,4 Tbps représente environ trois fois le précédent record. C'est l'équivalent du débit nécessaire pour diffuser simultanément plus de 6 millions de flux vidéo en 4K.

La campagne "The Night Before Christmas"

L'attaque record s'inscrit dans une campagne plus large baptisée "The Night Before Christmas", lancée le 19 décembre 2025. Le choix de la période n'est pas anodin : les équipes de checklist sécurité sont en effectif réduit pendant les fêtes, les temps de réaction sont plus longs, et la pression sur les services en ligne (e-commerce, streaming, services cloud) est à son maximum.

Cette stratégie de timing est devenue un classique des groupes d'attaquants sophistiqués. L'année 2025 a d'ailleurs vu une augmentation de 121 % des attaques DDoS par rapport à 2024, avec une moyenne de 5 376 attaques mitigées par heure chez Cloudflare seul.

Le botnet AISURU : une armée d'objets connectés

Composition du botnet

AISURU/Kimwolf exploite massivement les appareils IoT vulnérables. La majorité des nœuds du botnet sont des téléviseurs Android de marques peu connues, souvent vendus à bas prix et rarement mis à jour. Ces appareils cumulent plusieurs faiblesses :

• Firmware jamais mis à jour après la vente
• Services réseau exposés par défaut (ADB, Telnet)
• Mots de passe d'usine conservés
• Absence de mécanisme de mise à jour automatique sécurisé
• Connexion permanente à Internet via des réseaux résidentiels à haut débit

Ce profil est idéal pour un botnet : bande passante conséquente, disponibilité 24h/24, et propriétaires qui ignorent totalement que leur appareil participe à des attaques.

Vérifier votre exposition IoT

Voici comment scanner votre réseau pour détecter des appareils potentiellement compromis :

# Scanner le réseau local pour les services couramment exploités
nmap -sV -p 5555,23,80,8080,8443 192.168.1.0/24

# Vérifier si ADB (Android Debug Bridge) est exposé
nmap -p 5555 --open 192.168.1.0/24

# Lister les connexions sortantes suspectes sur un appareil Linux/Android
ss -tunp | grep -E ':(80|443|8080|53)' | grep -v LISTEN

Si vous détectez un appareil avec ADB ouvert (port 5555) ou Telnet actif (port 23), isolez-le immédiatement du réseau et appliquez une mise à jour firmware si disponible.

Pourquoi 35 secondes suffisent à tout casser

La durée extrêmement courte de l'attaque n'est pas un signe de faiblesse. C'est une évolution tactique. Les attaques DDoS modernes privilégient les rafales ultra-intenses pour plusieurs raisons :

• Saturation instantanée : 31,4 Tbps pendant 35 secondes suffit à faire tomber n'importe quel serveur non protégé par un CDN de grande envergure
• Évasion des systèmes de détection : certains systèmes de mitigation ont besoin de 30 à 60 secondes pour détecter et réagir à une attaque volumétrique
• Coût minimal pour l'attaquant : mobiliser un botnet de millions de nœuds pendant 35 secondes consomme peu de ressources
• Attaques répétées : l'attaquant peut lancer des dizaines de rafales successives, testant les limites de la défense

La leçon est claire : si votre infrastructure dépend d'une intervention humaine pour réagir à une attaque DDoS, vous êtes déjà vulnérable. La mitigation doit être automatisée et instantanée.

Protéger votre infrastructure : stratégies concrètes

Niveau 1 : le pare-feu local avec UFW

Même si un pare-feu local ne peut pas arrêter une attaque de 31 Tbps, il reste la première ligne de défense contre les scans, le brute force et les attaques de petite envergure. Configurez UFW de manière restrictive :

# Politique par défaut : tout bloquer en entrée
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Autoriser uniquement les services nécessaires
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

# Limiter le rate SSH (6 connexions en 30 secondes)
sudo ufw limit 22/tcp

# Activer le pare-feu
sudo ufw enable

# Vérifier les règles actives
sudo ufw status verbose

Pour aller plus loin avec les règles iptables avancées, vous pouvez ajouter des protections anti-SYN flood :

# Protection SYN flood via iptables
sudo iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT
sudo iptables -A INPUT -p tcp --syn -j DROP

# Limiter les connexions simultanées par IP
sudo iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j REJECT
sudo iptables -A INPUT -p tcp --dport 443 -m connlimit --connlimit-above 50 -j REJECT

# Bloquer les paquets invalides
sudo iptables -A INPUT -m state --state INVALID -j DROP

Niveau 2 : Nginx comme bouclier applicatif

Votre serveur Nginx peut absorber une partie des attaques de couche 7 (HTTP flood) avec une configuration adaptée :

# /etc/nginx/conf.d/rate-limiting.conf

# Zone de limitation : 10 requêtes/seconde par IP
limit_req_zone $binary_remote_addr zone=global:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
    listen 443 ssl;
    server_name exemple.fr;

    # Appliquer le rate limiting
    limit_req zone=global burst=20 nodelay;
    limit_conn addr 30;

    # Limiter la taille des requêtes
    client_max_body_size 10m;
    client_body_timeout 10s;
    client_header_timeout 10s;

    # Fermer les connexions lentes
    keepalive_timeout 15s;
    send_timeout 10s;
}

Niveau 3 : Fail2ban pour le blocage dynamique

Fail2ban reste indispensable pour bloquer automatiquement les IP abusives. Cependant, comme je l'explique dans l'article Fail2ban ne suffit pas, il ne constitue qu'une brique parmi d'autres. Voici une configuration anti-DDoS basique :

# /etc/fail2ban/jail.d/nginx-ddos.conf
[nginx-limit-req]
enabled = true
filter = nginx-limit-req
action = iptables-multiport[name=nginx-limit-req, port="80,443", protocol=tcp]
logpath = /var/log/nginx/error.log
findtime = 60
bantime = 3600
maxretry = 10

[nginx-botsearch]
enabled = true
filter = nginx-botsearch
action = iptables-multiport[name=nginx-botsearch, port="80,443", protocol=tcp]
logpath = /var/log/nginx/access.log
findtime = 120
bantime = 86400
maxretry = 5

Niveau 4 : CDN et protection DDoS externe

Face à des attaques de l'ordre du térabit, aucune infrastructure auto-hébergée ne peut résister seule. Cloudflare a mitigé cette attaque de 31,4 Tbps de manière autonome grâce à un réseau distribué sur plus de 300 datacenters. Les options :

• Cloudflare (gratuit à entreprise) : protection DDoS incluse même sur le plan gratuit, mode "Under Attack" activable en un clic
• OVH Anti-DDoS : inclus avec les serveurs dédiés, mitigation automatique jusqu'à plusieurs Tbps
• AWS Shield : protection intégrée pour les services AWS, version Advanced pour les attaques sophistiquées

Vérifier que votre IP réelle est masquée

# Vérifier les enregistrements DNS historiques de votre domaine
# (depuis un poste externe)
dig +short exemple.fr
dig +short www.exemple.fr

# Tester si l'IP répond directement (elle ne devrait pas)
curl -sk --connect-timeout 5 https://VOTRE_IP_SERVEUR

# Vérifier que seules les IP Cloudflare peuvent accéder à Nginx
# /etc/nginx/conf.d/cloudflare-only.conf
# allow 173.245.48.0/20;
# allow 103.21.244.0/22;
# allow 103.22.200.0/22;
# allow 104.16.0.0/13;
# allow 108.162.192.0/18;
# deny all;

Checklist de sécurité anti-DDoS

Consultez la checklist complète de sécurité serveur Linux pour une vue d'ensemble. En complément, voici les points spécifiques DDoS :

#!/bin/bash
# Script d'audit rapide anti-DDoS

echo "=== Audit Anti-DDoS ==="

# 1. Vérifier que le pare-feu est actif
echo "[1] Statut UFW :"
sudo ufw status | head -5

# 2. Vérifier les limites de connexion kernel
echo "[2] Paramètres kernel :"
sysctl net.ipv4.tcp_syncookies
sysctl net.ipv4.tcp_max_syn_backlog
sysctl net.core.somaxconn

# 3. Vérifier Fail2ban
echo "[3] Jails Fail2ban actives :"
sudo fail2ban-client status | grep "Jail list"

# 4. Vérifier le rate limiting Nginx
echo "[4] Rate limiting Nginx :"
grep -r "limit_req_zone" /etc/nginx/ 2>/dev/null

# 5. Connexions actives
echo "[5] Connexions actives par état :"
ss -s

Optimisation des paramètres kernel

Le noyau Linux propose plusieurs paramètres qui renforcent la résistance aux attaques réseau. Ajoutez ces lignes à /etc/sysctl.conf :

# /etc/sysctl.conf - Paramètres anti-DDoS

# Activer les SYN cookies (protection SYN flood)
net.ipv4.tcp_syncookies = 1

# Augmenter le backlog SYN
net.ipv4.tcp_max_syn_backlog = 65535

# Réduire les SYN-ACK retries
net.ipv4.tcp_synack_retries = 2

# Augmenter le nombre max de connexions
net.core.somaxconn = 65535

# Ignorer les broadcasts ICMP (anti-smurf)
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Ignorer les réponses ICMP bogus
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Activer le reverse path filtering
net.ipv4.conf.all.rp_filter = 1

# Désactiver les redirections ICMP
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# Appliquer immédiatement
# sudo sysctl -p

Ce que cette attaque change pour les sysadmins

Le record de 31,4 Tbps marque un tournant. Voici les enseignements à retenir :

1. La mitigation automatisée n'est plus optionnelle. Avec une attaque de 35 secondes, le temps de réaction humain est insuffisant. Vos systèmes de défense doivent être capables de réagir en millisecondes.
2. L'IoT est le maillon faible. Des millions d'appareils connectés vulnérables fournissent une puissance de feu colossale aux attaquants. Chaque appareil non sécurisé sur votre réseau est un soldat potentiel dans l'armée adverse.
3. La défense en profondeur est impérative. Pare-feu local, rate limiting applicatif, Fail2ban, CDN : chaque couche filtre une partie du trafic malveillant. Aucune couche seule ne suffit.
4. Les périodes de fêtes sont des fenêtres d'attaque. Planifiez vos astreintes et vos systèmes d'alerte en conséquence.
5. Le coût d'une attaque DDoS baisse constamment. Avec l'augmentation de 121 % des attaques en 2025, la question n'est plus de savoir si vous serez ciblé, mais quand.

Conclusion

L'attaque DDoS de 31,4 Tbps orchestrée par le botnet AISURU est un signal d'alarme pour l'ensemble de l'industrie. Elle démontre que les botnets IoT ont atteint une maturité et une puissance de feu qui dépassent les capacités de défense de la plupart des infrastructures individuelles. La réponse passe par une combinaison de mesures locales rigoureuses (pare-feu, rate limiting, durcissement kernel) et de services de mitigation externes capables d'absorber des volumes de trafic de plusieurs dizaines de térabits.

Commencez par auditer votre infrastructure avec le script proposé dans cet article, appliquez les configurations recommandées, et assurez-vous que vos appareils IoT ne participent pas, à votre insu, à la prochaine attaque record.