Spara Sophos Firewall-loggar för support och analys

Vid funktionsfel, VPN-problem eller oklara brandväggshändelser räcker det ofta inte med enskilda skärmdumpar från webbgränssnittet. För en välgrundad analys behöver ett supportärende tydliga tidsangivelser, relevanta loggfiler och ibland även en paketinsamling.

Den officiella nedladdnings- och diagnostikprocessen gäller SFOS 22 och SFOS 23. De kompletterande manuella arkiven är fortfarande en separat analysmetod, inte en bekräftad standardexport för båda versionerna. Den beskriver den officiella vägen via Diagnostics > Tools och skiljer den från den kompletterande vägen för råloggar via Advanced Shell. För Sophos Support är Consolidated Troubleshooting Report (CTR) vanligtvis den bästa utgångspunkten, eftersom rapporten samlar loggfiler och en ögonblicksbild av systemet i ett krypterat arkiv. Ett manuellt skapat /log-arkiv är fortfarande användbart för fullständiga råloggar, ytterligare IPsec-data eller intern analys. Det är däremot inte en krypterad CTR eller den standardexport som Sophos dokumenterar.

Processen ersätter inte den inledande felavgränsningen i Log Viewer. Om det fortfarande är oklart vilken modul som påverkas, kommer översikten Sophos Firewall Felsökning: Tjänster och loggar att hjälpa först.

Avgränsa supportärendet först

Ett stort arkiv är inte automatiskt ett bra supportunderlag. Fastställ först vilket test som misslyckades, när det utfördes och vilken komponent som sannolikt berörs.

Analysera först eller samla in data direkt?

Beroende på felmönstret är ett annat tillvägagångssätt snabbare:

• Kontrollera specifikt anslutningsförsök: Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture, om regeln, NAT-regeln eller rutten är otydlig.
• Identifiera rätt lokala loggfiler: Sophos Firewall Felsökning: Tjänster och loggar, om det först behöver klargöras vilken logg som tillhör VPN, webb, IPS, GUI eller systemtjänster.
• Problemet är känt och underlaget ska lämnas vidare: Följ den här artikeln för att skapa en CTR, riktade loggar eller ett råloggarkiv.

För historiska rapporter eller återkommande händelser används Central Firewall Reporting. Långsiktig lagring och korrelation kräver Syslog eller SIEM. Ett tillfälligt supportarkiv ersätter inget av dem.

Välj underlag efter feltyp

Inte alla problem behöver ett komplett loggarkiv omedelbart. Ju tydligare felet är isolerat, desto mindre och mer användbar blir data.

• Brandväggsregel eller NAT-regel gäller oväntat: Tid, Käll-IP, Destinations-IP, Regel-ID, NAT-ID, export av loggvisare och, om nödvändigt, Packet Capture.
• Tjänsten startar inte eller WebAdmin visar fel: Konsoliderad felsökningsrapport, påverkad tjänst, tid och senaste konfigurationssteg.
• IPsec-tunneln upprättas inte eller bryts: normalt loggarkiv, IPsec-diagnostikdata, peer-IP, lokala och fjärranslutna nätverk samt tidpunkten för anslutningsförsöket.
• Trafik når inte destinationen: Log Viewer, Packet Capture eller för längre analyser tcpdump-PCAP.
• Problem efter konfigurationsändring: Granskningsspår, ungefärlig ändringstid, admin involverad, berörda objekt och, om nödvändigt, CTR.

För många supportärenden är kombinationen av tidpunkten för problemet, en kort felbeskrivning, ett loggarkiv och riktade kompletterande underlag bättre än ett stort datapaket utan sammanhang. Om ett officiellt Sophos-ärende ska skapas är även guiden Öppna ett Sophos-supportärende: förberedelser och portal användbar.

Krav

För den här guiden behöver du:

• Administrativ åtkomst till Sophos Firewall
• Tillgång till Diagnostics > Tools i WebAdmin
• För råloggarkiv ytterligare tillgång till Advanced Shell
• En målserver, supportportal eller annat säkert sätt att överföra arkiv
• Tillräckligt ledigt utrymme på brandväggen för tillfälliga arkiv

