Introduction à Suricata

Suricata est un moteur open source de détection et de prévention des intrusions réseau. Il inspecte le trafic en temps réel, le compare à des milliers de règles et produit des journaux structurés exploitables par un SOC. Ce cours s’adresse aux administrateurs, techniciens et responsables sécurité de PME qui veulent comprendre ce que fait réellement une sonde réseau, la déployer proprement et en tirer des alertes utiles plutôt que du bruit. Les commandes présentées correspondent à la branche 8.0 de Suricata (version 8.0.8 publiée le 29 octobre 2026) installée sur Ubuntu Server 24.04 LTS.

Cadre légal : une sonde réseau voit le contenu des communications. Ne la déployez que sur des réseaux dont vous avez la responsabilité, après information des utilisateurs et validation de la direction (et du DPO le cas échéant). Les manipulations des travaux pratiques se font dans un laboratoire isolé.

1. IDS, IPS et NSM : ce que fait Suricata

Un IDS (Intrusion Detection System) observe une copie du trafic et lève des alertes lorsqu’il reconnaît un comportement suspect. Il ne bloque rien : il est placé « à côté » du flux, sur un port miroir (SPAN) ou derrière un TAP réseau. Un IPS (Intrusion Prevention System) est placé « dans » le flux : chaque paquet le traverse et il peut décider de le laisser passer ou de le rejeter. Le NSM (Network Security Monitoring) désigne enfin la journalisation exhaustive des métadonnées réseau (requêtes DNS, transactions HTTP, poignées de main TLS, flux) indépendamment de toute alerte, afin de pouvoir enquêter après coup.

Suricata sait jouer ces trois rôles avec le même binaire. C’est ce qui le distingue d’outils plus spécialisés : Snort, dont il reprend en grande partie le langage de règles, est historiquement centré sur la détection par signatures, tandis que Zeek privilégie l’analyse comportementale et la production de journaux. Suricata est développé par l’OISF (Open Information Security Foundation), publié sous licence GPLv2, et maintenu en deux branches : 8.0 (actuelle) et 7.0 (maintenance).

Concrètement, Suricata répond à trois questions qu’un pare-feu seul ne traite pas :

• Que se passe-t-il réellement sur mon réseau ? Quels domaines sont résolus, quels certificats TLS sont présentés, quels agents HTTP circulent.
• Une menace connue est-elle présente ? Communication vers un serveur de commande et contrôle, exploitation d’une vulnérabilité, outil d’attaque reconnu.
• Puis-je bloquer automatiquement ce qui est certain ? En mode IPS, une règle drop supprime le paquet avant qu’il n’atteigne sa cible.

2. Architecture interne du moteur

Suricata traite le trafic comme une chaîne de modules spécialisés. Chaque paquet suit le même parcours, que l’on peut représenter ainsi :

Schéma : Capture (AF_PACKET, NFQUEUE, PCAP) → Décodage (Ethernet, IP, TCP/UDP) → Gestion des flux et réassemblage TCP → Analyse applicative (HTTP, DNS, TLS, SMB…) → Moteur de détection (règles) → Sorties (EVE JSON, fast.log, stats).

• Capture : récupération des paquets depuis la carte réseau (AF_PACKET sous Linux), depuis une file NFQUEUE du noyau (mode IPS) ou depuis un fichier PCAP (analyse hors ligne).
• Décodage : lecture des en-têtes de chaque couche et détection des anomalies (paquets malformés, fragments incohérents).
• Flux et réassemblage : les paquets sont regroupés en flux (adresse source, destination, ports, protocole) et le contenu TCP est réassemblé, ce qui empêche un attaquant de dissimuler une charge en la découpant en petits segments.
• Analyse applicative : les parseurs reconnaissent le protocole quel que soit le port utilisé. Un serveur HTTP sur le port 8443 sera analysé comme du HTTP.
• Détection : les règles sont compilées en groupes et un algorithme multi-motifs sélectionne rapidement les règles candidates pour chaque paquet ou transaction.
• Sorties : alertes et métadonnées sont écrites, principalement dans le fichier eve.json.

