Configurer un IPS (Suricata + Vuurmuur) sur Fedora 17

Ce guide explique comment installer Suricata et Vuurmuur sur Fedora 17, tester d’abord en mode IDS puis basculer en IPS. Vous apprendrez à charger des règles, à rediriger le trafic via NFQUEUE et à bloquer des connexions (ex. bloquer facebook).

Introduction

Un IPS (Intrusion Prevention System) inspecte le trafic réseau et peut bloquer des flux malveillants en temps réel. Suricata est un moteur IDS/IPS multicœur récent, capable d’inspecter et de réassembler des flux, d’extraire des fichiers HTTP et d’opérer en mode inline. Vuurmuur est un gestionnaire de pare-feu pour Linux qui génère des règles iptables lisibles par l’humain et offre un visualiseur de logs.

Ce tutoriel montre comment obtenir un IPS fonctionnel sur Fedora 17 en n’utilisant que des paquets Fedora.

Important — sauvegardez votre système et testez en IDS avant de passer en IPS. Un IPS mal configuré peut couper l’accès réseau.

Prérequis

Accès root sur une machine Fedora 17.
Interface réseau principale (ex. eth0).
Connexion Internet pour télécharger des règles.
Connaissances de base d’iptables/iproute et des services systemd.

Installer Vuurmuur et Suricata

Installez les paquets avec yum :

yum install suricata Vuurmuur-daemon Vuurmuur-tui

Tester Suricata en mode IDS (passif)

Avant d’activer le blocage, testez Suricata en mode passif (IDS). Téléchargez les règles Emerging Threats optimisées pour Suricata et placez-les dans /etc/suricata/rules/ :

cd /etc/suricata/  
curl -O https://rules.emergingthreatspro.com/open/suricata/emerging.rules.tar.gz  
tar xzvf emerging.rules.tar.gz  
ln -s /etc/suricata/rules/reference.config /etc/suricata/reference.config  
ln -s /etc/suricata/rules/classification.config /etc/suricata/classification.config  
cp /etc/suricata/rules/suricata-1.2-prior-open.yaml /etc/suricata/suricata.yaml

Lancez Suricata en mode surveillance sur l’interface eth0 :

suricata -c /etc/suricata/suricata.yaml -i eth0

Laissez-le tourner quelques minutes puis vérifiez /var/log/suricata/stats.log et /var/log/suricata/http.log. Générer du trafic (ouvrir un navigateur) pour valider la capture.

Préparer Vuurmuur pour l’usage IPS

Pour qu’un IPS inspecte le trafic, il faut faire transiter les paquets à Suricata. Nous utiliserons Vuurmuur pour gérer iptables et rediriger vers NFQUEUE.

Ouvrez l’interface de configuration : vuurmuur_conf. Dans Rules, ajoutez une règle accept par défaut pour vérifier le flux :

accept service any from any to any log

La règle ressemble à ceci :

Alt text réécrit en français : Capture d'écran : règle Vuurmuur

Ensuite, ajoutez une interface dans Interfaces. Donnez-lui un nom et mettez device = “eth0” :

Alt text réécrit en français : Capture d'écran : ajout de l'interface eth0 dans Vuurmuur

Quittez vuurmuur_conf.

Adapter rsyslog pour Vuurmuur

Pour que le visualiseur de logs de Vuurmuur fonctionne, ajoutez la ligne suivante à /etc/rsyslog.conf :

*.debug /var/log/debug

Redémarrez rsyslog :

service rsyslog restart

Démarrez Vuurmuur :

service vuurmuur start

Assurez-vous qu’il démarre au boot :

systemctl enable vuurmuur.service

Ouvrez vuurmuur_conf, allez dans le logviewer et vérifiez que le trafic apparaît :

Alt text réécrit en français : Capture d'écran : visualiseur de logs de Vuurmuur montrant du trafic réseau

Rediriger le trafic vers Suricata (NFQUEUE)

Changez la règle Vuurmuur pour passer à NFQUEUE :

nfqueue service any from any to any

La règle ressemble à :

Alt text réécrit : Capture d'écran : règle Vuurmuur envoyant le trafic vers NFQUEUE

Appliquez les changements dans vuurmuur_conf. Le visualiseur montrera que les paquets sont redirigés :

Alt text réécrit : Capture d'écran : log Vuurmuur indiquant redirection vers NFQUEUE

Démarrez Suricata en mode inline avec la file 0 :

suricata -c /etc/suricata/suricata.yaml -q0

Testez la navigation et vérifiez /var/log/suricata/stats.log et /var/log/suricata/http.log pour confirmer l’inspection profonde.

Extrait de stats.log (exemple) :

-------------------------------------------------------------------
Date: 10/8/2012 -- 17:20:08 (uptime: 0d, 01h 39m 02s)
-------------------------------------------------------------------
Counter                   | TM Name                   | Value
-------------------------------------------------------------------
decoder.pkts              | Decode1                   | 3147
... (truncated)
detect.alert              | Detect                    | 0

Extrait de http.log (exemple) :

10/08/2012-17:24:02.447292 www.howtoforge.com [] / [] Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0.1 [] 192.168.122.48:48396 -> 188.40.16.205:80

