Configurer Suricata sur un segment réseau critique

Un système de détection d’intrusion réseau, ou IDS (Intrusion Detection System), ne se place pas au hasard sur un commutateur et ne devient pas exploitable parce qu’un tableau de bord affiche beaucoup de rouge. La décision structurante est le mode de placement : démarrer en écoute passive pour observer le trafic réel, puis n’envisager le blocage qu’après validation des règles, des flux métier et de la capacité de reprise.

→ Lire l’explication complète de la marmotte

Positionnement de la sonde Suricata

Le compromis est brutal : une sonde passive ne bloque rien mais ne peut pas casser le service ; une sonde en coupure peut arrêter une attaque mais devient elle-même un composant critique du chemin réseau. La recommandation est de déployer Suricata en passif sur tout nouveau segment, pendant une période d’observation couvrant les cycles métier habituels, puis de limiter le blocage à des signatures testées et à des périmètres étroits.

En écoute passive, raccorder la sonde à un TAP (Test Access Port), matériel qui duplique électriquement ou optiquement un lien, ou à un port miroir du commutateur, aussi appelé SPAN (Switched Port Analyzer). Préférer le TAP sur un segment critique : un port miroir peut perdre des paquets lors d’une saturation, masquer certains paquets selon le matériel et dépend d’une configuration d’administration qui peut disparaître après un remplacement de commutateur. La magie réseau finit souvent dans une sauvegarde de configuration oubliée.

Le port miroir doit recopier les deux directions du flux. Un miroir unidirectionnel dégrade la reconstruction des sessions TCP (Transmission Control Protocol), fausse les détections applicatives et produit des alertes dont la moitié du contexte manque. Désactiver toute adresse IP sur l’interface de capture : une sonde passive ne doit ni répondre aux paquets ARP (Address Resolution Protocol), ni devenir une cible administrable depuis le segment observé.

Le mode IPS (Intrusion Prevention System), donc en coupure, repose généralement sur NFQUEUE (Netfilter Queue), mécanisme du noyau Linux qui remet les paquets à Suricata avant décision. Il impose deux interfaces, une politique de contournement documentée et des tests de défaillance. Configurer bypass revient à privilégier la disponibilité si Suricata tombe ; configurer un rejet par défaut privilégie le confinement. Pour un système sensible exposé à Internet, le choix dépend de la tolérance métier à une interruption. Pour un segment interne critique, le passif est la position initiale défendable.

Suricata ne détecte pas ce qu’il ne voit pas : trafic chiffré, contournement par un chemin non miré, paquets perdus, trafic encapsulé non décodé. Il ne remplace ni la segmentation réseau, ni le durcissement des services, ni les journaux applicatifs. Voir une attaque et l’empêcher sont deux capacités distinctes, même si les slides de vendeurs aiment les fusionner dans une bulle violette.

Installation et prérequis de capture réseau

Prévoir une machine dédiée sous Debian 12 ou Ubuntu 24.04 LTS, un stockage local dimensionné pour les journaux, une synchronisation horaire via NTP (Network Time Protocol) et une interface de gestion séparée de l’interface de capture. Suricata 7 est le seuil raisonnable : les versions anciennes privent de correctifs de décodeurs et compliquent les règles modernes.

La carte réseau de capture doit accepter le mode promiscuité et disposer de pilotes stables. Désactiver les mécanismes d’agrégation qui brouillent l’analyse sur l’interface surveillée : GRO (Generic Receive Offload), LRO (Large Receive Offload) et TSO (TCP Segmentation Offload). Ces optimisations sont très bien pour transporter du trafic, moins pour observer fidèlement les paquets avant leur transformation par le noyau.

Installer Suricata et les outils de gestion de règles, puis vérifier la version.

# Installer le moteur et l'outil de téléchargement des règles
sudo apt update
sudo apt install -y suricata suricata-update ethtool

# Vérifier que Suricata est disponible
suricata --build-info | sed -n '1,20p'

# Préparer l'interface passive eno2 : aucune adresse IP, promiscuité et offloads coupés
sudo ip link set dev eno2 down
sudo ip addr flush dev eno2
sudo ethtool -K eno2 gro off lro off tso off gso off
sudo ip link set dev eno2 promisc on up

Déclarer les réseaux protégés dans /etc/suricata/suricata.yaml. La variable HOME_NET ne doit jamais rester à any sur une sonde de production : cela inverse des directions de règles, gonfle les alertes et détruit une partie du contexte. Définir les préfixes réellement observés, par exemple "[10.42.16.0/20]".
Configurer la capture AF_PACKET (Address Family Packet), interface Linux de capture à haut débit, dans la section af-packet. Déclarer une seule interface passive et activer la détection de pertes. Une perte de paquets n’est pas un détail de performance : elle constitue un angle mort mesurable.

