Vérification des journaux de piste d'audit de Sophos Firewall

Les journaux de piste d’audit aident à retracer les modifications de configuration sur Sophos Firewall. Cela est important lorsqu’une règle change soudainement après une modification, qu’une interface a été modifiée, qu’un objet hôte manque ou qu’un audit demande qui a ajusté quel paramètre et quand.

Depuis Sophos Firewall v22, SFOS enregistre des entrées détaillées dans configuration-audit.log. Les journaux montrent non seulement qu’une modification a été effectuée, mais aussi les valeurs avant et après la modification. Avec SFOS 22.0 MR1, la traçabilité des modifications via Sophos Central a été améliorée, car l’identité de l’utilisateur Sophos Central est enregistrée pour les modifications sur une seule firewall.

Quel article de journalisation convient ?

Les journaux de piste d’audit ne sont qu’une partie du dépannage. Selon la question, un autre point de départ peut être plus rapide :

Cette séparation évite les attentes erronées. La piste d’audit répond aux questions de changement. Pour le flux de paquets, NAT, VPN, Web Protection, IPS ou les erreurs de service, il faut toujours utiliser Log Viewer, Packet Capture, Service-Logs, Central Reporting ou Syslog.

Quand les journaux de piste d’audit sont utiles

Les journaux d’audit sont particulièrement utiles lorsque la question n’est pas “pourquoi le trafic a-t-il été bloqué ?”, mais “qui ou quoi a modifié la configuration ?”.

Cas typiques :

• Une règle de firewall a été modifiée, déplacée ou supprimée.
• Un hôte IP, un hôte FQDN ou un objet réseau a été ajusté.
• Une interface ou une configuration VLAN semble différente de ce qui est documenté.
• Après une fenêtre de maintenance, il n’est pas clair quelle modification a causé un problème.
• Un MSP ou une équipe interne doit attribuer des modifications à plusieurs administrateurs.
• Pour la conformité, NIS2, ISO 27001 ou les processus de changement internes, une preuve est nécessaire.

Pour l’analyse normale du trafic, d’autres outils restent plus importants. Si l’on veut vérifier quelle règle a autorisé ou rejeté une connexion, Tester une règle de firewall avec Log Viewer, Policy Test et Packet Capture est approprié. Les journaux d’audit complètent cette analyse lorsqu’une modification de configuration est suspectée comme cause.

Ce que configuration-audit enregistre

configuration-audit enregistre les modifications de configuration effectuées par les administrateurs dans le WebAdmin ou via la CLI. Sont enregistrés, entre autres :

• Configuration avant la modification.
• Configuration après la modification.
• Horodatage.
• Identité de l’administrateur.
• Adresse IP de l’administrateur.
• Console ou méthode d’accès utilisée.

Les entrées sont enregistrées dans configuration-audit.log et écrites au format XML. Elles sont donc très détaillées, mais pas toujours agréables à lire. Pour une vérification rapide, il suffit souvent de rechercher le nom de l’objet, l’administrateur, l’adresse IP ou la période. Pour des analyses plus importantes, il peut être utile de rechercher le fichier à l’extérieur ou de l’intégrer dans un outil d’analyse de journaux.

Fonctionnalités actuelles

La piste d’audit couvre actuellement des objets de configuration importants, notamment :

• Hôtes IP.
• Règles de firewall.
• Interfaces réseau, y compris les interfaces WAN physiques, virtuelles, sans fil et cellulaires.
• Depuis SFOS v22, Hosts and services fait également partie des domaines pris en charge.

Cela est déjà très utile pour de nombreuses analyses de changement, mais ce n’est pas encore un système de gestion des changements complet. Les journaux de piste d’audit ne remplacent pas une documentation de changement, un ticket ou un principe de double validation.

⚠️ Les journaux d’audit prouvent qu’une modification a été enregistrée. Cependant, les journaux n’expliquent pas automatiquement si la modification était techniquement correcte, approuvée ou entièrement testée.

Vérifier le statut de configuration-audit

La configuration se fait dans la Device Console, pas dans l’Advanced Shell.

Le statut est vérifié avec :

system configuration-audit show

