Un IDS raconte ce qui se passe. Vient forcément le moment où l'on se dit : « puisqu'il détecte, autant qu'il bloque ». C'est le passage à l'IPS — et c'est une décision bien plus lourde qu'un simple changement de configuration.
La différence tient à un seul mot : la position
Un IPS — Intrusion Prevention System — utilise exactement le même moteur d'analyse qu'un IDS. La différence est physique : il n'est plus à côté du flux, il est dedans. Le trafic le traverse, ce qui lui donne le pouvoir de ne pas le laisser passer.
Trois façons d'intervenir :
- rejeter le paquet — la connexion expire, sans explication pour l'émetteur ;
- réinitialiser la connexion — un message clair de fin, plus propre pour les applications ;
- filtrer sélectivement — laisser passer le flux en bloquant certaines requêtes.
Ce que ça change vraiment
Trois conséquences, et aucune n'est anodine.
1. Le capteur devient critique
En IDS, un capteur qui tombe fait perdre de la visibilité — c'est ennuyeux. En IPS, un capteur qui tombe coupe le réseau. L'équipement passe du statut d'outil d'observation à celui d'élément d'infrastructure, avec les exigences correspondantes : redondance, contournement matériel, supervision de la supervision.
2. Un faux positif devient une panne
C'est le point central. En mode détection, une règle mal calibrée produit du bruit dans un tableau de bord. En mode prévention, la même règle bloque une application métier — et personne ne fera le lien immédiatement. La question n'est plus « cette règle est-elle pertinente ? » mais « suis-je prêt à couper un service si elle se déclenche à tort ? ».
3. La latence entre en jeu
Analyser en ligne coûte du temps de traitement, et le débit du capteur devient celui du lien. Sur un réseau chargé, cela se dimensionne — un IPS sous-dimensionné dégrade tout le trafic, y compris parfaitement légitime.
Même moteur, même jeu de règles : seule la place dans le chemin des flux distingue l'observation de l'action.
La méthode qui fonctionne
Personne ne déploie un IPS directement en bloquant. La progression raisonnable — celle qui structure le lab de cette série — se déroule ainsi :
- observer en IDS pendant plusieurs semaines, sur le trafic réel ;
- analyser les alertes : lesquelles sont pertinentes ? Lesquelles se déclenchent tous les jours sans raison ?
- ajuster : désactiver les règles inadaptées, écrire les exceptions nécessaires ;
- basculer progressivement — d'abord un petit ensemble de règles fiables et à fort impact, puis élargir ;
- surveiller les blocages aussi attentivement que les alertes : un blocage inattendu est un incident, même s'il est techniquement correct.
Le principe tient en une phrase, empruntée à la documentation du lab : en sécurité réseau, on observe et on comprend avant d'agir.
Où l'IPS est pertinent, et où il l'est moins
- Pertinent : en bordure, sur des flux entrants exposés, contre des attaques automatisées et massives — balayages, exploitations connues, familles de codes malveillants. Ce sont des menaces où le blocage automatique a un intérêt évident et un risque de faux positif faible.
- Plus délicat : au cœur d'un réseau interne où les applications métier ont des comportements atypiques, ou sur des flux dont l'interruption a des conséquences immédiates.
Et un rappel utile : l'IPS ne remplace pas le pare-feu. Le pare-feu décide qui a le droit de parler à qui — c'est une politique. L'IPS examine le contenu de ce qui est autorisé — c'est une analyse. Les deux sont complémentaires, et l'IPS ne rattrapera jamais une politique de filtrage absente.
Le vrai critère de décision
Avant de basculer, une question à se poser honnêtement : l'organisation est-elle prête à traiter un blocage à 3 h du matin ? Si personne ne peut diagnostiquer et lever un blocage rapidement, l'IPS créera plus d'indisponibilité qu'il n'évitera d'incidents. Mieux vaut alors un IDS bien exploité qu'un IPS que l'on finira par désactiver après le premier incident.
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 ? — vous y êtes
- 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