Suricata : Integration dans VyOS via conteneur Podman

📘 Introduction

Ce document décrit la mise en place d’un conteneur Suricata sur un routeur VyOS afin d’analyser le trafic réseau en mode IDS/IPS.
L’objectif est d’obtenir une inspection des paquets transitant à travers le routeur, tout en gardant une configuration persistante dans /config.

Setup entièrement automatisé maintenant via Ansible, playbook public ici si ça t’intéresse de reproduire : github.com/jbsky/vyos-deploy.

---

🧩 Architecture générale

• VyOS joue le rôle de routeur principal.
• Suricata est déployé dans un conteneur Podman géré nativement par VyOS, à partir de mon image durcie jbsky/suricata-hardened (FROM scratch, non-root, capabilities réduites au strict minimum) plutôt que l’image générique jasonish/suricata utilisée au départ.
• La configuration et les règles de Suricata sont stockées dans le répertoire persistant /config.
• Le trafic réseau est redirigé vers Suricata via nftables (mangle + NFQUEUE) pour inspection.

flowchart LR
    A["Internet"] -->|"eth1 (WAN)"| B["VyOS routeur"]
    B -->|"mark 10 (mangle)"| C["NFQUEUE 0-3"]
    C --> D["Suricata inline (container)"]
    D -->|"NF_ACCEPT / NF_DROP"| B
    B -->|"eth0"| E["Reseau local"]

⚙️ Configuration VyOS

Conteneur Suricata (état actuel, config.boot) :

set container name suricata allow-host-networks
set container name suricata arguments '-q 0 -q 1 -q 2 -q 3 --runmode workers'
set container name suricata capability 'net-admin'
set container name suricata capability 'sys-nice'
set container name suricata image 'docker.io/jbsky/suricata-hardened:8.0.5'
set container name suricata memory '2048'
set container name suricata restart 'on-failure'
set container name suricata volume config destination '/etc/suricata'
set container name suricata volume config source '/config/containers/suricata/etc'
set container name suricata volume logs destination '/var/log/suricata'
set container name suricata volume logs source '/var/log/suricata'
set container name suricata volume rules destination '/var/lib/suricata/rules'
set container name suricata volume rules source '/config/containers/suricata/rules'
set container name suricata volume run destination '/var/run/suricata'
set container name suricata volume run source '/config/containers/suricata/run'

Ce qui a changé par rapport à la première version : image passée sur mon build durci et pinnée par tag (8.0.5 au lieu de latest), mémoire redescendue à 2 Go (le build durci est nettement plus léger, 6 Go ne servaient à rien), ajout de restart on-failure, et un nouveau volume run qui expose le socket unix de contrôle (suricata-command.socket) pour recharger les règles à chaud avec suricatasc sans redémarrer le container.

allow-host-networks : permet au conteneur d’accéder au réseau du routeur — obligatoire en mode NFQUEUE, qui a besoin du network namespace de l’hôte.

arguments : définit les files NFQUEUE utilisées (-q 0 -q 1 -q 2 -q 3) et le mode de travail (–runmode workers).

capabilities : seules net-admin et sys-nice sont nécessaires (détail des choix d’architecture NFQUEUE et de l’image durcie dans l’article dédié).

volumes : montent les répertoires persistants du système VyOS dans le conteneur.

📦 Organisation des fichiers

/config/
├── containers/
│   └── suricata/
│       ├── etc/          ← Configuration Suricata (suricata.yaml, classification.config, etc.)
│       ├── rules/        ← Règles IDS (Emerging Threats, etc.)
│       └── run/          ← Socket unix de controle (suricata-command.socket)
├── scripts/
│   └── suricata-update.sh  ← Script de mise à jour des règles
└── ...

🔁 Redirection du trafic avec nftables

Le script /config/scripts/vyos-preconfig-bootup.script contient les règles suivantes (version finale, après pas mal d’itérations) :

# Marquer seulement le trafic entrant depuis le WAN
iptables -t mangle -A FORWARD -i eth1 -j MARK --set-mark 10

# Marquer seulement le trafic sortant vers le WAN
iptables -t mangle -A FORWARD -o eth1 -j MARK --set-mark 10

