Suricata : IDS/IPS/NSM Open Source Multi-thread 2026

Suricata est le moteur de detection d'intrusions reseau open source multi-thread de reference, developpe depuis 2009 par l'Open Information Security Foundation (OISF). Distribue sous licence GPLv2, il combine trois roles dans un binaire unique : IDS passif (Intrusion Detection System) en mode promiscuous, IPS inline (Intrusion Prevention System) via AF_PACKET, NFQUEUE, IPFW ou Netmap, et NSM (Network Security Monitoring) avec extraction de fichiers, parsing protocolaire profond et export EVE JSON. Concu des l'origine pour exploiter les CPU multi-coeurs et les NIC multi-queue, Suricata depasse les 10 a 40 Gbps en production sur du materiel x86_64 grace a l'integration d'Intel Hyperscan pour le pattern matching et au support natif RSS, CPU pinning et zero-copy. La version stable en mai 2026 est Suricata 7.0.10 LTS (Long Term Support jusqu'en 2028) et la branche 8.0 est en developpement actif avec le moteur Hyperscan 5.5 et le parser HTTP/3 sur QUIC. Suricata se distingue de son ancetre Snort (mono-thread historique) par son architecture parallele native et de Zeek (ex-Bro) par sa compatibilite directe avec le format de regles signatures Snort/Emerging Threats. Au 1er trimestre 2026, le projet compte plus de 9 200 etoiles GitHub, 280 contributeurs et est deploye chez les operateurs telecom Tier-1, les CERT nationaux (ANSSI, CERT-FR, CISA), les SOC de defense et la majorite des SIEM hybrides open source bases sur Wazuh.

Definition technique de Suricata

Suricata est defini officiellement par l'Open Information Security Foundation comme un moteur de detection des menaces reseau open source haute performance. Il combine quatre fonctions cybersecurite dans une meme application : detection d'intrusions par signatures (IDS), prevention en coupure de flux (IPS), monitoring de securite reseau avec extraction protocolaire (NSM) et capture orientee threat hunting (PCAP-NG, file extraction, TLS metadata). La version stable courante est Suricata 7.0.10 LTS (avril 2026), publiee dans la serie 7.0.x dont le support s'etend jusqu'en juin 2028. Le code source est heberge sur github.com/OISF/suricata et la documentation officielle reside sur suricata.io. Suricata se distingue d'un firewall classique par sa capacite a inspecter le contenu applicatif (Layer 7), d'un proxy inverse par son fonctionnement transparent sur cable, et d'un EDR par sa nature exclusivement reseau (pas d'agent endpoint). Ses sorties EVE JSON sont consommees par les SIEM aval (Wazuh, Microsoft Sentinel, Splunk, Elastic, Graylog) ou par les XDR commerciaux qui s'en servent comme capteur reseau.

Histoire et trajectoire OISF de Suricata

Suricata a ete initie en juillet 2009 par le Department of Homeland Security americain (programme HOST), la Navy (SPAWAR) et plusieurs partenaires prives, dans le cadre d'un appel d'offres visant a creer une alternative multi-thread a Snort dont l'architecture mono-coeur etait devenue le goulot d'etranglement des sondes IDS sur les liens 10 GbE. La premiere version 1.0.0 a ete publiee en juillet 2010. L'Open Information Security Foundation a ete creee specifiquement pour heberger le projet, sous statut 501(c)(3) (organisation a but non lucratif americaine), avec un financement initial conjoint DHS/Navy puis bascule vers un modele consortium fonde en 2014. Au 1er trimestre 2026, l'OISF compte une vingtaine de Consortium Members (Stamus Networks, Proofpoint Emerging Threats, AT&T, Cisco, Akamai, Broadcom, Fortinet, NDR, Mandiant, ANSSI partenaire institutionnel) qui financent le developpement upstream et orientent la roadmap. Les jalons techniques majeurs : signatures Emerging Threats open en 2010, support IPS NFQUEUE en 2011, EVE JSON en 2014 (Suricata 2.0), integration Hyperscan en 2017 (Suricata 4.0), parser HTTP/2 en 2019 (Suricata 5.0), JA3/JA3S en 2020, support QUIC en 2022 (Suricata 7.0), JA4 fingerprinting en 2024. La branche 8.0 en alpha apporte HTTP/3 sur QUIC, Hyperscan 5.5 et un parser eBPF natif pour le bypass selectif.

