Sophos Firewall Audit Trail Logs controleren

Audit Trail Logs helpen om configuratiewijzigingen op de Sophos Firewall te traceren. Dit is belangrijk wanneer na een wijziging plotseling een regel anders werkt, een interface is veranderd, een host-object ontbreekt of in een audit wordt gevraagd wie wanneer welke instelling heeft aangepast.

Sinds Sophos Firewall v22 schrijft SFOS hiervoor gedetailleerde vermeldingen in configuration-audit.log. De logs tonen niet alleen dat er iets is gewijzigd, maar ook de waarden voor en na de wijziging. Met SFOS 22.0 MR1 is de traceerbaarheid bij wijzigingen via Sophos Central verbeterd, omdat bij wijzigingen aan een enkele firewall de Sophos Central gebruikersidentiteit wordt vastgelegd.

Welke logging-artikel past?

Audit Trail Logs zijn slechts een deel van de probleemoplossing. Afhankelijk van de vraag is een andere benadering sneller:

Deze scheiding voorkomt verkeerde verwachtingen. De Audit Trail beantwoordt vragen over wijzigingen. Voor pakketstroom, NAT, VPN, Web Protection, IPS of dienstfouten zijn Log Viewer, Packet Capture, Service-Logs, Central Reporting of Syslog nog steeds nodig.

Wanneer Audit Trail Logs nuttig zijn

Audit Logs zijn vooral nuttig wanneer de vraag niet is “waarom werd verkeer geblokkeerd?”, maar “wie of wat heeft de configuratie gewijzigd?”.

Typische gevallen:

• Een firewallregel is gewijzigd, verplaatst of verwijderd.
• Een IP Host, FQDN Host of netwerkobject is aangepast.
• Een interface of VLAN-configuratie ziet er anders uit dan gedocumenteerd.
• Na een onderhoudsvenster is onduidelijk welke wijziging een probleem heeft veroorzaakt.
• Een MSP of intern team moet wijzigingen aan meerdere beheerders toewijzen.
• Voor compliance, NIS2, ISO 27001 of interne wijzigingsprocessen is een bewijs nodig.

Voor normale verkeersanalyse blijven andere tools belangrijker. Als men wil controleren welke regel een verbinding heeft toegestaan of geblokkeerd, past Firewallregel testen met Log Viewer, Policy Test en Packet Capture. Audit Logs vullen deze analyse aan wanneer een configuratiewijziging als oorzaak wordt vermoed.

Wat configuration-audit vastlegt

configuration-audit legt configuratiewijzigingen vast die beheerders in WebAdmin of via de CLI uitvoeren. Vastgelegd worden onder andere:

• Configuratie voor de wijziging.
• Configuratie na de wijziging.
• Tijdsbestempel.
• Beheerdersidentiteit.
• IP-adres van de beheerder.
• Gebruikte console of toegangsmethode.

De vermeldingen worden opgeslagen in configuration-audit.log en in XML-formaat geschreven. Hierdoor zijn ze zeer gedetailleerd, maar niet altijd prettig om te lezen. Voor een snelle visuele controle volstaat vaak de zoekopdracht naar objectnaam, beheerder, IP-adres of tijdsvenster. Voor grotere analyses kan het nuttig zijn om het bestand extern te doorzoeken of in een loganalyse-tool te importeren.

Huidige functionaliteit

De Audit Trail dekt momenteel belangrijke configuratieobjecten, met name:

• IP Hosts.
• Firewallregels.
• Netwerkinterfaces, inclusief fysieke, virtuele, draadloze en Cellular-WAN-interfaces.
• Vanaf SFOS v22 behoort ook Hosts and services tot de ondersteunde gebieden.

Dit is voor veel wijzigingsanalyses al zeer nuttig, maar nog geen volledig wijzigingsbeheersysteem. Audit Trail Logs vervangen geen wijzigingsdocumentatie, geen ticket en geen vier-ogen-principe.

⚠️ Audit Logs bewijzen dat een wijziging is vastgelegd. De logs verklaren echter niet automatisch of de wijziging inhoudelijk correct, goedgekeurd of volledig getest was.

configuration-audit status controleren

De configuratie vindt plaats in de Device Console, niet in de Advanced Shell.

De status controleert men met:

system configuration-audit show