Si la fonction est active, le firewall devrait indiquer que l’audit de configuration est activé. Si vous n’êtes pas sûr de travailler dans la bonne console, la distinction est expliquée dans Dépannage de Sophos Firewall : Services et journaux.

Activer ou désactiver la piste d’audit

La journalisation d’audit est activée par défaut. Si elle a été désactivée, vous pouvez la réactiver dans la Device Console :

system configuration-audit enable

La désactivation est techniquement possible :

system configuration-audit disable

Dans les environnements de production, la journalisation d’audit devrait normalement rester active. Si elle est désactivée pour une raison particulière, cela devrait être documenté et limité dans le temps.

⚠️ La journalisation d’audit ne devrait pas être désactivée en premier lieu simplement parce que le fichier est volumineux ou difficile à lire. En cas de perturbations après des changements, ces données sont souvent la preuve décisive.

Télécharger configuration-audit.log

Le fichier s’appelle :

configuration-audit.log

Le téléchargement se fait via les journaux de dépannage. Le chemin WebAdmin est :

Diagnostics > Tools > Troubleshooting logs

Là, vous pouvez télécharger des fichiers journaux individuels ou générer un Consolidated troubleshooting report (CTR). Pour une analyse d’audit ciblée, le téléchargement individuel du fichier d’audit est souvent plus pratique qu’un CTR complet.

Si des journaux doivent être collectés pour le support ou une analyse externe, Sauvegarder les journaux de Sophos Firewall pour le support et l’analyse est également approprié. Pour les analyses directes en shell, Connecter Sophos Firewall via SSH est pertinent.

Analyser la piste d’audit

Pour une analyse propre, il faut d’abord délimiter la période.

Procédure pratique :

1. Déterminer le moment du problème ou du changement.
2. Télécharger configuration-audit.log.
3. Rechercher l’administrateur, le nom de l’objet, le nom de la règle, l’interface ou l’adresse IP.
4. Comparer la valeur avant et après la modification.
5. Comparer la modification avec le ticket, la fenêtre de maintenance ou la documentation de changement.
6. En cas de problèmes de trafic, vérifier également Log Viewer et Packet Capture.

Les journaux d’audit sont particulièrement utiles pour les problèmes de règles. Si une règle ne s’applique plus soudainement, Log Viewer ne montre que l’état actuel. La piste d’audit peut montrer si la source, la destination, le service, la fonctionnalité de sécurité, la position de la règle ou le contenu de l’objet ont été modifiés peu de temps avant.

Utiliser correctement la piste d’audit en cas de support

En cas de support, la piste d’audit est plus efficace lorsqu’elle est combinée avec une période spécifique et un symptôme reproductible. Un configuration-audit.log complet sans contexte est difficile à évaluer. Il est préférable d’avoir un court protocole de changement qui fournit les principaux points d’ancrage.

Si une modification a été déclenchée via Sophos Central, la Central Task Queue doit également être vérifiée. La file d’attente des tâches montre si Central a traité la commande. La piste d’audit montre ensuite ce qui est traçable localement sur le firewall.

Modifications via Sophos Central

SFOS 22.0 MR1 améliore la traçabilité des modifications de configuration via Sophos Central. Lorsqu’un seul firewall est configuré via Sophos Central, l’identité de l’utilisateur Sophos Central apparaît dans le contexte d’audit. Cette information est disponible dans le Log Viewer du firewall ainsi que dans les journaux et rapports de Sophos Central.

Cela est important pour les environnements avec plusieurs administrateurs ou en exploitation MSP. Un accès Central générique ne suffit pas pour une traçabilité propre. Il devrait être clair :

• Quelles personnes ont accès à Sophos Central ?
• Les administrateurs travaillent-ils avec leurs propres comptes utilisateurs au lieu de connexions partagées ?
• MFA est-il activé dans Sophos Central et sur le firewall ?
• Les journaux Central sont-ils conservés suffisamment longtemps ?
• Existe-t-il un processus pour faire correspondre les changements de Central avec les tickets ?

La connexion entre le firewall et Central est expliquée dans l’article Connecter Sophos Firewall à Sophos Central. Pour une conservation plus longue des journaux, Activer le reporting de firewall Central est approprié.

Prendre en compte les clusters HA

