Jbsky

IPS : Strategie de detection et gestion des rules Suricata

—

par

jb
dans

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 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.

Mecanisme de mise a jour des regles

Depuis la version 8.0.5, suricata-update (Python 3.12 + son runtime) est directement embarque dans l'image suricata-hardened -- plus besoin d'une image separee. La mise a jour tourne dans un container ephemere lance depuis cette meme image, en --user root :

Arreter Suricata (--queue-bypass maintient le trafic)
systemctl stop vyos-container-suricata.service

Container ephemere depuis l'image principale, root pour contourner
les file capabilities du binaire suricata en usage normal
podman run --rm --user root --network host --entrypoint python3 "$IMAGE" -c "
import os, sys
os.rename('/usr/bin/suricata', '/usr/bin/suricata.bak')
os.execvp('suricata-update', ['suricata-update'] + sys.argv[1].split())
" "update -f --no-test --suricata-version 8.0.5"

Redemarrer Suricata avec les nouvelles regles
systemctl start vyos-container-suricata.service

Piege decouvert a l'usage : suricata-update detecte normalement la version du moteur Suricata en executant le binaire suricata lui-meme. Une fois ce binaire renomme pour contourner les capabilities, cette detection echoue silencieusement et l'outil retombe sur son propre defaut cache : 6.0.0. Resultat, il telechargeait le ruleset ET Open construit pour Suricata 6.0.0 alors que le moteur tournait en 8.0.5 -- pendant plusieurs semaines, sans que rien ne plante ni n'alerte, juste le mauvais ruleset silencieusement. Corrige en passant --suricata-version explicitement, derive du tag de l'image plutot que code en dur une seconde fois.

Point benin a connaitre : l'etape finale de suricata-update tente d'invoquer /bin/sh pour son reload-command interne, absent de l'image FROM scratch. Ca se termine donc systematiquement en erreur non-zero -- sans importance, les regles sont deja ecrites sur disque avant cette derniere etape. Se fier au code de sortie aurait fait croire a un echec a chaque run pourtant reussi.

Performance : mode NFQUEUE accept vs repeat

Le choix entre les modes de verdict accept et repeat (et son impact CPU) est couvert dans l'article NFQUEUE dedie.

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