Le moteur est multithread. La répartition du travail est définie par le runmode : workers (chaque thread fait toute la chaîne pour une partie des flux, le mode le plus performant avec AF_PACKET), autofp (des threads de capture distribuent les flux vers des threads de traitement) et single (un seul thread, utile pour le débogage). Le runmode se règle dans suricata.yaml ou en ligne de commande avec --runmode.

Bonne pratique : la cohérence des flux est essentielle. Avec AF_PACKET, l’option cluster-type: cluster_flow garantit que tous les paquets d’un même flux sont traités par le même thread. Ne la modifiez pas sans raison.

3. Modes de déploiement

Le choix du mode de déploiement conditionne la valeur de la sonde. Trois architectures se rencontrent en entreprise.

IDS passif sur port miroir ou TAP

Le commutateur recopie le trafic d’un ou plusieurs ports (ou d’un VLAN) vers l’interface de la sonde. Suricata n’a aucun impact sur la production : s’il tombe, le réseau continue de fonctionner. C’est le point de départ recommandé. Placez la sonde là où passent les flux intéressants : derrière le pare-feu de sortie Internet pour voir les communications sortantes, devant les serveurs exposés, ou sur le cœur de réseau pour les flux internes (latéralisation).

IPS en ligne

Suricata se trouve sur le chemin des paquets. Sous Linux, deux mécanismes existent : NFQUEUE, où le pare-feu du noyau (iptables ou nftables) confie les paquets à Suricata qui rend un verdict, et AF_PACKET en mode IPS, où Suricata relie deux interfaces comme un pont (copy-mode: ips). Le gain est réel (blocage immédiat), mais le risque aussi : une règle trop large ou un arrêt du processus peut couper le service. Les pare-feu OPNsense et pfSense intègrent d’ailleurs Suricata comme module IPS.

Analyse hors ligne

Avec l’option -r, Suricata lit un fichier PCAP et produit exactement les mêmes journaux qu’en temps réel. C’est l’outil idéal pour analyser une capture fournie lors d’un incident, tester de nouvelles règles sans toucher à la production, ou rejouer un échantillon de trafic après une mise à jour.

À retenir : commencez toujours en IDS. Passez en IPS uniquement après plusieurs semaines d’observation, avec un jeu de règles de blocage réduit et maîtrisé.

4. Installation et organisation des fichiers

Sur Ubuntu, l’OISF publie un dépôt PPA qui suit la branche stable. C’est la méthode indiquée dans le guide de démarrage officiel :

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt update
sudo apt install suricata jq

La commande sudo suricata --build-info affiche la version et les fonctionnalités compilées (NFQUEUE, AF_PACKET, Lua…), et sudo systemctl status suricata l’état du service. Les emplacements à connaître :

• /etc/suricata/suricata.yaml : configuration principale ;
• /etc/suricata/classification.config, reference.config, threshold.config : fichiers annexes ;
• /var/lib/suricata/rules/suricata.rules : règles fusionnées par suricata-update ;
• /var/log/suricata/ : journaux (suricata.log, eve.json, fast.log, stats.log).

Pour le dimensionnement, comptez au minimum 2 vCPU et 4 Go de RAM pour un laboratoire ou un petit site. En production, la mémoire nécessaire croît avec le nombre de règles chargées et le nombre de flux simultanés ; le processeur avec le débit inspecté.

5. Le fichier suricata.yaml

Le fichier /etc/suricata/suricata.yaml est très long, mais quelques sections suffisent pour une sonde fonctionnelle.

Les variables réseau

La section vars définit les groupes d’adresses et de ports utilisés par les règles. La plus importante est HOME_NET : les réseaux que vous protégez. Par défaut, elle contient les trois plages privées RFC 1918, et EXTERNAL_NET vaut « tout sauf HOME_NET » :

vars:
  address-groups:
    HOME_NET: "[192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]"
    EXTERNAL_NET: "!$HOME_NET"