Als de functie actief is, zou de firewall moeten melden dat Configuration Audit is ingeschakeld. Als onduidelijk is of men in de juiste console werkt, helpt de onderscheid in Sophos Firewall Troubleshooting: Services en Logs.

Audit Trail inschakelen of uitschakelen

Audit Logging is standaard ingeschakeld. Als het is uitgeschakeld, kan men het in de Device Console weer inschakelen:

system configuration-audit enable

Uitschakelen is technisch mogelijk:

system configuration-audit disable

In productieve omgevingen zou Audit Logging normaal gesproken actief moeten blijven. Als het om een specifieke reden wordt uitgeschakeld, moet dit zelf worden gedocumenteerd en tijdelijk zijn.

⚠️ Audit Logging zou niet als eerste maatregel moeten worden uitgeschakeld, alleen omdat het bestand groot of moeilijk leesbaar lijkt. Vooral bij storingen na wijzigingen zijn deze gegevens vaak het doorslaggevende bewijs.

configuration-audit.log downloaden

Het bestand heet:

configuration-audit.log

De download gebeurt via de Troubleshooting Logs. Het WebAdmin-pad is:

Diagnostics > Tools > Troubleshooting logs

Daar kan men afzonderlijke logbestanden downloaden of een Consolidated troubleshooting report (CTR) genereren. Voor een gerichte audit-analyse is de afzonderlijke download van het auditbestand vaak praktischer dan een volledige CTR.

Als logs voor ondersteuning of externe analyse moeten worden verzameld, past daarnaast Sophos Firewall Logs voor ondersteuning en analyse veiligstellen. Voor directe Shell-analyses is Sophos Firewall per SSH verbinden relevant.

Audit Trail analyseren

Voor een correcte analyse moet men eerst de periode beperken.

Praktische procedure:

1. Tijdstip van het probleem of de wijziging bepalen.
2. configuration-audit.log downloaden.
3. Zoeken naar beheerder, objectnaam, regelnaam, interface of IP-adres.
4. De waarde voor en na de wijziging vergelijken.
5. De wijziging met ticket, onderhoudsvenster of wijzigingsdocumentatie afstemmen.
6. Bij verkeersproblemen daarnaast Log Viewer en Packet Capture controleren.

Audit Logs zijn vooral nuttig bij regelproblemen. Als een regel plotseling niet meer werkt, toont de Log Viewer alleen de huidige status. De Audit Trail kan laten zien of kort daarvoor bron, doel, dienst, beveiligingsfunctie, regelpositie of objectinhoud is gewijzigd.

Audit Trail correct gebruiken in ondersteuningsgevallen

In ondersteuningsgevallen is de Audit Trail het sterkst wanneer deze wordt gecombineerd met een specifiek tijdsvenster en een reproduceerbaar symptoom. Een complete configuration-audit.log zonder context is moeilijk te evalueren. Beter is een kort wijzigingsprotocol dat de belangrijkste ankers levert.

Als een wijziging via Sophos Central is geïnitieerd, moet daarnaast de Central Task Queue worden gecontroleerd. De Task Queue toont of Central de opdracht heeft verwerkt. De Audit Trail toont daarna wat lokaal op de firewall traceerbaar is.

Wijzigingen via Sophos Central

SFOS 22.0 MR1 verbetert de traceerbaarheid bij configuratiewijzigingen via Sophos Central. Wanneer een enkele firewall via Sophos Central wordt geconfigureerd, verschijnt de Sophos Central gebruikersidentiteit in de auditcontext. Deze informatie is beschikbaar in de Log Viewer van de firewall en in Sophos Central Logs en rapporten.

Dit is belangrijk voor omgevingen met meerdere beheerders of MSP-bedrijf. Een generieke Central-toegang is niet voldoende voor een duidelijke traceerbaarheid. Het moet duidelijk zijn:

• Welke personen hebben toegang tot Sophos Central?
• Werken beheerders met eigen gebruikersaccounts in plaats van gedeelde logins?
• Is MFA in Sophos Central en op de firewall actief?
• Worden Central Logs voldoende lang bewaard?
• Is er een proces om wijzigingen vanuit Central met tickets af te stemmen?