CLI-kommandona körs direkt på brandväggen. Du bör därför arbeta försiktigt och inte radera filer om det inte framgår vad de används till.

Om åtkomst till skalet ännu inte har ställts in, förklarar instruktionerna Anslut Sophos Firewall via SSH hur man upprättar en SSH-anslutning till brandväggen.

⚠️ Loggarkiv och PCAP-filer kan innehålla känslig information. Sådana filer bör endast finnas på brandväggen under en kort tid, överföras säkert och sedan tas bort igen efter lyckad överföring.

Samla loggar

Beroende på supportärendet räcker det med en riktad WebAdmin-nedladdning, en CTR eller ett råloggarkiv från Advanced Shell. Processen bör börja med den minsta datamängden som tydligt förklarar felet.

Den lokala lagringen av loggar begränsas av det utrymme som tilldelats varje undersystem och av brandväggsmodellen. När en loggfil når sin storleksgräns komprimeras den med gzip; när undersystemet når sin lagringsgräns tas de äldsta .gz-rotationerna bort först. Om brandväggen slutar svara kan även loggdata som fortfarande finns i RAM och ännu inte har skrivits till filsystemet gå förlorade. Spara därför relevanta loggar så snart som möjligt: en export innehåller bara data som fortfarande finns tillgängliga och kan inte återställa förlorade poster.

Felsökningsloggar lagras på partitionen /var och läses via /log. Kritiska komponenter får mer utrymme; två eller fler komprimerade rotationer sparas beroende på undersystemet. Efter rotationen fortsätter brandväggen att skriva under det ursprungliga filnamnet. På en XGS Appliance beror den tillgängliga historiken därför även på modell och tjänst, inte på en gemensam lagringstid.

Standardsätt: skapa CTR i WebAdmin

För många supportärenden bör du först skapa Consolidated Troubleshooting Report (CTR). CTR innehåller en ögonblicksbild av systemet och loggfiler i ett krypterat arkiv. Sophos Support kan utvärdera detta arkiv direkt i supportärenden.

Så här skapar du CTR:

1. Återskapa felet om möjligt och notera den exakta tiden.
2. Öppna Diagnostics > Tools i WebAdmin.
3. Välj önskade alternativ under Consolidated troubleshooting report.
4. Aktivera System snapshot och All log files för ett brett supportärende.
5. Ange en kort orsak, till exempel ärendenummer, felmönster och tidsfönster.
6. Välj Generate.
7. Välj Download när rapporten har skapats.
8. Gör filen tillgänglig via supportportalen, den överenskomna säkra uppladdningen eller den interna analyskanalen.

System snapshot kräver inte debugläge och registrerar det aktuella systemtillståndet, bland annat aktiva processer och resursanvändning. Det dokumenterade filnamnet är CTR_<APPKEY>_<MM_DD_YY>_<HH_MM_SS>: APPKEY är brandväggens serienummer; de återstående fälten anger skapandedatum som månad/dag/år och tid som timme/minut/sekund. Även filnamnet är därför konfidentiellt. Detta är användbart när flera brandväggar eller flera försök hör till samma supportärende.

Radgränsen gäller endast Service subsystem logs; Default subsystem logs ingår i sin helhet, så länge uppgifterna fortfarande finns tillgängliga. Kontrollera inte en krypterad CTR med kommandot tar -tzf som visas längre fram: kontrollera slutförd nedladdning, rimlig filstorlek, enhet och testtid, och bifoga filen säkert till supportärendet. Om generering eller nedladdning misslyckas, dokumentera felet och spara först de berörda enskilda loggarna i stället för att radera loggar.

⚠️ CTR är inte detsamma som en fullständig rådatadump. Loggar för tjänsteundersystem innehåller som standard högst 10 000 rader; gränsen gäller endast CTR. Om äldre eller fullständiga råloggar behövs ska berörda felsökningsloggar laddas ner individuellt eller sparas via Advanced Shell.

Kontrollera CTR-radgränsen i Device Console

Radgränsen för loggar från tjänsteundersystem i CTR kan visas och ställas in oberoende av råloggarna. Öppna 4. Device Console i CLI-huvudmenyn. SFOS 22 och SFOS 23 tillåter 250 till 10000 rader och använder 10000 som standard:

