IDS et IPS : détection et prévention des intrusions
Un IDS observe le trafic et signale les comportements suspects ; un IPS peut les bloquer. Placement, méthodes de détection, réglage des règles et exploitation des alertes : guide défensif.
Le pare-feu décide de ce qui peut passer en fonction des adresses, des ports et des applications. Mais un flux autorisé peut transporter une attaque : exploitation d'une vulnérabilité web, communication d'un logiciel malveillant avec son serveur de commande, balayage interne après compromission. Les systèmes de détection d'intrusion (IDS) et de prévention d'intrusion (IPS) analysent le contenu et le comportement du trafic pour repérer ces menaces.
Objectif : comprendre le fonctionnement des IDS/IPS, choisir leur placement, les déployer avec des outils libres et, surtout, les exploiter efficacement. Cet article est strictement orienté défense.
IDS ou IPS ?
| Critère | IDS (détection) | IPS (prévention) |
|---|---|---|
| Position | Hors du chemin (copie du trafic) | Sur le chemin (inline) |
| Action | Génère des alertes | Peut bloquer les paquets ou les connexions |
| Impact d'une panne | Aucun sur le trafic | Peut interrompre le trafic (selon le mode de défaillance choisi) |
| Impact d'un faux positif | Alerte inutile | Blocage d'un flux légitime |
| Latence ajoutée | Nulle | Faible mais réelle |
De nombreux pare-feu dits « nouvelle génération » intègrent une fonction IPS. Les sondes dédiées restent courantes pour la surveillance du réseau interne.
Il existe aussi des IDS d'hôte (HIDS), qui surveillent les journaux, fichiers et processus d'une machine, complémentaires des IDS réseau (NIDS) traités ici.
Les méthodes de détection
Par signatures
Le moteur compare le trafic à une base de règles décrivant des attaques connues : séquence d'octets, requête HTTP caractéristique, comportement protocolaire anormal. Méthode précise pour les menaces connues, inefficace face à une attaque totalement nouvelle ou fortement modifiée.
Exemple de règle au format Suricata (illustratif) :
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Exemple - User-Agent de test interdit"; flow:established,to_server; http.user_agent; content:"OutilDeTestInterne"; nocase; classtype:policy-violation; sid:9000001; rev:1;)
La règle décrit : l'action (alert), le protocole, les adresses et ports, puis les conditions (flow, contenu d'un champ HTTP) et des métadonnées (msg, sid, rev). Les identifiants sid à partir de 1 000 000 sont conventionnellement réservés aux règles locales.
Par anomalies et comportements
Le système établit une référence du trafic normal et signale les écarts : volume inhabituel, nouvelle destination, protocole inattendu sur un port, horaires anormaux. Utile pour détecter l'inconnu, mais plus sujet aux faux positifs.
Par analyse protocolaire et métadonnées
Des outils comme Zeek n'utilisent pas principalement des signatures : ils produisent des journaux riches (connexions, requêtes DNS, sessions HTTP et TLS, certificats, fichiers transférés), exploitables pour la recherche de menaces et l'analyse a posteriori.
Où placer les sondes ?
| Emplacement | Ce que l'on voit |
|---|---|
| Derrière le pare-feu périmétrique | Les flux entrants autorisés et les flux sortants vers Internet |
| En DMZ | Les attaques visant les services exposés |
| Entre utilisateurs et serveurs | Les mouvements latéraux, l'exploitation interne |
| Au cœur du réseau | Une vue large, mais un volume important |
Pour un IDS, la copie du trafic s'obtient par :
- mise en miroir de port (SPAN) sur un commutateur ;
- TAP réseau, dispositif matériel qui copie le trafic sans perte ni dépendance au commutateur ;
- fonctions de miroir des commutateurs virtuels ou des plateformes cloud.
! Mise en miroir de port sur Cisco IOS (exemple de laboratoire)
monitor session 1 source interface GigabitEthernet1/0/48 both
monitor session 1 destination interface GigabitEthernet1/0/47
Limite essentielle : une sonde ne voit pas le contenu du trafic chiffré (TLS). Elle voit cependant les métadonnées : adresses, volumes, noms de serveurs (SNI), empreintes de poignée de main, certificats. Ces informations restent très utiles pour la détection.
Déployer Suricata
Suricata est un moteur IDS/IPS libre et multi-fil, développé par l'OISF.
sudo apt install suricata
sudo suricata-update # télécharge les règles (ensemble ouvert par défaut)
sudo suricata -T -c /etc/suricata/suricata.yaml # tester la configuration
sudo systemctl enable --now suricata
sudo tail -f /var/log/suricata/fast.log
Points de configuration importants dans suricata.yaml :
HOME_NET: vos réseaux internes, pour que les règles distinguent l'interne de l'externe ;- l'interface de capture et le mode (af-packet sous Linux) ;
- la sortie EVE JSON (
eve.json), qui contient alertes et métadonnées dans un format directement exploitable par un SIEM.
Le réglage : l'essentiel du travail
Un IDS déployé avec toutes ses règles par défaut produit rapidement des milliers d'alertes. Sans réglage, elles sont ignorées, et l'outil devient inutile.
- Désactiver les règles non pertinentes pour votre environnement (systèmes et applications absents).
- Supprimer les faux positifs récurrents avec des exceptions précises (par source, destination ou signature), jamais en désactivant largement.
- Hiérarchiser : les alertes de forte criticité visant des actifs sensibles passent en priorité.
- Documenter chaque exception : pourquoi elle existe, qui l'a validée.
- Revoir régulièrement les règles et les exceptions.
En mode IPS, commencez toujours par une période d'observation en mode détection, puis activez le blocage pour un ensemble restreint de règles fiables.
Exploiter les alertes
Une alerte n'est utile que si quelqu'un la traite. Pour chaque alerte significative :
- Qualifier : vrai positif, faux positif, ou activité légitime mais inattendue ?
- Contextualiser : quelle machine, quel utilisateur, quel service ? Que disent les journaux du serveur et du pare-feu ?
- Décider : clôturer, surveiller, ou déclencher la procédure de réponse à incident.
L'intégration à un SIEM permet de corréler les alertes IDS avec les autres sources. Voir Journalisation et supervision des événements de sécurité.
Erreurs courantes
- Déployer sans réglage, puis ignorer le flot d'alertes.
- Placer la sonde où elle ne voit rien d'utile (miroir mal configuré, trafic asymétrique).
- Oublier de mettre à jour les règles.
- Passer en IPS bloquant sans phase d'observation.
- Surdimensionner les attentes : un IDS ne remplace ni les correctifs, ni la segmentation, ni la journalisation des systèmes.
Considérations juridiques et éthiques
L'analyse du trafic peut révéler des données personnelles et des communications privées. Encadrez le dispositif : information des utilisateurs selon les règles applicables, limitation des accès aux données collectées, durées de conservation définies et finalité strictement liée à la sécurité. N'analysez que les réseaux dont vous avez la responsabilité.
Conclusion
IDS et IPS apportent une visibilité précieuse sur ce que le pare-feu laisse passer. Leur valeur dépend moins de l'outil que de son placement, de son réglage et du traitement des alertes. Commencez en détection sur un périmètre restreint, réglez, intégrez à votre supervision, puis étendez.
