NIDS pour PME : détecter les attaques réseau avec Suricata et Snort

Un RSSI de PME a en général un EDR sur ses postes et serveurs. Il détecte l'exécution d'un binaire malveillant, une injection en mémoire, une commande PowerShell suspecte. Ce qu'il ne voit pas, structurellement, c'est ce qui transite entre les machines avant, pendant et après l'exécution : le C2 qui balise vers l'extérieur, le scan de partage SMB depuis un poste compromis, l'exploitation d'une vulnérabilité réseau contre un service qui n'a pas encore livré de code malveillant à un agent. C'est le rôle d'un NIDS (Network Intrusion Detection System) comme Suricata ou Snort : observer le trafic, pas les processus. La détection intrusion réseau NIDS n'est pas un doublon de l'EDR, c'est un angle mort qu'il ne couvre pas.

Où se place un NIDS : passif ou en coupure

Deux façons de brancher un moteur comme Suricata, avec des implications très différentes.

En passif, sur un SPAN/TAP. Le switch ou un TAP physique duplique le trafic vers le capteur, qui observe une copie sans jamais toucher au flux original. Aucune latence ajoutée, aucun risque de casser la production si le moteur tombe. C'est le mode de départ pour une PME : on installe, on observe, on affine les règles pendant des semaines sans aucun risque de faux positif métier. L'inconvénient : en mode passif, on détecte, on n'empêche rien. L'alerte part vers le SIEM, un humain ou un playbook agit ensuite.

En coupure (inline), en mode IPS. Le trafic traverse physiquement le moteur, qui peut alors dropper un paquet ou couper une connexion en temps réel. C'est plus puissant, mais ça change la nature du risque : une règle mal calibrée en IPS peut couper un flux métier légitime, pas juste générer une alerte bruyante. Pour une PME qui découvre le NIDS, la séquence recommandée est presque toujours : passif d'abord, IPS ensuite, et seulement sur un sous-ensemble de règles dont on a validé le très faible taux de faux positifs.

Dans les deux cas, ce que le moteur voit et que l'endpoint ne voit pas se résume à trois catégories : le C2 beaconing (connexions périodiques vers un domaine ou une IP suspecte, souvent avant même que l'implant n'agisse localement), le mouvement latéral (SMB, RDP, WinRM entre machines qui ne communiquent jamais habituellement), et l'exploit réseau pré-exécution (une charge malveillante qui transite dans une requête HTTP ou un paquet SMB avant même d'atteindre un process sur l'hôte). Ce dernier point est important : un NIDS peut bloquer une attaque avant qu'elle ne devienne un événement pour l'EDR.

Anatomie d'une règle Suricata

Prenons un exemple représentatif, une tentative d'exploitation contre un service SMB exposé :

alert tcp any any -> $HOME_NET 445 (
    msg:"POSSIBLE SMBv1 Exploit Attempt - Anomalous Trans2 Request";
    flow:established,to_server;
    content:"|FF|SMB"; offset:4; depth:4;
    content:"|32 00|"; distance:1; within:2;
    pcre:"/^.{8}\x00{4}/R";
    classtype:attempted-admin;
    sid:2100657; rev:3;
    metadata:attack_target Server, deployment Perimeter, signature_severity Major, created_at 2011_06_14, updated_at 2024_03_02;
)

(Exemple illustratif : la structure prime sur le CVE précis.) Chaque bloc a un rôle précis :

• Le header (alert tcp any any -> $HOME_NET 445) définit l'action, le protocole, la source, la destination. Ici : n'importe quelle source, vers n'importe quel port source, vers le réseau interne ($HOME_NET, une variable définie dans suricata.yaml), sur le port SMB.
• flow:established,to_server exige une connexion TCP déjà établie et un paquet allant du client vers le serveur. Sans cette ligne, la règle évaluerait aussi les paquets SYN et les réponses serveur, ce qui double le volume évalué pour rien.
• content et pcre sont le cœur de la signature : ils cherchent un motif d'octets précis (l'en-tête SMB, un code de commande) puis affinent avec une expression régulière sur la structure du paquet.
• classtype classe la règle dans une famille de sévérité (attempted-admin, trojan-activity, attempted-recon...), utilisée ensuite pour prioriser.
• sid et rev identifient la règle de façon unique et versionnée : un sid ne se réutilise jamais, une rev s'incrémente à chaque correction.
• metadata porte le contexte exploitable : cible, sévérité, dates de création et de mise à jour. C'est ce qui permet de trier et corréler après coup, exactement comme la classification CVE dans un template de scan de vulnérabilités.

