Kontrollera ändringar i Sophos Firewall med Audit Trail

Från och med SFOS 22 visar Configuration Audit vem som ändrade en konfiguration som stöds, när ändringen gjordes samt värdena före och efter. Det är rätt utgångspunkt när en brandväggsregel, ett värdobjekt eller ett gränssnitt ser annorlunda ut än väntat efter en ändring.

Det snabbaste arbetsflödet är att kontrollera status i Device Console, hämta configuration-audit.log eller söka i filen via Advanced Shell, jämföra ändringen med ärendet och tidsfönstret och sedan testa den tekniska effekten separat.

⚠️ Audit Trail visar en loggad ändring. Den bevisar inte automatiskt att ändringen var godkänd, tekniskt korrekt eller framgångsrikt testad och ersätter varken säkerhetskopia eller ändringsdokumentation.

Kontrollera Configuration Audit i fyra steg

1. Kontrollera status i Device Console

Configuration Audit är aktiverat som standard. Kommandona körs i Device Console, inte i Advanced Shell.

system configuration-audit show

Om funktionen är avaktiverad:

system configuration-audit enable

Det går tekniskt att avaktivera funktionen, men i produktionsmiljöer ska det bara göras med en motivering och under en begränsad tid:

system configuration-audit disable

⚠️ Avaktivera inte Audit Logging som första åtgärd bara för att filen är stor eller svårläst. Efter en incident kan dessa poster vara det avgörande beviset för en ändring.

2. Hämta loggfilen i WebAdmin

Filen heter configuration-audit.log och finns i WebAdmin under:

Diagnostics > Tools > Troubleshooting logs

För en riktad analys väljer och hämtar man den enskilda filen. En Consolidated troubleshooting report (CTR) är lämplig om Sophos Support även behöver systemstatus och ytterligare loggar, men vissa loggar för tjänstedelsystem i CTR kan begränsas av det konfigurerade radantalet.

3. Sök i loggfilen via Advanced Shell

Efter SSH-inloggning väljer man 5. Device Management och därefter 3. Advanced Shell. Ett objektnamn kan till exempel sökas så här:

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

Ersätt LAN_to_WAN med det faktiska namnet på regeln, värden eller gränssnittet. Nya poster kan följas i realtid med:

tail -f /log/configuration-audit.log

Avsluta realtidsvisningen med Ctrl+C. För en lugn sidvisning används less /log/configuration-audit.log. XML-utdata kan vara omfattande; spara endast det relevanta utdraget med tidsstämpel för ett supportärende.

4. Kontrollera ändringen och effekten separat

Audit Trail svarar först på frågan: Vad ändrades? Därefter måste ett funktionstest visa om ändringen fick avsedd effekt. Vid trafikproblem används därför även Log Viewer, Policy Test och Packet Capture. Arbetsflödet beskrivs i Testa en brandväggsregel med Log Viewer, Policy Test och Packet Capture.

Vad configuration-audit loggar

configuration-audit.log registrerar ändringar som stöds från WebAdmin och CLI i XML-format. En post kan innehålla:

• konfigurationen före och efter ändringen,
• tidsstämpel,
• administratörens identitet och käll-IP,
• använd konsol eller åtkomstmetod.

Det nuvarande omfånget omfattar framför allt brandväggsregler, IP Hosts eller Hosts and services samt nätverksgränssnitt. För gränssnitt nämner Sophos fysiska, virtuella, trådlösa och Cellular WAN-gränssnitt. Alla konfigurationssidor ger inte samma detaljnivå; ett fullständigt Audit Trail-omfång får inte förutsättas för NAT, routing, VPN eller andra funktioner.

En Description eller ett ärende förklarar varför ett objekt ska finnas. Audit Trail visar vad som faktiskt ändrades i ett objekt som stöds. Båda delarna behövs för ett fullständigt underlag.

Vad Audit Trail inte ersätter

• Trafikanalys: För tillåtna eller nekade anslutningar är Log Viewer och Packet Capture fortfarande avgörande.
• Säkerhetskopia och återställning: Före större ändringar behövs fortfarande en aktuell säkerhetskopia och återställningsväg.
• Fullständig ändringshantering: Godkännande, ansvar, test och verifiering hör hemma i ärendet eller underhållsprotokollet.
• Konfigurationsjämförelse: Sophos Firewall Config Studio jämför fullständiga konfigurationsexporter men läser inte configuration-audit.log.

Utvärdera en ändring på ett tillförlitligt sätt

Hitta och dokumentera ändringen

Ett effektivt arbetsflöde:

1. Fastställ tidpunkten för problemet eller ändringen inklusive tidszon.
2. Identifiera objektet, till exempel regelnamn, värd, gränssnitt eller VLAN.
3. Sök i configuration-audit.log efter objektnamn, administratör, IP-adress eller tidsfönster.
4. Jämför gammalt och nytt värde.
5. Jämför ändringen med ärendet, underhållsfönstret och ansvarig administratör.
6. Spara det relevanta XML-utdraget tillsammans med tidsfönster och objektnamn.

För en brandväggsregel kan exempelvis källa, destination, tjänst, regelposition eller aktiverade skyddsfunktioner ha ändrats. Den konkreta ändringen måste läsas i posten; listan garanterar inte att varje underfält visas identiskt i varje build.

