Détection réseau par IA — du pipeline au dimensionnement selon le débit

La détection d’intrusion réseau par intelligence artificielle est souvent présentée comme une boîte magique : « on branche l’IA sur le réseau et elle trouve les attaques ». La réalité est plus terre à terre — et bien plus intéressante pour qui doit la mettre en œuvre. Derrière le buzzword, il y a un pipeline parfaitement classique, et un maillon qui décide de tout : le prétraitement. C’est aussi lui dont le coût matériel explose dès qu’on monte en débit. Cet article, premier d’une série, pose le pipeline puis dimensionne concrètement la chaîne de 1 à 100 Gbps.

Le pipeline, toujours le même squelette

Quelle que soit la technologie — signatures, détection d’anomalie, machine learning, deep learning — on retrouve les mêmes quatre étapes :

1. Capture — une sonde reçoit une copie du trafic (TAP physique ou port miroir SPAN).
2. Prétraitement — on transforme les paquets bruts en vecteurs de features : un outil comme Zeek réassemble les connexions en flux, puis on agrège dans le temps des caractéristiques (débits, durées, tailles, intervalles entre paquets) qu’on normalise.
3. Modèle — le modèle (du simple jeu de règles au réseau de neurones) évalue ces vecteurs et produit un score d’anomalie ou une classification.
4. Alerte & SOC — au-delà d’un seuil, l’alerte part vers le SIEM, puis vers l’analyste.

L’IA, dans tout ça, vit à l’étape 3. Mais c’est l’étape 2 qui fait ou défait le système.

Le prétraitement : le vrai nœud

Sur le schéma, le prétraitement est une boîte anodine. Dans la vraie vie, c’est le cœur et le goulot d’étranglement de toute la chaîne. Pourquoi ?

• Assemblage de flux stateful : suivre les connexions, les réassembler, fenêtrer dans le temps pour calculer durée, octets, paquets, inter-arrivées — c’est coûteux en mémoire et en CPU, et ça explose sous fort débit ou pendant un DDoS. Le faire à la vitesse du lien est le vrai défi.
• Cohérence entraînement / production (train-serve skew) : les features calculées en direct doivent être exactement celles vues à l’entraînement — même définition, même normalisation. C’est l’écueil n°1, et silencieux, des systèmes de détection par ML.
• Trafic chiffré : sur du TLS, pas de payload → les features se limitent aux métadonnées de flux (tailles, timing, JA3/JA4, SNI). Une partie des features « naïves » n’existe tout simplement pas.

Bonne nouvelle : une fois les flux extraits, l’agrégation → vecteur tourne sur un flux d’événements bien moins nombreux que les paquets. C’est comparativement léger. Tout le poids est sur le paquet→flux. Dimensionner le prétraitement revient donc à dimensionner cette étape (Zeek + la couche de capture).

Dimensionner selon le débit du lien

L’intuition trompeuse, c’est de raisonner en « gigabits ». Le vrai facteur de difficulté, c’est le nombre de paquets par seconde (pps) — car chaque paquet doit être parsé. Et il dépend de la taille des trames : à 64 octets (le pire cas), un lien sature à un débit de paquets maximal ; à ~1000 octets (plus réaliste), c’est environ dix fois moins.

Règle de planification (full-fidelity, charge de scripts modérée, ordres de grandeur à ±) : ~0,5 à 1 Gbps par cœur worker. Au-delà de ~1 Gbps, il faut clusteriser et hacher les flux de façon symétrique (les deux sens d’une connexion sur le même worker, car l’analyse est stateful par connexion).

Lien	pps (trames 64 o)	pps (~1000 o)	Cœurs workers	Serveurs	RAM	Capture	full-PCAP
1 Gbps	≈ 1,5 Mpps	≈ 0,12 Mpps	1–2	1	4–8 Go	AF_PACKET fanout	0,13 Go/s (~0,45 To/h)
10 Gbps	≈ 15 Mpps	≈ 1,2 Mpps	10–20	1	32–64 Go	AF_PACKET / PF_RING	1,25 Go/s (~4,5 To/h)
25 Gbps	≈ 37 Mpps	≈ 3,1 Mpps	25–50	1–2	64–128 Go	PF_RING ZC / DPDK / RSS	3,1 Go/s (~11 To/h)
50 Gbps	≈ 74 Mpps	≈ 6,1 Mpps	50–100	2–4	128–256 Go	broker + DPDK	6,25 Go/s (~22 To/h)
100 Gbps	≈ 149 Mpps	≈ 12,3 Mpps	100–200	4–8 / appliances	256–512 Go+	broker + SmartNIC FPGA	12,5 Go/s (~45 To/h)

