Détection réseau avec Suricata et Snort

1 Introduction

2 Anatomie d'une règle

Une règle comporte deux parties. L'en-tête indique quel trafic est concerné :

alert  http  $HOME_NET any  ->  $EXTERNAL_NET any  ( options... )
  |      |        |      |   |        |       |
action proto  src IP  src  dir    dst IP   dst port
                     port

Les options, entre parenthèses, disent quoi chercher et comment le signaler. Chaque option se termine par un point-virgule. Voici une règle complète, puis le rôle de chaque mot-clé :

local.rules

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"MLAB DEMO Suspicious User-Agent mlab-demo-bot"; flow:established,to_server; http.user_agent; content:"mlab-demo-bot"; nocase; classtype:trojan-activity; sid:1000002; rev:1;)

Options de signalement

Options de détection

3 Exemples guidés

Toutes les règles ci-dessous se chargent dans Suricata 8 et utilisent des indicateurs fictifs : evil-update.example utilise le TLD réservé .example, et 203.0.113.0/24 est une plage réservée à la documentation.

Étape 1 : l'en-tête et le strict minimum

Les requêtes ICMP echo (ping, itype:8) qui atteignent votre réseau. Inutile en production, idéal pour vérifier que votre installation produit bien des alertes.

alert icmp any any -> $HOME_NET any (msg:"MLAB DEMO ICMP echo request to home net"; itype:8; classtype:misc-activity; sid:1000001; rev:1;)

Étape 2 : transformer des IOC réseau en règles

Un rapport de menace cite un domaine de C2. On le détecte dans les requêtes DNS et dans le Server Name Indication TLS, qui reste visible même en HTTPS. endswith couvre aussi les sous-domaines comme cdn.evil-update.example.

alert dns $HOME_NET any -> any any (msg:"MLAB DEMO DNS query for evil-update.example"; dns.query; content:"evil-update.example"; nocase; endswith; classtype:bad-unknown; sid:1000003; rev:1;)

alert tls $HOME_NET any -> $EXTERNAL_NET any (msg:"MLAB DEMO TLS SNI for evil-update.example"; flow:established,to_server; tls.sni; content:"evil-update.example"; nocase; endswith; classtype:bad-unknown; sid:1000005; rev:1;)

Étape 3 : une règle réaliste de beacon C2

Notre malware fictif envoie POST /gate.php?id= suivi de 16 caractères hexadécimaux, sans en-tête Referer (un vrai navigateur en envoie presque toujours un quand on suit un lien). Une règle longue peut s'écrire sur plusieurs lignes grâce à un \ final :

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"MLAB DEMO Beacon to fake gate.php panel"; \
    flow:established,to_server; \
    http.method; content:"POST"; \
    http.uri; content:"/gate.php?id="; startswith; fast_pattern; \
    pcre:"/^\/gate\.php\?id=[0-9a-f]{16}$/"; \
    http.header_names; content:!"Referer"; \
    threshold:type limit, track by_src, count 1, seconds 3600; \
    reference:url,academy.mlab.sh/page/suricata-snort-rules; \
    classtype:trojan-activity; \
    metadata:mitre_tactic_id TA0011, mitre_technique_id T1071.001, created_at 2026_10_21; \
    sid:1000004; rev:2;)

Étape 4 : compter les événements (force brute)

Un SYN isolé vers le port 22 est normal ; plus de 20 en une minute depuis la même source externe ressemble à une attaque par force brute SSH ou à un scan. flags:S,12; correspond à un SYN pur en ignorant les deux bits ECN.

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"MLAB DEMO Possible SSH brute force"; flow:to_server; flags:S,12; detection_filter:track by_src, count 20, seconds 60; classtype:attempted-admin; sid:1000007; rev:1;)

Étape 5 : inspecter les fichiers téléchargés

Le buffer file.data contient le corps des réponses HTTP (décompressé et réassemblé). Cette règle se déclenche quand un exécutable Windows (en-tête MZ) est téléchargé en HTTP clair, une alerte de politique classique. Suricata peut aussi extraire ces fichiers et calculer leurs hash, prêts à partir en sandbox.

alert http any any -> any any (msg:"MLAB DEMO file download with EXE magic"; flow:established,to_client; file.data; content:"MZ"; startswith; classtype:policy-violation; sid:1000008; rev:1;)

4 Tests et outils

Valider, puis rejouer une capture

Ne poussez jamais une règle sur une sonde sans ces deux étapes. La sortie ci-dessous est réelle : la capture de démonstration contient la requête de beacon de l'étape 3.

