IDS / IPS¶

Concepts fondamentaux¶

IDS vs IPS¶

Un IDS (Intrusion Detection System) surveille le trafic et les activites pour detecter les comportements suspects. Un IPS (Intrusion Prevention System) va plus loin en bloquant automatiquement les menaces detectees.

Critere	IDS	IPS
Action	Detection et alerte	Detection, alerte et blocage
Position	Passive (copie du trafic)	Inline (dans le flux reseau)
Latence	Aucun impact sur le trafic	Ajout minimal de latence
Risque	Faux negatifs (menaces non detectees)	Faux positifs (trafic legitime bloque)
Usage	Surveillance, forensic, conformite	Protection active, prevention temps reel

Modes de deploiement¶

Inline (IPS)¶

Le systeme est place dans le chemin reseau : tout le trafic le traverse. Il peut bloquer, modifier ou rejeter les paquets malveillants en temps reel. C'est le mode utilise par le FortiGate IPS.

Passif (IDS)¶

Le systeme recoit une copie du trafic (port mirroring, TAP) sans etre dans le flux. Il analyse et alerte mais ne peut pas bloquer directement. Avantage : aucun impact sur la disponibilite reseau.

Methodes de detection¶

Methode	Principe	Forces	Faiblesses
Signature	Comparaison avec des motifs connus (regles, hash)	Tres precis pour les menaces connues, peu de faux positifs	Inefficace contre les menaces zero-day
Anomalie	Detection des ecarts par rapport a un profil normal	Detecte les menaces inconnues	Taux de faux positifs plus eleve, necessite un apprentissage
Comportement	Analyse des sequences d'actions et des TTPs	Detecte les attaques complexes multi-etapes	Complexite de mise en oeuvre, ressources importantes

Defense en profondeur¶

Notre strategie de detection repose sur 3 niveaux complementaires qui assurent une couverture maximale :

flowchart TB
    subgraph N1["Niveau 1 -- Reseau"]
        FGT["FortiGate IPS<br/>Detection/prevention perimetre"]
    end

    subgraph N2["Niveau 2 -- Hote"]
        WAZ["Wazuh HIDS<br/>Detection sur chaque VM"]
    end

    subgraph N3["Niveau 3 -- Deception"]
        OC["OpenCanary<br/>Honeypots et canary tokens"]
    end

    INTERNET["Internet / Attaquant"] --> FGT
    FGT -->|Trafic autorise| N2
    N2 -->|Mouvement lateral| OC

    FGT -->|Alertes| SOC["SOC<br/>(Wazuh Manager + ELK)"]
    WAZ -->|Alertes| SOC
    OC -->|Alertes critiques| SOC

    style N1 fill:#1565C0,color:#fff
    style N2 fill:#E65100,color:#fff
    style N3 fill:#B71C1C,color:#fff
    style SOC fill:#2E7D32,color:#fff

Niveau 1 -- FortiGate IPS (Reseau)¶

Fonctionnement¶

Le FortiGate opere en mode inline sur le perimetre reseau. Tout le trafic entrant et sortant traverse son moteur IPS qui inspecte les paquets en temps reel.

Base de signatures¶

FortiGate maintient une base de milliers de signatures mises a jour quotidiennement via FortiGuard. Chaque signature identifie un motif specifique d'attaque (exploit, malware, C2 callback).

Decodeurs de protocoles¶

Le moteur IPS comprend les protocoles applicatifs (HTTP, DNS, SMB, TLS) et peut analyser le contenu au-dela des en-tetes reseau. Cela permet de detecter les attaques encapsulees dans des protocoles legitimes.

Detection d'anomalies¶

En complement des signatures, le FortiGate detecte les anomalies protocolaires : paquets malformes, violations de RFC, tentatives de fragmentation evasive, scans de ports.

Rate limiting¶

Les politiques de rate limiting protegent contre les attaques volumetriques (DDoS, brute force) en limitant le nombre de connexions par source et par service.

Virtual patching¶

Quand une CVE critique est publiee et qu'un correctif n'est pas encore deploye, le FortiGate peut appliquer un patch virtuel via une signature IPS qui bloque l'exploitation de la vulnerabilite au niveau reseau.

Niveau 2 -- Wazuh HIDS (Hote)¶

Wazuh est deploye sous forme d'agent sur chaque VM de l'infrastructure. Il fournit une detection au niveau systeme, la ou le NIDS est aveugle.

File Integrity Monitoring (FIM)¶

Le FIM surveille en continu les fichiers et repertoires critiques du systeme. Toute creation, modification ou suppression declenche une alerte.

Chemin surveille	Raison
/etc/passwd, /etc/shadow	Comptes systeme, modification = compromission potentielle
/etc/ssh/sshd_config	Configuration SSH, modification = backdoor potentielle
/etc/sudoers, /etc/sudoers.d/	Privileges sudo, modification = escalade de privileges
/usr/bin/, /usr/sbin/	Binaires systeme, modification = rootkit ou backdoor
/etc/cron.d/, /var/spool/cron/	Taches planifiees, modification = persistance
/boot/	Noyau et bootloader, modification = bootkits

Detection de rootkits¶

Wazuh execute des verifications specifiques pour identifier les rootkits :

• Recherche de fichiers caches non visibles par ls mais presents sur le disque
• Verification des ports caches (sockets ouverts non declares par netstat)
• Analyse des processus caches via comparaison /proc vs sortie ps
• Scan des signatures de rootkits connus (fichiers, repertoires, processus specifiques)