Följande uppgifter är särskilt värdefulla för Sophos Support:

• exakt tid med tidszon,
• berört objekt och förväntat tillstånd,
• faktiskt felbeteende,
• berörd administratör eller Central-användare,
• relevant före- och eftervärde,
• ärendenummer och utfört funktionstest.

Den fullständiga XML-filen kan innehålla interna IP-adresser, objektnamn och administratörsdata. Lagra därför exporter åtkomstskyddat och kontrollera dem före delning så att onödiga kunddata inte lämnas ut. Fler råd finns i Säkra Sophos Firewall-loggar för support och analys.

Testa den tekniska effekten

Efter en ändring av en regel, värd eller ett gränssnitt ska arbetet inte sluta när loggposten hittats:

1. Kontrollera den aktuella konfigurationen i WebAdmin.
2. Generera definierad testtrafik.
3. Kontrollera Rule ID, NAT, rutt och returväg med rätt verktyg.
4. Kontrollera även rollstatus och synkronisering i HA.
5. Dokumentera resultat och eventuella avvikelser i ändringen.

Vid ändringar av NAT, routing eller VPN kan configuration-audit.log endast visa berörda objekt som stöds. Själva funktionen måste verifieras via aktuell konfiguration, händelse- och tjänsteloggar och vid behov Packet Capture.

Klassificera ändringar via Sophos Central

Från SFOS 22.0 MR1 loggas Central-användarens identitet vid ändringar av en enskild brandvägg via Sophos Central. Sophos bekräftar att informationen finns i Firewall Log Viewer samt i Sophos Central Logs and Reports. Det innebär inte automatiskt att Central-identiteten alltid finns i configuration-audit.log.

Central Audit Logs finns under:

Reports > General logs > Audit Logs

Vyn visar som standard 7 dagar och kan visa aktiviteter upp till 90 dagar tillbaka. Sökningen är inriktad på IP address och Modified by. Vid export gäller:

• CSV/PDF of current view: använder de aktuella filtren.
• CSV/PDF of past 90 days: exporterar de senaste 90 dagarna; sökfiltret gäller men inte det valda datumintervallet.

För längre bevisperioder måste exporter skapas regelbundet och arkiveras skyddat. Central Firewall Reporting förlänger inte 90-dagarsgränsen för de allmänna Central Audit Logs.

När Task Queue hjälper

Task Queue är inte ett generellt bevis för varje Central-ändring. Rätt kontrollväg beror på uppdraget:

• Direkt öppnad enskild brandvägg: Kontrollera Central Audit Logs och Firewall Log Viewer samt, för objekt som stöds, configuration-audit.log.
• Brandväggsgruppolicy: Kontrollera status i Sophos Central Firewall Management Task Queue. Om gruppolicyn inte når brandväggen lokalt kontrolleras även fwcm-updaterd.log.
• MDR Settings eller MDR IOCs från Firewall Configuration API: Använd Firewall Task Queue och vid behov fwcm-api-executor.log.

Namngivna Central-användare möjliggör tillförlitlig tilldelning. Lämpliga roller och MFA skyddar administrativ åtkomst. Roller beskrivs i Administrativa roller i Sophos Central för Firewall Management.

Ta hänsyn till HA och lagring

Sophos dokumenterar att Audit Logs endast skapas när en enhet har status Active. Detta bedöms olika beroende på HA-läge:

• I Active-Passive är normalt den appliance som var aktiv vid ändringen relevant.
• I Active-Active kan även Auxiliary Appliance vara aktiv och ha relevanta nodlokala loggar.
• Efter en failover kan de relevanta tidsfönstren finnas på olika enheter.

Loggar och rapporter synkroniseras inte mellan HA-noder. För en fullständig analys dokumenterar man därför HA-läge, rollbyten och tidsfönster och hämtar Troubleshooting Logs separat från berörda appliances. Konfigurationshantering och synkronisering av klustret beskrivs i Konfigurera High Availability i Sophos Firewall.

Det finns inte heller någon dokumenterad fast lokal lagringstid på 7, 30 eller 90 dagar för configuration-audit.log. Troubleshooting Logs roteras beroende på komponent, modell och tilldelat lagringsutrymme; äldre rotationer kan komprimeras och senare raderas. Exportera därför nödvändiga data i tid för revision eller regelefterlevnad.

Driftchecklista

• Kontrollera system configuration-audit show regelbundet och låt Audit Logging vara aktiverat.
• Använd namngivna administratörskonton, lämpliga roller och MFA för administrativ åtkomst.
• Dokumentera ändringar med ärende, tidsfönster, objekt och förväntat test.
• Förbered säkerhetskopia och återställningsplan före större ändringar.
• Sök i configuration-audit.log efter tidsfönster, objekt och administratör.
• Jämför före- och eftervärden med den godkända ändringen.
• Verifiera den tekniska effekten med Log Viewer och verklig testtrafik.
• Använd Audit Logs, Log Viewer eller rätt kö i Central beroende på uppdrag.
• Ta hänsyn till relevanta noder och failover-tidpunkt i HA.
• Exportera nödvändiga granskningsdata skyddat före rotation.

FAQ