af-packet:
  - interface: eno2
    cluster-id: 99
    cluster-type: cluster_flow
    defrag: yes
    use-mmap: yes
    tpacket-v3: yes

Tester la syntaxe avant tout redémarrage :

# Valider la configuration et les règles sans lancer le service
sudo suricata -T -c /etc/suricata/suricata.yaml -v

Un test de syntaxe valide des fichiers, pas une architecture. Vérifier aussi que l’interface reçoit effectivement les deux sens du trafic avec tcpdump -ni eno2, depuis une session d’administration distincte.

Pour approfondir la topologie de collecte et les limites des captures, consulter les pratiques réseau et l’architecture cybersécurité.

Jeux de règles ET Open et réduction du bruit

ET Open, pour Emerging Threats Open, fournit un corpus de signatures maintenu publiquement. Il constitue un point de départ, pas une politique de détection prête à exploiter. Activer toutes les catégories sans qualification transforme le journal en décharge industrielle où les alertes exploitables enterrent les erreurs de configuration, les scanners autorisés et les faux positifs applicatifs.

Télécharger le jeu de règles, puis examiner les sources activées.

# Mettre à jour ET Open et reconstruire le fichier de règles actif
sudo suricata-update

# Vérifier les fichiers générés avant activation
sudo ls -lh /var/lib/suricata/rules/
sudo grep -n "default-rule-path\|rule-files" /etc/suricata/suricata.yaml

Suricata désactive des règles par identifiant de signature, ou SID (Signature ID), via /etc/suricata/disable.conf. Désactiver une catégorie entière seulement après inventaire des protocoles et des services absents. Par exemple, une infrastructure sans SMB (Server Message Block) peut écarter les signatures SMB, mais seulement si aucun flux SMB n’arrive par un tunnel, une zone d’administration ou un serveur de sauvegarde. L’absence déclarée n’est pas une preuve réseau.

Ajuster les seuils avant de désactiver une signature à forte valeur. Le mécanisme threshold limite le nombre d’alertes par source, destination ou règle ; il ne réduit pas l’attaque, seulement son bruit dans les journaux. Conserver au moins une alerte par intervalle pour les tentatives répétées, faute de quoi un balayage lent devient invisible sous prétexte de confort opérationnel.

Activer le journal eve.json, format JSON (JavaScript Object Notation) structuré, et l’expédier vers la plateforme de supervision déjà en place. Surveiller trois métriques : pertes de paquets, débit d’alertes par signature et taux de détection sans événement associé dans les journaux du système ciblé. Une signature sans corroboration mérite une enquête ; une signature ignorée parce qu’elle est fréquente mérite une correction, pas une habitude.

Première règle Suricata ciblant un système sensible

La première règle personnalisée doit surveiller un accès que l’organisation interdit explicitement, vers une ressource identifiée. Choisir un signal réseau vérifiable : tentative SSH (Secure Shell) vers un bastion d’administration depuis un réseau utilisateur, accès HTTP (Hypertext Transfer Protocol) à une console sensible, ou résolution DNS (Domain Name System) d’un nom interne réservé.

L’exemple suivant alerte sur une connexion SSH depuis le réseau utilisateur 10.42.16.0/20 vers le bastion 10.42.20.10. La règle ne prétend pas détecter une compromission : elle signale une violation de trajectoire réseau. La séparation effective doit venir des listes de contrôle réseau et de l’authentification, pas d’une alerte qui arrivera après le paquet.

Créer /etc/suricata/rules/local.rules, puis référencer ce fichier dans rule-files de suricata.yaml.

# Alerter sur toute tentative TCP vers SSH du réseau utilisateur vers le bastion
alert tcp 10.42.16.0/20 any -> 10.42.20.10 22 (
    msg:"POLICY SSH vers bastion depuis reseau utilisateur";
    flow:to_server,established;
    sid:1000001;
    rev:1;
    classtype:policy-violation;
)

Le sid doit appartenir à une plage réservée localement et être unique. La révision rev augmente à chaque modification fonctionnelle : sans cette discipline, corréler un changement de règle avec une variation d’alerte devient une séance de spiritisme avec des fichiers texte.

Valider la règle, redémarrer le service et produire un trafic contrôlé depuis une machine du réseau source.