Une valeur trop large ou trop étroite fausse la détection : une règle écrite pour du trafic « de l’extérieur vers HOME_NET » ne se déclenchera jamais si vos serveurs n’y figurent pas. Renseignez vos sous-réseaux réels.

La capture

La section af-packet désigne l’interface surveillée. L’exemple par défaut porte sur eth0 ; remplacez-le par le nom réel de votre interface (affiché par ip addr) :

af-packet:
  - interface: enp0s8
    cluster-id: 99
    cluster-type: cluster_flow
    defrag: yes

Les règles et les sorties

Les clés default-rule-path et rule-files indiquent où trouver les règles (/var/lib/suricata/rules et suricata.rules avec le paquet Ubuntu). La section outputs active le journal EVE et choisit les types d’événements enregistrés (alert, http, dns, tls, flow, stats…). Enfin, threshold-file, commenté par défaut, permet de charger un fichier de seuils et de suppressions.

Avant tout redémarrage, validez la configuration. L’option -T teste le fichier et les règles sans lancer la capture :

sudo suricata -T -c /etc/suricata/suricata.yaml -v

Bonne pratique : versionnez suricata.yaml et vos règles locales (Git ou sauvegarde datée). Une sonde se reconfigure souvent ; pouvoir revenir à la version précédente évite bien des heures de recherche.

6. Anatomie d’une règle

Une règle Suricata se compose de trois parties : l’action, l’en-tête et les options entre parenthèses. Exemple tiré de la documentation officielle :

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"HTTP GET Request Containing Rule in URI"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"rule"; fast_pattern; classtype:bad-unknown; sid:123; rev:1;)

L’action

• alert : génère une alerte ;
• pass : arrête l’inspection du paquet (liste blanche) ;
• drop : supprime le paquet et génère une alerte (mode IPS uniquement) ;
• reject, rejectsrc, rejectdst, rejectboth : envoient un RST TCP ou un ICMP « unreachable » à l’émetteur, au destinataire ou aux deux.

L’ordre d’application par défaut est pass, drop, reject, puis alert : une règle pass l’emporte sur une alerte portant sur le même trafic.

L’en-tête

Il précise le protocole (tcp, udp, icmp, ou un protocole applicatif comme http, dns, tls, ssh, smb…), les adresses et ports source et destination, et le sens : -> pour un sens unique, <> pour les deux sens. Utiliser un protocole applicatif dans l’en-tête permet de détecter un service quel que soit son port.

Les options

• msg : texte de l’alerte ;
• flow : état et sens du flux (established, to_server…) ;
• tampons collants (sticky buffers) : http.uri, http.user_agent, dns.query, tls.sni… Ils sélectionnent la partie du protocole sur laquelle portent les content qui suivent ;
• content : motif recherché, éventuellement suivi de nocase ;
• classtype, reference : classement et références externes ;
• sid : identifiant unique de la règle, et rev : sa révision.

Bonne pratique : réservez une plage de sid à vos règles internes (par exemple à partir de 1000000) pour ne jamais entrer en collision avec les jeux publics, et incrémentez rev à chaque modification.

7. Gérer les jeux de règles avec suricata-update

Écrire toutes ses règles soi-même n’est ni réaliste ni souhaitable. L’outil suricata-update, livré avec Suricata, télécharge les jeux de règles, les fusionne dans /var/lib/suricata/rules/suricata.rules et applique vos personnalisations. Sans configuration, il récupère le jeu gratuit ET Open (Emerging Threats).

sudo suricata-update
sudo suricata-update update-sources
sudo suricata-update list-sources
sudo suricata-update enable-source oisf/trafficid
sudo suricata-update list-enabled-sources

Pour adapter le jeu de règles à votre contexte, deux fichiers sont lus à chaque exécution :

• /etc/suricata/disable.conf : règles à désactiver, par sid, par fichier d’origine (group:) ou par expression régulière (re:) ;
• /etc/suricata/enable.conf : règles désactivées par défaut que vous souhaitez activer, avec la même syntaxe.

Les nouvelles règles sont prises en compte au redémarrage du service, ou à chaud grâce au rechargement :

sudo suricatasc -c reload-rules
sudo kill -USR2 $(pidof suricata)