De verbinding tussen firewall en Central wordt behandeld in het artikel Sophos Firewall met Sophos Central verbinden. Voor langere logbewaring past Central Firewall Reporting activeren.

Let op HA-cluster

In HA-omgevingen genereert Sophos volgens documentatie Audit Logs alleen op het apparaat dat op dat moment actief is. Bij analyses na een failover moet men daarom letten op de rolwisseling.

Belangrijke vragen:

• Welke firewall was op het moment van de wijziging actief?
• Was er kort daarvoor of daarna een failover?
• Zijn logbestanden van beide apparaten relevant?
• Is de wijziging correct op de cluster gesynchroniseerd?

Voor HA-bedrijf en loginterpretatie past Sophos Firewall High Availability instellen.

Validatie na een wijziging

De Audit Trail toont dat een object is gewijzigd. Daarna moet echter worden gecontroleerd of de wijziging het gewenste effect heeft en geen bijwerking veroorzaakt. Vooral bij firewallregels, interfaces, VPN’s en host-objecten moet men daarom niet bij het Audit Log blijven.

Een zinvolle procedure na kritieke wijzigingen:

1. Wijziging in de Audit Trail vinden op tijdsvenster en objectnaam.
2. Voor-/na-waarde vergelijken met ticket of wijzigingsdocumentatie.
3. Betrokken firewallregel, NAT-regel, route of interface in WebAdmin controleren.
4. Specifiek testverkeer genereren.
5. Log Viewer, Policy Test en Packet Capture tegen controleren.
6. Bij Central-wijzigingen daarnaast Task Queue en Central Logs controleren.
7. Bij HA-clusters rolstatus en synchronisatie controleren.

Hiermee wordt de Audit Trail een betrouwbaar bewijs in plaats van alleen een logvondst. Als de Audit Trail een wijziging toont, maar het testverkeer nog steeds verkeerd loopt, ligt de oorzaak vaak in regelvolgorde, NAT, routering, gebruikerskoppeling, beveiligingsfunctie of retourpad.

Grenzen en typische valkuilen

Audit Log is geen back-up

De Audit Trail toont wijzigingen, maar vervangt geen configuratieback-up. Voor grotere wijzigingen is nog steeds een volledige back-up en een rollback-plan nodig. Dit wordt beschreven in het artikel Sophos Firewall Backup maken of herstellen.

XML is gedetailleerd, maar niet mooi

Het bestand is goed voor machines en nauwkeurige vergelijkingen, maar lastig voor snelle leesbaarheid. Als men veel wijzigingen moet vergelijken, kan Sophos Firewall Config Studio of een extern diff-/logtool nuttiger zijn.

Niet elke analyse hoort in de Audit Trail

Als een verbinding niet werkt, eerst het verkeer controleren. Audit Logs zijn dan relevant wanneer een wijziging als oorzaak in aanmerking komt. Voor live-probleemoplossing zijn Log Viewer, Policy Test, Packet Capture en Service-Logs vaak directer.

Gedeelde beheerdersaccounts verzwakken het bewijs

Als meerdere personen hetzelfde beheerdersaccount gebruiken, is de Audit Trail minder overtuigend. Named Admins, rollen, MFA en duidelijke Central-gebruikers zijn daarom onderdeel van het bedrijfsmodel, niet alleen een beveiligings-extra.

Bedrijfschecklist

• system configuration-audit show controleren.
• Audit Logging ingeschakeld laten.
• Named Admin Accounts in plaats van gedeelde logins gebruiken.
• MFA voor WebAdmin, VPN Portal en Remote Access controleren.
• Wijzigingen met ticket of onderhoudsvenster documenteren.
• Voor grotere wijzigingen back-up maken.
• Na problemen configuration-audit.log doorzoeken op tijdsvenster en objectnaam.
• Voor-/na-waarden vergelijken met de verwachte wijziging.
• Bij regel-, NAT- of VPN-problemen Log Viewer en Packet Capture aanvullen.
• Bij HA-clusters actieve node en failover-tijdstip in overweging nemen.
• Central-wijzigingen met Sophos Central Logs en rapporten afstemmen.

Voor MFA op de firewall past MFA voor Sophos Firewall WebAdmin, VPN Portal en Remote Access activeren. Voor beheerstoegang moet daarnaast Device Access correct configureren worden gecontroleerd.

FAQ