system diagnostics show ctr-log-lines
system diagnostics ctr-log-lines 5000

Normalt behöver standardvärdet inte ändras. 5000 visar bara syntaxen för ett avsiktligt mindre CTR: intervallet är fast, men värdet beror på supportärendet. Dokumentera det aktuella värdet med show före en ändring och återställ det med samma inställningskommando efter att CTR har skapats. Ändringen gäller bara framtida CTR-filer, inte de fullständiga råloggarna, och återställer inte data som redan har raderats eller skrivits över.

Ladda ner individuella felsökningsloggar

Om modulen redan är känd är en riktad loggexport ofta bättre än en mycket bred datamängd.

1. Öppna Diagnostics > Tools.
2. Välj relevanta loggfiler under Troubleshooting logs.
3. Välj Download.
4. Skicka vidare den genererade komprimerade filen tillsammans med feltid, testfall och påverkad brandvägg.

Denna väg passar om till exempel endast strongswan.log, charon.log, sslvpn.log, reverseproxy.log, applog.log eller en annan tydligt berörd tjänst behövs. Till skillnad från CTR omfattas dessa individuella nedladdningar inte av radgränsen. Vilken fil som hör till vilken modul finns i Sophos Firewall Felsökning: Tjänster och loggar.

Öppna Advanced Shell

Logga in på Sophos Firewall och öppna Advanced Shell:

1. Välj 5. Device Management i CLI-huvudmenyn.
2. Öppna därefter 3. Advanced Shell.
3. Bekräfta åtkomst om brandväggen visar ytterligare en fråga.

Efter att ha loggat in är du på brandväggsskalet. Därifrån kan loggfilerna arkiveras.

Spara ett kort utdrag från en livelogg

Följ nya poster i Advanced Shell under ett avgränsat test:

cd /log
tail -f /log/charon.log

charon.log är ett konkret IPsec-exempel; välj vid andra problem rätt befintlig fil i översikten över tjänsteloggar. Anteckna testets start, slut och tidszon, återskapa felet och kopiera utdata till en skyddad textfil på administratörens dator. Ctrl+C stoppar visningen, inte brandväggstjänsten. tail -f visar de senaste befintliga raderna och nya poster, inte en fullständig export. Om poster saknas, kontrollera först nod, filnamn, tid och tjänst; ladda vid behov ned hela den enskilda filen. Ladda upp utdraget och dess sammanhang till supportärendet.

Samla in specifika loggar innan du säkerhetskopierar

Om ett problem är reproducerbart bör det om möjligt utlösas omedelbart innan loggarna arkiveras. Då finns så aktuella relevanta poster som möjligt i loggfilerna.

För mer komplexa problem räcker ibland inte de normala loggarna till. I det här fallet kan det vara vettigt att aktivera en felsökningslogg för den berörda tjänsten innan arkivering. Debug bör endast köras specifikt och kort och avaktiveras igen efter insamling, annars kan loggfiler växa snabbt. Hur detta fungerar beskrivs i avsnittet Aktivera felsökningslogg specifikt.

Vilken loggfil som hör till vilken brandväggsmodul sammanfattas i Sophos Firewall Felsökning: Tjänster och loggar. Den här översikten är användbar om du specifikt vill kontrollera om VPN, IPS, webb, e-post, GUI eller systemloggar är mer relevanta för ett problem.

Om det inte är ett tjänsteproblem utan själva paketflödet som är oklart räcker det ofta inte med enbart ett loggarkiv. För korta tester passar Packet Capture i WebAdmin. För PCAP-filer, längre inspelningar eller supportanalyser är tcpdump på Sophos Firewall rätt verktyg.

Samla debug med en kontrollerad återställning

Debug är avstängt som standard. Kontrollera ändå med administratörer och support om insamling redan pågår innan något ändras; dokumentera nod, ledigt utrymme och ett kort testfönster. Arbeta med ett undersystem som stöds åt gången. Debugdata är tillgängliga genom enskilda nedladdningar, CTR och CLI. Kör för det dokumenterade tjänsteexemplet i 4. Device Console:

