Envoyer les journaux Syslog de Sophos Firewall à un SIEM

Avec Syslog, un Sophos Firewall peut envoyer des événements à un serveur de journaux externe, un SIEM ou une plateforme de sécurité. Cela est particulièrement important lorsque les journaux doivent être conservés plus longtemps, recherchés de manière centralisée, corrélés avec d’autres systèmes ou utilisés pour des audits et des réponses aux incidents.

Le Log viewer local est utile pour une analyse rapide directement sur le pare-feu. Central Firewall Reporting est pratique lorsque Sophos Central est utilisé comme plateforme de reporting. Syslog est en revanche le meilleur choix lorsqu’un SIEM propre, un SOC, un processus de détection géré ou une architecture de journaux multi-fournisseurs est en place.

Quel article de journalisation est adapté ?

La journalisation sur Sophos Firewall se compose de plusieurs niveaux. Selon la question, Syslog n’est pas toujours le meilleur point de départ :

Ainsi, l’évaluation reste claire : le Log Viewer répond aux cas de paquets ou de politiques actuels, les journaux locaux aident au diagnostic de module plus approfondi, le Central Reporting est pratique pour les évaluations Sophos, et Syslog fournit la couche externe à long terme et SIEM.

Quand Syslog est-il pertinent ?

Syslog est utile non seulement pour les grandes environnements. Même avec quelques pare-feux, un serveur de journaux central peut aider à conserver les événements plus longtemps et indépendamment de l’appliance.

Cas d’utilisation typiques :

• conservation centrale des journaux sur des semaines, mois ou années
• corrélation avec les journaux des endpoints, serveurs, identités, proxys, cloud ou commutateurs
• cas d’utilisation SIEM pour les attaques, scans de ports, connexions VPN, événements WAF ou détections de flux de menaces
• évaluation externe par SOC, MDR ou équipes de sécurité internes
• traçabilité après mises à jour de firmware, basculement, restauration ou remplacement de matériel
• analyse forensique lorsque les journaux locaux du pare-feu ne suffisent plus

Pour les cas de dépannage urgents, les journaux locaux restent néanmoins importants. Quel fichier journal local appartient à quel module de pare-feu est indiqué dans Dépannage Sophos Firewall : Services et journaux. Si les journaux doivent être sauvegardés pour le support ou une analyse externe, Sauvegarder les journaux Sophos Firewall pour le support et l’analyse est approprié.

Syslog, Central Reporting ou journaux locaux ?

Les trois méthodes répondent à des questions différentes. En pratique, plusieurs d’entre elles sont souvent utilisées en parallèle.

Syslog ne remplace donc pas le Log Viewer. Il le complète. Le Log Viewer montre rapidement quelle règle ou quel module a pris une décision. Syslog garantit que ces informations restent disponibles ultérieurement à l’extérieur.

Prérequis

Avant la configuration, ces points doivent être clarifiés :

• Le serveur Syslog ou SIEM est accessible.
• L’IP de destination ou le FQDN est stable et documenté.
• Le port et le transport sont définis, souvent UDP 514 ou TLS sur un port dédié.
• Le pare-feu peut router et atteindre le serveur Syslog.
• Un parseur approprié ou au moins un stockage brut existe dans le système cible.
• La durée de conservation et les exigences de protection des données sont définies.
• Il est clair quels types de journaux sont réellement nécessaires.

Pour les cibles SIEM externes ou basées sur le cloud, il convient de prêter une attention particulière au chiffrement du transport, à l’IP source, au routage, au DNS et à la vérification des certificats.

Clarifier la protection des données, la conservation et la responsabilité

Syslog n’est pas seulement un transfert technique. Les journaux de pare-feu peuvent contenir des adresses IP internes, des noms d’utilisateur, des systèmes cibles, des URL, des catégories, des connexions VPN, des événements administratifs et des détections de sécurité. Il est donc important de clarifier avant la connexion en production qui peut voir ces données et combien de temps elles seront conservées.

Avant le déploiement, clarifiez :

Surtout dans les modèles MSP, SOC ou MDR, cette responsabilité ne doit pas rester ouverte. Un SIEM sans propriétaires clairs génère des données, mais pas de réaction fiable.

Planifier le déploiement par phases

Pour les pare-feux en production, un petit pilote est préférable à l’envoi immédiat de tous les types de journaux à toutes les cibles. Cela permet de contrôler les parseurs, les noms de champs, le bruit et les coûts avant que le SIEM ne soit planifié comme source fiable.

Un déroulement judicieux :

