Paquets pfSense : pfBlockerNG et Suricata

Les paquets sont des extensions officielles qui ajoutent des fonctions à pfSense depuis System > Package Manager. Les deux plus utiles en sécurité sont pfBlockerNG, qui bloque des adresses IP et des domaines selon des listes de réputation (filtrage DNS compris), et Suricata, un système de détection et de prévention d'intrusion (IDS/IPS) qui analyse le contenu du trafic avec des signatures. Ce chapitre explique comment les installer, les régler sans couper le réseau, et les exploiter de façon défensive ; il passe aussi en revue les autres paquets du cours.

Le gestionnaire de paquets

System > Package Manager a deux onglets : Installed Packages (les paquets installés, leur version, le bouton de mise à jour quand une version plus récente existe) et Available Packages (le catalogue, avec un champ de recherche). Un clic sur Install, une confirmation, et le menu du paquet apparaît (dans Firewall, Services, Status ou VPN selon le paquet).

Trois règles d'hygiène : chaque paquet est du code de plus exposé, donc n'installe que ce qui sert ; mets les paquets à jour avec le système (un pfSense mis à jour avec un paquet ancien est une source classique de pannes) ; et lis les avertissements du catalogue. Les paquets Squid, SquidGuard et Lightsquid sont marqués dépréciés par Netgate dans pfSense CE comme dans Plus, qui recommande de les désinstaller : les tutoriels de proxy web sur pfSense qui s'appuient sur eux sont périmés.

La configuration des paquets est enregistrée dans config.xml avec le reste : après une restauration, pfSense réinstalle automatiquement les paquets qui y figurent (chapitre 14).

pfBlockerNG : bloquer selon la réputation

pfBlockerNG (NG pour next generation) télécharge régulièrement des listes publiées par des organismes de sécurité et les applique de deux façons :

• IP : des listes d'adresses malveillantes (serveurs de commande de logiciels malveillants, sources d'attaques connues) deviennent des alias que pfBlockerNG insère dans des règles de blocage, en entrée sur le WAN et en sortie depuis les réseaux internes. Il peut aussi filtrer par pays (GeoIP), à partir de la base MaxMind, qui demande une clé de licence gratuite à créer sur le site de MaxMind ;
• DNSBL (DNS blocklist) : des listes de domaines (publicité, pistage, hameçonnage, logiciels malveillants) sont chargées dans le résolveur Unbound. Une requête pour un domaine listé reçoit une adresse factice, celle d'un petit serveur web de pfBlockerNG (par défaut 10.10.10.1), au lieu de la vraie adresse.

Installation : System > Package Manager > Available Packages, pfBlockerNG (la variante pfBlockerNG-devel suit le développement). Puis Firewall > pfBlockerNG : l'assistant de première configuration demande l'interface d'entrée (WAN), les interfaces internes à protéger, et l'adresse du serveur DNSBL. Ensuite :

1. Onglet Feeds : choisis des listes reconnues, catégorie par catégorie, plutôt que d'en empiler des dizaines (plus de listes, plus de faux positifs et de mémoire).
2. Onglet IP : active les listes IP choisies, action Deny Both (entrée et sortie) ou Deny Inbound selon la liste.
3. Onglet DNSBL : active le DNSBL et les listes de domaines.
4. Onglet Update : lance la première mise à jour ; elles se répètent ensuite selon la fréquence choisie (une fois par heure ou par jour).
5. Onglet Reports : les blocages, par adresse, par domaine, par liste.

Le cas de Sorbier. Grâce au montage du chapitre 8, toutes les requêtes DNS vers Internet passent par le résolveur du pare-feu : le DNSBL protège ainsi tous les postes, sans rien configurer sur eux. Un salarié qui clique sur un lien d'hameçonnage tombe sur la page de blocage au lieu du faux site.