# Rediriger vers Suricata via NFQUEUE
iptables -t mangle -A POSTROUTING -m mark --mark 10 -j NFQUEUE \
  --queue-balance 0:3 \
  --queue-cpu-fanout \
  --queue-bypass

Différence avec la toute première version : au départ je marquais tout le trafic FORWARD, peu importe l’interface. Ça marchait, mais ça inspectait aussi du trafic inter-VLAN qui n’avait rien à voir avec l’extérieur. Restreint maintenant explicitement à eth1 (le WAN) dans les deux sens, ce qui limite l’inspection au trafic qui traverse vraiment la frontière internet.

Sous le capot, VyOS traduit tout ça en règles nftables (table ip mangle), iptables n’est qu’une couche de compatibilité en surface.

Explications :

Le trafic WAN entrant et sortant est marqué (mark 10).

Les paquets marqués sont envoyés à Suricata via NFQUEUE.

–queue-balance 0:3 : répartit la charge sur 4 files de traitement.

–queue-bypass : laisse passer le trafic si Suricata n’est pas actif (pas de coupure réseau, y compris pendant un redémarrage pour mise à jour des règles).

🧠 Mode d’analyse Suricata

Dans le fichier /config/containers/suricata/etc/suricata.yaml, le paramètre suivant est activé :

host-mode: router

Cela indique que Suricata doit analyser le trafic forwardé (celui qui transite à travers le routeur) et non le trafic local (input/output de VyOS lui-même).

🔄 Mise à jour automatique des règles

Une tâche planifiée VyOS déclenche la mise à jour quotidienne :

set system task-scheduler task update-suricata-rules executable path '/config/scripts/suricata-update.sh'
set system task-scheduler task update-suricata-rules interval '1d'

Le mécanisme exact du script (container éphémère, contournement des file capabilities, bug de détection de version) est détaillé dans l’article dédié à la gestion des règles.

📡 Déploiement et synchronisation

Toute cette configuration (config, règles, script de mise à jour) est maintenant versionnée et déployée via Ansible plutôt qu’à coups de rsync manuel. Le playbook cible un groupe Ansible vyos (pas un hostname en dur) et est réutilisable tel quel : github.com/jbsky/vyos-deploy.

ansible-playbook suricata-deploy.yaml -i inventories/production --tags config
ansible-playbook suricata-deploy.yaml -i inventories/production --tags script
ansible-playbook suricata-deploy.yaml -i inventories/production --tags check

Ça permet de :

Versionner la config dans Git plutôt qu’un dump rsync ponctuel.

Redéployer proprement sur une autre instance VyOS.

Vérifier l’état du container après coup (show container) plutôt que de deviner.

⚠️ Points à surveiller

Performance et choix d’architecture (NFQUEUE vs AF_PACKET, allow-host-networks) sont détaillés dans l’article NFQUEUE dédié — en pratique toujours pas de différence notable, je plafonne à 1 Gb avec iperf3.

Logs : /var/log/suricata peut croître rapidement, logrotate configuré en conséquence :

/var/log/suricata/*.log /var/log/suricata/*.json
{
    daily
    maxsize 100M
    rotate 10
    missingok
    nocompress
    copytruncate
}

Mise à jour du container : l’image étant pinnée par tag (8.0.5), plus de surprise de type "latest a changé sous mes pieds" — la mise à jour d’image est un choix explicite, pas un effet de bord d’un pull.

🧩 Références utiles

Documentation VyOS – Containers

Suricata Documentation

NFQUEUE & Suricata Inline Setup

🏁 Conclusion

Cette intégration permet à VyOS de fonctionner comme un routeur IDS/IPS complet grâce à Suricata, avec une architecture modulaire, persistante et maintenant entièrement automatisée via Ansible. Les débuts manuels (image générique, marquage de trafic trop large, mises à jour de règles à la main) ont progressivement laissé place à un setup reproductible, avec une image durcie et pinnée, et un playbook public que n’importe qui peut reprendre.

---

Liens

Code source : vyos-deploy (Suricata + stack proxy Squid/c-icap/ClamAV)
Image Docker : suricata-hardened

Articles connexes :
Suricata hardened : image Docker durcie pour NFQUEUE (architecture, image durcie)
IPS : stratégie de détection et gestion des rules Suricata (politique de règles, mécanisme de mise à jour)