Le réseau est stable, la chaîne d'analyse attend. C'est le moment d'installer le capteur — et de découvrir qu'un IDS, contrairement à ce qu'on imagine, se configure en trois lignes mais s'exploite pendant des semaines.
Installation et choix de l'interface
La séquence complète : installer, désigner l'interface, mettre à jour les règles, tester — puis démarrer.
Le paquet est disponible dans les dépôts de la distribution. Une fois installé, la seule décision réellement structurante est quelle interface écouter :
af-packet:
- interface: enp2s0 # l'interface LAN, côté utilisateurs
cluster-id: 99
cluster-type: cluster_flow
defrag: yes
C'est l'interface interne qui est choisie, et non l'externe. La différence est importante : côté interne, on voit les adresses réelles des machines, avant la traduction d'adresses opérée par la passerelle. Côté externe, tout le trafic semblerait provenir de la passerelle elle-même — et l'on perdrait la réponse à la question la plus utile : quelle machine du réseau a fait ça ?
Le mode de répartition retenu garantit par ailleurs que les deux sens d'une même conversation sont traités par le même fil d'exécution — condition nécessaire pour que le moteur puisse reconstruire les échanges.
Les règles
suricata-update
Une commande, qui récupère et compile les jeux de règles publics. Par défaut, cela signifie plusieurs dizaines de milliers de signatures — largement de quoi commencer, et largement de quoi produire du bruit. L'ajustement viendra après observation : c'est précisément ce qu'on vient apprendre.
Tester avant de démarrer
suricata -T -c /etc/suricata/suricata.yaml -i enp2s0 i: suricata: Configuration provided was successfully loaded. Exiting.
Ce mode charge la configuration et l'ensemble des règles, puis s'arrête. Cinq secondes qui évitent un service qui refuse de démarrer — sur une passerelle de production, la nuance compte.
Ce que produit le moteur, dès la première minute
tail -f /var/log/suricata/eve.json
Le fichier se remplit immédiatement, et l'on découvre alors la vraie nature de l'outil : l'essentiel de ce qui sort n'est pas des alertes. Ce sont des transactions DNS, des requêtes HTTP, des connexions TLS, des résumés de flux — et des statistiques du moteur lui-même.
Cette matière est plus précieuse que les alertes. Le jour d'un incident, la question « quelles machines ont contacté ce domaine, et depuis quand ? » se répond grâce à ces événements de routine, pas grâce à une signature qui se serait déclenchée.
Le compteur qu'il faut regarder
Parmi les événements de statistiques figure un chiffre à surveiller : les paquets perdus par le noyau. Un moteur saturé — trop de trafic, trop de règles, pas assez de processeur — cesse silencieusement d'analyser une partie du trafic. Aucune alerte ne le signale, et l'on croit voir tout ce qui passe alors qu'on en rate une part.
Sur un lab, ce compteur reste à zéro. Sur un réseau réel, c'est l'un des premiers indicateurs à mettre sous supervision — au même titre que l'espace disque.
À ce stade, le lab est en mode détection
Le moteur observe, écrit, et ne bloque rien. C'est volontaire, et c'est l'état dans lequel il faut rester le temps de comprendre le trafic du réseau : quelles alertes reviennent tous les jours ? Lesquelles correspondent à un comportement applicatif légitime ? Lesquelles seraient réellement graves ?
Le passage en mode prévention viendra ensuite, règle par règle. Le faire trop tôt, c'est se garantir un incident de production et une confiance perdue dans l'outil.
La série « détection réseau »
Cinq articles pour comprendre, cinq pour construire :
- Qu'est-ce qu'un IDS ?
- Qu'est-ce qu'un IPS ?
- Suricata, le moteur
- OpenSearch, le socle analytique
- Détection réseau et NIS2 : la logique de sécurité
- Lab (1) : architecture et passerelle
- Lab (2) : OpenSearch et Grafana
- Lab (3) : Suricata en mode IDS — vous y êtes
- Lab (4) : la chaîne d'ingestion
- Lab (5) : les tableaux de bord