Démarrer Suricata comme service et l’activer au boot

Arrêtez la session manuelle (Ctrl+C) et éditez /etc/sysconfig/suricata pour ajouter les options système :

OPTIONS="-q 0 -D --pidfile /var/run/suricata.pid"

Puis lancez le service et activez-le au démarrage :

service suricata start
systemctl enable suricata.service

Passer de l’IDS à l’IPS et bloquer des connexions

Par défaut, les règles téléchargées sont en mode alert (aucun blocage). Pour bloquer, activez l’inline stream reassembly dans suricata.yaml : recherchez la section stream et mettez inline: yes (exemple ci‑dessous montre memcap 32 Mo) :

stream:
  memcap: 32mb
  checksum_validation: yes      # reject wrong csums
  inline: yes

Ajoutez un fichier local.rules dans /etc/suricata/rules/ et référez‑le depuis suricata.yaml :

default-rule-path: /etc/suricata/rules/
rule-files:
 - local.rules
 - emerging-ftp.rules
 - emerging-policy.rules

Créez /etc/suricata/rules/local.rules et ajoutez par exemple une règle de blocage simple :

drop tcp any any -> any any (msg:"facebook is blocked"; content:"facebook.com"; http_header; nocase; classtype:policy-violation; sid:1;)

Redémarrez Suricata :

service suricata restart

Ouvrez ensuite http://www.facebook.com/ depuis un poste client ; la requête doit se terminer par un timeout si le blocage fonctionne.

Le fichier /var/log/suricata/fast.log contiendra des entrées de type :

10/06/2012-11:40:49.018377  [Drop] [] [1:1:0] facebook is blocked [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 192.168.122.48:57113 -> 173.252.100.16:80

Tests et critères de réussite

Suricata capture des paquets sur l’interface choisie (vérifier stats.log).
Les logs HTTP montrent les requêtes (http.log).
Un drop configuré apparaît dans fast.log et la requête côté client échoue.
Les services Vuurmuur et Suricata démarrent correctement au boot.

Quand ça peut échouer (contre‑exemples)

NFQUEUE non activé dans la pile iptables : Suricata ne voit rien.
Suricata en mode utilisateur sans droits suffisants : pas d’accès à l’interface.
Règles mal formées ou conflit de priorité : blocages inattendus.
Haute charge réseau sans tuning : Suricata peut faire chuter les performances.

Bonnes pratiques et durcissement

Testez toujours en IDS avant d’activer l’inline/IPS.
Utilisez une file NFQUEUE dédiée et limitez le nombre de règles inline coûteuses.
Tenez à jour vos règles (gestion via oinkmaster ou gestionnaires modernes).
Surveillez les SLIs basiques : latence réseau, taux de paquets décodés, drops par saturation.
Limitez la taille de memcap en fonction de la RAM (exprimé en Mo).
Restreignez l’interface d’administration de Vuurmuur et les accès SSH.

Alternatives et approches complémentaires

Utiliser un switch capable de SPAN (port mirroring) pour surveiller hors ligne plutôt qu’inline.
Employer un appliance dédiée (ex. pfSense + Suricata) pour séparer fonctions réseau et analyse.
Remplacer Vuurmuur par une gestion manuelle d’iptables/nftables ou par Firewalld selon préférence.

Mini‑méthodologie de déploiement (checklist rapide)

Sauvegarde et snapshot de la machine.
Installer Suricata et Vuurmuur.
Tester Suricata en IDS.
Configurer Vuurmuur pour NFQUEUE.
Activer inline et charger local.rules.
Monitorer logs et métriques, ajuster memcap et règles.

Rôles et tâches (checklist par rôle)

Administrateur système : installer paquets, configurer services systemd, sauvegardes.
SecOps / analyste SOC : gérer règles, interpréter alertes, tester faux positifs.
Réseau : configurer interfaces, vérifier MTU et mirroring si nécessaire.

Critères d’acceptation (tests)

Les règles de blocage provoquent un Drop et une entrée correspondante dans fast.log.
Les flux légitimes ne subissent pas de latence excessive après activation IPS.
Les services redémarrent automatiquement après reboot.

Fiche pratique — chiffres clés (qualitatifs)

Memcap recommandé pour tests : 32 Mo (ajuster selon RAM).
Mode conseillé en début de déploiement : IDS puis IPS après validation.
Surveillance : stats.log, fast.log, http.log, et le logviewer Vuurmuur.

Migration et compatibilité

Fedora 17 est ancienne : si vous migrez vers une version plus récente, vérifiez la compatibilité des paquets Suricata et Vuurmuur, et adaptez les chemins de configuration et unités systemd.

Résumé

Ce guide montre la mise en place d’un IPS avec Suricata et Vuurmuur sur Fedora 17 : installation, test IDS, redirection via NFQUEUE, activation inline et blocage avec une règle simple. Testez toujours en IDS, surveillez les logs et ajustez les ressources.

Important — un IPS peut interrompre le service réseau si mal configuré. Procédez par étapes et conservez un accès console hors bande.

Lectures recommandées :

Suricata User Guide
Gestion de règles avec oinkmaster
Vuurmuur User Guide