Ces chiffres sont des ordres de grandeur : ils dépendent fortement du mix de trafic, de la taille moyenne des paquets, de la charge de scripts et du tuning. On dimensionne sur le pic observé, pas sur le débit théorique du lien.

Les cinq paliers en détail

1 Gbps — un seul serveur

Tout tient sur une petite machine, capture logicielle (AF_PACKET fanout), un ou deux workers Zeek. Trivial à déployer.

10 Gbps — cluster Zeek sur une seule machine

On reste sur un seul (gros) serveur, mais Zeek tourne désormais en cluster : un manager, un logger, et 10 à 20 workers derrière une répartition de charge (AF_PACKET fanout ou PF_RING). Accessible.

25 Gbps — capture accélérée + hachage symétrique

La capture logicielle naïve ne suit plus : il faut une couche accélérée (PF_RING ZC, DPDK, ou le RSS de la carte réseau) et un hachage symétrique qui garantit que les deux sens d’un flux atterrissent sur le même worker. C’est la zone « le tuning fait tout ».

50 Gbps — broker de paquets + cluster multi-serveurs

On ne tient plus sur une machine. Un broker de paquets (ou load-balancer matériel) en frontal distribue le trafic, avec hachage symétrique, vers 2 à 4 serveurs Zeek. Les flux partent ensuite dans un bus (Kafka) consommé par un traitement de flux (Flink/Spark) qui produit les vecteurs.

100 Gbps — broker + matériel dédié

Le full-packet NSM à 100 Gbps est un vrai projet d’ingénierie. On combine un broker, des SmartNIC FPGA (ou des appliances spécialisées type Corelight), et un sharding sur 4 à 8 serveurs. À ce stade, on bascule souvent vers du matériel dédié plutôt que du logiciel sur serveur générique.

Quelle sonde déployer ?

Une « sonde » n’est pas un seul produit, c’est une chaîne : un point de prélèvement (TAP ou port miroir SPAN) qui alimente une couche de capture, puis le moteur d’extraction de features (Zeek & co). Voici les briques, en privilégiant le self-hosted.

Clé en main, open-source :

• Security Onion — la distribution de référence : elle empaquette Zeek + Suricata + Arkime + Elastic et des tableaux de bord. Déployée derrière un TAP/SPAN, c’est une sonde NSM complète et gratuite. Le meilleur point de départ.
• Malcolm (Idaho National Lab) — Zeek + Suricata + Arkime + OpenSearch, particulièrement solide sur l’OT/ICS.

Les briques, séparément (pour assembler sa propre sonde) :

• Zeek — le moteur d’extraction de features (paquet → flux, logs riches).
• Suricata — IDS/IPS + journal d’événements (eve.json).
• Arkime (ex-Moloch) — capture full-PCAP indexée et consultable.
• ntopng / nProbe — sonde de flux (NetFlow/IPFIX), légère : idéale pour le levier d’offload à très haut débit.
• OPNsense / pfSense + plugins Suricata/Zeek — pour un petit périmètre, le pare-feu fait office de sonde.

Commercial / appliances — le palier « matériel dédié » (50–100 Gbps) :

• Corelight — Zeek d’entreprise sur appliances avec SmartNIC, jusqu’à 100 Gbps et au-delà (la cible directe du schéma 100 Gbps).
• Plateformes NDR : ExtraHop Reveal(x), Vectra, Darktrace, Cisco Stealthwatch, et côté français Gatewatcher ou Custocy.

La couche d’alimentation (souvent oubliée — c’est elle qui détermine le passage à l’échelle) :

• TAP : Profitap, Garland, Keysight/Ixia.
• Packet broker (le « broker de paquets » des schémas 50/100 Gbps) : Gigamon, Arista DANZ, Niagara.
• SmartNIC FPGA : Napatech, NVIDIA/Mellanox — capture line-rate 25–100 Gbps.