# Tester la configuration, puis relancer Suricata
sudo suricata -T -c /etc/suricata/suricata.yaml
sudo systemctl restart suricata

# Depuis une machine 10.42.16.0/20 autorisée au test uniquement
nc -vz -w 2 10.42.20.10 22

# Vérifier l'alerte locale
sudo jq 'select(.alert.signature_id == 1000001)' /var/log/suricata/eve.json

Le test doit confirmer l’alerte, son adresse source, sa destination et son horodatage. Si aucune alerte n’apparaît, vérifier dans cet ordre : le trafic traverse-t-il réellement le lien capturé, les deux directions sont-elles visibles, la règle est-elle chargée, le flux atteint-il l’état established ? Ne pas assouplir la règle au hasard. Une règle qui alerte sur tout finit toujours par alerter sur rien.

Exploitation, secrets et reprise de la sonde

Protéger les accès d’administration, les identifiants d’expédition des journaux et les certificats de transport. Une sonde compromise révèle la cartographie réseau, les métadonnées de sessions et parfois des extraits de charges utiles. Chiffrer les journaux en transit, restreindre les droits de lecture sur /var/log/suricata et faire tourner les secrets d’agent selon une procédure testée.

Sauvegarder suricata.yaml, les règles locales, les fichiers d’activation et de désactivation, ainsi que la configuration du port miroir ou du TAP. La restauration d’une machine sans ces éléments recrée un capteur, pas le dispositif de détection. Tester périodiquement la reprise sur une machine distincte et rejouer le trafic de validation.

Définir un runbook par alerte prioritaire : propriétaire du système cible, source de confirmation, décision de confinement et délai d’escalade. Une alerte sans responsable finit dans un index de recherche, où elle mène une existence calme et parfaitement inutile. Les guides pratiques et les pages consacrées aux menaces complètent cette partie opérationnelle.

🐝 Ce qui arrive si on s’en passe

Sans sonde sur le segment, il ne reste que les journaux des machines, c’est-à-dire des traces stockées sur les systèmes que l’attaquant contrôle une fois entré et qu’il peut tronquer ou effacer. Aucune source indépendante ne permet alors de corroborer une connexion, de dater un premier accès ni de délimiter la portée d’un incident. Les mouvements latéraux entre hôtes internes, les balayages lents et les rappels périodiques vers un serveur de commande ne laissent aucune trace exploitable, puisque ces flux ne traversent pas nécessairement un équipement qui journalise. Les violations de trajectoire réseau, comme un accès d’administration depuis une zone utilisateur, restent invisibles tant qu’elles aboutissent. La détection se déplace vers des signaux tardifs : une facture d’hébergement, un correspondant externe, un service indisponible. La reconstruction après coup devient une hypothèse plutôt qu’une chronologie.

🦫 Explication de la marmotte 🍫

Le dispositif est placé à un endroit où il peut observer les échanges entre des machines. Il peut recevoir une copie des communications sans les modifier, ou être installé directement sur leur passage pour pouvoir les arrêter. Le premier choix évite de provoquer une panne mais ne bloque pas une attaque. Le second permet de bloquer, mais une erreur de réglage ou une panne du dispositif peut empêcher des communications normales.

Le logiciel reçoit les paquets réseau, les remet dans l’ordre quand cela est possible et cherche des signes définis dans des fichiers de règles. Ces signes peuvent viser une technique d’attaque connue ou une interdiction locale, par exemple une connexion vers une machine d’administration depuis un réseau qui ne doit pas y accéder. Les règles publiques fournissent beaucoup de détections déjà écrites, mais elles produisent aussi des alertes inutiles si elles ne correspondent pas aux services réellement présents.

Avant de faire confiance aux alertes, il faut tester que la machine voit bien les communications dans les deux sens. Ensuite, un trafic volontairement généré doit déclencher la règle locale attendue. Si ce test échoue, le problème peut venir du mauvais emplacement, d’une copie incomplète du trafic, d’une règle non chargée ou d’une condition trop stricte. Les journaux doivent être protégés, surveillés et sauvegardés, car ils servent à comprendre ce qui s’est passé après une alerte.

Pages voisines

La citent

Configurer Suricata sur un segment réseau critique

Elle cite

Configurer Suricata sur un segment réseau critique

Configurer Suricata sur un segment réseau critique

Positionnement de la sonde Suricata

Installation et prérequis de capture réseau

Jeux de règles ET Open et réduction du bruit

Première règle Suricata ciblant un système sensible

Exploitation, secrets et reprise de la sonde

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines