IDS/IPS — signatures vs comportement

Page concept

Cette page explique les grands principes des IDS/IPS — de quoi parler avant de lire une alerte Falco ou un log filterlog. La mise en œuvre pas à pas est dans les TP de l’Acte 2 — SIEM. Les ressources en fin de page sont votre point de départ pour aller plus loin par vous-même.

Le concept en une phrase

Un IDS détecte les intrusions soit en reconnaissant des motifs connus (signatures), soit en repérant ce qui dévie du normal (comportement) — sur le réseau ou sur l’hôte.

Deux questions structurent tout le domaine : où regarde-t-on, et comment décide-t-on qu’un événement est suspect ? Les réponses à ces deux questions dessinent une grille à quatre cases, et TAAF n’en occupe volontairement qu’une partie.

---

Les grands principes

1. Les deux axes — où on regarde × comment on décide

flowchart TB
    subgraph Où
        RES[Réseau]
        HOTE[Hôte / runtime]
    end
    subgraph Comment
        SIG[Signature]
        COMP[Comportement]
    end

• Où : sur le réseau (on inspecte les paquets qui circulent) ou sur l’hôte / au runtime (on observe ce qu’un processus fait réellement sur une machine — appels système, fichiers ouverts, connexions initiées).
• Comment : par signature (un motif connu, comme un antivirus) ou par comportement (un écart par rapport à une ligne de base attendue).

Ces deux axes sont indépendants : un IDS réseau peut être à signatures ou comportemental, et de même côté hôte.

2. Les signatures — précises mais aveugles au nouveau

Un IDS à signatures compare le trafic ou l’activité observée à une base de motifs connus (une chaîne d’octets caractéristique d’un exploit, un user-agent connu de scanner). C’est précis quand la signature existe — peu de faux positifs — mais aveugle à toute variante non répertoriée : un attaquant qui modifie légèrement sa charge utile échappe à la détection. C’est un principe général des IDS réseau — Snort et Suricata en sont les représentants historiques les plus connus dans l’industrie. Note : cette approche est présentée ici comme un concept ; TAAF ne déploie pas d’IDS réseau à signatures dans ses TP.

3. Le comportemental / runtime — Falco et les syscalls

Un IDS comportemental observe ce qui se passe réellement sur un système, et compare à une ligne de base : « ce processus ouvre-t-il d’habitude ce fichier ? », « cet utilisateur exécute-t-il d’habitude cette commande ? ». Dans TAAF, cette approche est incarnée par Falco, qui surveille les appels système (syscalls) au niveau du noyau Linux.

C’est exactement le mécanisme derrière T7 du fil rouge : un pg_dump sur la table classifiée genetic_samples n’est pas une signature connue d’attaque — c’est une commande légitime, exécutée par un compte légitime (svc_backup). Ce qui la rend suspecte, c’est le contexte : l’heure, l’absence d’approbation tracée, la table visée. Falco capture l’événement au runtime et le fait remonter à Loki, où une règle Sigma le reconnaît.

4. IDS vs IPS — détecter ou bloquer

• IDS (Intrusion Detection System) — observe et alerte. Il ne touche pas au trafic ou à l’exécution ; un humain décide de la suite.
• IPS (Intrusion Prevention System) — observe et bloque activement, en ligne sur le flux.

Le prix d’un IPS mal réglé est direct : un faux positif devient un blocage à tort — un service légitime coupé en pleine base australe, où une intervention physique peut prendre des jours. C’est pourquoi TAAF privilégie la détection (IDS, Falco) pour le comportemental fin, et réserve le blocage actif à des règles plus grossières et plus sûres, comme celles du pare-feu.

5. Le pare-feu comme capteur — pas seulement un mur

OPNsense n’est pas qu’un dispositif de blocage : son journal filterlog est une source de détection à part entière, au même titre que Falco ou les logs applicatifs. C’est exactement T8 du fil rouge : la tentative d’exfiltration de genetic_samples vers l’extérieur est refusée par la segmentation réseau — et ce refus, capturé dans filterlog, devient lui-même une alerte à part entière dans le SOC Grafana-natif. Un mur qui bloque sans qu’on le sache ne sert que la moitié de sa valeur ; loggé et remonté, il devient un capteur.

---

Où ça sert dans TAAF

• Falco dans les TP de l’Acte 2 — notamment le TP — Détection Sigma → LogQL, où les events Falco du fil rouge deviennent la source de la règle sur genetic_samples.
• Sources OPNsense (filterlog, DNS Unbound) — intégrées comme sources de détection dans le module SIEM — Acte 2, notamment pour T8 (exfiltration bloquée) et T9 (beaconing DNS résiduel).
• Programme ingénieurs — le bloc « malware + IDS/IPS » est mappé sur l’Acte 2 dans la progression de formation.

---

Ressources associées

Ces liens sont des points de départ pour vos propres recherches — voir la bibliothèque complète sur la page Ressources, section Détection & SIEM.

À chercher par vous-même : « IDS vs IPS », « network-based vs host-based intrusion detection », « Falco syscall runtime security », « signature-based vs anomaly-based detection », « firewall log as detection source ».