Dans les environnements HA, Sophos génère des journaux d’audit uniquement sur l’appareil actuellement actif, selon la documentation. Lors des analyses après un basculement, il faut donc prêter attention au changement de rôle.

Questions importantes :

• Quel firewall était actif au moment de la modification ?
• Y a-t-il eu un basculement peu avant ou après ?
• Les fichiers journaux des deux appareils sont-ils pertinents ?
• La modification a-t-elle été correctement synchronisée sur le cluster ?

Pour le fonctionnement HA et l’interprétation des journaux, Configurer la haute disponibilité de Sophos Firewall est approprié.

Validation après un changement

La piste d’audit montre qu’un objet a été modifié. Ensuite, il faut vérifier si la modification a l’effet souhaité et ne génère pas d’effet secondaire. Surtout pour les règles de firewall, les interfaces, les VPN et les objets hôtes, il ne faut donc pas s’arrêter au journal d’audit.

Une procédure sensée après des changements critiques :

1. Trouver la modification dans la piste d’audit par période et nom d’objet.
2. Comparer la valeur avant/après avec le ticket ou la documentation de changement.
3. Vérifier la règle de firewall, la règle NAT, la route ou l’interface concernée dans le WebAdmin.
4. Générer un trafic de test concret.
5. Vérifier Log Viewer, Policy Test et Packet Capture.
6. Pour les modifications Central, vérifier également la file d’attente des tâches et les journaux Central.
7. Pour les clusters HA, contrôler le statut des rôles et la synchronisation.

Cela transforme la piste d’audit en une preuve solide plutôt qu’en une simple découverte de journal. Si la piste d’audit montre une modification, mais que le trafic de test continue de mal fonctionner, la cause réside souvent dans l’ordre des règles, le NAT, le routage, l’attribution des utilisateurs, la fonctionnalité de sécurité ou le chemin de retour.

Limites et pièges typiques

Le journal d’audit n’est pas une sauvegarde

La piste d’audit montre les modifications, mais ne remplace pas une sauvegarde de configuration. Avant des modifications importantes, un backup complet et un plan de retour en arrière sont toujours nécessaires. Cela est décrit dans l’article Créer ou restaurer une sauvegarde de Sophos Firewall.

XML est détaillé, mais pas agréable

Le fichier est bon pour les machines et les comparaisons précises, mais difficile à lire rapidement. Si vous devez comparer de nombreux changements, Sophos Firewall Config Studio ou un outil externe de comparaison/d’analyse de journaux peut être plus utile.

Toute analyse ne relève pas de la piste d’audit

Si une connexion ne fonctionne pas, vérifiez d’abord le trafic. Les journaux d’audit sont pertinents lorsque la modification est suspectée comme cause. Pour le dépannage en direct, Log Viewer, Policy Test, Packet Capture et Service-Logs sont souvent plus directs.

Les comptes administrateurs partagés affaiblissent la preuve

Si plusieurs personnes utilisent le même compte administrateur, la piste d’audit est moins probante. Les administrateurs nommés, les rôles, MFA et les utilisateurs Central propres font donc partie du modèle d’exploitation, pas seulement un extra de sécurité.

Liste de vérification opérationnelle

• Vérifier system configuration-audit show.
• Laisser la journalisation d’audit activée.
• Utiliser des comptes administrateurs nommés au lieu de connexions partagées.
• Vérifier MFA pour WebAdmin, VPN Portal et Remote Access.
• Documenter les changements avec un ticket ou une fenêtre de maintenance.
• Créer une sauvegarde avant des modifications importantes.
• Après des problèmes, rechercher configuration-audit.log par période et nom d’objet.
• Comparer les valeurs avant/après avec la modification attendue.
• Pour les problèmes de règles, NAT ou VPN, compléter avec Log Viewer et Packet Capture.
• Pour les clusters HA, prendre en compte le nœud actif et le moment du basculement.
• Faire correspondre les modifications Central avec les journaux et rapports de Sophos Central.

Pour MFA sur le firewall, Activer MFA pour Sophos Firewall WebAdmin, VPN Portal et Remote Access est approprié. Pour les accès de gestion, Configurer correctement Device Access devrait également être vérifié.

FAQ