Examinons ce qui se passe à l’intérieur du CG-NAT sous charge de botnet, pourquoi les abonnés ordinaires en souffrent et quels outils permettent d’y mettre fin.
Comment un botnet « dévore » les ressources du CG-NAT
La plupart des opérateurs utilise la technologie CG-NAT (Carrier-Grade NAT). Il s’agit d’une technologie par laquelle l’opérateur de télécommunications utilise une seule adresse IPv4 publique pour un groupe d’abonnés simultanément. Les abonnés reçoivent des adresses IP privées et, lors de l’accès à internet, leur trafic passe par une passerelle partagée où il est traduit vers l’une des adresses publiques de l’opérateur.
Cela résout le problème de pénurie d’espace d’adressage, mais crée simultanément une dépendance : la ressource NAT est finie.
Les opérateurs distribuent généralement les ports NAT avec sursouscription. Un seul abonné peut se voir attribuer jusqu’à 2 000 ports, tandis que des dizaines d’utilisateurs partagent simultanément la même IP publique. En théorie, cela offre des centaines de milliers de connexions, mais la limite physique reste inchangée : environ 64 000 ports par adresse IP.
Lorsque plusieurs abonnés avec des appareils infectés partageant la même adresse publique commencent à générer des milliers de sessions UDP courtes, ils épuisent instantanément l’intégralité du pool de ports alloué.
En conséquence, les abonnés légitimes utilisant cette même adresse sont contraints de rivaliser avec les appareils du botnet pour l’obtention de ports et cessent de recevoir de nouvelles connexions : les navigateurs se bloquent, les appels sont coupés, le streaming s’interrompt. Pendant ce temps, l’utilisateur infecté ignore souvent que son appareil participe à une attaque.
Ce qui arrive au NAT sous charge de botnet
Au-delà de l’épuisement des ports, les attaques de botnet impactent directement les performances du CG-NAT. Le flood de botnet devient un test de charge pour des chemins de recherche linéaire peu évidents dans le code du NAT. Un abonné ordinaire maintient en moyenne quelques dizaines à quelques centaines de connexions simultanées. Un appareil infecté, en revanche, en crée des milliers par seconde, avec des schémas de trafic fondamentalement différents du comportement d’un utilisateur normal.
Ce trafic produit ainsi les effets suivants :
- il remplit rapidement les tables de traduction ;
- il surcharge les files d’attente ;
- il crée une contention de ressources entre les threads.
S’il existe ne serait-ce qu’un seul chemin de code non optimisé, un botnet en fera très probablement un goulot d’étranglement. Le résultat final est une dégradation non seulement de la disponibilité, mais des performances de l’ensemble du système NAT. C’est pourquoi, lors de l’optimisation du produit CG-NAT, les développeurs de VAS Experts tiennent compte non seulement du comportement du trafic normal, mais aussi des scénarios d’attaque susceptibles d’affecter la stabilité globale du système.
La principale source de botnets : les appareils des abonnés
Le vecteur d’infection principal est constitué des routeurs domestiques et SOHO n’ayant pas reçu de mises à jour de sécurité depuis longtemps. En avril 2026, la NSA américaine a officiellement appelé les utilisateurs à mettre à jour le firmware de leurs routeurs, ayant constaté une vague d’attaques via des appareils obsolètes.
Avertissement NSA / FBI (avril 2026)
L’Agence de sécurité nationale américaine a appuyé un avertissement du FBI selon lequel des groupes de hackers étrangers ciblent délibérément les routeurs vulnérables dans le monde entier, notamment via la vulnérabilité CVE-2023-50224 dans les appareils TP-Link. Les attaquants exploitent des routeurs domestiques insuffisamment sécurisés pour intercepter des données et constituer une infrastructure de botnet.
Les recommandations des régulateurs se résument à une hygiène de base : changer les identifiants et mots de passe par défaut, désactiver la gestion à distance depuis internet, installer le firmware le plus récent et remplacer les appareils qui ne bénéficient plus du support du fabricant. Dans la pratique, cependant, la plupart des utilisateurs domestiques ne réalisent pas ces opérations de manière autonome.
Cela signifie que l’opérateur doit protéger non seulement sa propre infrastructure, mais aussi les appareils des abonnés — sinon, le préjudice causé par le botnet se répartit sur l’ensemble des clients.
Listes noires d’IP : un problème pour toute la base d’abonnés
Le deuxième effet critique d’un botnet est l’inscription des adresses IP de l’opérateur dans des listes de blocage. Lorsque les hôtes infectés commencent à envoyer du spam, à participer à des attaques DDoS ou à scanner internet, les IP publiques de l’opérateur sont enregistrées dans des listes noires de services tels que Spamhaus, AbuseIPDB, Cloudflare Radar et d’autres.
L’impact d’une infection de botnet s’étend à tous. Bloquer une seule IP publique dans une liste de blocage affecte instantanément jusqu’à 100 abonnés « propres » qui se trouvent derrière cette même adresse NAT. Ils commencent à essuyer des refus lorsqu’ils tentent d’envoyer des e-mails, de s’inscrire sur des sites, d’utiliser des services CDN ou d’accéder à des espaces de stockage en ligne. Les plaintes arrivent au support technique, tandis que la source du problème se situe chez un abonné voisin.
En conséquence, le problème dépasse le cadre d’un incident isolé. L’opérateur est confronté non seulement à un risque technique, mais aussi à des pertes de réputation. Les utilisateurs perçoivent les restrictions comme une panne de service et non comme les conséquences d’une infection dans le réseau.
Le diagnostic se complique également. Dans un environnement CG-NAT, relier une activité malveillante à un abonné précis est plus difficile, et le processus de nettoyage de la réputation IP prend du temps et nécessite une coordination avec des services externes.
Pour l’opérateur, il ne s’agit plus d’un problème de sécurité local, mais d’un facteur affectant directement la qualité du service et la fidélisation des abonnés.
Comment cela fonctionne en pratique : détection et mitigation du UDP flood
Voici un exemple pratique de détection d’activité de botnet et de sa neutralisation chez l’un des opérateurs clients de VAS Experts.
Étape 1. Détection de l’attaque via QoE Analytics
Dans le module QoE Analytics, dans la section QoE Analytics → DDoS Attacks → Top Attacks, les statistiques des dernières 24 heures ont été exportées. Le tri a été configuré par la colonne Sessions par ordre décroissant afin d’identifier immédiatement les directions générant le plus de sessions.
En situation normale, le haut de la liste est assez uniforme : les valeurs peuvent différer, mais sans pics marqués. Dans ce cas, cependant, le sommet de la liste révélait une activité anormale sur une adresse interne — 10.248.90.181 — avec un nombre de sessions radicalement supérieur à la norme.
Étape 2. Analyse du trafic et signature de l’attaque
La navigation vers QoE Analytics → DDoS Attacks Log a permis d’examiner précisément ce qui composait cette charge. La période a été maintenue à Last 24 Hours, un filtre a été ajouté pour Target IP address = 10.248.90.181, et le tri par Sessions a de nouveau été appliqué.
Le filtrage du journal par l’adresse IP cible 10.248.90.181 a révélé un tableau caractéristique :
| Protocole ~99 % du trafic — UDP (Net protocol: 17) |
Sessions par enregistrement ~12 000–13 000 par entrée de journal |
Paquets par flux Médiane 2–4 paquets (flux très courts) |
| Port de destination Presque tout le trafic visant le port 41880 |
Ports de l’attaquant Grande dispersion — typique d’un botnet |
Conclusion UDP Flood — attaque DDoS volumétrique depuis un botnet |
La quasi-totalité du trafic s’est révélée être de l’UDP (Net protocol: 17). Le TCP était pratiquement absent, ce qui permet d’écarter d’emblée l’hypothèse d’une activité utilisateur ordinaire — navigation web, streaming, messagerie.
En examinant la structure des enregistrements : le journal contenait de nombreuses lignes, chacune décrivant un flux court avec un très grand nombre de sessions — environ 12 000–13 000 sessions par entrée, mais seulement 2 à 4 paquets par flux.
Un grand nombre d’enregistrements (des dizaines de milliers) avec un faible nombre de paquets par flux et un nombre de sessions considérable est la signature classique d’un botnet générant des sessions UDP courtes.
En analysant la destination du trafic : le rapport affichait un grand nombre de ports dans la colonne Event Object, tandis que presque toutes les entrées pointaient vers le même port de destination — 41880. La charge n’était donc pas aléatoire, mais dirigée vers un point précis. La dispersion des ports côté source exclut une origine unique et confirme la participation coordonnée de nombreux appareils infectés.
Un tableau classique d’UDP Flood, distribué sur de nombreuses sources.
Étape 3. Mitigation automatisée
Le processus de neutralisation est déclenché automatiquement selon la chaîne suivante :
- Détecteur QoE. Détection d’anomalie par nombre de sessions.
- Liste des IP attaquantes. Formation du conteneur Attacks.
- Interface graphique / script. Attribution du profil UDP UNKNOWN DROP.
- Déploiement sur le DPI. Application du blocage sur les nœuds du réseau.
- Levée du blocage. Une fois par jour en l’absence d’attaques.
L’ensemble du cycle — de l’insertion du dump à l’application du profil sur le DPI — prend quelques minutes. Lors de la détection d’une attaque, le profil UDP UNKNOWN – DROP est appliqué sur le DPI pour les abonnés figurant dans le conteneur. Tout le trafic UDP classifié comme UNKNOWN est bloqué.
Le conteneur est réexaminé une fois par jour. Si aucune activité répétée n’a été constatée pendant ce délai, l’IP est automatiquement exclue et le blocage est levé automatiquement.
Pour la surveillance en temps réel, des notifications vers un canal Telegram sont configurées à chaque modification du conteneur d’attaques :
- IP ajoutée → instantanément lors de la détection.
- IP supprimée → une fois par jour à minuit.
Un ingénieur peut vérifier à tout moment l’état actuel des conteneurs et des blocages dans le CLI.
Stingray AntiDDoS — protection du réseau de l’opérateur contre les DDoS et les botnets
La plateforme Stingray AntiDDoS détecte et bloque les attaques en temps réel. Le module QoE Analytics collecte des données IPFIX Fullflow depuis le StingrayDPI, construit un profil de référence du trafic normal et, grâce à des algorithmes de réseaux de neurones, identifie les anomalies — notamment les activités de botnet, les UDP Flood et les SYN Flood.
Lors de la détection d’une attaque, le système automatiquement :
- constitue une liste des IP attaquantes,
- applique un profil de blocage sur le DPI,
- supprime les restrictions après normalisation du trafic.
Pourquoi l’opérateur est tenu de lutter contre les botnets dans son réseau
Premièrement, le trafic de botnet épuise directement la ressource NAT. Un seul abonné infecté peut occuper les ports prévus pour des dizaines d’autres utilisateurs. Deuxièmement, les adresses IP publiques de l’opérateur se retrouvent sur des listes de blocage internationales, et les restrictions commencent à affecter tous les clients derrière cette adresse, pas seulement la source du problème. Troisièmement, les appareils dotés de firmware obsolète sont réinfectés si aucune mesure centralisée n’est prise.
Dans ces conditions, l’automatisation devient obligatoire. La réponse manuelle prend des heures et ne passe pas à l’échelle. Les scénarios automatisés basés sur le QoE et le DPI permettent de détecter les anomalies et de restreindre l’activité malveillante en quelques minutes, sans nécessiter l’intervention des ingénieurs à chaque incident.