1. Une première pare-feu pilote est sélectionnée.
2. Le nom d’hôte, la source de temps, la version du firmware et le format des journaux sont documentés.
3. La cible Syslog est configurée avec un transport sécurisé.
4. Le démarrage se fait avec quelques types de journaux, par exemple Firewall, Events et VPN.
5. Des événements de test définis sont générés et vérifiés dans le système cible.
6. Les parseurs, champs, horodatages, fuseau horaire et device_name sont validés.
7. Le volume des journaux et le bruit sont observés sur plusieurs jours.
8. Ensuite, d’autres types de journaux comme IPS, Web, WAF, réponse active aux menaces ou santé du système sont ajoutés.
9. Ce n’est qu’après un pilote réussi que le déploiement est étendu à d’autres pare-feux.

Avec plusieurs pare-feux, il ne suffit pas de vérifier si les données arrivent. Il est important de savoir si chaque événement est correctement attribué au bon site, appareil, nœud HA, client ou locataire.

Ajouter un serveur Syslog

La configuration se fait dans l’interface Web de Sophos Firewall.

1. Ouvrir System services > Log settings.
2. Sélectionner Add.
3. Attribuer un nom unique, par exemple siem-primary ou syslog-soc.
4. Entrer l’adresse IP/domaine du serveur Syslog.
5. Définir le port en fonction du système cible.
6. Choisir la facility de manière consciente.
7. Définir le niveau de sévérité.
8. Sélectionner le format.
9. Activer éventuellement la transmission sécurisée des journaux si la cible prend en charge TLS.
10. Enregistrer.

Sophos Firewall peut configurer plusieurs serveurs Syslog externes. La documentation actuelle prévoit jusqu’à cinq serveurs Syslog. Cependant, il ne faut pas connecter chaque cible au hasard, mais définir pour chaque cible quel est l’objectif.

Réglages importants

Facility

La facility aide le serveur Syslog à distinguer les sources ou catégories de journaux. Dans des environnements simples, une valeur par défaut suffit souvent. Dans des environnements plus grands, il peut être judicieux de séparer les pare-feux ou groupes de sites à l’aide de valeurs LOCAL0 à LOCAL7 différentes.

Il est important que les règles SIEM, les parseurs et la documentation utilisent la même logique. Si chaque pare-feu utilise une facility différente au hasard, l’évaluation devient inutilement difficile.

Niveau de sévérité

La sévérité détermine à partir de quel niveau de gravité les journaux sont envoyés. Pour des raisons de sécurité et de dépannage, un seuil trop élevé est dangereux, car des événements d’information ou de notification importants peuvent manquer. Pour des environnements très bruyants, un seuil trop bas peut générer un bruit inutile.

Un pilote avec une sélection de journaux plus large est généralement judicieux, suivi d’une réduction consciente basée sur de véritables détections et cas d’utilisation SIEM.

Format

Selon la documentation actuelle, Sophos Firewall propose deux formats :

• Protocole syslog standard
• Format standard de l’appareil (héritage)

Pour les nouvelles intégrations, il convient d’abord de vérifier quel format le système cible ou le parseur existant attend. Si un SIEM dispose déjà d’un parseur Sophos Firewall, c’est son attente qui prévaut. Un changement de format après le démarrage en production peut casser les tableaux de bord, les requêtes de recherche et les règles de détection.

Transmission sécurisée des journaux

Lorsque la transmission sécurisée des journaux est activée, les journaux sont envoyés chiffrés au serveur Syslog. Pour cela, le système cible doit accepter TLS sur le port configuré, fournir un certificat serveur approprié et utiliser une chaîne de certificats à laquelle le pare-feu fait confiance. Avant le lancement, il ne suffit donc pas de cocher la case dans le pare-feu, mais il faut également vérifier le nom du certificat, la chaîne de confiance, le port, le parseur et le processus de renouvellement de la cible Syslog.

Pour les laboratoires internes, UDP peut techniquement suffire. Pour les connexions SIEM ou SOC en production, un Syslog non chiffré sur des réseaux non sécurisés n’est cependant pas une bonne base, car les données de journaux peuvent contenir des adresses IP internes, des utilisateurs, des cibles, des URL ou des événements de sécurité.

Avec TLS, le nom de la cible Syslog est important. Selon le mode, Sophos vérifie le Common Name ou le Subject Alternative Name du certificat par rapport au domaine du serveur Syslog. Si une adresse IP est saisie dans le pare-feu, mais que le certificat ne contient qu’un nom DNS, la connexion peut échouer. Il est donc conseillé de planifier un FQDN stable, un certificat serveur approprié et un renouvellement de certificat documenté pour les cibles Syslog TLS en production.

Choisir les types de journaux