Le cas des fabrics : la sonde, c’est le réseau lui-même

Tout ce qu’on a déroulé jusqu’ici suppose un modèle « TAP/SPAN + serveur de capture en frontal ». Mais sur une fabric managée moderne — Extreme Fabric Connect, Cisco ACI / SD-Access, Arista DANZ Monitoring Fabric, Juniper Apstra, Aruba CX — l’architecture change de nature : ce sont les commutateurs eux-mêmes qui exportent la télémétrie de flux, en continu, vers un collecteur d’analyse. Pas de TAP, pas de port miroir, pas de probe externe.

Les mécanismes typiques : sFlow, IPFIX, NetFlow v9, parfois du gNMI streaming, voire de la DPI légère dans l’ASIC sur certaines plateformes. La sonde devient une fonction distribuée de la fabric.

Le cas Extreme, à titre d’exemple : Fabric Connect (SPB) pour la mobilité L2/L3, sFlow exporté ligne-à-ligne par les Universal Switching (5320/5420/5520/7720/8720), et ExtremeAnalytics (héritier de Purview) qui consomme ce sFlow plus des signatures DPI fournies par les switches supportés — classifiant applications et utilisateurs sans poser de probe externe. Plus récemment, ExtremeAIOps ajoute du ML sur la même télémétrie.

Côté écosystème équivalent :

• Cisco — Stealthwatch / Secure Network Analytics + NetFlow Catalyst/Nexus, Encrypted Traffic Analytics, Catalyst Center.
• Arista — DANZ Monitoring Fabric + EOS Telemetry, et Arista NDR (issu de l’acquisition d’Awake Security).
• Juniper — Mist AI / Marvis, Apstra avec télémétrie gNMI.
• Aruba (HPE) — NetInsight + NAE (Network Analytics Engine) sur les ArubaOS-CX.
• Open-source — Akvorado (sFlow/IPFIX + ClickHouse, excellent et libre), pmacct, NfDump/NfSen.

Trade-offs honnêtes :

• ✓ Couverture est-ouest native sur toute la fabric, zéro TAP à poser, scale gratuit avec la taille du réseau.
• ✗ Échantillonné (typiquement 1:1000 à 1:10000) — risque de manquer les flux malveillants discrets ou de faible volume.
• ✗ Métadonnées seules : pas de payload, peu de décodage protocolaire fin. Toutes les features Zeek-style ne sont pas disponibles.
• ✗ Souvent du vendor lock-in pour la plateforme d’analytics embarquée.

Dans la vraie vie, on combine : du sFlow/IPFIX fabric-natif pour la couverture est-ouest large et l’observation à coût marginal, et une sonde Zeek/Suricata sur les liens critiques (Internet, DMZ, segmentation sensible) pour la profondeur d’analyse.

Zoom Extreme Networks : la mise en œuvre concrète

Pour ancrer ce modèle « la sonde, c’est le réseau lui-même », voici à quoi ressemble une mise en œuvre concrète chez Extreme Networks — c’est l’écosystème le plus cohérent sur ce terrain, et il sert ici d’exemple générique transposable aux équivalents Cisco / Arista / Juniper / Aruba.

Fondamentaux : SPB → I-SID → UNI

Trois notions à poser avant de regarder les briques à déployer — ce sont elles qui font marcher tout le reste :

• SPB (Shortest Path Bridging, IEEE 802.1aq) — le protocole sous-jacent de Fabric Connect. Il remplace le Spanning Tree par un plan de contrôle IS-IS, encapsule le trafic utilisateur en MAC-in-MAC (802.1ah PBB), et expose une fabric L2 multi-chemins : tous les liens sont actifs (pas de blocage STP), convergence sub-50 ms, le cœur n’apprend que les MAC de backbone (les MAC clientes restent encapsulées). Côté télémétrie, ça donne une couverture uniforme — chaque lien transporte du trafic réel — et de la stabilité même en re-convergence.
• I-SID (Service Identifier) — identifiant de service unique à l’échelle de la fabric (24 bits → 16 millions de services possibles). Chaque réseau virtuel (VSN, en L2 ou L3) porte son I-SID, et c’est lui qui isole logiquement des services qui partagent la même infrastructure physique. Le point clé pour le NDR : les flux télémétriques portent l’I-SID, donc le collecteur peut segmenter par service sans configuration supplémentaire.
• UNI (User Network Interface) — point de démarcation entre le réseau traditionnel (VLAN, VRF) et la couche de service SPB. Plusieurs formes selon la granularité voulue : VLAN UNI (un VLAN → un I-SID), Flex UNI Switched (paire VLAN + port → I-SID), Flex UNI Transparent Port (tout le port → I-SID), E-Tree UNI (hub-and-spoke, trafic bloqué entre spokes), Layer 3 VSN UNI (VRF → I-SID, unicast + multicast).