Sources de règles : acheter, construire ou s'abonner

Trois options s'offrent à une PME, avec des compromis très différents.

ET Open (Emerging Threats Open), gratuit, est le socle historique de la communauté Suricata. Volume important, mise à jour active, mais un taux de faux positifs significatif sur certaines catégories quand le flux est déployé tel quel, sans tri ni tuning local. C'est un excellent point de départ, un mauvais point d'arrivée pour une équipe qui n'a pas le temps de trier des centaines d'alertes par semaine.

ET Pro, payant, resserre une partie de ce bruit et ajoute une couverture plus rapide sur les menaces émergentes. Le compromis reste financier et suppose une équipe capable d'absorber le flux et d'ajuster.

Talos (Snort) publie un jeu de règles maintenu par l'équipe de recherche de Cisco, avec un accès communautaire décalé dans le temps par rapport à l'accès abonné.

Les règles maison packagées répondent à un besoin différent : un pack curé, testé sur un moteur réel contre un trafic bénin et une cible patchée, avec un taux de faux positifs mesuré avant livraison plutôt que découvert en production. La logique buy vs build vs subscribe se résume ainsi : construire tout en interne coûte un temps d'ingénierie que peu de PME ont ; s'abonner à un flux brut non trié déplace le coût vers le triage quotidien des alertes ; un pack curé absorbe ce travail de tri en amont, une fois, pour tout le monde.

Le piège fondateur : la règle trop large

L'erreur la plus commune, et la plus coûteuse en confiance, est une règle qui matche sur un port sans contenu ni état de connexion :

# Mauvais : une tempête d'alertes garantie
alert tcp any any -> $HOME_NET 445 (msg:"SMB traffic"; sid:9000001; rev:1;)

Cette règle déclenche sur tout paquet TCP vers le port 445, y compris le trafic SMB légitime de tous les jours. Résultat : des milliers d'alertes identiques, noyant les vraies anomalies dans le bruit, jusqu'à ce que l'équipe désactive purement et simplement la règle, ou pire, toute la catégorie. Le principe de spécificité est simple : plus une règle exige de conditions concordantes (flow:established, un content précis, une taille de paquet, une séquence d'octets), moins elle déclenche à tort. Une règle sans content ni flow n'est pas une détection, c'est un compteur de trafic déguisé en alerte.

Prioriser et router vers le SIEM

Une fois les règles en place, tout ne mérite pas le même traitement. Le classtype et le champ priority (qui peut être surchargé par règle) permettent de router : une alerte trojan-activity en priorité 1 remonte immédiatement vers l'équipe SOC ou le playbook automatisé, une alerte attempted-recon en priorité 3 s'agrège en tendance hebdomadaire dans le SIEM.

C'est précisément là que la différence se joue entre un flux ET Open collé tel quel et un pack curé à faible taux de faux positifs : le premier oblige l'équipe à faire elle-même ce travail de tri, règle par règle, semaine après semaine ; le second arrive déjà classé, déjà testé contre un corpus de trafic bénin, avec une priorisation qui reflète l'exploitation réelle plutôt que la sévérité théorique du CVE.

En résumé

Un NIDS ne remplace pas un EDR, il couvre ce que l'EDR ne voit structurellement pas : le C2 avant l'exécution, le mouvement latéral entre machines, l'exploit réseau au moment où il transite. La qualité d'un déploiement Suricata ou Snort ne se joue pas sur le volume de règles chargées, mais sur leur spécificité et leur taux de faux positifs mesuré, pas supposé.

C'est exactement ce que livre le pack de règles NIDS ThreatClaw : des signatures Suricata prêtes à l'emploi, testées sur le moteur réel contre du trafic bénin et des cibles patchées, priorisées par classtype et sévérité réelle, pour détecter sans noyer votre équipe sous les faux positifs.