Après avoir ajouté le serveur Syslog, le travail n’est pas terminé. Il faut définir sous System services > Log settings quels types de journaux seront envoyés à cette cible.

Important : Une règle de pare-feu ne génère des journaux de trafic utiles que si Log firewall traffic est activé dans la règle. Pour l’inspection SSL/TLS, la journalisation doit également être active dans la règle d’inspection appropriée. La sélection des journaux sous Log settings détermine ensuite où ces journaux sont envoyés.

Types de journaux typiques pour un SIEM :

Si des événements DoS ou de spoofing doivent être évalués, le renforcement technique lui-même doit également être vérifié. Le processus est décrit dans Vérifier la protection contre le spoofing et les paramètres DoS de Sophos Firewall.

Si Third-Party Threat Feeds, NDR et réponse active aux menaces ou WAF sont utilisés, le SIEM doit évaluer ces événements de manière ciblée. Envoyer simplement des journaux ne suffit pas. Il faut des requêtes de recherche claires, des alertes, des responsabilités et un ajustement contre les fausses alertes.

Pièges de visibilité importants

Dans les projets Syslog, de nombreuses lacunes ne se produisent pas dans le transport, mais avant : le pare-feu ne génère pas l’événement attendu, le type de journal n’est pas envoyé au serveur Syslog ou le SIEM interprète mal les champs.

Journalisation des règles et des modules

Les règles de pare-feu et les règles d’inspection SSL/TLS doivent générer elles-mêmes des journaux. Sous System services > Log settings, on choisit ensuite si ces journaux sont envoyés localement, à Sophos Central ou à des serveurs Syslog. Si une règle de pare-feu n’a pas Log firewall traffic, le serveur Syslog ne peut pas afficher un historique complet du trafic de pare-feu.

Pour les événements de politique Web, il est également pertinent de savoir si la règle de pare-feu associée génère des journaux de trafic. Sinon, on peut voir dans le SIEM moins d’événements de filtrage Web ou de contenu que prévu.

Suppression des journaux

Sophos Firewall peut supprimer plusieurs entrées de journal identiques consécutives. Cela économise de l’espace de stockage et du traitement, mais peut être déroutant pour les cas d’utilisation SIEM si des valeurs de comptage, des fréquences ou des comportements de rafale doivent être évalués. La fonction agit sur le Log Viewer, Sophos Central et les serveurs Syslog externes.

Avant un déploiement SIEM en production, il convient donc de définir :

• Quels événements de pare-feu peuvent être supprimés ?
• Quelles règles de détection nécessitent chaque connexion individuelle ?
• Le SIEM travaille-t-il avec des valeurs de comptage ou uniquement avec des événements individuels ?
• Comment documenter que la suppression des journaux est active ?

Réponse active aux menaces

Les journaux de réponse active aux menaces sont particulièrement utiles lorsque des flux de menaces, NDR Essentials ou des flux externes sont utilisés. Sophos distingue différents types de correspondance, par exemple les correspondances de destination pour le trafic sortant et les correspondances de source pour le trafic entrant.

Important : La correspondance de source distante pour le trafic entrant n’est pas activée automatiquement. Si le trafic WAF ou DNAT doit être surveillé par rapport aux flux de menaces, cette visibilité doit être vérifiée consciemment. Sinon, les correspondances entrantes, souvent attendues par un SOC, peuvent manquer.

Journaux sans fil

Les journaux sans fil ne sont pas automatiquement visibles dans le Log Viewer local. Les journaux des points d’accès et des SSID doivent être envoyés spécifiquement à Sophos Central ou Syslog et vérifiés séparément dans le système cible si les événements sans fil sont pertinents pour l’exploitation, le support ou la conformité.

Environnements multi-pare-feux

Dans les environnements avec plusieurs pare-feux, chaque événement doit pouvoir être attribué de manière unique à une appliance. Pour cela, le nom d’hôte, le numéro de série, le modèle et d’autres champs sont pertinents. Le guide Syslog SFOS décrit notamment des champs comme device_name, device_model et device_serial_id.

Recommandations pratiques :

• Définir proprement le nom d’hôte du pare-feu.
• Prendre en compte le site ou le rôle dans le nom d’hôte.
• Définir une stratégie de facility ou de balisage uniforme.
• Vérifier dans le SIEM si les événements peuvent être filtrés par pare-feu, site et cluster.
• Distinguer clairement les clusters HA et les pare-feux autonomes.

Surtout après un remplacement de matériel ou une restauration, cette attribution est importante. Sinon, les événements dans le SIEM peuvent apparaître comme de nouveaux systèmes ou des doublons.

Tester la configuration

Après l’enregistrement, la connexion doit être testée consciemment. Un système cible vert seul ne prouve pas encore que les bons journaux arrivent avec les bons champs.

