Superviser pfSense avec Zabbix et envoyer ses journaux à Wazuh

Superviser pfSense, c'est mesurer en continu son état (processeur, mémoire, table d'états, débit et erreurs des interfaces, services) pour être alerté avant la panne, et collecter ses journaux pour détecter les attaques et pouvoir enquêter. Dans le laboratoire de Sorbier, Zabbix interroge le pare-feu en SNMP et Grafana en fait des tableaux de bord, tandis que Wazuh reçoit ses journaux par syslog et lève des alertes de sécurité. Ce chapitre configure les deux chaînes, côté pfSense et côté serveurs.

Deux besoins, deux outils

Avant d'équiper des outils externes, pfSense a ses propres écrans : Status > Dashboard (charge, mémoire, états, interfaces), Status > Monitoring (graphiques historiques), Status > Traffic Graph (débit en temps réel par interface et par machine). Ils servent au dépannage ; ils ne préviennent personne la nuit.

Activer SNMP sur pfSense

pfSense contient un agent SNMP (le démon bsnmpd de FreeBSD), configurable dans Services > SNMP :

L'agent intégré fonctionne avec une communauté, en SNMP v2c : la communauté circule en clair. On compense en limitant l'exposition : l'agent n'écoute que sur l'interface SERVEURS, une seule règle autorise srv-journaux à l'interroger (règle 3 de l'onglet SERVEURS, chapitre 5), et le flux reste dans le VLAN des serveurs. Pour du SNMPv3, chiffré et authentifié, le paquet net-snmp existe, mais il ne connaît pas les compteurs du filtre pf ; l'autre option est le paquet Zabbix-agent, dont les échanges avec le serveur se chiffrent avec une clé partagée (PSK).

Teste depuis srv-journaux (paquet snmp), avec des identifiants numériques pour ne pas dépendre des fichiers MIB :

# Description du système : doit renvoyer une chaîne qui mentionne pfSense et FreeBSD
snmpget -v2c -c '<communauté>' 192.168.10.188 1.3.6.1.2.1.1.1.0
# Les compteurs du filtre pf (branche BEGEMOT-PF-MIB)
snmpwalk -v2c -c '<communauté>' 192.168.10.188 1.3.6.1.4.1.12325.1.200

Les adresses sont celles de pf1 en grappe (chapitre 13) : on supervise chaque pare-feu à son adresse propre (.188 pour pf1, .189 pour pf2), jamais l'adresse virtuelle, qui répondrait tantôt pour l'un, tantôt pour l'autre. Avec un seul pare-feu, l'adresse est 192.168.10.190.

Ajouter pfSense dans Zabbix

Zabbix fournit un modèle officiel pour pfSense, PFSense by SNMP. Dans l'interface de Zabbix 7.0 LTS : Data collection > Hosts > Create host :

Le modèle découvre les interfaces et collecte notamment :

Ses déclencheurs (triggers) préviennent par exemple quand une interface tombe, quand le taux d'occupation de la table d'états dépasse un seuil, ou quand le pare-feu ne répond plus en SNMP. L'envoi des alertes (courriel, messagerie d'équipe) et l'organisation de la supervision sont expliqués dans le cours Supervision.

Un tableau de bord Grafana

Grafana ne collecte rien : il affiche des données stockées ailleurs. Avec le greffon Zabbix pour Grafana (alexanderzobnin-zabbix-app), il lit les mesures de Zabbix par son API :

# Sur srv-journaux, Grafana 13 : installer le greffon, puis redémarrer Grafana
sudo grafana cli plugins install alexanderzobnin-zabbix-app
sudo systemctl restart grafana-server

Il reste à activer l'application dans Grafana, à créer une source de données Zabbix (URL de l'API de Zabbix, jeton d'API d'un compte Zabbix en lecture seule), puis un tableau de bord « Pare-feu » : débit du WAN, occupation de la table d'états, charge et mémoire de pf1 et pf2, trafic bloqué par interface. C'est l'écran qu'on affiche dans le bureau du service informatique, et une bonne illustration pour l'oral de l'E6.

Envoyer les journaux à Wazuh

Côté pfSense : Status > System Logs > Settings, section Remote Logging Options :

Garde le format de message par défaut, BSD (RFC 3164), dans les réglages généraux de la même page : c'est celui que les décodeurs de Wazuh reconnaissent. Les alertes de Suricata partent aussi si l'option Send Alerts to System Log est cochée sur ses interfaces (chapitre 12).

Côté Wazuh : le serveur doit accepter le syslog du pare-feu. Dans /var/ossec/etc/ossec.conf sur srv-journaux, ajoute un bloc remote à côté de celui des agents :

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
  <allowed-ips>192.168.10.188</allowed-ips>
  <allowed-ips>192.168.10.189</allowed-ips>
  <!-- les équipements du VLAN ADMIN : switchs, bornes -->
  <allowed-ips>192.168.10.208/28</allowed-ips>
  <local_ip>192.168.10.180</local_ip>
</remote>

allowed-ips est obligatoire : Wazuh n'accepte le syslog que des adresses listées (ici pf1 et pf2, avec un seul pare-feu 192.168.10.190, et le réseau ADMIN, dont les switchs et les bornes envoient leur syslog par la règle 6 de l'onglet ADMIN). Redémarre le service : sudo systemctl restart wazuh-manager.

Ce que Wazuh fait des journaux de pfSense

Le jeu de règles livré avec Wazuh contient un décodeur pf pour les lignes du programme filterlog (le journal du filtre, chapitre 5), qui en extrait l'action, le protocole, les adresses et les ports, et des règles dédiées :

Un blocage isolé est du bruit de fond (Internet balaie en permanence le WAN) ; une rafale depuis la même source mérite une alerte. Pour vérifier le décodage, l'outil /var/ossec/bin/wazuh-logtest du serveur Wazuh accepte une ligne collée à la main et affiche le décodeur et la règle qui correspondent.

On complète avec ses propres règles, dans /var/ossec/etc/rules/local_rules.xml. Par exemple, une alerte à chaque échec de connexion à l'interface web du pare-feu, que pfSense journalise avec le message « webConfigurator authentication error » :

<group name="pfsense,local,">
  <rule id="100200" level="10">
    <match>webConfigurator authentication error</match>
    <description>pfSense : échec de connexion à l'interface d'administration</description>
    <group>authentication_failed,</group>
  </rule>
</group>

Les identifiants de 100000 à 120000 sont réservés aux règles locales. Teste la règle avec wazuh-logtest, puis redémarre wazuh-manager.

Exercices