Syslog Sophos Firewall : envoi sécurisé vers un SIEM

Avec Syslog, Sophos Firewall envoie des événements à un serveur de logs externe, un SIEM ou un SOC. Pour que l’intégration soit réellement exploitable, quatre éléments doivent correspondre : le transport, la sélection des logs, le format et l’analyseur. Cet article commence donc directement par la configuration, puis montre comment identifier les logs manquants ou mal interprétés.

Le Log viewer local reste important pour l’analyse en direct. Central Firewall Reporting convient aux rapports dans Sophos Central ; Syslog est le bon choix pour une conservation gérée en interne, une corrélation multifournisseur et la détection SIEM.

Configurer le serveur Syslog

Il faut d’abord définir l’adresse IP ou le FQDN de destination, le port, le transport, le format de log attendu et un analyseur adapté. Le pare-feu doit disposer d’une route vers le collecteur et les deux systèmes d’une source de temps fonctionnelle. UDP 514 est courant ; TCP 6514 est souvent utilisé avec TLS, mais la configuration du collecteur fait foi.

Ouvrir System services > Log settings.
Sélectionner Add.
Saisir un nom unique tel que siem-primary.
Saisir le collecteur sous IP address/domain.
Sélectionner Port, Facility, Severity level et Format en fonction du système de destination.
Activer Secure log transmission si le collecteur TLS est prêt.
Enregistrer.
Sous Log settings, activer les types de logs souhaités dans la colonne de ce serveur Syslog.

SFOS prend en charge jusqu’à cinq serveurs Syslog externes. Plusieurs destinations sont utiles lorsqu’elles remplissent des rôles différents, par exemple une archive locale et un collecteur MDR. Envoyer tous les logs sans distinction vers chaque destination augmente en revanche le volume, les coûts et les risques liés à la protection des données.

Facility, niveau de gravité et format

Facility : LOCAL0 à LOCAL7 permettent de distinguer les pare-feu ou les groupes de sites. L’affectation doit être identique dans le collecteur et dans la documentation.
Severity level : la sélection correspond à la gravité minimale. Error envoie également Critical, Alert et Emergency, mais aucun événement Information ou Notice. Des connexions et des événements de fonctionnement normaux peuvent ainsi manquer.
Format : les options disponibles sont Standard syslog protocol et Device standard format (legacy). Le format attendu par l’analyseur SIEM est déterminant. Un changement ultérieur peut casser les recherches, les tableaux de bord et les règles de détection.

Secure log transmission

TLS est pertinent pour les connexions de production passant par des réseaux non fiables ou partagés, car les logs peuvent contenir des adresses internes, des noms d’utilisateur, des URL et des événements de sécurité. Cocher la case ne suffit toutefois pas : le collecteur doit accepter TLS sur le port sélectionné et les deux côtés doivent pouvoir valider les certificats.

Les conditions suivantes s’appliquent à la connexion Secure Syslog documentée par Sophos :

Le certificat de serveur du collecteur et sa chaîne de certificats doivent être approuvés par le pare-feu.
Le FQDN configuré doit correspondre au certificat. Sans LINCE, SFOS vérifie le Common Name ; avec LINCE, le Common Name ou le Subject Alternative Name peut correspondre.
Télécharger l’autorité de certification Sophos Default sous Certificates > Certificate authorities. Le collecteur doit approuver le fichier Default.pem extrait, car Sophos utilise cette autorité de certification pour son côté de la connexion.
Activer ensuite seulement Secure log transmission avec le port TLS préparé.

Dans l’exemple officiel syslog-ng, Default.pem et l’autorité de certification externe se trouvent dans le répertoire des autorités de certification du collecteur ; peer_verify(required-trusted) impose la validation des certificats. Les autres produits de collecte utilisent leurs propres magasins de confiance. Un FQDN présent uniquement dans le SAN ne fonctionne pas sans LINCE, et une adresse IP configurée ne correspond pas à un certificat qui contient uniquement un nom DNS.

Si un SIEM cloud ne prend pas directement en charge cette méthode, le pare-feu peut envoyer les logs en interne à un collecteur local, qui les retransmet ensuite de manière chiffrée. Un éventuel segment non chiffré doit être court, segmenté et documenté.

Définir les types de logs et leur visibilité

La destination est activée en deux étapes :

La règle ou la fonction concernée doit générer l’événement. Les règles de pare-feu nécessitent Log firewall traffic et les règles d’inspection SSL/TLS Log connections.
Sous System services > Log settings, le type de log correspondant doit être sélectionné dans la colonne du serveur Syslog.