Points de test :

1. Ouvrir System services > Log settings sur le pare-feu.
2. S’assurer que le serveur Syslog est visible.
3. Activer temporairement Syslog pour un type de journal non critique.
4. Déclencher une action définie, par exemple une règle de pare-feu enregistrée ou un accès de test.
5. Vérifier dans le système cible si l’événement arrive.
6. Vérifier les champs tels que l’heure, le nom d’hôte, device_name, source, destination, ID de règle, action et type de journal.
7. Contrôler les horodatages et le fuseau horaire dans le SIEM.

Pour les tests de règles, Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture est utile. Si aucun événement n’est généré, la cause se trouve souvent non pas dans le transport Syslog, mais dans la journalisation désactivée dans la règle ou dans le mauvais type de journal.

Exploitation et surveillance

Une connexion Syslog n’est pas un simple paramètre à cocher. L’exploitation doit être surveillée et vérifiée régulièrement.

Au minimum, ces points doivent être documentés :

• Qui est le propriétaire de la plateforme de journaux ?
• Quels pare-feux envoient des journaux ?
• Quels types de journaux sont envoyés ?
• Quelle durée de conservation s’applique ?
• Quels parseurs, tableaux de bord et alertes en dépendent ?
• Comment détecter que plus aucun journal n’arrive ?
• Comment les changements de format après les mises à jour de firmware sont-ils vérifiés ?
• Qui évalue les fausses alertes et ajuste les règles SIEM ?

Après les mises à jour de firmware, il convient de vérifier par échantillonnage si les événements importants sont toujours correctement analysés. Cela est particulièrement vrai pour les règles SIEM en production qui dépendent de certains noms de champs, types de journaux ou formats.

Dépannage

Aucun journal n’arrive dans le SIEM

Vérifiez d’abord l’adresse IP, le port, le routage et les règles de pare-feu entre Sophos Firewall et le serveur Syslog. Ensuite, vérifiez si le bon type de journal est activé pour le serveur Syslog sous System services > Log settings.

Seuls certains événements manquent

Dans ce cas, la journalisation des modules ou des règles n’est souvent pas active. Pour les règles de pare-feu, Log firewall traffic doit être activé. Pour les événements Web ou SSL/TLS, la politique ou la règle d’inspection appropriée doit également générer des journaux.

Les journaux arrivent, mais sont mal analysés

Vérifiez le format, la version du parseur et la version du firmware. Si un changement a été effectué entre Protocole syslog standard et Format standard de l’appareil (héritage), le parseur SIEM doit être adapté.

La connexion TLS-Syslog ne fonctionne pas

Vérifiez le FQDN, le certificat, le Common Name, le Subject Alternative Name, la chaîne de certificats et le port. Si le pare-feu attend un nom DNS, mais que le serveur Syslog est saisi uniquement avec une adresse IP, la vérification du certificat peut échouer. Vérifiez également si le système cible accepte réellement TLS sur le port configuré.

Les horodatages ne sont pas corrects

Vérifiez NTP sur le pare-feu, le fuseau horaire dans le SIEM et la logique du parseur. Des heures incorrectes rendent la corrélation avec les journaux des endpoints, serveurs ou identités peu fiable.

Trop de journaux ou trop de bruit

Ne désactivez pas tout immédiatement. Vérifiez d’abord quels types de journaux sont réellement nécessaires, quelles règles génèrent trop de journaux et si la suppression des journaux est judicieuse. Réduisez ensuite de manière ciblée.

Liste de contrôle

• Le serveur Syslog ou SIEM est accessible.
• Le transport, le port et le chiffrement sont définis.
• Le format correspond au parseur SIEM.
• La stratégie de facility est documentée.
• Les types de journaux pertinents sont activés sous System services > Log settings.
• Les règles de pare-feu importantes ont Log firewall traffic activé.
• Les règles d’inspection SSL/TLS génèrent leurs propres journaux si nécessaire.
• La suppression des journaux est évaluée et documentée consciemment.
• Les types de correspondance de réponse active aux menaces correspondent aux cas d’utilisation SIEM.
• La protection des données, l’accès et la durée de conservation sont clarifiés.
• La pare-feu pilote, les événements de test et le parseur SIEM ont été validés.
• Les événements de test arrivent dans le système cible.
• Les champs tels que le nom d’hôte, device_name, source, destination, action et ID de règle sont correctement reconnus.
• Les horodatages et le fuseau horaire sont corrects.
• La surveillance détecte lorsque plus aucun journal n’arrive.
• Après les mises à jour de firmware, la fonction du parseur est vérifiée.

FAQ