IPS : Strategie de detection et gestion des rules Suricata

Suricata en mode IPS inline (NFQUEUE) inspecte chaque paquet du trafic WAN et peut bloquer les menaces en temps reel. Mais la puissance d'un IPS reside dans la qualite de ses regles et la strategie de gestion adoptee. Cet article couvre la politique de rules, le processus de mise a jour, et les optimisations de performance.

Politique de regles : modify.conf

Par defaut, les regles Emerging Threats (ET) sont en mode alert : elles generent un evenement mais laissent passer le trafic. Le fichier modify.conf convertit les regles critiques de alert vers drop pour un blocage actif :

# modify.conf - conversion alert → drop
# Menaces confirmees
re:"classtype:trojan-activity" "alert" "drop"
re:"classtype:command-and-control" "alert" "drop"
re:"classtype:attempted-admin" "alert" "drop"

# Sources malveillantes connues
re:"ET DROP" "alert" "drop"
re:"ET CINS" "alert" "drop"
re:"ET MALWARE" "alert" "drop"
re:"ET CNC" "alert" "drop"

# Attaques actives
re:"ET EXPLOIT" "alert" "drop"
re:"ET SCAN.*Zmap" "alert" "drop"
re:"ET TROJAN" "alert" "drop"

# Attaques web
re:"PHP|SQLi|RCE|WebShell" "alert" "drop"
re:"GPL DNS.*recon" "alert" "drop"

Faux positifs : disable.conf

Certaines regles declenchent des alertes sur du trafic legitime du homelab. Le fichier disable.conf les desactive par SID :

# disable.conf - faux positifs identifies
# Squid CONNECT method (trafic proxy transparent normal)
2013926
2013927
2013928

# BingBot crawler (trafic SEO legitime)
2032981

# Android connectivity check
2036220
2046370
2046428

# WAF 403 responses (ModSecurity bloque, pas une menace reseau)
2010516
2101201

# TeamViewer (utilisation legitime)
2030668
2060624
2060625
2060626
2060627
2060628
2060629
2060630
2060631
2060632

Resultat de la politique

Apres application des fichiers modify et disable :

flowchart LR
    A["~50K regles ET"] --> B{"Politique appliquee"}
    B --> C["~23K rules DROP<br/>Blocage actif"]
    B --> D["~27K rules ALERT<br/>Detection passive"]
    B --> E["13 rules DISABLED<br/>Faux positifs"]
    style C fill:#e74c3c,color:#fff
    style D fill:#f39c12,color:#fff
    style E fill:#95a5a6,color:#fff

Cette repartition offre un bon equilibre : les menaces confirmees (malware, C&C, exploits) sont bloquees activement, tandis que les signatures moins fiables restent en mode detection pour analyse dans Graylog.

Processus de mise a jour des regles

L'image Suricata est construite FROM scratch : elle ne contient aucun interpreteur Python, ce qui rend suricata-update inutilisable directement dans le container de production. La mise a jour passe par un container Alpine ephemere :

flowchart TD
    A["Stop container Suricata"] --> B["queue-bypass actif<br/>Trafic non impacte"]
    B --> C["Container ephemere Alpine<br/>suricata-update"]
    C --> D{"Telechargement ET rules"}
    D --> E["Application modify.conf"]
    E --> F["Application disable.conf"]
    F --> G["Ecriture rules compilees"]
    G --> H["Erreur /bin/sh benigne<br/>reload-command echoue"]
    H --> I["Start container Suricata"]
    I --> J["Nouvelles rules chargees"]
    style B fill:#27ae60,color:#fff
    style H fill:#f39c12,color:#fff
    style J fill:#27ae60,color:#fff

Strategie stop/update/start

La sequence de mise a jour suit un ordre strict :

Stop du container Suricata : les queues NFQUEUE sont videes, mais le flag --queue-bypass dans les regles nftables garantit que le trafic continue de passer sans inspection
Execution du container updater : image Alpine ephemere avec --network host (necessaire pour la resolution DNS car slirp4netns n'est pas disponible sur VyOS) et --user root
Start du container Suricata : les nouvelles regles sont chargees au demarrage

Gotchas du processus

L'erreur FileNotFoundError: /bin/sh en fin de suricata-update est benigne. Elle se produit quand l'updater tente d'executer la commande de reload -- mais l'image FROM scratch n'a pas de shell. Les regles sont ecrites sur le volume avant cette erreur. La verification se fait par le timestamp des fichiers rules, pas par le code de retour du container.

Le container updater utilise --network host parce que slirp4netns n'est pas installe sur VyOS et les reseaux bridge Podman ne disposent pas forcement du NAT necessaire pour atteindre les serveurs de regles ET.

Performance : mode NFQUEUE accept vs repeat

Suricata en NFQUEUE propose deux modes de verdict :

nfq.mode: accept : les paquets autorises recoivent un verdict NF_ACCEPT, les paquets bloques recoivent NF_DROP. Simple et efficace.
nfq.mode: repeat : les paquets autorises sont re-injectes dans la pile netfilter avec un mark pour eviter une boucle. Necessaire uniquement si d'autres regles nftables doivent s'appliquer apres Suricata.

Le mode repeat avec ~50K regles actives genere une charge CPU de 300%+ sur 4 vCPUs. Pour un homelab, le mode accept est largement suffisant et maintient le CPU a un niveau raisonnable. Le mode repeat ne se justifie que sur une infrastructure dediee avec 8+ vCPUs.

Pipeline complet des regles

flowchart TD
    A["Sources ET Open"] --> B["suricata-update<br/>telechargement"]
    B --> C["modify.conf<br/>alert vers drop"]
    C --> D["disable.conf<br/>suppression faux positifs"]
    D --> E["Compilation rules"]
    E --> F["Volume partage<br/>/config/containers/suricata/rules/"]
    F --> G["Suricata IPS<br/>chargement au start"]
    G --> H{"Verdict NFQUEUE"}
    H --> I["NF_ACCEPT<br/>Trafic autorise"]
    H --> J["NF_DROP<br/>Menace bloquee"]
    J --> K["Log EVE JSON<br/>vers Graylog"]
    style J fill:#e74c3c,color:#fff
    style I fill:#27ae60,color:#fff

Articles lies

Image Docker Suricata IPS NFQUEUE : construction de l'image hardened FROM scratch avec Go init
VyOS routeur zone-based firewall : integration NFQUEUE dans les zones firewall VyOS