Suricata sur OPNsense : IDS/IPS et listes de blocage

Le passage à OPNsense a permis d'activer Suricata en natif, sans add-on payant comme c'était le cas côté pfSense pour des règles à jour. Voici la configuration complète : mode détection vs blocage, choix des listes de règles, et surtout comment éviter qu'un IDS/IPS mal réglé ne devienne plus gênant qu'utile.

1. IDS ou IPS : détection ou blocage actif

Suricata peut fonctionner selon deux logiques bien distinctes :

• Mode IDS (détection) : analyse le trafic et journalise les alertes, sans rien bloquer. Idéal en phase de découverte, pour observer le volume et la nature des alertes avant d'activer un blocage qui pourrait couper du trafic légitime.
• Mode IPS (prévention, blocage actif) : bloque en plus le trafic identifié comme malveillant, en ligne. Sur OPNsense, ce mode s'appuie sur netmap pour intercepter le trafic en coupure, avec un impact CPU plus marqué que le mode détection seule.

2. Activer Suricata sur l'interface WAN

Dans OPNsense : Services → Intrusion Detection → Administration.

1. Activer Suricata sur l'onglet Interfaces, en sélectionnant l'interface WAN (celle qui voit le trafic Internet entrant/sortant).
2. Choisir le mode dans les réglages de l'interface : IDS (détection seule) pour commencer, puis IPS une fois les règles stabilisées.
3. Activer Promiscuous mode si nécessaire selon la configuration réseau (généralement inutile en mode IPS natif avec netmap).

3. Choisir et mettre à jour les listes de règles

Onglet Rules → Rulesets : cochez au minimum le jeu de règles ET Open (Emerging Threats Open), gratuit et maintenu par la communauté, qui couvre un large spectre de signatures (malware, exploits connus, scan de ports, C2...). Onglet Update : planifiez une mise à jour automatique quotidienne des règles pour rester à jour sans intervention manuelle.

En complément des signatures Suricata, OPNsense permet d'ajouter des listes de blocage d'IP (réputation), via Firewall → Aliases avec des alias de type URL Table, pointant vers des listes publiques régulièrement mises à jour (par exemple des listes de type Spamhaus DROP pour les réseaux connus pour héberger du spam ou des botnets). Ces alias s'utilisent ensuite comme source/destination dans une règle de pare-feu classique bloquant tout trafic vers/depuis ces plages.

# Consulter les dernières alertes Suricata en ligne de commande (shell OPNsense)
$ tail -f /var/log/suricata/*/eve.json | grep '"event_type":"alert"'

# Ou plus lisible : Services → Intrusion Detection → Alerts dans l'interface web

4. Réduire les faux positifs

Un jeu de règles complet génère inévitablement des faux positifs : trafic légitime (jeu en ligne, VPN, synchronisation cloud) identifié à tort comme suspect. Deux leviers, dans l'onglet Rules :

• Désactiver une règle précise qui déclenche à tort, plutôt que de désactiver toute une catégorie de règles.
• Suppress list : supprimer les alertes pour une combinaison IP/règle spécifique, sans désactiver la règle globalement — utile quand seul un hôte précis (ex. votre propre scanner de vulnérabilités interne) déclenche une signature par ailleurs pertinente pour le reste du trafic.

Un IDS/IPS n'est utile que si ses alertes sont regardées : mieux vaut un jeu de règles restreint mais réellement surveillé qu'une configuration exhaustive dont les logs personne ne consulte jamais.

Conclusion

Suricata en mode IDS puis IPS, combiné à des listes de réputation IP, apporte une couche de détection et de blocage qui complète utilement le filtrage de ports classique d'un pare-feu — à condition de le déployer progressivement et de garder un œil sur les faux positifs. L'étape suivante, CrowdSec, ajoute une couche complémentaire basée sur le comportement et la détection communautaire plutôt que sur des signatures. Si vous voulez être accompagné sur la mise en place ou le tuning de votre IDS/IPS, n'hésitez pas à me contacter.