Si l’une des deux étapes manque, le collecteur ne peut pas recevoir l’événement. Un ensemble volontairement limité suffit pour un pilote :

Firewall et Events : événements de règles, activité des administrateurs et des utilisateurs, ainsi que des événements d’authentification, VPN, DHCP et DNS.
IPS, Content filtering, Web server protection et Zero-day protection : décisions de sécurité et de stratégie.
Active threat response : correspondances de MDR, NDR Essentials, Sophos X-Ops et Third-Party Threat Feeds.
System health, Wireless, Heartbeat et SD-WAN : état opérationnel supplémentaire lorsque ces modules sont utilisés.

Les autres modules ne sont ajoutés que s’ils répondent à un besoin de recherche, d’alerte ou d’audit. Pour analyser les événements DoS, il faut également vérifier la configuration contre l’usurpation et les DoS. Les Third-Party Threat Feeds ainsi que NDR et Active Threat Response nécessitent, en plus du transport des logs, des requêtes de recherche et des alertes concrètes.

Pièges fréquents concernant la visibilité

Log Suppression : SFOS peut regrouper des événements de pare-feu identiques et consécutifs. Cela affecte Log Viewer, Sophos Central et Syslog. Les analyseurs et les détections doivent donc également tenir compte de log_occurrence.
Active Threat Response : Remote Source Match pour le trafic DNAT ou WAF entrant n’est pas activé par défaut. Sans cette sélection, les correspondances de sources concernées manquent.
Wireless : les logs des points d’accès et des SSID ne sont pas disponibles dans le Log Viewer local. Ils doivent être envoyés de manière ciblée à Sophos Central ou à Syslog et y être contrôlés.
Content filtering et SSL/TLS : le type de log sélectionné ne remplace pas la journalisation dans la règle de pare-feu ou d’inspection correspondante.

Vérifier le format et l’analyseur

Un test d’analyseur ne doit pas seulement démontrer qu’un texte quelconque arrive. Les valeurs essentielles doivent pouvoir être recherchées comme des champs distincts. Cet exemple abrégé et anonymisé correspond au Standard syslog protocol pour un événement de règle de pare-feu :

device_name="BRANCH-01" timestamp="2026-08-03T09:15:21+0200" device_model="XGS136" device_serial_id="C00000000000000" log_id="010101600001" log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" log_version=1 severity="Information" fw_rule_id="12" fw_rule_name="LAN_to_WAN_Web" nat_rule_id="4" src_ip="10.10.20.25" dst_ip="203.0.113.10" protocol="TCP" src_port=53144 dst_port=443 con_event="Stop" log_occurrence="1"

Le format legacy utilise en revanche notamment device, date, time, timezone, device_id et priority. Des champs tels que status, user_name, nat_rule_id ou log_occurrence dépendent en outre du type de log et de l’événement. Ils ne doivent pas être considérés comme obligatoires pour chaque événement au format standard.

Selon le cas d’usage, les champs suivants sont particulièrement importants pour la recette :

Identité : device_name, device_model, device_serial_id
Classification : log_id, log_type, log_component, log_subtype, severity
Stratégie : fw_rule_id, fw_rule_name, nat_rule_id
Connexion : src_ip, dst_ip, ports, protocole et utilisateur
Temps et fréquence : timestamp, fuseau horaire et log_occurrence

log_id contient le type de log, le composant, le sous-type, la gravité et l’ID de message. Les règles de détection sont ainsi plus stables que de simples recherches en texte libre. Les champs fournis par un module particulier doivent néanmoins être vérifiés à l’aide d’un événement réel de ce type de log.

Le module Syslog Events n’est pas identique à configuration-audit.log. Les valeurs avant/après n’y sont disponibles que pour les objets clés pris en charge, tels que les règles de pare-feu, les interfaces et les hôtes IP, et non pour chaque modification de configuration. La portée et l’analyse sont traitées dans l’article consacré aux logs Audit Trail.

Plusieurs pare-feu et HA

Dans un environnement comportant plusieurs appliances, chaque événement doit pouvoir être attribué clairement à un pare-feu, un site, un client et un cluster HA. Le nom d’hôte, le numéro de série, le modèle et le champ Facility doivent donc être documentés et filtrables dans le SIEM.

Après un basculement HA, une restauration ou un remplacement matériel, il faut vérifier si les événements restent affectés à l’asset existant ou apparaissent comme un système nouveau ou dupliqué. Il en va de même après une modification du nom d’hôte ou du format Syslog.