Visuellement, ça donne ce sandwich : IS-IS programme la fabric en plan de contrôle, le plan de données encapsule en MAC-in-MAC autour d’un I-SID, et les UNIs assurent l’entrée et la sortie côté utilisateur.

Anatomie matérielle : BCB vs BEB

Ce sandwich cache une dichotomie qui structure toute la fabric. Les commutateurs ne sont pas interchangeables — ils se répartissent en deux rôles, et ce découpage explique pourquoi Fabric Connect tient ses promesses d’agilité et d’opacité.

• BCB (Backbone Core Bridge), le cœur volontairement aveugle — il ne lit que le B-MAC externe (l’adresse du BEB d’entrée et celle du BEB de sortie), achemine la trame à la vitesse du fil par multipath IS-IS, et n’a aucune connaissance des VLAN, VRF ou MAC clientes. Il sert de transit pur. Pour une ASIC de cœur, c’est trivial : pas de table énorme, pas de reconfiguration au gré des services. Côté télémétrie, c’est aussi le moins bavard — c’est sur les BEB qu’on plante les sondes.
• BEB (Backbone Edge Bridge), l’edge intelligent — c’est le point de démarcation. Il fait la traduction UNI → I-SID à l’entrée, encapsule en MAC-in-MAC (ajoute le header SPBM avec son B-MAC source et le B-MAC du BEB de destination), tient les tables MAC/IP/VRF clientes, et fait l’opération inverse à la sortie. C’est aussi lui qui sort le sFlow et l’Application Telemetry — la télémétrie a déjà l’I-SID en main, donc le collecteur sait par construction à quel service appartient chaque flux.

Conséquence côté exploitation : ajouter ou retirer un service ne touche QUE les BEB des sites concernés — le cœur reste passif, aucune reconfiguration BCB nécessaire. Conséquence côté sécurité : un attaquant qui atteint le cœur ne voit qu’un trafic point-à-point entre BEB, opaque sur les sous-réseaux internes (la propriété « stealth » revendiquée par Fabric Connect — l’encapsulation MAC-in-MAC masque l’adressage applicatif au transit).

Ce qu’il faut déployer, brique par brique :

• La fabric, côté réseau — des commutateurs Universal Switching (5320 / 5420 / 5520 / 7720 / 8720), fédérés en Fabric Connect (SPB). Chacun active deux exports : sFlow (échantillonnage de flux) et Application Telemetry (hints DPI calculés dans l’ASIC sur les plateformes qui le supportent). Les agents pointent tous vers le collecteur.
• Le collecteur — ExtremeAnalytics Engine — la pièce centrale. C’est lui qui ingère le sFlow, applique le signature pack DPI (mis à jour par Extreme), corrèle les hints ASIC des switches et classifie applications et utilisateurs. Le signature pack reconnaît par défaut +8 000 applications et +10 000 empreintes comportementales — assez pour faire émerger immédiatement le shadow IT (SaaS non approuvés) et les flux suspects, sans configuration spécifique. La technologie K-mirror, combinée aux flux, génère des données de Niveau 7 et calcule la latence des flux : c’est ce qui permet, côté dashboard, de séparer visuellement la lenteur réseau de la lenteur purement applicative. À dimensionner (CPU/RAM/stockage) selon le volume de flux exportés et la rétention souhaitée.
• Le contexte identité — ExtremeControl (le NAC) — fournit la correspondance utilisateur · équipement · rôle qui transforme un IP en « Alice sur son portable, segment Finance ». C’est ce qui rend l’analytics exploitable côté SOC.
• Le pilotage — ExtremeCloud IQ Site Engine (héritier d’XMC / NetSight) — dashboards, alarmes, gestion centralisée des switches. C’est l’interface opérateur quotidienne.
• La couche ML — ExtremeAIOps (et ExtremeCloud IQ CoPilot) — par-dessus les flux et la classification, ajoute la détection d’anomalies, l’analyse de performance applicative et le diagnostic automatisé.
• L’intégration SOC — les alarmes Site Engine et les anomalies AIOps remontent au SIEM (Wazuh, Splunk, Elastic…) en syslog ou via webhook, et l’analyste prend la main à partir de là.

