Un pare-feu décide qui a le droit de passer. Un antivirus examine des fichiers. Entre les deux, il manque quelqu'un pour répondre à une question simple : que se passe-t-il réellement sur mon réseau ? C'est le rôle d'un IDS.
Définition, et ce qu'elle implique
Un IDS — Intrusion Detection System — observe le trafic réseau, le compare à des signatures et à des comportements connus, et produit des événements quand quelque chose sort de l'ordinaire. Le mot important est « produit » : un IDS ne bloque rien. Il regarde et il raconte.
Cette passivité, qui semble une faiblesse, est en réalité sa principale qualité : parce qu'il n'intervient pas dans le flux, il ne peut pas casser la production. On peut donc le déployer largement, l'observer, se tromper — sans conséquence pour les utilisateurs.
Ce qu'un IDS voit, et que personne d'autre ne voit
Un IDS réseau moderne ne se contente pas de reconnaître des motifs suspects. Il reconstruit les flux et identifie les protocoles applicatifs, ce qui produit une matière bien plus riche que des alertes :
- toutes les résolutions DNS — les noms demandés, par qui, à quelle fréquence ;
- les requêtes HTTP — hôtes, chemins, agents utilisateurs ;
- les connexions TLS — certificats, noms de serveurs, versions ;
- les flux — qui parle à qui, combien de temps, quel volume ;
- les fichiers transférés, leurs empreintes.
Autrement dit, l'essentiel de la valeur d'un IDS n'est pas dans ses alertes mais dans cette visibilité. Quand un incident survient, ce sont ces journaux qui permettent de répondre à « depuis quand ? », « quoi d'autre a été touché ? », « où est parti le trafic ? ».
Où le placer
Un IDS ne voit que ce qui passe devant lui. Trois positions classiques :
- sur la passerelle — tout le trafic entrant et sortant y transite. C'est le point le plus rentable, et celui du lab décrit dans cette série ;
- sur un port miroir d'un commutateur — le trafic est dupliqué vers le capteur, y compris les échanges internes ;
- sur un TAP réseau — un boîtier passif qui copie le signal, sans aucun impact possible sur le réseau.
Une conséquence à connaître : ce qui ne passe pas par le point d'observation n'existe pas pour l'IDS. Deux machines qui discutent sur le même commutateur, sans traverser la passerelle, resteront invisibles.
Les deux difficultés réelles
Le bruit. Un jeu de règles générique, appliqué à un réseau réel, produit des centaines d'alertes par jour dont l'écrasante majorité est sans intérêt : sondes de supervision, mises à jour, comportements applicatifs atypiques mais légitimes. Un IDS qu'on n'a pas ajusté devient un fil qu'on n'ouvre plus.
Le chiffrement. La généralisation de TLS réduit ce que l'on peut lire du contenu. Restent les métadonnées — noms de serveurs, certificats, tailles et rythmes des échanges — qui suffisent souvent à repérer une anomalie, mais plus à lire ce qui s'échange.
Ces deux limites conduisent à la même conclusion : un IDS n'est pas un produit qu'on installe, c'est une pratique qu'on entretient.
Ce qu'il ne fait pas
- Il n'empêche rien — pour cela, il faut un IPS, sujet de l'article suivant.
- Il ne remplace pas les journaux système — authentifications, exécutions, accès aux fichiers restent invisibles depuis le réseau.
- Il ne détecte pas l'inconnu — les signatures décrivent ce qui est déjà connu ; l'analyse comportementale aide, sans miracle.
Malgré cela, c'est souvent le premier capteur à déployer : il coûte peu, ne casse rien, et transforme un réseau opaque en quelque chose d'observable.
La différence tient à la position dans le réseau : à côté du flux pour observer, dans le flux pour agir.
La série « détection réseau »
Cinq articles pour comprendre, cinq pour construire :
- Qu'est-ce qu'un IDS ? — vous y êtes
- 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
- Lab (4) : la chaîne d'ingestion
- Lab (5) : les tableaux de bord