För andra tjänster som stöds är syntaxen system diagnostics subsystems <subsystem> debug on och system diagnostics subsystems <subsystem> debug off. Ersätt <subsystem> med ett CLI-namn som har bekräftats på den aktuella builden, inte med ett loggfilnamn. Om debuginsamling redan pågår för ett annat supportärende, ändra inte dess tillstånd utan överenskommelse.

system diagnostics subsystems Pktcapd debug on

Utför endast det planerade testet, ladda ned loggen eller den färdiga CTR-filen och stäng sedan av debug i samma Device Console:

system diagnostics subsystems Pktcapd debug off

Dokumentera utdata och tider för aktivering och avaktivering; kontrollera med ett kort uppföljningstest att inga nya debugposter skapas och att loggtillväxt och lagringsförbrukning är normala igen. Om kommandot avvisas, gissa inte namn: kontrollera buildens syntax och kontakta support. Avstängning tar inte bort insamlade filer.

För systemkontrollern anger logguiden samma kommando, system diagnostics subsystems CSC debug, för aktivering och avaktivering, utan on eller off. Använd inte denna växlingsfunktion som en statusfråga och kör den inte blint två gånger. Om startläget eller återställningen är oklart, ändra inte CSC-debug; följ den kontrollerade CSC-processen med support. Loggfilnamn är inte CLI-undersystemsnamn.

Diagnostiköversikten för SFOS 22/23 listar följande Default logs för debug; denna grupp är också undantagen från CTR-radgränsen:

syslog.log, postgres.log, reportdb.log, applog.log, access_server.log, awarrenhttp.log, awed.log, charon.log, csc.log, garner.log, heartbeatd.log, ips.log, iview.log, msync.log, nSXLd.log, networkd.log, red.log, reverseproxy.log, smtpd_main.log, sslvpn.log, tomcat.log, u2d.log, up2date_av.log, npu-startup.log.prev, npu_syslog.log, syslog-ng.log, xgs-healthmond.log, xgs-host.log, xgs-npu-fw.log, xgs-pport-wait.log.

De listade Service logs är:

awarrenhttp_access.log, httplogd.log, bwm.log, awarrensmtp.log, pktcapd.log, warren.log.

Listan beskriver filer som stöder debug, inte alla loggar eller garanterad förekomst på varje plattform. Kontrollera NPU- och XGS-filer utifrån den aktuella XGS Appliance. Behåll stora och små bokstäver: pktcapd.log är inte kommandoparametern Pktcapd.

Säkra bevis innan loggar rensas

En purge behövs inte för CTR eller enskilda nedladdningar. Diagnostikguiden listar tömning av ett undersystem före återskapandet endast som valfri. Klargör först bevis-, support- och lagringskrav och spara nödvändiga filer utanför brandväggen. Till skillnad från den senare borttagningen av egna arkiv raderar en purge diagnostikhistorik; det finns ingen återställning.

De globala Device Console-kommandona är system diagnostics purge-old-logs för alla komprimerade .gz-loggar och system diagnostics purge-all-logs för allt logginnehåll. Enligt CLI-hjälpen lämnar en fullständig purge kvar tomma filer. Globala åtgärder påverkar även andra undersystem och pågående supportärenden.

Syntaxkonflikt för ett enskilt undersystem: Administratörshjälpen för SFOS 22/23 anger system diagnostics <subsystem> purge-log och system diagnostics <subsystem> purge-old-log; CLI-hjälpen dokumenterar däremot system diagnostics subsystems <subsystem> purge-log och system diagnostics subsystems <subsystem> purge-old-log. Kontrollera före en godkänd rensning i 4. Device Console fullständig syntax och namn med CLI-hjälpen eller Tab-komplettering och klargör konflikten med support. Prova inte båda varianterna.

Avbryt vid oklar syntax, filernas ursprung eller pågående insamling och använd processen för lagringsanalys och kontrollerad rensning. Kontrollera efter en överenskommen åtgärd ledigt utrymme, nya normala loggposter och tjänstestatus; mindre använt utrymme bevisar inte att orsaken är löst. Radera inte systemloggar manuellt med rm eller jokertecken.