Architecture multi-thread : pipeline parser, decode, flow tracking, detect, output

L'architecture Suricata se compose d'un pipeline en cinq etages repartis sur des threads paralleles independants. Le schema ci-dessous illustre le flux d'un paquet depuis l'interface reseau jusqu'au log EVE JSON.

+----------------------+      +-----------------------+      +-----------------------+
|   NIC + RSS queues   |      |   Capture threads     |      |   Decode threads      |
|   AF_PACKET / DPDK   |─►►►─|   ring buffer mmap    |─►►►─|   Eth/IP/TCP/UDP      |
|   napatech / netmap  |      |   per-queue affinity  |      |   defrag, reassembly  |
+----------------------+      +-----------------------+      +-----------------------+
                                                                       |
                              +-----------------------+      +-----------------------+
                              |   App layer parsers   |◄───|   Flow tracking       |
                              |   HTTP/2 TLS QUIC DNS |      |   stream5 reassembly  |
                              +-----------------------+      +-----------------------+
                                          |
                                          v
                              +-----------------------+      +-----------------------+
                              |   Detect threads      |─►►►─|   Output threads      |
                              |   Hyperscan + lua     |      |   EVE JSON / unified2 |
                              |   signature match     |      |   PCAP / file extract |
                              +-----------------------+      +-----------------------+

L'etage capture recupere les paquets depuis l'interface via une API DAQ (Data Acquisition) modulaire : AF_PACKET (Linux par defaut), AF_XDP (Linux 5.4+), DPDK (zero-copy userspace), Netmap (BSD), PF_RING ZC (Tilera/Napatech), NFLOG, IPFW divert, ou pcap fichier pour replay. Chaque file RSS de la NIC est attachee a un thread capture dedie pinned sur un coeur CPU specifique, ce qui realise le parallelisme sans contention.

L'etage decode deserialize les en-tetes Ethernet, VLAN/QinQ, MPLS, IPv4/IPv6, GRE, ESP/IPSec, TCP/UDP/SCTP, ICMP, et les empile dans la structure interne Packet. Les fragments IP sont reassembles avant remontee, et les flux TCP sont reassembles par le module stream5 qui maintient l'etat des connexions (SEQ/ACK tracking, TCP states machine, anti-evasion).

L'etage flow tracking hashe le 5-tuple (src IP, dst IP, src port, dst port, protocole) dans une hash table sharded par coeur CPU. Chaque flow porte un buffer de reassembly, un context applicatif (HTTP transactions, TLS handshake state, DNS queries) et les compteurs de bytes/packets.

L'etage detect est le coeur de la detection : chaque flow et chaque transaction applicative (HTTP request, TLS hello, DNS query) sont evalues contre l'ensemble des regles compilees. Suricata utilise Hyperscan (bibliotheque Intel libre de pattern matching SIMD) pour la recherche multi-pattern simultanee, et un evaluateur de conditions structurel pour les modificateurs (content, pcre, byte_test, flowbits, etc.). Le multi-pattern matching reduit la complexite de O(N*M) a O(L) ou L est la taille du paquet.

L'etage output serialize les alertes et les meta-evenements en EVE JSON, unified2 (legacy), syslog, fichier de capture, ou pousse vers Redis/Kafka via le plugin output natif.

Modes IDS passif, IPS inline et NSM logging

Suricata supporte trois modes d'exploitation distincts, selectionnes au demarrage par la combinaison du DAQ et de la directive --af-packet, --nfqueue, -r ou -i.

Mode IDS passif. Suricata ecoute sur une interface en mode promiscuous ou via un port mirror SPAN sur le switch (Cisco SPAN, Juniper analyzer, NetFlow probe). Aucun paquet n'est modifie ni bloque, seules les alertes sont generees. C'est le mode classique pour la detection sans risque d'impact reseau, deploye en sortie de coeur de reseau ou en bordure DMZ. Le DAQ par defaut est AF_PACKET en mode TPACKET_V3 zero-copy.

