Vérifier les modifications Sophos Firewall avec l'Audit Trail

À partir de SFOS 22, Configuration Audit permet de savoir qui a modifié une configuration prise en charge, à quel moment, et quelles étaient les valeurs avant et après la modification. C’est le bon point de départ lorsqu’une règle de pare-feu, un objet hôte ou une interface ne correspond plus à ce qui était attendu après un changement.

La procédure la plus rapide consiste à vérifier le statut dans la Device Console, à télécharger configuration-audit.log ou à le parcourir dans l’Advanced Shell, à rapprocher la modification du ticket et de la période concernée, puis à tester séparément son effet technique.

⚠️ L’Audit Trail montre une modification journalisée. Il ne prouve pas automatiquement qu’elle a été approuvée, qu’elle était techniquement correcte ou qu’elle a été testée avec succès. Il ne remplace ni une sauvegarde ni la documentation des changements.

Vérifier Configuration Audit en quatre étapes

1. Contrôler le statut dans la Device Console

Configuration Audit est activé par défaut. Les commandes s’exécutent dans la Device Console, pas dans l’Advanced Shell.

system configuration-audit show

Si la fonction est désactivée :

system configuration-audit enable

Il est techniquement possible de la désactiver, mais dans un environnement de production, cela ne devrait se faire que pour un motif documenté et pendant une période limitée :

system configuration-audit disable

⚠️ Ne pas désactiver l’Audit Logging comme première mesure simplement parce que le fichier paraît volumineux ou difficile à lire. Après un incident en particulier, ces entrées peuvent constituer la preuve décisive d’une modification.

2. Télécharger le fichier journal dans WebAdmin

Le fichier s’appelle configuration-audit.log. Dans WebAdmin, il se trouve sous :

Diagnostics > Tools > Troubleshooting logs

Pour une analyse ciblée, sélectionner et télécharger ce fichier individuellement. Un Consolidated troubleshooting report (CTR) est utile lorsque Sophos Support a également besoin de l’état du système et d’autres journaux. Certains journaux de sous-systèmes de services inclus dans le CTR peuvent toutefois être limités par le nombre de lignes configuré.

3. Parcourir le fichier journal dans l’Advanced Shell

Après la connexion SSH, sélectionner 5. Device Management, puis 3. Advanced Shell. La commande suivante permet par exemple de rechercher un nom d’objet :

grep -i 'LAN_to_WAN' /log/configuration-audit.log

Remplacer LAN_to_WAN par le véritable nom de la règle, de l’hôte ou de l’interface. La commande suivante permet de suivre les nouvelles entrées en direct :

tail -f /log/configuration-audit.log

Arrêter l’affichage en direct avec Ctrl+C. Pour une consultation statique page par page, utiliser less /log/configuration-audit.log. La sortie XML peut être longue. Pour un dossier de support, ne conserver que l’extrait pertinent avec son horodatage.

4. Vérifier séparément la modification et son effet

L’Audit Trail répond d’abord à la question : Qu’est-ce qui a été modifié ? Un test fonctionnel doit ensuite montrer si la modification produit l’effet attendu. En cas de problème de trafic, utiliser également Log Viewer, Policy Test et Packet Capture. La procédure est décrite dans Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture.

Ce que configuration-audit enregistre

configuration-audit.log enregistre au format XML les modifications prises en charge effectuées depuis WebAdmin et la CLI. Une entrée peut contenir :

• la configuration avant et après la modification
• l’horodatage
• l’identité de l’administrateur et l’adresse IP source
• la console ou la méthode d’accès utilisée

Le périmètre actuel comprend notamment les règles de pare-feu, les IP Hosts ou Hosts and services, ainsi que les interfaces réseau. Pour les interfaces, Sophos mentionne les interfaces physiques, virtuelles, sans fil et Cellular WAN. Toutes les pages de configuration n’offrent pas le même niveau de détail. Il ne faut donc pas supposer que NAT, le routage, VPN ou d’autres fonctions bénéficient d’une piste d’audit complète.

Une description ou un ticket explique pourquoi un objet est censé exister. L’Audit Trail montre ce qui a réellement été modifié sur un objet pris en charge. Les deux sont nécessaires pour disposer d’une preuve complète.

Ce que l’Audit Trail ne remplace pas

• Analyse du trafic : Log Viewer et Packet Capture restent indispensables pour les connexions autorisées ou rejetées.
• Sauvegarde et restauration : Avant toute modification importante, il faut toujours disposer d’une sauvegarde actuelle et d’une procédure de retour.
• Gestion complète des changements : L’approbation, les responsabilités, les tests et la validation doivent figurer dans le ticket ou le journal de maintenance.
• Comparaison de configurations : Sophos Firewall Config Studio compare des exports complets de configuration, mais ne lit pas configuration-audit.log.

Évaluer une modification de manière fiable

Trouver et documenter la modification

Une procédure de vérification efficace :

1. Déterminer l’heure du problème ou de la modification, avec le fuseau horaire.
2. Identifier l’objet concerné, par exemple le nom de la règle, l’hôte, l’interface ou le VLAN.
3. Rechercher dans configuration-audit.log le nom de l’objet, l’administrateur, l’adresse IP ou la période.
4. Comparer l’ancienne et la nouvelle valeur.
5. Rapprocher la modification du ticket, de la fenêtre de maintenance et de l’administrateur responsable.
6. Conserver l’extrait XML pertinent avec la période et le nom de l’objet.

Pour une règle de pare-feu, la source, la destination, le service, la position de la règle ou les fonctions de sécurité activées peuvent par exemple avoir changé. La modification exacte doit être lue dans l’entrée. Cette liste ne garantit pas que chaque sous-champ soit présenté de manière identique dans chaque build.