Automatisez la mise à jour quotidienne (timer systemd ou cron), toujours suivie d’un test de la configuration. Un jeu de règles qui n’est plus mis à jour perd rapidement sa valeur face aux nouvelles campagnes.

8. Les journaux : EVE JSON, fast.log et statistiques

Suricata écrit ses résultats dans /var/log/suricata/. Trois fichiers servent au quotidien :

• suricata.log : journal du moteur lui-même (démarrage, erreurs de configuration, règles invalides). C’est le premier fichier à lire quand quelque chose ne fonctionne pas ;
• fast.log : une ligne par alerte, lisible à l’œil nu, pratique pour un test rapide ;
• eve.json : le journal principal, au format JSON, une ligne par événement.

Chaque ligne d’eve.json possède un champ event_type : alert, http, dns, tls, flow, fileinfo, stats, anomaly… On y retrouve systématiquement l’horodatage, les adresses et ports, le protocole et un identifiant de flux (flow_id) qui relie entre eux tous les événements d’une même connexion. Une alerte peut ainsi être replacée dans son contexte : la requête DNS qui la précède, la transaction HTTP qui l’a provoquée, le volume échangé dans le flux.

L’outil jq permet de filtrer ce journal en ligne de commande :

sudo tail -f /var/log/suricata/eve.json | jq 'select(.event_type=="alert")'
sudo tail -f /var/log/suricata/eve.json | jq 'select(.event_type=="stats")|.stats.capture.kernel_packets'

Le format JSON est aussi ce qui rend Suricata facile à intégrer : un agent de collecte lit le fichier ligne par ligne et l’envoie vers un SIEM ou une plateforme d’analyse, sans analyseur syntaxique spécifique.

Bonne pratique : le journal EVE grossit vite (plusieurs gigaoctets par jour sur un lien chargé avec tous les types activés). Configurez la rotation (logrotate, fourni par le paquet) et désactivez les types d’événements dont vous ne vous servez pas.

9. Réglage fin : réduire les faux positifs

Une sonde fraîchement installée avec ET Open produit inévitablement des alertes sans intérêt pour votre contexte : mises à jour logicielles légitimes, outils d’administration, applications métier au comportement inhabituel. Le travail de réglage (tuning) consiste à garder les alertes qui méritent une action humaine. Quatre leviers existent, du plus ciblé au plus radical.

• Le seuil dans la règle : l’option threshold limite le nombre d’alertes, par exemple threshold: type limit, track by_src, count 1, seconds 60; pour une alerte par source et par minute.
• Le fichier threshold.config : sans modifier la règle, il permet de supprimer une alerte pour une adresse donnée (suppress gen_id 1, sig_id 2002087, track by_src, ip 209.132.180.67) ou d’en limiter la fréquence (threshold gen_id … type limit …). Il faut activer la clé threshold-file dans suricata.yaml.
• La règle pass : elle exclut de l’inspection un trafic de confiance précis, par exemple les sauvegardes entre deux serveurs.
• La désactivation : via disable.conf, pour une règle qui n’a aucun sens dans votre environnement.

Préférez toujours la mesure la plus étroite : supprimer une alerte pour une seule adresse IP plutôt que désactiver la règle pour tout le réseau. Documentez chaque exception (raison, date, auteur) pour pouvoir la réévaluer.

Performances et pertes de paquets

Une sonde qui perd des paquets ne voit pas tout, et c’est silencieux. Surveillez dans stats.log ou dans les événements stats les compteurs capture.kernel_packets et capture.kernel_drops. Si les pertes augmentent : vérifiez le runmode workers, augmentez le nombre de threads, réduisez les règles inutiles et désactivez les déchargements matériels de la carte réseau (GRO, LRO) qui fusionnent les paquets avant que Suricata ne les voie. En analyse hors ligne, l’option -k none désactive la vérification des sommes de contrôle, souvent fausses dans les captures réalisées sur la machine émettrice.

10. Le mode IPS en pratique