Mode IPS inline. Suricata se positionne en coupure du flux et peut dropper les paquets matchant une regle de type drop ou reject. Quatre integrations existent : AF_PACKET en mode bridge avec une paire d'interfaces (la plus simple, sans dependance kernel), NFQUEUE via netfilter (paquets routes par iptables vers un queue userspace), IPFW divert sur FreeBSD, et Netmap avec switch logiciel pour les debits eleves. Le mode AF_PACKET inline supporte le bypass selectif via eBPF/XDP depuis Suricata 5.0 : les flows juges anodins (apres TLS handshake termine et SNI whitelisted) sont court-circuites au niveau kernel pour reduire la charge userspace. Cette technique est cruciale au-dela de 10 Gbps.

Mode NSM logging. Suricata est utilise comme sonde NSM pure (Network Security Monitoring), generant les flow logs, transaction logs HTTP/TLS/DNS/SSH/SMB, et l'extraction de fichiers via reassembly applicatif. Cest le mode favorise dans les SOC qui privilegient la detection comportementale et le threat hunting retroactif sur les metadata, plutot que les signatures bruyantes. Les events EVE JSON sont alors la source primaire pour des outils de hunting comme threat hunting MITRE ou des plateformes XDR.

Format des regles Suricata : signatures .rules

Les regles Suricata sont stockees dans des fichiers .rules et utilisent la syntaxe heritee de Snort avec extensions specifiques. Une regle se compose de l'action (alert, drop, reject, pass), du protocole, des adresses/ports source/destination, de la direction (-> ou <>) et d'un bloc d'options entre parentheses.

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"ET MALWARE Cobalt Strike Beacon Activity";
    flow:established,to_server;
    http.method; content:"POST";
    http.uri; pcre:"/^\/[a-zA-Z0-9]{4}\?[a-zA-Z0-9]+=/";
    http.user_agent; content:"Mozilla/5.0 (compatible; MSIE 10.0";
    flowbits:set,malware.cobaltstrike;
    classtype:trojan-activity;
    sid:2030549; rev:3;
    metadata: created_at 2024_03_15, attack_target Client_Endpoint,
              former_category MALWARE, mitre_tactic_id TA0011,
              mitre_technique_id T1071;
)

