IDS et IPS : détecter et bloquer les intrusions

Un IDS (Intrusion Detection System, système de détection d'intrusion) analyse le trafic réseau ou l'activité d'une machine et lève une alerte quand il reconnaît une attaque ; un IPS (Intrusion Prevention System) fait la même analyse mais bloque en plus le trafic malveillant. Ce chapitre explique les deux modes, les méthodes de détection et leurs erreurs (faux positifs, faux négatifs), le fonctionnement de Suricata et de ses règles, la lecture d'une alerte et la façon de traiter un blocage injustifié, comme dans le sujet E7 SISR 2026.

IDS ou IPS

Un IPS en panne doit-il laisser passer le trafic (fail-open, la disponibilité d'abord) ou tout bloquer (fail-closed, la sécurité d'abord) ? Le choix dépend de ce que l'organisation peut le moins supporter, et doit être documenté.

On distingue aussi :

• le NIDS (network IDS), qui analyse le trafic réseau : Suricata, Snort, ou le module IDS/IPS d'un pare-feu (pfSense, OPNsense, Stormshield, UniFi) ;
• le HIDS (host IDS), installé sur chaque machine, qui surveille ses journaux, l'intégrité de ses fichiers, ses processus : l'agent Wazuh en est l'exemple libre le plus courant (chapitre 13). Les EDR des postes et serveurs vont plus loin en analysant le comportement des programmes et en pouvant isoler une machine.

Les méthodes de détection

• Par signatures : l'IDS compare le trafic à une base de motifs d'attaques connues (une chaîne caractéristique dans une requête, une suite de paquets typique d'un balayage). Très précis pour ce qui est connu, aveugle à ce qui ne l'est pas encore.
• Par anomalies (comportementale) : l'IDS apprend le trafic normal et signale les écarts (un serveur qui se met à envoyer des gigaoctets la nuit, un poste qui contacte cinquante machines en une minute). Il repère des attaques inconnues, mais produit plus de fausses alertes.
• Par réputation : l'IDS signale les connexions vers des adresses ou des domaines connus pour être malveillants (listes publiées et mises à jour en continu).

Toute détection fait des erreurs. Il faut savoir les nommer :

Trop de faux positifs noient les vraies alertes (on parle de « fatigue d'alerte ») ; régler les règles pour en réduire le nombre est une partie normale du travail. Un IDS mal réglé qui alerte mille fois par jour n'est plus lu par personne.

Suricata et ses règles

Suricata, développé par l'OISF, est l'IDS/IPS libre de référence. Il analyse les protocoles (HTTP, TLS, DNS, SMB, SSH…), extrait les fichiers, écrit ses alertes et ses métadonnées dans le fichier JSON eve.json, facile à envoyer vers un SIEM. Snort 3 (Cisco) est son équivalent historique. Les deux utilisent des jeux de règles mis à jour quotidiennement : ET Open (gratuit), ET Pro (payant), et les règles de Snort (communautaires ou par abonnement).

Une règle se lit comme une phrase : « si tel trafic contient tel motif, alors telle action ». En voici une, écrite localement pour Sorbier, qui signale une même source qui ouvre dix connexions SSH en une minute vers le réseau interne :

alert tcp any any -> $HOME_NET 22 (msg:"LOCAL Tentatives SSH repetees depuis une meme source"; flow:to_server; flags:S; threshold:type both, track by_src, count 10, seconds 60; classtype:attempted-admin; sid:1000001; rev:1;)

Une autre, qui repère l'usage de Telnet, un protocole d'administration en clair qui ne devrait plus exister sur le réseau :

alert tcp $HOME_NET any -> any 23 (msg:"LOCAL Telnet en clair sur le reseau interne"; flow:to_server,established; classtype:policy-violation; sid:1000002; rev:1;)

Suricata sur pfSense et OPNsense

Sur pfSense, le paquet Suricata (System > Package Manager) s'installe en quelques minutes ; sur OPNsense, il est intégré (Services > Intrusion Detection). Les étapes sont les mêmes (le cours pfSense les détaille au chapitre pfBlockerNG et Suricata) :

1. Choisir les interfaces à surveiller. Sur le WAN, l'IDS voit toutes les attaques venues d'Internet, y compris celles que le pare-feu bloque déjà : beaucoup de bruit. Sur les interfaces internes (POSTES, SERVEURS, DMZ), il voit ce qui a franchi le filtrage et le trafic entre zones, souvent plus utile.
2. Activer les jeux de règles (ET Open au minimum) et leur mise à jour automatique quotidienne.
3. Choisir les catégories de règles en rapport avec le réseau (inutile d'activer les règles d'un logiciel qu'on n'a pas).
4. Commencer en mode IDS (alertes seules) pendant quelques semaines, analyser les alertes, supprimer ou ajuster celles qui sont des faux positifs (listes de suppression).
5. Passer en mode IPS (Inline IPS Mode), en ne mettant en drop que les catégories fiables.

pfSense propose aussi un mode « blocage des adresses fautives » (Legacy Mode) : l'adresse source d'une alerte est ajoutée à une liste de blocage du pare-feu pour une durée donnée. Simple, mais dangereux : une adresse interne bloquée par erreur, ou l'adresse d'un serveur DNS, peut couper un service entier. On y ajoute toujours une liste blanche (pass list) des adresses à ne jamais bloquer : passerelles, serveurs DNS, serveurs internes critiques.

Lire une alerte et la traiter

Une ligne d'alerte de eve.json, mise en forme :

{
  "timestamp": "2026-04-21T03:14:07.512+0200",
  "event_type": "alert",
  "src_ip": "192.168.10.71",
  "src_port": 50322,
  "dest_ip": "192.168.10.177",
  "dest_port": 445,
  "proto": "TCP",
  "alert": {
    "action": "allowed",
    "signature_id": 1000010,
    "signature": "LOCAL Poste qui enumere les partages de nombreux serveurs",
    "category": "Detection of a Network Scan",
    "severity": 2
  }
}

Pour chaque alerte, pose ces questions, dans l'ordre :

1. Quand ? Ici à 3 h du matin : aucun salarié ne travaille, c'est un premier signal.
2. Qui vers qui ? Un poste du VLAN 10 vers le contrôleur de domaine, sur SMB. Une alerte de l'intérieur vers l'intérieur est souvent plus grave qu'une alerte venue d'Internet : quelque chose est déjà entré.
3. Quoi ? La signature et sa catégorie disent ce qui a été reconnu : ici, une énumération de partages, typique de la phase de découverte d'un attaquant (tactique Discovery de MITRE ATT&CK).
4. Quelle gravité ? Dans Suricata, severity 1 est la plus élevée, 3 la plus faible.
5. Qu'a fait l'IDS ? allowed : il a seulement alerté (mode IDS) ; blocked : il a bloqué (mode IPS).
6. Est-ce légitime ? Un outil d'inventaire ou une sauvegarde planifiée peut produire ce trafic : vérifier dans la documentation, les tâches planifiées, auprès des collègues.
7. Qu'en disent les autres journaux ? Ouverture de session sur le poste à cette heure-là, connexions du pare-feu, alertes de l'EDR : c'est le travail de corrélation du SIEM.

Si l'alerte est confirmée, on passe à la gestion d'incident (chapitre 14). Si c'est un faux positif, on le documente et on ajuste la règle (suppression pour cette source, ou seuil modifié) pour qu'il ne se reproduise pas.

Les limites d'un IDS

• Le chiffrement : dans un flux HTTPS, l'IDS ne voit que les métadonnées (adresses, nom du site dans la négociation TLS, certificat, empreinte du client TLS). Pour analyser le contenu, il faut l'inspection TLS (chapitre 9) ou une détection sur les machines elles-mêmes (EDR, HIDS).
• Ce qu'il ne voit pas : le trafic entre deux machines d'un même VLAN ne passe pas par le pare-feu. Pour l'observer, il faut un port miroir sur le switch, ou un agent sur les machines.
• La performance : analyser chaque paquet demande beaucoup de processeur ; un IPS sous-dimensionné devient un goulot d'étranglement.
• Les attaques inconnues passent à travers les signatures : la détection comportementale et la corrélation dans un SIEM complètent le dispositif.

Exercices

alert tcp $HOME_NET any -> any 23 (msg:"LOCAL Telnet en clair sur le reseau interne"; flow:to_server,established; classtype:policy-violation; sid:1000002; rev:1;)