Spara råloggar via Advanced Shell

Om CTR inte räcker till eller om alla råloggar som för närvarande är tillgängliga krävs för intern analys kan du arkivera katalogen /log manuellt. Den här shellmetoden ersätter inte den officiella CTR-rapporten eller enskild hämtning under Troubleshooting logs. Kontrollera först att det finns tillräckligt med ledigt utrymme under /var:

Kontrollera befintliga kataloger och ledigt utrymme innan denna kompletterande shellmetod används. Om /log är en symbolisk länk kan nedanstående tar-kommando arkivera enbart länken i stället för loggfilerna: fortsätt inte med ett till synes färdigt arkiv; använd den officiella enskilda nedladdningen eller kom överens om arkivmetoden med support. En katalog som fortfarande skrivs till är inte heller en konsekvent säkerhetskopia. Utred först saknade sökvägar, läsfel eller lagringsproblem; radera inte systemloggar för att frigöra utrymme.

ls -ld /log
df -h /var

Skapa sedan ett komprimerat arkiv med filerna från katalogen /log:

tar -cvzf /var/Sophos-Firewall-Logs.tar.gz -C / log

Kommandot skapar filen:

/var/Sophos-Firewall-Logs.tar.gz

De viktigaste delarna av kommandot:

• tar skapar ett arkiv.
• -c skapar ett nytt arkiv.
• -v visar de bearbetade filerna.
• -z komprimerar arkivet med gzip.
• -f anger filnamnet för arkivet.
• -C / växlar till rotkatalogen för arkivering.
• log är katalogen med loggfilerna för Sophos Firewall.

Fördelen med -C / är att kommandot fungerar oavsett den aktuella arbetskatalogen. En tidigare cd / är därför inte nödvändig. Om filen redan finns kommer kommandot att skriva över den.

Beroende på storleken och belastningen på brandväggen kan arkiveringsprocessen ta lite tid. Samtidigt visar utdata från tar vilka filer som skrivs till arkivet.

Arkivstorleken kan sedan kontrolleras:

ls -lh /var/Sophos-Firewall-Logs.tar.gz

Dessutom bör du kort kontrollera om arkivet är läsbart och faktiskt innehåller loggkatalogen:

tar -tzf /var/Sophos-Firewall-Logs.tar.gz

Utdata ska visa sökvägar under log/. Om kommandot rapporterar ett fel eller arkivet är ovanligt litet ska arkivet inte distribueras. Kontrollera sedan först ledigt utrymme, skrivbehörigheter och den föregående tar-körningen.

Kopiera loggarkivet till en Linux-server

Om en Linux-server kan nås via SSH, kan arkivet överföras med scp.

Exempel:

scp /var/Sophos-Firewall-Logs.tar.gz root@192.0.2.10:/root/

IP-adressen, användaren och målvägen måste anpassas till din egen miljö.

Efter överföringen finns arkivet på målservern på:

/root/Sophos-Firewall-Logs.tar.gz

Därifrån kan den vidarebefordras internt eller göras tillgänglig för Sophos Support eller Avanet.

Spara IPsec-diagnostik separat

Vid VPN- eller IPsec-problem kan även anslutningsdata från /tmp/ipsec/connections/ vara användbara. De granskade SFOS 22/23-guiderna beskriver inte denna manuella arkivmetod som standardexport. Använd den endast för intern analys eller på uttrycklig begäran från support och kontrollera först att katalogen finns.

Skapa ett separat arkiv för detta:

ls -ld /tmp/ipsec/connections
tar -cvzf /var/Sophos-Firewall-IPsec-Connections.tar.gz -C /tmp/ipsec connections

Även här kan den genererade filen kontrolleras kort:

ls -lh /var/Sophos-Firewall-IPsec-Connections.tar.gz

Detta arkiv kan också kopieras till en målserver med scp:

scp /var/Sophos-Firewall-IPsec-Connections.tar.gz root@192.0.2.10:/root/

Speciellt i fallet med IPsec-fel är det vettigt att tillhandahålla detta arkiv tillsammans med de vanliga brandväggsloggarna så att tunnelstatus, anslutningsinformation och loggposter kan utvärderas tillsammans.