Les étapes typiques de mise en place :

1. Activer Fabric Connect (SPB + IS-IS) sur le périmètre cible. Côté edge, configurer les UNIs selon le type de service voulu (VLAN / Flex Switched / Flex Transparent / E-Tree / L3 VSN UNI) et leur mapper les I-SID. Sur une topologie non-fabric, on peut se contenter de sFlow + Application Telemetry — c’est sous-optimal mais ça marche.
2. Côté commutateur, configurer sFlow sur ExtremeXOS en 4 étapes : (a) agent local (IP source du switch), (b) adresses des collecteurs distants (ExtremeAnalytics Engine), (c) activation sFlow globale, (d) échantillonnage sur les ports cibles (Ingress et/ou Egress, taux éventuellement différencié par port). L’agent applique un throttling CPU — un plafond strict d’échantillons par seconde — pour ne pas perturber le plan de contrôle. Activer Application Telemetry en parallèle sur les plateformes compatibles.
3. Vérifier que les statistiques remontent bien : trames reçues (Received), échantillonnées (Sampled), UDP transmises (Transmitted), broadcast/multicast, et — important pour le SOC — les rejets matériels (Packet Drops), signal direct des saturations.
4. Déployer le VM/appliance ExtremeAnalytics Engine dimensionné pour le volume de flux et la rétention, et l’intégrer à Site Engine.
5. Brancher ExtremeControl pour le contexte identité (RADIUS / 802.1X / MAC auth, intégration AD/LDAP).
6. Activer ExtremeAIOps si on veut la couche ML / anomalie.
7. Câbler la sortie SIEM (Wazuh ou autre) : syslog des alarmes Site Engine, webhooks AIOps.

Confidentialité (RGPD) — trois niveaux paramétrables restreignent la collecte d’identifiants utilisateurs. C’est ce qui rend la solution acceptable en environnement RGPD ou lorsque le personnel IT ne doit pas avoir accès aux détails par utilisateur final.

Le modèle de coût se déplace par rapport au TAP/SPAN classique : on n’investit plus dans des serveurs de capture et des TAPs, mais dans les licences ExtremeAnalytics + Site Engine + AIOps, et dans le bon dimensionnement du collecteur. En contrepartie, on couvre toute la fabric sans points de capture supplémentaires.

Au final : une boucle fermée. Infrastructure (Fabric Connect / SPB via I-SID et UNI) → Télémétrie (sFlow à la source, throttlée matériellement) → Intelligence (ExtremeAnalytics + DPI sur 10 000+ empreintes, K-mirror Niveau 7) → Opérations (Site Engine, QoE, alertes, intervention). Chaque maillon nourrit le suivant, et l’ensemble vit sur le même substrat, sans sonde matérielle dédiée.

En pratique, par palier

Débit	Sonde recommandée (self-hosted)	Alimentation	Alternative appliance
1–10 Gbps	Security Onion (Zeek + Suricata + Arkime) sur 1 serveur	SPAN ou TAP	—
25 Gbps	Idem + capture accélérée (PF_RING ZC / DPDK)	TAP + NIC RSS	Corelight AP
50 Gbps	Zeek shardé sur 2–4 serveurs	Packet broker	Corelight / NDR
100 Gbps	Cluster + SmartNIC, ou bascule en sonde de flux (nProbe)	Broker + SmartNIC FPGA	Appliances Corelight / NDR

En résumé : jusqu’à ~10–25 Gbps, Security Onion sur un serveur correctement dimensionné suffit largement. Au-delà, le coût se déplace vers la couche d’alimentation (broker, SmartNIC) et l’on bascule soit vers du Zeek shardé, soit vers des appliances, soit vers une sonde de flux échantillonné.

De la détection à la remédiation : la boucle fermée en DMZ