# 1. Vérification de syntaxe : charge la config + vos règles, puis quitte
$ suricata -T -c /etc/suricata/suricata.yaml -S local.rules -v
...
Info: detect: 1 rule files processed. 8 rules successfully loaded, 0 rules failed, 0 rules skipped
Notice: suricata: Configuration provided was successfully loaded. Exiting.

# 2. Rejouer une capture à travers les règles (-k none : ignorer les checksums faux des pcap)
$ suricata -r demo.pcap -S local.rules -k none -l ./out
$ cat ./out/fast.log
10/21/2026-12:02:41.519555  [**] [1:1000002:1] MLAB DEMO Suspicious User-Agent mlab-demo-bot [**] [Classification: A Network Trojan was detected] [Priority: 1] {TCP} 192.168.1.50:49152 -> 203.0.113.10:80
10/21/2026-12:02:41.519555  [**] [1:1000004:2] MLAB DEMO Beacon to fake gate.php panel [**] [Classification: A Network Trojan was detected] [Priority: 1] {TCP} 192.168.1.50:49152 -> 203.0.113.10:80
10/21/2026-12:02:41.519555  [**] [1:1000006:1] MLAB DEMO legacy-style URI match [**] [Classification: A Network Trojan was detected] [Priority: 1] {TCP} 192.168.1.50:49152 -> 203.0.113.10:80

# 3. Les mêmes alertes, avec tout leur contexte, en JSON
$ jq 'select(.event_type=="alert") | .alert.signature' ./out/eve.json

Une seule erreur de syntaxe (ici, un ; oublié après le content) et Suricata ignore la règle. En mode test, il indique précisément la ligne fautive :

E: detect: error parsing signature "alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"MLAB DEMO broken"; http.uri; content:"/gate.php" sid:1000010; rev:1;)" from file local.rules at line 1

Pour fabriquer des captures de test, enregistrez votre propre trafic avec tcpdump -w test.pcap en reproduisant le comportement dans un labo, ou utilisez des collections publiques comme malware-traffic-analysis.net (à manipuler comme du malware actif).

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

# Télécharger et fusionner Emerging Threats Open (la source par défaut)
$ sudo suricata-update

# Lister et activer d'autres sources gratuites
$ sudo suricata-update list-sources
$ sudo suricata-update enable-source tgreen/hunting
$ sudo suricata-update

# Désactiver une règle bruyante par son SID : l'ajouter à /etc/suricata/disable.conf, puis relancer
$ echo "1000001" | sudo tee -a /etc/suricata/disable.conf

Snort et Suricata : même famille, dialectes différents

Dans la syntaxe classique héritée de Snort 2, le buffer est un modificateur écrit après le content. Suricata l'accepte toujours (cette règle se charge et s'est déclenchée dans le test ci-dessus) :

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"MLAB DEMO legacy-style URI match"; flow:established,to_server; content:"/gate.php"; http_uri; classtype:trojan-activity; sid:1000006; rev:1;)

Suricata privilégie désormais les sticky buffers à point, placés avant le content (http.uri; content:"...";). Snort 3 utilise lui aussi des sticky buffers, mais avec ses propres noms (http_uri;) et des modificateurs de content séparés par des virgules dans la même option :

alert http $HOME_NET any -> $EXTERNAL_NET any ( msg:"MLAB DEMO gate.php request"; flow:established,to_server; http_uri; content:"/gate.php?id=",nocase; classtype:trojan-activity; sid:1000009; rev:1; )

Testez les règles Snort 3 avec snort -c /usr/local/etc/snort/snort.lua -R local.rules -T. Beaucoup de mots-clés applicatifs (dns.query, tls.sni, file.data avec un point) n'existent que dans Suricata : validez toujours une règle sur le moteur qui l'exécutera.

5 Pièges courants

Conseils de performance

Une sonde inspecte chaque paquet en temps réel : une règle lente, ce sont des paquets perdus, et des paquets perdus, ce sont des attaques manquées. Le moteur effectue d'abord une recherche multi-motifs rapide sur un seul content par règle, et n'évalue le reste de la règle que sur les candidats.

6 Aller plus loin

Les règles de la communauté

Relier les points

Les journaux EVE JSON de Suricata (les alertes, mais aussi chaque requête DNS, requête HTTP et négociation TLS) alimentent parfaitement un SIEM, où des règles Sigma peuvent les corréler avec les événements des postes. Étiquetez vos règles avec les techniques MITRE ATT&CK dans metadata, nourrissez-les avec les indicateurs reçus via STIX/TAXII, et servez-vous du trafic de C2 observé en sandbox pour écrire des règles comportementales qui survivront à n'importe quel domaine suspect.