Les options principales couvrent le contenu (content, pcre, byte_test, byte_jump), le contexte applicatif (http.uri, http.method, http.host, tls.sni, tls.cert_subject, dns.query, ja3.hash), les flowbits (correlation entre regles d'un meme flow), les seuils (threshold), et les metadonnees MITRE ATT&CK pour mapping XDR. Suricata 7.0 ajoute le support des sticky buffers (http.uri au lieu de http_uri) qui sont la syntaxe canonique recommandee.

Emerging Threats Open ruleset : 70 000 regles communautaires

Le ruleset Emerging Threats Open (ET Open), maintenu par Proofpoint, est le standard de fait pour Suricata en deploiement libre. Il regroupe environ 70 000 signatures classifiees en categories malware, exploit, scan, policy, shellcode, dns, tor, 3coresec, chat, games, p2p. Le ruleset est mis a jour toutes les 24 heures et distribue gratuitement sur rules.emergingthreats.net. La version commerciale ET Pro ajoute environ 30 000 regles supplementaires (couverture APT, ransomware nominatif, malware fresh).

L'installation se fait typiquement via suricata-update, le gestionnaire officiel ecrit en Python qui telecharge les rulesets, gere les disabled.conf, enabled.conf, modify.conf et drop.conf pour personnaliser sans editer les fichiers upstream. Les autres sources de regles supportees nativement sont SSL Blacklist (abuse.ch), tor exit nodes, OSINT compromised IP, plus toute source HTTPS au format tarball.

Compatibilite Snort 3 et migration progressive

Suricata est largement compatible avec Snort 3 au niveau du format de regles, ce qui facilite la migration des sites historiquement Snort vers une stack Suricata multi-thread. Les differences principales : Snort 3 utilise un fichier de configuration LuaJIT (snort.lua) tandis que Suricata utilise YAML (suricata.yaml) ; les variables HOME_NET et EXTERNAL_NET sont communes ; les options modernes (sticky buffers, http.* fields, file_data) sont identiques ; quelques options legacy (uricontent) sont deprecated mais encore acceptees par Suricata via compat-rules. Les sites en environnement mixte deploient souvent Suricata en parallele de Snort pendant 4 a 8 semaines pour comparer les detections, puis migrent en bloc.

Lua scripting pour detection avancee

Suricata embarque LuaJIT pour exprimer des conditions de detection que la grammaire de regles standard ne couvre pas : decodage de protocoles proprietaires, calcul d'entropie sur un payload (detection de packed binaries ou de tunneling DNS), corellation multi-flow temporelle, ou interrogation d'une threat intel locale en clef-valeur. Une regle invoque un script Lua via l'option luajit: ou lua: et le script retourne 0 (pas de match) ou 1 (match).

L'usage typique du Lua est le DNS tunneling detection par calcul de l'entropie de Shannon sur les sous-domaines, la detection de domain generation algorithms (DGA) par n-gramme et frequence de consonnes, ou la verification de la signature numerique d'un certificat TLS. Le surcout CPU est de l'ordre de 5-15% selon la complexite du script, generalement acceptable car les regles Lua sont peu nombreuses.

EVE JSON output : format unifie pour SIEM

EVE JSON (Extensible Event Format) est le format de log canonique de Suricata depuis la version 2.0 (2014). Chaque event est un objet JSON sur une ligne (NDJSON), avec un champ event_type qui discrimine la nature : alert (signature match), http (transaction HTTP), tls (handshake TLS), dns (query/answer), flow (flow record termine), fileinfo (extraction de fichier), anomaly (decoder ou stream anomaly), ssh, smb, krb5, rdp, nfs, ftp, smtp, dnp3, modbus, quic, ja3, ja4.

{
  "timestamp": "2026-05-08T14:23:09.412358+0200",
  "flow_id": 1473829471829345,
  "event_type": "alert",
  "src_ip": "10.42.17.83",
  "src_port": 53412,
  "dest_ip": "185.220.101.45",
  "dest_port": 443,
  "proto": "TCP",
  "alert": {
    "action": "allowed",
    "signature_id": 2030549,
    "signature": "ET MALWARE Cobalt Strike Beacon Activity",
    "category": "A Network Trojan was detected",
    "severity": 1,
    "metadata": {
      "mitre_tactic_id": ["TA0011"],
      "mitre_technique_id": ["T1071"]
    }
  },
  "tls": {
    "sni": "cdn-update[.]example",
    "ja3": {"hash": "5d82e2b3437b5d4e1e8b8a9c8e2b2b2b"},
    "ja4": "t13d1516h2_8daaf6152771_e5627efa2ab1"
  }
}

Cette unification facilite l'ingestion par Wazuh (decoder eve-json natif), Elastic (module Filebeat suricata), Splunk (TA-Suricata), Graylog (input GELF/Beats), Sentinel (Custom Logs API) et tout pipeline Kafka/Logstash. Le partitionnement par event_type dans l'index Elastic permet d'optimiser le mapping et la retention differenciee.

File extraction : reassembly et MD5/SHA256

Suricata extrait nativement les fichiers transferes via HTTP (GET/POST), SMTP (attachments), FTP, SMB, NFS et HTTP/2. L'extraction repose sur la reassembly du flux applicatif et sur les magic bytes pour identifier le type MIME. Chaque fichier extrait genere un event fileinfo avec les hash MD5, SHA1, SHA256, le nom, la taille, le type detecte, et optionnellement le binaire est sauvegarde sur disque pour analyse offline (sandbox, antivirus, YARA scanning aval).

Cette capacite est exploitee par les SOC pour la chasse retroactive : lorsqu'un IOC SHA256 est publie (par exemple suite a une campagne ransomware), un grep dans les logs EVE permet d'identifier instantanement si le fichier a transite sur le reseau, sans avoir besoin de rejouer les PCAP integraux. La storage policy typique est extraction selective : seuls les binaires (PE, ELF, Mach-O), les archives (ZIP, RAR, 7z) et les documents office sont sauvegardes, le reste etant logue avec hash uniquement.

TLS inspection sans MITM : metadata et JA3/JA3S/JA4

Suricata realise une inspection TLS passive (sans interception MITM, sans dechiffrement) qui extrait les metadonnees du handshake TLS visibles en clair : version TLS, ciphersuites, cle echangee, SNI (Server Name Indication), certificat X.509 (sujet, issuer, fingerprint, validite, SAN), et empreintes JA3 (client) et JA3S (serveur) calculees a partir de la composition du Client Hello/Server Hello. Le format JA4 introduit par FoxIO en 2024 ajoute la stabilite multi-libssl, le hash separe pour HTTP/TLS/SSH/QUIC, et la classification a-z des sous-empreintes (JA4, JA4S, JA4H, JA4X, JA4T, JA4SSH, JA4L).

L'usage principal de JA3/JA4 est la detection de malware C2 qui presente une empreinte TLS specifique meme avec un certificat valide Let's Encrypt : Cobalt Strike, Sliver, Mythic, Brute Ratel ont des JA3/JA4 publies sur les threat feeds (abuse.ch SSL Blacklist, ThreatFox). Couple avec une regle Suricata alert tls any any -> any any (ja3.hash; content:"5d82e2b3437b5d4e1e8b8a9c8e2b2b2b"; sid:99001;), la detection est instantanee sans necessite d'inspection profonde. Voir aussi threat hunting MITRE pour les patterns JA4 de hunting proactif.

Parsing HTTP/2 et QUIC (HTTP/3)

Suricata 7.0 parse nativement HTTP/2 sur TLS (RFC 9113) en decodant le multiplexage des streams binaires, l'header compression HPACK, et le mapping vers la structure transaction HTTP commune (host, uri, method, status, user_agent, request/response body). Les regles http.uri, http.method, http.user_agent fonctionnent identiquement sur HTTP/1.1 et HTTP/2, ce qui evite la duplication des signatures. Le parser HTTP/2 supporte les preferences server push, les priorites de stream, et les flags de fin de stream.

Pour QUIC (RFC 9000) et HTTP/3 (RFC 9114), Suricata 7.0 extrait les metadonnees QUIC visibles : version negociee, CID (Connection ID), SNI dans le ClientHello QUIC, et calcule les empreintes JA4 specifiques QUIC. Le parsing applicatif HTTP/3 (sur QUIC chiffre) reste impossible sans dechiffrement, mais les SNI et JA4 fournissent un signal de detection suffisant pour la majorite des usages C2 et exfiltration. La branche Suricata 8.0 en developpement apporte le decodage des frames QUIC initial avec session resumption tracking, et une extension du parser pour HTTP/3 si les cles TLS sont fournies via SSLKEYLOGFILE (cas de lab seulement).

Integration ELK, Splunk, Wazuh, Graylog

Suricata est concu pour s'integrer en amont d'un SIEM aval qui assure le stockage, l'investigation et la correlation. Les patterns d'integration les plus deployes en 2026 sont les suivants.

Le pattern Wazuh + Suricata est particulierement bien documente : Wazuh ingere les EVE JSON via son agent natif sur la sonde, applique son decoder 0250-suricata.xml et corrole avec les events endpoint pour produire un SIEM hybride open source SOC. La latence p99 entre detection Suricata et alerte Wazuh est typiquement sous 5 secondes.

Suricata 7.0 LTS : nouveautes et roadmap 8.0

La branche Suricata 7.0 LTS publiee en juillet 2023 apporte des nouveautes structurelles importantes : reecriture en Rust de plusieurs parsers (DNS, SMB, MQTT, Modbus, DCERPC), support natif des datasets (matching contre des listes IP/string compactes en memoire), JA4 fingerprinting, parsing complet HTTP/2, integration eBPF/XDP avec bypass selectif, performance Hyperscan amelioree de 30% par rapport a Suricata 6, support PGSQL et MQTT decodeurs.

La roadmap Suricata 8.0 publiee dans la wiki OISF cible une release stable en 2026 avec : parser HTTP/3 sur QUIC (au-dela des metadata), Hyperscan 5.5 nouvelle generation, support napatech 3-tuple offload, ameliorations stream5 pour TCP fast open, refactoring du detect engine pour reduire la latence p99 de 25%, integration native suricatasc en Rust, et un nouveau format de logs EVE 2.0 avec streams CBOR pour les bandwidth-constrained environments. Le calendrier 2026 prevoit une beta en T3 et une release stable T4.

Comparatif Suricata vs Snort 3 vs Zeek vs OpenSnort

Suricata partage le marche de la sonde reseau open source avec trois autres projets majeurs. Le tableau ci-dessous synthetise les differences techniques en 2026.

La regle pratique : Suricata excelle en signature-based detection multi-Gbps avec NSM secondaire ; Zeek est superieur pour la detection comportementale et les protocoles industriels esotériques ; Snort 3 reste pertinent dans les ecosystemes Cisco Firepower/Talos. La combinaison Suricata + Zeek sur la meme sonde (chacun lit le meme TAP/SPAN) est la stack NSM open source de reference dans les SOC matures, ingeree par Wazuh ou SIEM hybride Wazuh/Graylog/Suricata.

Performance : 10 a 40 Gbps avec Hyperscan

Le facteur cle de performance Suricata est Intel Hyperscan, bibliotheque libre de pattern matching multi-pattern utilisant les instructions SIMD AVX2/AVX-512. Hyperscan compile en avance les patterns en automate optimise et evalue jusqu'a 100 patterns par cycle CPU. Avec 70 000 regles ET Open compilees, le throughput observe sur du materiel standard est detaille dans le tableau ci-dessous.

Au-dela de 25 Gbps, le bypass eBPF/XDP devient critique : les flows TLS apres handshake (volume principal) sont court-circuites en kernel et ne remontent plus userspace. La proportion de bypass typique sur un trafic mixte web est de 60-70%, ce qui multiplie effectivement le throughput utile par 2,5 a 3.

Tuning hardware : CPU pinning, RSS, AF_PACKET

Le tuning Suricata haute performance repose sur trois piliers. Premierement, le RSS multi-queue sur la NIC : configurer la NIC avec autant de queues hardware que de coeurs CPU dedies, avec un hash symetrique 5-tuple pour preserver la coherence par flow. Sur Intel X710/E810, la commande ethtool -L eth1 combined 16 alloue 16 queues, et ethtool -X eth1 hkey 6d:5a:... applique la cle Toeplitz symetrique.

Deuxiemement, le CPU pinning : les threads capture, decode et detect doivent etre epingles sur des coeurs differents pour eviter la contention. La directive threading.cpu-affinity dans suricata.yaml mappe les pools worker-cpu-set, receive-cpu-set et management-cpu-set. Sur un systeme NUMA, garder tous les threads d'une instance Suricata sur le meme node memoire pour beneficier de la localite cache.

Troisiemement, le DAQ approprie : AF_PACKET v3 zero-copy pour 1-25 Gbps, AF_XDP pour 25-50 Gbps avec une charge de tuning intermediaire, DPDK pour 40-100 Gbps avec le poll-mode driver dedie, et napatech/Tilera pour au-dela. La directive af-packet.ring-size doit etre adaptee a la rafale (typiquement 200 000 paquets) et af-packet.use-mmap active le zero-copy.

Conformite : PCI DSS, NIS2, ANSSI

Suricata contribue a plusieurs cadres de conformite reglementaires en fournissant la couche capteur reseau requise.

• PCI DSS 4.0 Requirement 11.5.1 (intrusion detection/prevention) : Suricata satisfait directement l'exigence de monitoring du trafic perimetrique et du segment CDE (Cardholder Data Environment) avec alertes en temps reel.
• NIS2 Article 21.2.b (gestion des incidents) : Suricata fournit la couche detection reseau indispensable au pilier "detection" du dispositif. Voir threat hunting MITRE.
• ANSSI Guide d'hygiene informatique R20 (detection des incidents) : Suricata est mentionne explicitement comme solution conforme dans le guide PA-022 sur les sondes IDS/IPS.
• ISO 27001:2022 Annexe A 8.16 (monitoring activities) : Suricata couvre l'exigence de surveillance reseau continue et de generation d'evidences pour audits.
• HIPAA 164.312(b) (audit controls) : les logs EVE JSON Suricata constituent une trail audit reseau exploitable pour les couvertures sante US.
• MITRE ATT&CK : les regles ET Open et ET Pro sont taggees avec les techniques (T1071 C2 over web, T1567 exfiltration over web, T1059 command execution, T1055 process injection via shellcode network), permettant l'alignement direct.

Use cases : perimeter, segmentation interne, cloud, DPI

Les deploiements Suricata couvrent six scenarios principaux observes dans les missions audit reseau et SOC.

Sonde perimetrique sortie internet. Suricata IDS sur un TAP optique entre routeur de bordure et firewall, ingestion EVE JSON dans Wazuh ou Sentinel. Couverture detection C2, exfiltration, drive-by download, scans entrants. C'est le scenario le plus repandu et le plus mature.

Segmentation interne et zone OT. Suricata IPS inline entre VLAN OT (operational technology, automates Modbus/DNP3) et reseau corporate, avec regles ET Open OT et regles custom IEC 62443. Permet la microsegmentation comportementale dans les usines et environnements industriels.

Sondes cloud (AWS VPC Mirror, Azure VNet TAP). Suricata deployee sur EC2/VM avec port mirror VPC Traffic Mirroring (AWS) ou Azure Virtual Network TAP, ingestion EVE vers Sentinel ou Wazuh. Couverture lateral movement intra-VPC souvent invisible aux flow logs natifs.

Inspection DPI Kubernetes. Suricata sur node Kubernetes en sidecar avec eBPF capture des packets de pods, complementaire a Falco qui couvre les syscalls. La combinaison Falco + Suricata fournit une couverture exhaustive runtime + reseau.

Threat hunting NSM offline. Suricata replay sur fichiers PCAP archives (-r) pour rejouer une periode d'incident avec un ruleset enrichi a posteriori. Pratique courante en CSIRT post-mortem.

Honey-net et deception. Suricata sur des reseaux de leurre ou tout trafic est par definition suspect, generant des IOC haute confiance pour enrichissement threat intel.

Limites et angles morts de Suricata

Suricata presente des limites assumees qu'il faut comprendre avant de standardiser sa stack NSM autour du projet.

Pas de dechiffrement TLS sans MITM. Suricata inspecte les metadata TLS (SNI, certificat, JA3/JA4) mais ne dechiffre pas le payload. Pour l'inspection profonde, il faut un proxy MITM amont (Squid, Mitmproxy) ou un firewall enterprise avec SSL break-and-inspect.

Faux positifs sur ruleset bruyant. ET Open est volontairement large pour ne rien rater, ce qui produit une volumetrie d'alertes elevee non-tunee. Le tuning disable.conf/modify.conf demande 4-8 semaines en production initiale.

Comportementale limitee. Suricata reste un moteur signature-centric. Pour la detection comportementale fine (anomalies trafic, beacon timing, DGA via ML), il faut coupler avec Zeek ou un module ML aval.

Pas de prevention sans IPS inline. En mode IDS sniffing, Suricata alerte mais ne bloque pas. Pour bloquer, il faut deployer en inline avec les contraintes operationnelles que cela impose (latence ajoutee, single-point-of-failure si non HA).

Configuration YAML complexe. Le fichier suricata.yaml compte plus de 1500 lignes avec des centaines d'options. La courbe d'apprentissage est reelle, et de mauvaises directives stream.reassembly.depth ou defrag.memcap peuvent provoquer des drops silencieux.

Pas d'UI native. Suricata genere du JSON ; l'interface utilisateur est fournie par le SIEM aval (Kibana, Wazuh dashboard, Splunk) ou par SELKS (distribution Stamus tout-en-un avec Scirius UI) ou EveBox.

FAQ Suricata

Suricata ou Snort 3, lequel choisir en 2026 ?

Pour un nouveau deploiement, Suricata 7.0 LTS est generalement le choix recommande grace a sa maturite multi-thread native (depuis 2010), sa communaute plus large dans le monde non-Cisco, son support natif de JA4, EVE JSON et eBPF/XDP. Snort 3 reste pertinent dans les ecosystemes Cisco Firepower/FTD ou la chaine d'outils Talos est deja en place. La compatibilite des regles permet de migrer progressivement de Snort vers Suricata sans reecriture massive du ruleset.

Suricata fonctionne-t-il sur Windows ?

Oui mais avec des limitations. Suricata pour Windows est compile via Cygwin/MinGW et fonctionne en mode pcap.dll (capture WinPcap/Npcap). La performance est inferieure a Linux (pas de zero-copy AF_PACKET, pas de eBPF/XDP) et le mode IPS inline n'est pas disponible sous Windows. Pour la production, deployer Suricata sur Linux (Ubuntu 22.04 LTS ou Debian 12 conseille) ou FreeBSD.

Comment integrer Suricata a Wazuh ?

L'integration est pre-cablee. Sur la sonde Suricata, installer l'agent Wazuh, configurer suricata.yaml pour ecrire EVE JSON dans /var/log/suricata/eve.json, ajouter dans ossec.conf de l'agent un bloc <localfile> avec log_format=json et location=/var/log/suricata/eve.json. Wazuh applique automatiquement son decoder 0250-suricata.xml, et les alertes apparaissent dans le dashboard Wazuh avec le mapping MITRE ATT&CK preserve. Voir guide SIEM hybride Wazuh/Graylog/Suricata pour le detail architecture.

Quelle est la difference entre IDS, IPS et NSM avec Suricata ?

Le binaire Suricata est unique mais le mode est determine par le DAQ et la configuration : IDS = ecoute passive sur TAP/SPAN, alertes seulement, zero impact reseau ; IPS = en coupure inline, drop des paquets matchant une regle drop, ajoute de la latence et necessite haute disponibilite ; NSM = focus sur le logging de transactions (HTTP/TLS/DNS/SMB) et l'extraction de fichiers, utilise comme telemetry pour threat hunting et investigation, generalement combine avec IDS sur la meme instance.

Suricata peut-il vraiment monter a 100 Gbps ?

Oui, mais necessite du materiel dedie. Sur du x86_64 standard avec NIC Mellanox CX7 100 GbE, on plafonne a 35-40 Gbps utile. Au-dela, il faut des SmartNIC Napatech ou NVIDIA BlueField DPU qui offload le pre-filtering et le RSS hardware, combines avec PF_RING ZC ou DPDK. Plusieurs operateurs Tier-1 deploient Suricata a 100+ Gbps en production avec cette architecture, mais le cout hardware est de l'ordre de 30 a 80 keuros par sonde.

Suricata est-il vraiment gratuit en production ?

Oui, integralement. Suricata est distribue sous licence GPLv2 sans aucune restriction d'usage commercial, de nombre de sondes, ou de volume de regles. Le ruleset Emerging Threats Open est egalement gratuit. Les options payantes existantes : ET Pro (signatures premium Proofpoint, 30 000 regles supplementaires), Stamus Networks NDR (plateforme commerciale qui embarque Suricata + analytics + UI), et le support entreprise OISF (consulting + tuning + training). La version open source pure est suffisante pour la plupart des SOC.

Liens approfondis

• Documentation officielle : suricata.io
• Code source et releases : github.com/OISF/suricata
• Ruleset Emerging Threats : rules.emergingthreats.net
• Wazuh XDR/SIEM : plateforme Wazuh
• Falco runtime detection CNCF : Falco eBPF Kubernetes
• Microsoft Sentinel SIEM/SOAR : Sentinel cloud
• SIEM hybride Wazuh/Graylog/Suricata : guide SOC
• Threat hunting MITRE ATT&CK : detection proactive
• Audit reseau : prestation audit
• Glossaire IDS : definition IDS