En mode NFQUEUE, le pare-feu du noyau envoie les paquets vers une file numérotée (0 par défaut) et Suricata, lancé avec l’option -q 0, rend un verdict pour chacun. Sur une passerelle, on redirige la chaîne FORWARD ; sur un hôte, les chaînes INPUT et OUTPUT :

sudo iptables -I FORWARD -j NFQUEUE
sudo suricata -c /etc/suricata/suricata.yaml -q 0

Point de vigilance majeur : si aucun programme n’écoute la file, le noyau rejette les paquets. Un arrêt de Suricata coupe donc le trafic. Avec nftables, l’option bypass laisse passer les paquets dans ce cas, au prix de la protection. Il faut choisir en connaissance de cause entre disponibilité et sécurité.

Les règles téléchargées utilisent l’action alert : passer en IPS ne bloque donc rien par défaut. Le blocage se construit progressivement : quelques règles drop écrites par vous, ou une sélection de règles publiques converties en drop, après avoir vérifié qu’elles ne produisent aucun faux positif en mode IDS.

11. Intégrer Suricata dans un dispositif de sécurité

Seule, une sonde produit des journaux que personne ne lit. Sa valeur apparaît lorsqu’elle alimente un processus de détection et de réponse.

• Centralisation : le fichier eve.json est envoyé vers un SIEM ou une plateforme de journaux (Wazuh, Graylog, Elastic, OpenSearch). Le champ community_id, activable dans suricata.yaml, facilite la corrélation avec d’autres outils réseau.
• Complémentarité : Zeek excelle dans la production de métadonnées détaillées, Suricata dans la détection par signatures ; de nombreuses équipes les déploient côte à côte sur le même port miroir. Côté hôtes, la télémétrie système (Sysmon, agents EDR) complète la vision réseau.
• Réponse : une alerte fiable peut déclencher un blocage sur le pare-feu, l’isolement d’un poste ou l’ouverture d’un ticket.

Prioriser les alertes

Toutes les alertes ne se valent pas. Chaque règle porte une classtype associée à une priorité (de 1, la plus grave, à 4) définie dans classification.config. Pour un premier tri, concentrez-vous sur les alertes de priorité 1 et 2 qui concernent vos serveurs exposés et vos postes d’administration, puis sur les communications sortantes vers des destinations classées malveillantes. Une alerte isolée sur un poste utilisateur mérite une vérification ; la même alerte répétée sur plusieurs postes en quelques minutes signale un incident à traiter sans attendre. Enrichissez enfin chaque alerte avec le contexte disponible : nom de la machine, utilisateur connecté, criticité de l’actif. C’est ce contexte, bien plus que la signature elle-même, qui permet de décider rapidement entre fausse alerte, comportement à surveiller et incident avéré.

Check-list d’exploitation

1. HOME_NET renseigné avec les sous-réseaux réels.
2. Mise à jour quotidienne des règles, suivie d’un test -T et d’un rechargement.
3. Surveillance des pertes de paquets et de l’espace disque.
4. Revue hebdomadaire des alertes les plus fréquentes et ajustement des exceptions.
5. Mises à jour de Suricata appliquées rapidement : les versions correctives de la branche 8.0 corrigent régulièrement des vulnérabilités du moteur lui-même.
6. Procédure écrite pour le traitement d’une alerte critique.

12. Synthèse

Suricata transforme le trafic réseau en informations exploitables : alertes sur des menaces connues, métadonnées pour l’investigation, et, lorsque le contexte s’y prête, blocage automatique. Sa mise en œuvre repose sur quelques choix structurants (emplacement de la sonde, mode IDS ou IPS, HOME_NET, jeux de règles) et sur un travail continu de réglage. Les huit travaux pratiques qui suivent vous font parcourir ce cycle complet dans un laboratoire : installation, configuration, gestion des règles, écriture de signatures, analyse des journaux et des captures, réduction du bruit, puis blocage en ligne.

Pour aller plus loin sur le blog : Suricata : anatomie complète d’un moteur open source de détection et de prévention des intrusions réseau · CrowdSec : l’IPS collaboratif et open source qui mutualise la défense des serveurs