Les faux positifs. Un domaine légitime bloqué (le site d'un transporteur partenaire, un service de mise à jour) se débloque en l'ajoutant à la liste blanche (Whitelist du DNSBL, ou bouton de suppression dans l'onglet Reports). Garde une trace de chaque exception et de sa raison.

Suricata : détecter les intrusions

Suricata analyse le contenu des paquets et le compare à des milliers de signatures décrivant des attaques connues, des balayages, des communications de logiciels malveillants ou des usages interdits. Là où une règle de pare-feu dit « TCP 443 vers srv-web autorisé », une signature reconnaît, dans un flux autorisé en clair (HTTP), une tentative d'injection ou un outil d'attaque. Sur du HTTPS, Suricata ne voit que les métadonnées TLS (nom de serveur demandé, certificat, empreinte de la négociation), sauf si un proxy inverse déchiffre et parle en HTTP au serveur. Le fonctionnement des IDS/IPS, des signatures et des méthodes de détection est expliqué dans le cours Cybersécurité des infrastructures.

Installation : System > Package Manager, paquet Suricata. Puis Services > Suricata :

1. Onglet Global Settings : coche le téléchargement des règles ETOpen (Emerging Threats Open, gratuites) ; les règles de Snort demandent un code d'abonné (Oinkcode), gratuit pour les règles communautaires. Fréquence de mise à jour : toutes les 12 ou 24 heures. Durée de blocage des adresses fautives (Remove Blocked Hosts Interval) : une heure, par exemple.
2. Updates : lance le premier téléchargement des règles.
3. Onglet Interfaces : Add, interface DMZ, Enable, Send Alerts to System Log coché (les alertes partent avec les journaux vers Wazuh), Block Offenders décoché pour commencer. Vérifie la variable Home Net : les réseaux internes à protéger.
4. Dans l'interface créée, onglet Categories : choisis les catégories de signatures utiles (attaques web, logiciels malveillants, balayages, exploits) plutôt que tout activer.
5. Démarre l'interface (icône de lecture) et regarde l'onglet Alerts.

Où placer Suricata

Chez Sorbier, deux interfaces : DMZ et SERVEURS. Chacune consomme du processeur et de la mémoire : compte 4 vCPU et au moins 4 Gio pour pf1 (chapitre 2).

Passer de la détection au blocage

On n'active jamais le blocage le premier jour. La démarche :

1. Observer une à deux semaines en mode IDS. Pour chaque alerte récurrente, décider : vraie attaque, ou faux positif (une application métier qui ressemble à une attaque, un outil d'administration).
2. Affiner : supprimer les signatures qui produisent des faux positifs pour une adresse précise (bouton de suppression dans l'onglet Alerts, qui crée une entrée dans la liste de suppression), désactiver les catégories inutiles.
3. Protéger ce qui ne doit jamais être bloqué : une liste de passage (Pass List) contenant les passerelles, les contrôleurs de domaine, le serveur de supervision, les adresses du pare-feu. Une adresse de la liste ne sera jamais bloquée, même si elle déclenche une alerte.
4. Activer le blocage (Block Offenders, mode Legacy) sur la DMZ d'abord, en bloquant l'adresse source de l'alerte (Which IP to Block : SRC), puis sur SERVEURS.
5. Surveiller l'onglet Blocks et les alertes dans Wazuh, et réviser régulièrement.

Lire une alerte

L'onglet Alerts affiche pour chaque alerte : la date, la priorité, le protocole, la classification (Attempted Information Leak, Web Application Attack, A Network Trojan was detected…), la source et la destination avec leurs ports, l'identifiant de la signature (GID:SID) et sa description. Un clic sur l'identifiant affiche la signature complète.

Pour chaque alerte, quatre questions :

1. Qui attaque qui ? Une adresse d'Internet vers srv-web, ou une adresse interne vers l'extérieur (bien plus grave : une machine interne est peut-être compromise) ?
2. L'attaque a-t-elle pu réussir ? Le serveur visé est-il concerné (une attaque contre un logiciel qu'il n'utilise pas est sans effet) ? A-t-il répondu ? Les journaux du serveur le disent.
3. Est-ce un faux positif ? Le flux correspond-il à un usage légitime connu ?
4. Que faire ? Rien (bruit de fond bloqué), corriger une faille, isoler une machine, ouvrir un incident.

Exercices

Exercice 1 sur 3 Interpréter des alertes Réussi À revoir

Suricata, sur l'interface DMZ, remonte trois alertes. srv-web est publié par les redirections de port du chapitre 6 : HTTPS (443) et HTTP (80, que le serveur redirige vers HTTPS). Pour chaque alerte, dis ce qu'elle signifie et ce que tu fais.

Classification	Source	Destination	Description
Web Application Attack	198.51.100.77:51200	192.168.10.225:80	Tentative d'injection SQL dans un paramètre d'URL
Attempted Information Leak	203.0.113.250:40001	192.168.10.225:80	Analyse automatisée des répertoires du site
A Network Trojan was detected	192.168.10.225:48812	198.51.100.66:443	Communication caractéristique d'un logiciel de prise de contrôle à distance

Voir la réponseMasquer la réponse de l'exercice 1

Les deux premières alertes visent le port 80 : la requête circule en clair, Suricata peut lire l'URL. Sur le port 443, chiffré, il ne la verrait pas.

• Ligne 1 : une adresse d'Internet tente une injection SQL contre le site. Sur le port 80, srv-web répond normalement par une redirection vers HTTPS, sans exécuter l'application : vérifier dans les journaux de srv-web si la requête a abouti (code de réponse, erreurs de base de données) et que l'application utilise des requêtes préparées (cours SQL). Si l'adresse insiste, le blocage de Suricata (après la phase d'observation) ou une règle pfBlockerNG la tiendra à l'écart.
• Ligne 2 : une reconnaissance automatisée, du bruit de fond quotidien pour un site public. Rien à faire de plus que de vérifier qu'aucun répertoire sensible n'est exposé.
• Ligne 3 : la plus grave. C'est srv-web qui ouvre une connexion vers Internet avec la signature d'un logiciel de prise de contrôle : le serveur est probablement compromis. Isoler srv-web, conserver les preuves (instantané de la machine virtuelle, journaux), ouvrir un incident. La connexion est chiffrée (port 443) : la signature ne lit pas son contenu, elle reconnaît les métadonnées TLS (empreinte de la négociation, certificat, nom demandé) ou la réputation de la destination. Cette connexion n'aurait d'ailleurs pas dû être possible : la règle de mises à jour de la DMZ ne vise que DEPOTS_MAJ ; il faut vérifier pourquoi elle a pu partir (alias trop large, règle ajoutée).

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 3 Le lundi sans session Réussi À revoir

Lundi à 8 h 30, plus personne n'ouvre de session. Suricata est actif en mode bloquant sur l'interface SERVEURS depuis vendredi. L'onglet Blocks contient 192.168.10.177, ajouté à 8 h 12 après l'alerte « trafic SMB inhabituel ».

1. Explique l'enchaînement.
2. Que fais-tu tout de suite, puis pour que cela ne se reproduise pas ?

Voir la réponseMasquer la réponse de l'exercice 2

1. Une signature a vu dans le trafic de srv-ad (les postes qui lisent SYSVOL en SMB au démarrage) un motif qu'elle juge suspect : faux positif. En mode Legacy, Suricata a ajouté l'adresse source de l'alerte, le contrôleur de domaine, à sa liste de blocage : plus aucune machine ne le joint à travers le pare-feu, donc plus d'ouverture de session.
2. Tout de suite : retirer 192.168.10.177 de l'onglet Blocks. Ensuite : créer une liste de passage (contrôleurs de domaine, passerelles, serveurs critiques) et l'associer à l'interface ; supprimer la signature en cause pour ce trafic ; revenir en mode IDS sur SERVEURS le temps d'une vraie phase d'observation. Le blocage avait été activé sans observation préalable : c'est l'erreur de méthode.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 3 Choisir son outil Réussi À revoir

Pour chaque besoin, dis s'il relève d'une règle de pare-feu, de pfBlockerNG ou de Suricata : (1) empêcher les postes de joindre des domaines d'hameçonnage connus ; (2) détecter une tentative d'injection dans une requête HTTPS autorisée vers srv-web ; (3) interdire au Wi-Fi invité de joindre les serveurs ; (4) refuser les connexions entrantes depuis des adresses classées malveillantes ; (5) repérer un poste interne qui communique avec un serveur de commande de logiciel malveillant.

Voir la réponseMasquer la réponse de l'exercice 3

(1) pfBlockerNG, module DNSBL : le domaine reçoit une adresse factice. (2) Suricata, sur l'interface DMZ : il analyse le contenu, ce qu'une règle ne fait pas (le flux est autorisé). Pour lire une requête HTTPS, il faut qu'elle soit déchiffrée en amont (proxy inverse) ou analysée sur le serveur. (3) Règle de pare-feu sur l'onglet VISITEURS. (4) pfBlockerNG, module IP, liste appliquée en entrée sur le WAN. (5) Suricata (signature de communication) et pfBlockerNG (adresse ou domaine du serveur de commande listé), avec les alertes centralisées dans Wazuh.

Tu avais trouvé ?

Oui, j'avais bonPas encore