Les informations suivantes sont particulièrement utiles pour Sophos Support :

• heure exacte avec le fuseau horaire
• objet concerné et état attendu
• symptômes constatés
• administrateur ou utilisateur Central impliqué
• valeur avant/après pertinente
• numéro de ticket et test fonctionnel effectué

Le fichier XML complet peut contenir des adresses IP internes, des noms d’objets et des données relatives aux administrateurs. Conserver les exports avec un contrôle d’accès et vérifier qu’ils ne contiennent pas de données client inutiles avant de les transmettre. Pour plus d’informations, consulter Collecter les journaux de Sophos Firewall pour le support et l’analyse.

Tester l’effet technique

Après la modification d’une règle, d’un hôte ou d’une interface, ne pas s’arrêter à la découverte de l’entrée de journal :

1. Vérifier la configuration actuelle dans WebAdmin.
2. Générer un trafic de test défini.
3. Contrôler l’ID de règle, le NAT, la route et le chemin retour dans l’outil approprié.
4. En cas de HA, vérifier également le statut des rôles et la synchronisation.
5. Documenter le résultat et les éventuels écarts dans le dossier de changement.

Pour les modifications liées au NAT, au routage ou au VPN, configuration-audit.log peut ne montrer que les objets pris en charge qui sont impliqués. Valider la fonction elle-même au moyen de sa configuration actuelle, des journaux d’événements et de services, ainsi que de Packet Capture si nécessaire.

Interpréter les modifications effectuées via Sophos Central

À partir de SFOS 22.0 MR1, l’identité de l’utilisateur Central est journalisée lorsqu’un pare-feu individuel est modifié via Sophos Central. Sophos confirme cette information dans le Firewall Log Viewer ainsi que dans Sophos Central Logs and Reports. Cela ne signifie pas automatiquement que l’identité Central apparaît systématiquement dans configuration-audit.log.

Les Central Audit Logs se trouvent sous :

Reports > General logs > Audit Logs

Par défaut, la vue affiche 7 jours et peut présenter les activités des 90 derniers jours. La recherche porte sur IP address et Modified by. Les règles suivantes s’appliquent à l’export :

• CSV/PDF of current view : reprend les filtres actuellement définis.
• CSV/PDF of past 90 days : exporte les 90 derniers jours ; le filtre de recherche s’applique, mais pas la plage de dates sélectionnée.

Pour une conservation plus longue, créer régulièrement les exports et les archiver de manière sécurisée. Central Firewall Reporting ne prolonge pas la limite de 90 jours des Central Audit Logs généraux.

Quand la Task Queue est utile

La Task Queue ne constitue pas une preuve générale pour chaque modification Central. Le bon chemin de vérification dépend de l’opération :

• Pare-feu individuel ouvert directement : vérifier Central Audit Logs et Firewall Log Viewer ; pour les objets pris en charge, vérifier également configuration-audit.log.
• Stratégie de groupe de pare-feu : vérifier le statut dans la Sophos Central Firewall Management Task Queue. Si le push de la stratégie de groupe n’arrive pas localement, analyser également fwcm-updaterd.log.
• MDR Settings ou MDR IOCs issus de la Firewall Configuration API : utiliser Firewall Task Queue et, si nécessaire, fwcm-api-executor.log.

Les utilisateurs Central nominatifs permettent une attribution fiable. Des rôles adaptés et MFA protègent les accès administratifs. Les rôles sont expliqués dans Rôles administratifs Sophos Central pour la gestion des pare-feu.

Tenir compte de HA et de la conservation

Sophos indique que les Audit Logs ne sont générés que lorsqu’un appareil est Active. L’interprétation dépend du mode HA :

• En mode Active-Passive, l’appliance active au moment de la modification est normalement celle qui compte.
• En mode Active-Active, l’appliance Auxiliary peut également être active et détenir des journaux locaux pertinents.
• Après un basculement, les périodes requises peuvent se trouver sur différents appareils.

Les journaux et rapports ne sont pas synchronisés entre les nœuds HA. Pour une analyse complète, documenter le mode HA, les changements de rôle et la période, puis télécharger séparément les Troubleshooting Logs des appliances concernées. La gestion de la configuration et la synchronisation du cluster sont décrites dans Configurer la haute disponibilité de Sophos Firewall.

Il n’existe pas non plus de durée fixe documentée de 7, 30 ou 90 jours pour la conservation locale de configuration-audit.log. Les Troubleshooting Logs sont soumis à une rotation qui dépend du composant, du modèle et de l’espace de stockage attribué. Les anciennes rotations peuvent être compressées, puis supprimées. Pour disposer de preuves à des fins d’audit ou de conformité, exporter les fichiers requis à temps.

Liste de contrôle opérationnelle

• Vérifier régulièrement system configuration-audit show et laisser l’Audit Logging activé.
• Utiliser des comptes administrateur nominatifs, des rôles adaptés et MFA pour les accès administratifs.
• Documenter les changements avec le ticket, la période, l’objet et le test attendu.
• Préparer une sauvegarde et un plan de retour avant toute modification importante.
• Rechercher dans configuration-audit.log par période, objet et administrateur.
• Comparer les valeurs avant/après avec la modification approuvée.
• Valider l’effet technique avec Log Viewer et un trafic de test réel.
• Pour Central, utiliser Audit Logs, Log Viewer ou la file d’attente appropriée selon l’opération.
• En cas de HA, tenir compte des nœuds pertinents et du moment du basculement.
• Exporter de manière sécurisée les données d’audit nécessaires avant leur rotation.

FAQ