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 :
- Capture — une sonde reçoit une copie du trafic (TAP physique ou port miroir SPAN).
- 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.
- 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.
- 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.
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é.
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.