Le développement des services cloud et des solutions IoT sans attention suffisante à la sécurité de l’information conduit à des infections par des botnets tels que Mirai. Selon les données de Cloudflare, début septembre 2025, plusieurs fournisseurs de services IoT et de services cloud, dont Google Cloud, ont été sources d’une attaque UDP Flood d’une puissance de 11,5 Tbps d’une durée de 35 secondes. C’est comparable à la diffusion en continu de 10 000 heures de vidéo haute qualité en à peine une demi-minute. De telles attaques démontrent clairement les capacités des attaquants : les attaques DDoS de plusieurs centaines de Gbps peuvent désormais être menées avec un effort minimal, provoquant des interruptions d’activité de plusieurs heures, voire plusieurs jours.
Quelle est la puissance de ces attaques et comment les contrer ? Nous l’expliquons dans cet article et suggérons les mesures à prendre pour en atténuer les conséquences.
Comment fonctionne l’UDP Flood
L’UDP Flood est un type d’attaque DDoS volumétrique au niveau de la couche transport (L4) du réseau, dans laquelle l’attaquant envoie un grand nombre de paquets UDP vers des ports aléatoires ou prédéfinis de l’hôte cible.
À l’origine, le protocole UDP (User Datagram Protocol) a été conçu comme un transport minimaliste sur IP pour les applications ne nécessitant pas de mécanismes de livraison fiable : accusé de réception, retransmissions ou contrôle de l’ordre des paquets. C’est précisément pourquoi un attaquant peut continuellement « inonder » la cible dans un seul sens sans attendre aucune réponse. Ces propriétés ont ensuite fait d’UDP une base pratique pour la VoIP, le streaming vidéo et les jeux en ligne, où la perte de paquets individuels n’est pas critique.
Une autre caractéristique du protocole UDP est que l’hôte de destination répond par un message ICMP « service indisponible » si le port est fermé et qu’ICMP n’est pas restreint par des politiques de sécurité. Ce processus charge le serveur attaqué avec le traitement de la requête, la vérification de l’existence d’un service sur le port indiqué et la formulation d’une réponse. Le message de réponse chargerait également la source de l’attaque elle-même, mais les attaquants ont commencé à utiliser la technique d’IP Spoofing, remplaçant l’adresse IP de l’expéditeur dans le paquet par une adresse aléatoire. Ainsi, avec des ressources minimales, l’attaquant parvient à saturer à la fois le canal de communication descendant et montant.
Nous avons précédemment examiné en détail le SYN Flood — une attaque TCP classique visant à épuiser les tables de connexions et les ressources de la pile TCP.
Comparons UDP Flood et TCP SYN Flood.
| Critère | UDP Flood | TCP SYN Flood |
| Coût computationnel de l’attaquant | Faible | Élevé |
| Évolutivité | Élevée | Limitée par le maintien des connexions semi-ouvertes |
| Facilité d’usurpation d’adresse IP | Élevée | Moyenne |
| Épuisement des ressources | Bande passante / limites matérielles (tables TCAM, session tables, CPU du plan de contrôle) / CPU de l’hôte de destination | Nombre d’utilisateurs du service / CPU de l’hôte de destination |
| Impact sur l’opérateur | Élevé | Faible |
| Méthode de détection | Anomalies du profil de trafic (PPS/BPS, asymétrie de flux, augmentation multiple des sources) | Ratio de paquets SYN par rapport au total (SYN ratio) |
| Méthode de protection au niveau de l’hôte attaqué | Limitation du flux UDP (Rate-limiting), mécanismes de protection des services (DNS RRL, SIP rate control, QUIC Retry Token) | SYN Cookies |
Types d’UDP Flood
Savoir qu’une attaque opère au niveau de la couche transport via UDP n’est que la première étape. Pour une protection efficace, il est important d’identifier son type spécifique : le mécanisme, la source du trafic et les protocoles applicatifs impliqués. Sans cela, les contre-mesures peuvent s’avérer soit excessives, soit inefficaces. Examinons les principales variantes d’UDP Flood auxquelles les opérateurs sont le plus fréquemment confrontés.
UDP Flood via Botnet (non-spoofed)
C’est aujourd’hui le scénario le plus courant. Le nombre croissant de dispositifs IoT vulnérables, de serveurs obsolètes et de routeurs domestiques crée une base massive pour les botnets. Le trafic provient des IPs réelles des appareils infectés, de sorte que les paquets semblent légitimes et sont difficilement filtrés.
Les risques vont au-delà de la partie attaquée : un opérateur dont le réseau contient des abonnés infectés peut être confronté à un débordement des tables CG-NAT en raison du trafic sortant massif. En conséquence, les utilisateurs ordinaires sont affectés et l’opérateur devient de facto un participant involontaire à l’attaque.
UDP Flood Classique (spoofed)
Une méthode ancienne mais toujours d’actualité : un flux de paquets UDP est généré avec des adresses d’expéditeur falsifiées, souvent à l’aide d’utilitaires facilement disponibles. Le faible seuil d’entrée le rend populaire auprès des attaquants débutants.
Sa prévalence diminue progressivement grâce à la mise en œuvre du filtrage BCP38 et à l’émergence de méthodes d’amplification plus efficaces. Néanmoins, avec un filtrage insuffisant, ce type d’attaque peut encore saturer les canaux.
Ces deux types peuvent attaquer un seul port ou de nombreux ports aléatoires. Dans le second cas, l’hôte cible est en outre chargé du traitement des réponses ICMP.
UDP Flood par Réflexion (reflection/amplification)
Un sous-type particulièrement dangereux qui utilise des services réflecteurs ouverts. L’attaquant envoie une petite requête avec l’adresse usurpée de la victime, et le serveur renvoie une réponse nettement plus volumineuse à la victime. Le facteur d’amplification peut atteindre des dizaines, des centaines, voire des milliers de fois, permettant de générer un trafic énorme avec des ressources minimales de l’attaquant.
Attaques par Tapis de Bombes et Multivectorielles
N’importe lequel de ces types peut être dirigé non pas vers un seul hôte mais vers un sous-réseau entier — le carpet bombing, où le trafic est réparti sur de nombreuses adresses et est plus difficile à détecter. En pratique, les attaquants combinent souvent plusieurs méthodes simultanément, formant des attaques multivectorielles nécessitant une protection globale.
Comment détecter un UDP Flood
La première étape pour construire une protection est d’apprendre à identifier en temps opportun quel type d’attaque a touché l’infrastructure.
Le premier signe, et le plus évident, est une augmentation soudaine et anormale du trafic entrant. Contrairement à la croissance organique de la charge caractéristique des heures de pointe, une attaque apparaît comme un pic vertical sur le graphique : le trafic augmente en quelques secondes de plusieurs fois ou de plusieurs ordres de grandeur. Dans le même temps, la charge CPU du routeur frontalier ou du pare-feu augmente rapidement, car l’équipement est contraint de traiter chaque paquet entrant.
Simultanément, on constate une dégradation de la qualité de service : la latence augmente, le taux de perte de paquets croît pour les utilisateurs légitimes, les services commencent à répondre avec retard ou cessent de répondre. En cas d’attaque sur le CG-NAT, l’opérateur reçoit des plaintes d’abonnés sur l’impossibilité d’établir de nouvelles connexions — signe certain de l’épuisement des tables de traduction.
Lors de l’analyse du trafic, on observe un tableau caractéristique : une forte proportion de paquets UDP de taille minimale ou fixe, des ports de destination pseudo-aléatoires ou clairement répétitifs, un nombre anormalement élevé d’adresses IP uniques d’expéditeurs (lors d’attaques spoofed) ou, au contraire, du trafic provenant de certains ASN ou régions géographiques (lors d’attaques botnet). Lors d’attaques par réflexion, le trafic provient des adresses de serveurs DNS ou NTP publics connus, ce qui constitue en soi une anomalie. La liste des serveurs vulnérables est souvent distribuée via des plateformes de Threat Intelligence, fournissant une liste prête pour le blocage ou la limitation de débit.
Pour la détection rapide des attaques, les opérateurs utilisent généralement plusieurs sources de surveillance.
- NetFlow/sFlow/IPFIX — la télémétrie des routeurs reste la principale source de données pour l’analyse du trafic au niveau de l’opérateur. Les collecteurs permettent de construire des profils de trafic en temps réel et de détecter les anomalies par protocole, port, volume et géographie. Les alertes de seuil pour la forte croissance du trafic UDP sont configurées sur la base des métriques de charge normale.
- Surveillance SNMP des interfaces des routeurs via Zabbix, Prometheus avec exportateur SNMP ou Grafana permet d’enregistrer la saturation des canaux et la croissance anormale des compteurs d’erreurs et de paquets rejetés.
- DPI (Deep Packet Inspection) permet l’analyse au niveau du contenu des paquets, identifiant les signatures caractéristiques des attaques connues, y compris le trafic de réflexion de types spécifiques de réflecteurs. Les solutions basées sur DPI, comme Stingray de VAS Experts, permettent non seulement de détecter une attaque, mais aussi d’appliquer immédiatement des politiques de filtrage granulaires sans bloquer le trafic légitime.
- Systèmes de détection d’anomalies (NBAD) — solutions AntiDDoS spécialisées qui analysent le comportement du trafic par rapport à une ligne de base et déclenchent automatiquement les procédures de mitigation lorsqu’une attaque est détectée. Le temps de réaction de ces systèmes se mesure en secondes, ce qui est critique lors d’attaques de haute intensité. Stingray AntiDDoS est un exemple phare de système de cette classe : en analysant les données QoE à l’aide de réseaux de neurones et d’algorithmes de machine learning, le détecteur identifie les écarts par rapport à la norme, classe les menaces et détermine leurs sources.
Méthodes de protection
La protection contre l’UDP Flood n’est pas universelle : un serveur DNS, une plateforme SIP et les services web sont attaqués différemment et nécessitent des contre-mesures distinctes. Voici des recommandations pratiques pour chaque type d’infrastructure avec des commandes et configurations spécifiques.
Protection des serveurs DNS
Le DNS est une double cible : le serveur est attaqué directement et également utilisé comme réflecteur pour attaquer d’autres cibles. Un resolver autoritaire avec résolution récursive ouverte et sans rate limiting est un amplificateur idéal pour l’attaquant.
Fermer la récursion pour les clients externes
Un serveur DNS autoritaire ne doit pas répondre aux requêtes récursives provenant d’IPs externes. Dans BIND :
options { recursion yes; allow-recursion { 192.168.0.0/16; 10.0.0.0/8; }; allow-query-cache { 192.168.0.0/16; 10.0.0.0/8; }; };
Dans Unbound — refuser les requêtes de tous sauf des sous-réseaux de confiance via access-control.
access-control: 192.168.0.0/16 allow access-control: 10.0.0.0/8 allow access-control: 0.0.0.0/0 refuse
Response Rate Limiting (RRL)
Limite le nombre de réponses envoyées à une même adresse IP par unité de temps. Réduit l’efficacité du DNS Amplification et protège contre les inondations directes de requêtes. Exemple pour BIND 9.18+ :
rate-limit { responses-per-second 15; window 15; slip 2; };
Minimisation des réponses ANY
Les requêtes ANY produisent le facteur d’amplification maximal. Les versions modernes de BIND et Unbound retournent minimal-any par défaut, mais il est préférable de le spécifier explicitement.
minimal-responses yes; // BIND minimal-any yes; // BIND 9.11+
Protection de l’infrastructure VoIP / SIP
SIP fonctionne sur UDP (port 5060) et est particulièrement vulnérable aux inondations : chaque paquet entrant nécessite une analyse au niveau applicatif, ce qui épuise rapidement les ressources du SBC (Session Border Controller) et d’Asterisk/FreeSWITCH. De plus, l’infrastructure SIP est souvent la cible d’attaques combinées — l’inondation se conjugue avec le spam d’enregistrement et le Toll Fraud.
Rate limiting orienté SIP sur le SBC
Le Session Border Controller doit limiter le nombre de messages SIP (INVITE, REGISTER, OPTIONS) provenant d’une même IP. Exemple de configuration dans Kamailio :
modparam("pike", "sampling_time_unit", 2)
modparam("pike", "reqs_density_per_unit", 16)
modparam("pike", "remove_latency", 4)
Le module pike bloque une source lorsqu’elle dépasse 16 requêtes en 2 secondes. Pour le trafic d’entreprise, le seuil doit être calibré selon la charge réelle.
Restrictions au niveau du sous-système noyau Linux
Le filtrage au niveau du système d’exploitation avant que les paquets n’atteignent la pile SIP réduit considérablement la charge. Avec iptables :
iptables -A INPUT -p udp --dport 5060 -m hashlimit \ --hashlimit 50/sec --hashlimit-burst 100 \ --hashlimit-mode srcip --hashlimit-name SIP \ -j ACCEPT iptables -A INPUT -p udp --dport 5060 -j DROP
Avec nftables :
table inet filter {
chain input {
type filter hook input priority 0;
ip protocol udp udp dport 5060 \
limit rate over 50/second burst 100 \
per ip saddr accept
ip protocol udp udp dport 5060 drop
}
}
La valeur de 50/sec ou 50/second est ajustée à la charge réelle — la valeur actuelle convient à un petit SBC d’entreprise. La limite doit être appliquée par IP, sinon du trafic burst légitime risque d’être rejeté ou la négociation RTP perturbée.
Masquer l’infrastructure SIP derrière le SBC
Les serveurs médias (Asterisk, FreeSWITCH) ne doivent pas avoir d’IPs publiques. Le SBC reçoit tout le trafic SIP/RTP externe, le termine et le transmet au réseau interne. Cela élimine les attaques directes contre les serveurs applicatifs.
Bande passante dédiée pour le trafic RTP
Les flux médias (RTP/UDP) doivent être assignés à une plage de ports séparée et limités en bande passante au niveau QoS. Lors d’une attaque, l’inondation sur le port 5060 ne doit pas concurrencer les sessions vocales actives.
Important : le SIP OPTIONS flood est une attaque populaire qui imite des requêtes keepalive légitimes. Assurez-vous que votre SBC distingue les OPTIONS provenant de pairs de confiance et de sources aléatoires, et limite strictement ces dernières.
Protection des services web et des API
HTTP fonctionne sur TCP, mais l’UDP Flood affecte l’infrastructure web de manière indirecte : en saturant le canal et en surchargeant l’équipement frontalier, l’attaque rend tous les services inaccessibles, y compris les services web. Une menace distincte est QUIC (HTTP/3), qui fonctionne sur UDP/443 : les attaquants utilisent de plus en plus des réflecteurs QUIC ou attaquent directement les endpoints QUIC.
Restriction d’UDP/443 (QUIC) lors d’une attaque
Si le serveur web n’utilise pas HTTP/3, le port UDP/443 doit être fermé complètement. Si QUIC est nécessaire, implémentez un rate limiting similaire à celui du SIP.
ip protocol udp udp dport 443 \ limit rate over 500/second burst 1000 \ per ip saddr accept ip protocol udp udp dport 443 drop
Utilisation de la migration de connexion QUIC avec précaution
La migration de connexion dans QUIC permet de changer d’IP sans interrompre la connexion — utile pour les clients mobiles, mais peut être utilisée pour l’amplification. Contrôlez les paramètres preferred_address et migration dans la configuration du serveur.
Configuration de nginx pour la protection contre les attaques QUIC
En plus des filtres réseau, les paramètres nginx peuvent être optimisés pour réduire la charge lors d’attaques UDP indirectes.
quic_retry on; quic_max_idle_timeout 30s; quic_max_packet_size 1350;
Assurez-vous que votre version de nginx prend en charge QUIC et les directives correspondantes. Ces paramètres ne remplacent pas la protection au niveau réseau, mais contribuent à réduire la charge sur le serveur web.
Mesures de protection universelles pour l’opérateur
uRPF (BCP38)
Filtre les paquets avec des adresses usurpées directement sur le routeur — avant d’entrer dans le réseau de l’opérateur. Le mode strict est le plus efficace mais nécessite un routage symétrique ; le mode loose convient au multihoming. Exemple pour Cisco IOS sur une interface frontalière :
ip verify unicast source reachable-via rx ! strict mode ip verify unicast source reachable-via any ! loose mode
BGP Flowspec
Permet de distribuer des règles de filtrage sur l’ensemble du réseau via des annonces BGP — en bloquant le trafic d’attaque au plus près de la source sans surcharger les nœuds centraux. Exemple de règle pour bloquer l’UDP Flood sur un préfixe spécifique :
match destination 203.0.113.0/24 protocol udp dst-port 53 then discard
Pour appliquer Flowspec, l’équipement réseau doit prendre en charge cette fonctionnalité au niveau du plan de données.
RTBH (Remotely Triggered Black Hole)
Mesure d’urgence lors d’attaques de gamme térabit : annonce du préfixe attaqué à la communauté blackhole du fournisseur amont. Le trafic est rejeté au point d’interconnexion — avant d’atteindre votre canal. La victime est temporairement inaccessible, mais l’infrastructure de l’opérateur est protégée.
ip route 203.0.113.1/32 Null0 router bgp 65000 network 203.0.113.1/32 route-map BLACKHOLE
Centre de nettoyage (Scrubbing Center)
Avec un centre de nettoyage de trafic propre ou loué, le préfixe attaqué est redirigé à travers lui via BGP. Le scrubbing center filtre le trafic anormal et renvoie le flux propre à l’opérateur via un tunnel GRE ou MPLS.
Protection par VAS Experts
Le système Stingray AntiDDoS offre une protection complète contre l’UDP Flood au niveau opérateur, combinant DPI, analyse comportementale et mitigation automatique en une seule solution.
| Capacité | Description |
| DPI à vitesse de ligne | Analyse du trafic jusqu’à 5 Tbps sans dégradation des performances |
| Détection du débit de paquets (niveau Mpps) | Détection instantanée de la croissance anormale du PPS et protection contre les attaques par débit de paquets qui chargent le CPU et le plan de contrôle des équipements |
| Filtrage granulaire | Par protocole, port, taille de paquet, géographie — sans bloquer le trafic légitime |
| Protection CG-NAT | Contrôle des inondations sortantes, prévention de l’épuisement des tables de traduction |
| Intégration BGP | Déclenchement automatique de RTBH et Flowspec lors de la détection d’une attaque |
| Détection du carpet bombing | Analyse agrégée au niveau AS — détecte les attaques distribuées sur les sous-réseaux |
| Filtrage inline dans le plan de données | Mitigation directement sur le nœud de l’opérateur sans rediriger le trafic vers un scrubbing center externe — cycle de protection complet au sein d’une seule plateforme |
Études de cas
L’analyse d’incidents publics permet non seulement d’évaluer l’ampleur des menaces modernes, mais aussi d’en tirer des leçons pratiques pour sa propre infrastructure.
Cas 1 — GitHub, février 2018
| Puissance de l’attaque | 1,35 Tbps (record à l’époque) / 126,9 Mpps |
| Durée | ~10 minutes |
| Vecteur | Memcached UDP Amplification (port 11211), ~50 000 réflecteurs |
| Facteur d’amplification | Jusqu’à 51 000x (1 octet de requête → 51 Ko de réponse) |
| Conséquences | GitHub était inaccessible pendant plusieurs minutes avant le basculement vers Akamai Prolexic |
| Leçon clé | Memcached ne doit pas être accessible depuis Internet. UDP/11211 doit être fermé globalement |
| Comment c’a été atténué | La redirection du trafic via le scrubbing center d’Akamai a absorbé l’attaque en ~8 minutes |
Cas 2 — Client NDA de Microsoft Azure, novembre 2021
| Puissance de l’attaque | 3,47 Tbps / 340 millions de paquets par seconde |
| Durée | ~15 minutes |
| Vecteur | UDP Reflection sur le port 80 avec utilisation simultanée de quatre protocoles amplificateurs : SSDP, CLDAP, DNS et NTP. |
| Distribution | L’attaque provenait d’environ 10 000 sources dans 10 pays : États-Unis, Chine, Corée du Sud, Russie, Thaïlande, Inde, Vietnam, Iran, Indonésie et Taïwan |
| Cible | Client entreprise de Microsoft Azure en Asie (non divulgué publiquement) |
| Conséquences | Aucune ; la mitigation automatique a été réalisée sans intervention de l’opérateur |
| Leçon clé | L’amplification multivectorielle est la nouvelle norme ; la protection doit être automatisée |
| Comment c’a été atténué | Azure DDoS Protection ; puis protection inline via NVA avec Gateway Load Balancer |
Cas 3 — Client NDA de Cloudflare, septembre 2024
| Puissance de l’attaque | 3,8 Tbps / 2,14 milliards de paquets par seconde |
| Durée | ~65 secondes |
| Vecteur | UDP Flood via botnet (routeurs ASUS, DVR, serveurs VPN) |
| Cible | Client Cloudflare du secteur financier |
| Conséquences | Aucune ; la mitigation automatique a été réalisée sans intervention de l’opérateur |
| Leçon clé | Les attaques de gamme térabit sont devenues monnaie courante ; la réponse manuelle est impossible |
| Comment c’a été atténué | Systèmes automatiques : Anycast + analyse comportementale + Flowspec instantané |
Cas 4 — DDoS Scrubbing en Europe de l’Ouest, septembre 2025
| Puissance de l’attaque | 1,5 milliard de paquets/s — l’un des plus importants par débit de paquets dans l’histoire publique |
| Durée | ~65 secondes |
| Vecteur | UDP Flood via botnet de dispositifs CPE/IoT ; plus de 11 000 réseaux uniques dans le monde |
| Cible | Site web du fournisseur européen de DDoS scrubbing FastNetMon — tentative de neutraliser le système de protection lui-même |
| Problème | Le trafic vers une IP individuelle était en dessous des seuils d’alerte, mais le backbone était saturé |
| Conséquences | Nulles pour les utilisateurs ; l’incident a été divulgué publiquement par FastNetMon |
| Leçon clé | La haute fréquence de petits paquets UDP charge davantage le CPU des équipements réseau que les attaques volumétriques |
| Comment c’a été atténué | FastNetMon Advanced a détecté le pic en quelques secondes et a automatiquement redirigé et rejeté le trafic malveillant avant la saturation du canal |
Conclusion
L’UDP Flood n’est pas le seul, mais l’un des types d’attaques DDoS les plus destructeurs. La nature sans connexion du protocole UDP en fait un vecteur d’attaque idéal : il n’est pas nécessaire d’établir une connexion, il n’y a pas de protection intégrée contre le spoofing, et les mécanismes d’amplification peuvent transformer les ressources modestes d’un attaquant en térabits de trafic indésirable.
Les attaques modernes sont devenues automatisées, multivectorielles et de courte durée — ce qui exclut toute réponse manuelle et nécessite des systèmes automatiques de détection et de mitigation. Les attaques de carpet bombing contournent en outre la surveillance classique par seuils. Dans ces conditions, ceux qui ont mis en place une défense en profondeur l’emportent, et non ceux qui disposent d’un ensemble d’outils disparates.
Aide-mémoire rapide : ce qu’il faut faire
- Implémenter uRPF (BCP38) sur toutes les interfaces frontalières — c’est le fondement ;
- Configurer la télémétrie NetFlow/sFlow avec une analyse au niveau AS, et pas seulement des hôtes individuels ;
- Fermer les resolvers DNS récursifs ouverts et appliquer RRL sur les serveurs autoritaires ;
- Placer l’infrastructure SIP derrière un SBC avec rate limiting au niveau applicatif ;
- Restreindre ou fermer UDP/443 (QUIC) là où HTTP/3 n’est pas utilisé ;
- Disposer de procédures prêtes pour RTBH et BGP Flowspec — ne pas les configurer sous la pression d’une attaque ;
- Envisager l’implémentation d’une plateforme DPI pour la visibilité du trafic au niveau paquet.