Scan de vulnerabilites (CVE)¶

L'agent Wazuh inventorie les paquets installes sur chaque VM et les compare avec les bases de vulnerabilites connues (NVD, Red Hat Security Advisories). Les CVE identifiees sont classees par severite (CVSS).

CIS Benchmark¶

Wazuh evalue la conformite de chaque VM selon les referentiels CIS (Center for Internet Security) et ANSSI-BP028. Chaque recommandation est verifiee et le score de conformite est calcule.

Correlation de logs¶

Le manager Wazuh correle les evenements de multiples sources pour identifier les attaques complexes :

• Tentatives de brute force : X echecs de connexion SSH en Y minutes
• Escalade de privileges : execution suspecte de su, sudo, ou changement UID
• Exfiltration : volume de donnees sortant anormal
• Mouvement lateral : connexions SSH entre VMs inhabituelles

Active Response¶

Wazuh peut reagir automatiquement aux menaces detectees :

Declencheur	Action	Duree
5 echecs SSH en 2 min	Blocage IP via firewalld	30 minutes
Modification /etc/passwd	Alerte critique + notification	Permanente
Detection rootkit	Isolation de la VM + alerte critique	Manuelle
CVE critique detectee	Alerte + ticket remediation	Jusqu'a correction

Niveau 3 -- OpenCanary (Deception)¶

Concept des honeypots¶

Un honeypot est un systeme volontairement expose qui simule des services reels pour attirer les attaquants. Puisqu'aucun utilisateur legitime n'a de raison d'interagir avec ces faux services, toute connexion est par definition suspecte.

flowchart LR
    ATT["Attaquant"] -->|Scan reseau| NET["Reseau interne"]
    NET -->|Decouvre faux service| HC["Honeypot<br/>OpenCanary"]
    HC -->|Alerte immediate| SOC["SOC"]
    SOC -->|Investigation| IR["Incident Response"]

    style HC fill:#D32F2F,color:#fff
    style SOC fill:#2E7D32,color:#fff

Faux services deployes¶

OpenCanary simule des services attractifs pour les attaquants sur la VM dediee (10.15.80.30) :

Service	Port	Objectif de detection
SSH	22	Tentatives de connexion, brute force
HTTP	80, 443	Scans web, tentatives d'exploitation
SMB	445	Mouvement lateral Windows, EternalBlue
MySQL	3306	Tentatives d'acces aux bases de donnees
RDP	3389	Acces bureau a distance non autorise
FTP	21	Tentatives de transfert de fichiers
SNMP	161	Reconnaissance reseau

Canary tokens¶

En complement des honeypots, des canary tokens sont disposes dans l'infrastructure :

Fichiers pieges¶

Des fichiers nommes de maniere attractive (passwords.xlsx, backup_db.sql, id_rsa.bak) sont places dans des repertoires strategiques. Toute ouverture ou copie declenche une alerte via Wazuh FIM.

URLs pieges¶

Des liens uniques sont integres dans des documents internes. Tout acces a ces URLs (via un proxy compromis ou un document exfiltre) genere une alerte.

Tokens DNS¶

Des enregistrements DNS specifiques sont configures. Toute resolution de ces noms (indicatrice d'une exfiltration DNS ou d'une analyse de documents voles) declenche une alerte.

Mapping Kill Chain et detection¶

Le tableau suivant montre quel niveau detecte quelle phase de la kill chain :

Phase d'attaque	FortiGate (Reseau)	Wazuh (Hote)	OpenCanary (Deception)
Reconnaissance (scan de ports, enumeration)	Oui -- signatures scan	Oui -- log analysis	Oui -- faux services contactes
Weaponization (preparation de l'exploit)	Non -- hors perimetre	Non -- hors perimetre	Non -- hors perimetre
Delivery (envoi du payload)	Oui -- IPS inline	Non	Non
Exploitation (execution de l'exploit)	Oui -- signatures CVE	Oui -- FIM + log correlation	Non
Installation (persistance)	Non -- trafic interne	Oui -- FIM + rootkit detection	Non
Command & Control (communication C2)	Oui -- signatures C2	Oui -- log analysis	Non
Mouvement lateral	Partiel -- inter-VLAN	Oui -- log correlation	Oui -- interaction honeypot
Exfiltration	Oui -- DLP + anomalie	Oui -- volume analysis	Oui -- canary tokens

Flux de detection global¶

flowchart TB
    EVT["Evenement suspect"] --> FGT{"FortiGate IPS"}
    EVT --> WAZ{"Wazuh Agent"}
    EVT --> OC{"OpenCanary"}

    FGT -->|Signature match| BLK["Blocage inline"]
    FGT -->|Log IPS| SYSLOG["rsyslog VIP .50"]

    WAZ -->|Alerte HIDS| MGR["Wazuh Manager"]
    MGR --> SYSLOG

    OC -->|Toute interaction| SYSLOG

    SYSLOG --> LS["Logstash VIP .51"]
    LS --> ES["Elasticsearch"]
    ES --> EA["ElastAlert2"]
    EA --> SH["Shuffle SOAR"]

    SH -->|Enrichissement| CORTEX["Cortex"]
    SH -->|Case| THEHIVE["TheHive"]
    SH -->|IoC lookup| MISP["MISP"]
    SH -->|Remediation| AR["Active Response"]

    style BLK fill:#D32F2F,color:#fff
    style SH fill:#2E7D32,color:#fff
    style THEHIVE fill:#1565C0,color:#fff