Tout ce qui précède s’arrête au scoring. Mais une alerte sans action n’a pas plus de valeur qu’un capteur sans collecteur. La DMZ — surface la plus exposée — est précisément l’endroit où il faut fermer la boucle entre détection et remédiation, et où le coût d’une action mal calibrée est maximal (le réseau exposé encaisse en direct). L’IA peut intervenir des deux côtés à la fois : qualifier l’alerte, et décider quoi faire.

Quatre questions structurantes, qui ne se résolvent jamais avec un seul outil.

Qui décide — matrice confiance × blast-radius. Toutes les alertes ne méritent pas la même réponse. Un agent LLM classifie l’alerte, lui attache un score de confiance et estime son blast-radius (combien de services impactés, quelle zone). Trois bandes en sortie : auto (haute confiance + faible rayon — block d’une IP isolée, kill d’un pod), proposition au SOC (zone grise — un humain valide en un clic), humain seul (critique ou inconnu — l’IA arrête de proposer et passe la main). La frontière entre ces bandes est un paramètre opérationnel, pas une vérité de l’IA.

Quoi automatiser — playbooks bornés. Les exécuteurs ne sont pas un agent généraliste qui « fait ce qu’il faut ». Ce sont des APIs avec liste blanche d’actions : block IP / range côté pare-feu, kill pod + NetworkPolicy d’isolation côté Kubernetes, rotation de token + snapshot forensic côté Vault. Sortie de cette liste = escalade humaine. L’idée est que même si l’IA hallucine, l’espace des dégâts possibles est borné par construction.

Comment vérifier — la boucle de vérification. Une remédiation qui ne vérifie pas son effet est juste un changement de configuration. Après chaque action, la sonde NDR re-mesure le SPAN : l’attaque a-t-elle disparu, ou juste muté (rebond vers un autre vecteur) ? Si l’indicateur persiste, on ré-escalade — d’abord en proposition humaine, puis kill-switch. C’est cette ré-observation qui distingue une vraie boucle SOC autonome d’un script qui ferme des connexions à l’aveugle.

Quels garde-fous. Trois sont non négociables : un kill-switch humain toujours présent (l’analyste peut arrêter la boucle à tout instant), un audit trail qui capture chaque action de l’IA (verdict + arguments + effet observé), et un dry-run par défaut sur toute action à fort blast-radius (rotation de credentials globaux, isolation d’un namespace entier). En DMZ surtout, mieux vaut un faux négatif géré humainement qu’une remédiation auto qui coupe le site de production.

L’apprentissage ferme tout — le verdict humain (faux positif / vrai positif, confirmation que l’action a été pertinente) alimente le ré-entraînement. C’est ce qui fait grossir la bande auto avec le temps : on déplace la frontière au fur et à mesure que la confiance est validée par l’usage, pas l’inverse.

Pièges et leviers

• La RAM suit le nombre de connexions concurrentes, pas seulement le débit. Un lien à fort taux de nouveaux flux par seconde peut épuiser la mémoire avant la bande passante.
• Le full-PCAP devient vite infaisable : à 100 Gbps, c’est ~45 To par heure à débit plein. On ne garde donc que des captures sélectives (sur alerte, ou échantillonnées).
• Trafic chiffré : prévoir des features qui survivent au chiffrement (métadonnées de flux, JA3/JA4, SNI, certificats) plutôt que l’inspection de contenu.
• Levier majeur à 50–100 Gbps : décharger l’assemblage de flux sur le NetFlow / IPFIX exporté par les équipements réseau (souvent échantillonné 1:1000). Beaucoup moins de calcul côté sonde, au prix de features plus grossières. C’est le compromis réel des très hauts débits.

En résumé

La détection réseau par IA n’est pas un problème d’IA, c’est d’abord un problème de plomberie de données à haut débit. Le modèle est presque gratuit en regard du prétraitement, et la faisabilité bascule complètement entre 10 Gbps (un serveur) et 100 Gbps (cluster + matériel spécialisé, ou flux échantillonné). Avant de choisir un algorithme, il faut savoir à quel débit on observe, et provisionner la capture et l’extraction de features en conséquence.

Prochain article de la série : les approches d’analyse elles-mêmes — du jeu de signatures au deep learning, qui fabrique les features et à quel prix.