Tester l’intégration avec des événements réels

Un état vert du collecteur ne prouve ni que les bons logs sont sélectionnés ni que l’analyseur fonctionne. Pour la recette :

Documenter un pare-feu pilote et le format configuré.
Envoyer d’abord Firewall et Events vers la destination.
Déclencher une règle de test journalisée avec une source, une destination et un service définis.
Vérifier dans le SIEM l’appareil, l’heure, le type de log, l’action, le Rule ID, la source et la destination.
Générer un blocage défini ainsi qu’une connexion et une déconnexion VPN.
Tester au moins un événement de sécurité provenant de IPS, Content filtering ou Active threat response, à condition que le module soit utilisé en production.
Activer ensuite progressivement d’autres types de logs et observer le volume ainsi que le résultat de l’analyseur.

Pour le test des règles, consulter le guide sur Log Viewer, Policy Test et Packet Capture. Un test négatif est également important : une connexion attendue est volontairement bloquée et doit apparaître comme un blocage avec la bonne règle.

Pour les projets HA ou de migration, la recette doit inclure un test de basculement, de restauration ou de remplacement matériel. Le SOC doit ensuite toujours pouvoir déterminer quel appareil et quel site ont généré l’événement.

Exploitation, conservation et pannes

Une intégration Syslog doit avoir un responsable, une durée de conservation définie et une procédure de réaction aux alertes. Il faut également préciser qui évalue les faux positifs et adapte les règles de détection. Les logs du pare-feu peuvent contenir des données personnelles, des adresses internes, des noms d’utilisateur, des URL et des activités VPN. Les droits d’accès, les délais de suppression, la séparation des clients et les coûts du SIEM doivent donc être clarifiés avant un déploiement à grande échelle.

L’exploitation doit détecter non seulement les attaques, mais aussi l’absence de données :

Surveiller un niveau d’activité minimal attendu pour chaque pare-feu.
Contrôler séparément la fraîcheur des types de logs importants comme Firewall, Events, IPS ou Active threat response.
Surveiller les champs centraux de l’analyseur afin de détecter les valeurs vides ou soudainement renommées.
Surveiller par des alertes l’expiration des certificats et l’état du collecteur.
Générer à nouveau des événements de test après les mises à jour du firmware, de l’analyseur et des certificats.

La surveillance elle-même doit également être testée : si les données d’un type de log attendu ou d’un pare-feu sont volontairement interrompues, l’alerte de panne définie doit se déclencher.

Des données brutes sans champs analysés constituent également une panne. Une mise à jour de l’analyseur peut laisser le transport intact alors que les tableaux de bord et les règles de détection ne renvoient plus aucun résultat.

Syslog ne remplace ni les logs de service locaux ni une archive de dépannage pour le support. sFlow convient aux flux de trafic plutôt qu’aux événements individuels ; l’état du matériel et des interfaces peut en outre être surveillé avec SNMP.

Isoler les erreurs de manière ciblée

Aucun log n’arrive : vérifier la destination, le port, le transport, le routage et le pare-feu distant. Contrôler ensuite si le type de log souhaité est activé dans la colonne Syslog. Si le collecteur se trouve derrière un VPN ou un réseau de management, tenir également compte de la route, de la stratégie SD-WAN et du Source NAT.

Seuls certains événements manquent : vérifier d’abord la journalisation dans la règle de pare-feu ou d’inspection concernée, puis le type de log sous Log settings. Pour ATR, contrôler également le type de correspondance requis.

Les logs bruts arrivent, mais des champs manquent : comparer le format configuré, la version de l’analyseur et la version du firmware. Les champs standard et legacy ne doivent pas être attendus dans le même profil d’analyseur.

TLS ne se connecte pas : vérifier le port TLS et le service du serveur, puis la chaîne de certificats, le FQDN, le Common Name, le SAN et le mode LINCE. Le collecteur doit en outre approuver l’autorité de certification Sophos Default.pem. Lors des changements de certificats, contrôler les deux magasins de confiance et le processus de renouvellement.

Les horodatages sont incorrects : vérifier NTP sur le pare-feu et le collecteur, le fuseau horaire du SIEM ainsi que la normalisation de l’analyseur. Des heures incorrectes empêchent une corrélation fiable avec les logs des endpoints, des serveurs et des identités.

Trop de logs ou trop de bruit : ne pas tout désactiver sans distinction. Évaluer d’abord les types de logs inutilisés, les règles inutilement bruyantes, les cas d’usage SIEM et log_occurrence, puis réduire la sélection de manière ciblée.