Vad ett supportarkiv inte ersätter

En CTR och ett /log-arkiv är ögonblicksbilder av den lokala brandväggen. De hjälper vid tjänste- och systemfel, men ger inte automatiskt lång historik och bevisar inte att ett visst paket passerade brandväggen. Använd Central Firewall Reporting eller Syslog och SIEM för historik och sökning. Konfigurationsändringar spåras mer direkt med Audit Trail Logs.

Behandla paketinspelningar separat

Loggarkiv och paketinspelningar är olika former av bevis. Loggarkivet visar servicemeddelanden, fel, VPN-tillstånd och systemhändelser. En Packet Capture eller tcpdump, å andra sidan, visar om paket faktiskt anländer, vidarebefordras eller om svar saknas.

För supportärenden bör du inte skicka paketinspelningar ofiltrerade. Det är bättre:

1. Notera testfallet med käll-IP, destinations-IP, port, protokoll och tid.
2. Kontrollera först Log Viewer och WebAdmin Packet Capture om det är tillräckligt.
3. Skapa endast vid behov en snävt filtrerad tcpdump-insamling som PCAP.
4. Överför PCAP fil säkert.
5. Ta bort filen PCAP från brandväggen efter lyckad överföring.

PCAP-filen hör inte hemma i /log-arkivet, utan skapas och överförs separat. Detta gör det tydligt vilken fil som innehåller tjänstloggar och vilken fil som innehåller nätverkspaket.

Säkerhet, integritet och städning

Loggfiler kan innehålla känslig information, till exempel:

• Offentliga och interna IP-adresser
• Användarnamn
• Värdnamn
• VPN information
• Felmeddelanden med tekniska detaljer
• Information om interna nätverksstrukturer

Loggarkiv bör därför endast överföras via säkra kanaler och endast göras tillgängliga för personer eller organisationer som är involverade i analysen. Om loggar skickas till en extern partner bör det i förväg klargöras internt om överföringen är tillåten enligt dina egna dataskydds- och säkerhetsriktlinjer.

I HA-kluster synkroniseras loggar och rapporter inte automatiskt mellan Primary- och Auxiliary-enheterna. Varje enhet innehåller loggar och rapporter för den trafik som den bearbetar. Vid HA-problem eller perioder som omfattar en failover bör du dokumentera vilken nod arkivet kommer från och om loggar från den andra noden också behövs.

Ta bort tillfälliga arkiv

Kontrollera arkivet på målsystemet efter överföringen och ta sedan bort det från brandväggen för att frigöra det tillfälliga utrymmet. Följande kommandon tar endast bort de fasta arkivnamn som skapats i den här guiden:

rm /var/Sophos-Firewall-Logs.tar.gz

Om ett separat IPsec-arkiv också skapades, bör detta också tas bort:

rm /var/Sophos-Firewall-IPsec-Connections.tar.gz

Innan du tar bort bör du kontrollera om filerna har anlänt till målsystemet.

Checklista för supportärenden

• Problem beskrivet kort: Vad fungerar inte, sedan när, hur ofta?
• Exakt tid noteras med tidszon.
• Berörd käll-IP, destinations-IP, användare, tjänst eller tunnelnamn noterat.
• Relevant modul kontrollerad i Log Viewer.
• Vid behov: Debug aktiveras endast kort och avaktiveras igen.
• CTR skapas under Diagnostics > Tools när Sophos Support eller en ögonblicksbild av systemet krävs.
• Om det behövs, skapa individuella felsökningsloggar eller kompletta /log-arkiv.
• Vid IPsec-problem säkerhetskopieras också IPsec-diagnostikdata.
• Vid paketflödesproblem har Packet Capture eller tcpdump skapats separat.
• Kontrollerat faktiska loggfiler med tar -tzf endast i manuella gzip-arkiv; för krypterad CTR kontrollerat nedladdning, enhet och tid.
• Vid HA kontrollerade vilken nod loggarna kommer från.
• Arkiv och PCAP överförs endast via säkra kanaler.
• Tillfälliga filer på brandväggen togs bort efter lyckad överföring.

FAQ