Använd Sophos Firewall Log Viewer på rätt sätt

I SFOS 22 är Log Viewer ofta den snabbaste utgångspunkten vid en störning: Vilken brandväggsregel hanterade trafiken, vilken NAT-regel användes, vilken användare identifierades och vilken säkerhetsmodul blockerade? För att svaret ska bli korrekt måste modul, tidsintervall, filter och tidpunkten för loggposten stämma överens.

Log Viewer visar loggade händelser. Den är varken Packet Capture eller en fullständig anslutningshistorik. En saknad post bevisar därför varken ett drop eller att paketet nådde brandväggen.

För en tillförlitlig analys dokumenteras alltid source, destination, service, exakt testtid och förväntad riktning. Därefter skapas exakt ett nytt testflöde och söks i de relevanta modulerna.

Utvärdera ett test i sju steg

1. Kontrollera Log firewall traffic i den berörda brandväggsregeln eller Log connections i SSL/TLS-regeln.
2. Säkerställ under System services > Log settings att den nödvändiga loggtypen är aktiverad under Local reporting.
3. Öppna Log viewer (SFOS 22) eller Logs and policy test (SFOS 23) uppe till höger i WebAdmin och välj sedan relevant loggmodul.
4. Ställ in tidsfiltret och begränsa först vyn efter source-IP, destination-IP och service med Add filter.
5. Skapa ett nytt, kort testflöde och notera den exakta tiden.
6. Kontrollera Rule ID, NAT ID, action, interfaces, användare och modulspecifika fält i Detailed view.
7. Om posten inte stämmer med det observerade beteendet, korrelera samma test med Packet Capture innan en regel ändras.

Den här ordningen skiljer mellan tre frågor som ofta blandas ihop: Skapades någon logg över huvud taget? Vilken policy fattade beslutet? Och gick paketen faktiskt in och ut igen?

Event Logs registrerar autentisering, systemhändelser och konfigurationsändringar utöver trafik och lagras lokalt som standard. Troubleshooting Logs är detaljerade tjänsteloggar som nås via WebAdmin eller CLI. Arbetsflödet för tjänsteloggar förklarar åtkomst och debuginsamling. Debug använder extra diskutrymme och måste stängas av efter den nödvändiga insamlingen; det är ingen knapp för att återställa saknade Event Logs.

För central överföring måste brandväggen vara registrerad för Sophos Central Firewall Management. Aktivera därefter Central-tjänster och Send reports and logs to Sophos Central och välj nödvändiga loggtyper under System services > Log settings. Den granskade SFOS 22-dokumentationen kallar målet Sophos Fusion, medan SFOS 23-dokumentationen kallar det Sophos Central; följ de angivna UI-fälten. Arbetsflödet för Central Reporting beskriver konfiguration och mottagningskontroll.

Läs loggposter korrekt

Varför loggposter inte alltid visas direkt

Log Viewer uppdaterar vyn automatiskt. En brandväggssession loggas dock normalt först när brandväggen tar emot en Destroy-händelse och stänger anslutningen. Vid en lång session kan loggposten därför visas senare än den första förfrågan.

Om en anslutning avbryts utan att brandväggen tar emot en Destroy-händelse, exempelvis när internetanslutningen försvinner, kan den förväntade sessionsloggen saknas helt. SSL/TLS-anslutningar loggas efter en lyckad handshake och när de stängs. För ett kort test är därför en avsiktligt avslutad anslutning bättre än en permanent öppen webbläsar-, streaming- eller HTTP/2-session.

En uppdatering i webbläsaren skapar inte nödvändigtvis en ny anslutning. Beroende på applikationen passar ett privat webbläsarfönster, en omstartad klientprocess eller ett kort anrop som detta för ett reproducerbart test:

curl -I https://example.com/

Kommandot körs på testklienten, inte i brandväggens shell. example.com är en reserverad exempeldomän och kan ersättas med en känd, tillåten tjänst.

Välj rätt modul

Ett trafikflöde kan beröra flera loggmoduler. Modulen Firewall kan exempelvis visa att en LAN-to-WAN-regel tillät anslutningen, medan Web filter, Application filter, IPS eller SSL/TLS inspection senare blockerar eller behandlar samma flöde på ett annat sätt.

Därför räcker inte en enskild grön brandväggspost vid webb- eller säkerhetsproblem. Modulerna korreleras för samma testflöde utifrån testperioden och adresserna:

• Firewall: regelbeslut, NAT, interfaces, portar och grundläggande anslutningsstatus.
• Web filter: beslut om URL, kategori och Web Policy.
• SSL/TLS inspection: beslut om certifikat, handshake och dekryptering.
• Application filter: identifierad applikation och Application Control-action.
• IPS: signatur- eller avvikelsehändelser.
• VPN: etablering och status för respektive VPN-komponent.
• Authentication: identifierad användare samt lyckad eller misslyckad autentisering.
• System: systemhändelser och händelser som utlösts av administratörer.
• SD-WAN: SD-WAN-profil, SLA och ruttanvändning.

Vilka loggtyper som visas lokalt bestäms under System services > Log settings i Local reporting. Dessa Event Logs är inte samma sak som On-box Reports. Central reporting och syslog är separata mål som måste aktiveras var för sig. Web Policy-händelser kräver dessutom Log firewall traffic i den tillhörande brandväggsregeln. Wireless-loggar är inte tillgängliga i Log Viewer utan måste skickas till Sophos Fusion (tidigare Sophos Central) eller en syslog-server.

Web Proxy-gräns: SFOS 22/23-dokumentationen om loggbeteende beskriver denna proxyväg för HTTP/HTTPS på port 80 och 443: en matchande Drop-regel lämnar inkommande paket till Web Proxy, som skickar en blockeringssida till användaren; utan en matchande Web Exception visar Firewall-loggen Allowed och Web filter-loggen Blocked. Web Exceptions gäller fortfarande och kan tillåta förfrågningar trots Drop. Den dokumenterade Reject-vägen avslutar flödet före proxybearbetningen. Kontrollera brandväggsregeln, Web Policy och Web Exceptions tillsammans; detta är ett dokumenterat scenario, inte en universell garanti för en blockeringssida i varje build eller inspektionsläge.

Olöst dokumentationskonflikt: SFOS 22/23-hjälpen för regelformuläret beskriver autentisering av okända webbanvändare när Use web authentication for unknown users är aktiverat, tillåter matchande Web Exceptions och beskriver annars en HTML-blockeringssida. Guiden för loggning av bortkastad trafik beskriver däremot att trafiken kastas utan meddelande och kopplar webbens blockeringssida till autentiseringsalternativet. Dra inte slutsatsen att enbart alternativet avgör svaret. Innan Drop används som grund för webbblockering krävs ett skriftligt förtydligande från Sophos för exakt version, build och bearbetningsväg, eller en uttryckligen godkänd, isolerad verifiering. Dokumentera aktuell regel och inställningar för återställning; kontrollera HTTP och HTTPS separat, kända/okända användare, autentisering på/av och matchande undantag finns/saknas. Korrelera nya flöden med Rule ID, loggar, Packet Capture och webbläsarresultat. Varken en blockeringssida eller en timeout bevisar ensamt blockering. Vid oväntad åtkomst eller oklara resultat ska teständringarna återställas och ärendet eskaleras; inför inte ändringen i produktion.

På andra portar än 80 och 443 släpper en matchande Drop-regel inte igenom paketen; Firewall-loggen visar dropped. Med Reject visar Firewall-loggen rejected, både på 80/443 och andra portar. Dessa observationer kräver Log firewall traffic i den matchande regeln. En Web Exception kan exempelvis tillåta Windows-uppdateringar från Microsoft trots en Drop-regel; det motiverar inte att regeln breddas utan analys.

Allow-regel och saknad heartbeat

Ett annat fall än Drop uppstår när den brandväggsregel som faktiskt matchar har Action Allow, Block clients with no Heartbeat är aktiverat och endpointen inte skickar någon heartbeat. Log firewall traffic måste vara aktiverat i regeln för de loggobservationer som beskrivs här. Kontrollera även de nödvändiga loggtyperna under System services > Log settings > Local reporting före sökningen; enbart ett aktiverat externt loggmål räcker inte för den lokala vyn.

• Andra portar än 80 och 443: Brandväggen släpper inte igenom endpointens paket. Firewall-loggen visar dropped.
• Portar 80 och 443 i den dokumenterade Web Proxy-vägen: Brandväggen accepterar inkommande paket och lämnar dem till Web Proxy. Eftersom endpointen inte skickar någon heartbeat beslutar heartbeat-systemet att blockera; proxyn skickar en blockeringssida till användaren. Firewall-loggen visar allowed, en annan Firewall-logg visar Heartbeat blocked och Web filter-loggen visar blocked. Här hör Heartbeat blocked alltså också till Firewall-modulen, inte till en separat heartbeat-loggmodul.

Allowed ensamt bevisar inte att åtkomsten lyckades. Korrelera posterna för samma testflöde innan en regel ändras: kontrollera testperiod, source, destination, portar och matchande regel tillsammans. Sök efter den separata Heartbeat blocked-posten och Web filter-posten med blocked. Det kräver varken en fast händelseordning, identiska tidsstämplar eller ett universellt antal loggrader; om förväntade poster saknas kontrolleras först loggning, lokala mål och filter, och vid behov används Packet Capture.

Denna tolkning gäller exakt detta regelalternativ, en endpoint utan heartbeat och den beskrivna proxyvägen. Den är inte ett allmänt påstående om alla Allow-regler, röda eller på annat sätt ohälsosamma endpoints eller andra inspektionslägen. Inaktivera inte heartbeat-kravet som en generell lösning; fastställ först regelmatchningen och orsaken till den saknade heartbeaten.

Skilj mellan Standard view och Detailed view

Standard view passar för snabb läsning. Kolumner kan visas eller döljas, och ett klick på ett värde kan använda det direkt som filter. För teknisk verifiering är Detailed view viktigare eftersom den visar de underliggande fältnamnen och ytterligare värden.

En viktig NAT-detalj: Om en annan översatt source-adress än standardadressen för MASQ används kan Standard view ändå visa MASQ-adressen som utgående adress. Den faktiskt översatta source-adressen finns i Detailed view i fältet src_trans_ip.

I Standard view visas även detaljer när muspekaren hålls över en modulikon. Kopieringsfunktionen lägger logginformation i urklipp. Viewer öppnas i ett nytt webbläsarfönster i helskärm; om det inte visas kontrolleras först webbläsarens popupblockering.

Typiska fält vid ett brandväggstest är:

• source- och destination-IP samt source- och destination-port
• In interface och Out interface
• Firewall Rule ID och NAT Rule ID
• Action eller status
• användarnamn, om en identitet identifierades
• översatt source och destination
• Log component och Log subtype

Ett fältnamn eller ID förklarar inte orsaken automatiskt. Rule ID jämförs med den aktuella regelbasen, NAT ID med motsvarande NAT-regel och ett Security-Policy-ID med respektive modul.

Om en Packet Capture samtidigt är aktiv under Diagnostics > Packet capture kan Open PCAP på motsvarande loggpost öppna tillhörande paketinformation. Funktionen kopplar loggbeslutet till paketdetaljerna, men ersätter inte ett tydligt avgränsat fångstfilter: source, destination, port och testtid måste fortfarande motsvara det flöde som undersöks.

Isolera rätt flöde

Filtrera så att endast rätt flöde återstår

Log Viewer har fyra filternivåer:

1. Module: begränsar vyn till Firewall, Web, IPS, VPN eller ett annat område.
2. Time / Timer filter: begränsar händelserna till testperioden; klicka på Timer filter och välj ett tidsalternativ.
3. Add filter: kombinerar ett specifikt fält, ett villkor och ett värde.
4. Free text search: söker exempelvis efter port, IP-adress, användare eller regelnamn och fungerar även med anonymiserad information.

Ett normalt anslutningstest börjar med source-IP, destination-IP och destination-port. Därefter begränsas resultatet ytterligare med Rule ID, användare eller Action. Reset tar bort alla filter. Det är viktigt eftersom ett gammalt tids- eller fältfilter lätt kan ge intrycket att viewer inte längre tar emot nya händelser.

Antalet tillgängliga poster beror på diskstorlek och lokal lagringstid. Log Viewer ersätter därför inte en långsiktig, manipulationsskyddad lagring. För det passar Central Firewall Reporting eller skicka syslog till ett SIEM.

Den lokala kvoten för Event Logs beror på appliancemodellen: för större modeller anger Sophos upp till 15 procent av hela /var-partitionen eller 50 procent av dess lediga utrymme, beroende på vilket som är lägst. Det är varken en garanterad lagringstid eller en kvot för alla modeller. Lagringsanalysen skiljer mellan Event Logs, rapporter och Troubleshooting Logs; radera inte filer på chans.

Använd Pause, Refresh och CSV-export korrekt

Pause stoppar den automatiska uppdateringen av vyn. Det är användbart när en rad behöver läsas eller kopieras i lugn och ro. Det stoppar inte loggningen på brandväggen. Refresh laddar om vyn manuellt och Export hämtar de för närvarande tillgängliga loggarna som CSV.

Dokumentera modul, tidsintervall och filter före exporten. CSV-filen kan innehålla interna IP-adresser, användarnamn, URL:er och kommunikationsrelationer och ska därför hanteras i ett skyddat support- eller analysflöde.

När Data anonymization är aktiverad visas identifierande värden som användarnamn, IP-, MAC- och e-postadress i skyddad form. Sophos rekommenderar minst två Authorizers: om den inloggade administratören är en av dem måste minst en annan behörig person godkänna avanonymiseringen. En skärmbild eller export bör ändå bara innehålla de rader som behövs för ärendet.

För att visa identiteter med avanonymiseringsfunktionen krävs behörighet och att autentiseringsuppgifter anges. Att kopiera en rad ersätter inte denna auktorisering.

Förstå Log suppression och Log occurrence

Under System services > Log settings kan brandväggen undertrycka efterföljande, identiska Firewall-händelser. Det sparar lagring och bearbetning. Undertryckningen påverkar inte bara lokala loggar utan även Sophos Fusion och konfigurerade syslog-mål.

I Log Viewer visar Log occurrence hur många gånger en sammanfattad händelse inträffade. En enda rad kan därför representera många upprepningar. Den får inte automatiskt räknas som ett enda paket eller en enda anslutning.

Kontrollera om den aktuella loggvolymen verkligen orsakar ett problem innan Log suppression ändras. För en kort diagnos räcker det oftast att läsa Log occurrence medvetet. En global ändring påverkar även externa loggmål och bör inte göras enbart för att skapa en skärmbild.

Tolka resultat på ett säkert sätt

Tolka Invalid traffic korrekt

Invalid traffic betyder att conntrack inte kunde koppla ett paket till en aktuell anslutning. Det kan inträffa vid en asymmetrisk väg, en utgången session, oväntade TCP-flaggor eller ytterligare RST- och FIN-paket. Det är inte automatiskt ett angrepp eller ett brandväggsfel.

Om ett anslutningsproblem uppstår samtidigt kontrolleras båda riktningarna med Packet Capture. Source, destination, TCP-flaggor, interfaces och tidsstämplar måste tillhöra samma flöde. En ökning av Tcp Connection Establishment Idle Timeout kan minska antalet sådana loggar men löser inte den bakomliggande orsaken i vägen eller sessionen. Värdet ska därför inte ändras på chans.

Loggning av Invalid traffic är aktiverad som standard. Conntrack följer TCP-sessioner samt vissa UDP- och ICMP-sessioner; inledande paket som TCP SYN eller en ICMP Echo Request skapar kopplingen till anslutningen. TCP-flaggorna betyder följande:

• SYN: begär synkronisering.
• SYN-ACK: bekräftar den och kommer överens om anslutningsparametrar.
• ACK: bekräftar överenskommelsen; dataöverföringen kan börja.
• PSH: begär omedelbar leverans av data.
• FIN: begär ett ordnat avslut; båda sidor bekräftar avslutningen.
• RST: avslutar anslutningen utan att vänta på svar, till exempel efter ett oväntat paket.

Extra RST- och FIN-paket kan stoppas och loggas som Invalid traffic. Korrelera en enskild post med det faktiska anslutningsproblemet i stället för att tolka den som ett separat angrepp.

Det skrivskyddade kommandot show advanced-firewall i Device Console visar det aktuella globala värdet; Sophos dokumenterar 10800 sekunder, alltså tre timmar, som standard. En ändring påverkar alla motsvarande TCP-sessioner på firewallen. Först ska den berörda applikationen, dess faktiska inaktivitetstid och händelsen Invalid traffic korreleras entydigt. En högre timeout är endast en motiverad driftsanpassning, inte en lösning på asymmetrisk routing eller paketförlust.

Hela drop-flödet med Reason, Rule ID och det särskilda Firewall ID 0 beskrivs i Analysera tappade paket på Sophos Firewall.

Källan kallar fältet Tcp Connection Establishment Idle Timeout, men beskriver conntrack-poster som löper ut efter inaktivitet och använder inställningen tcp-est-idle-timeout. Namnet är tvetydigt; det bevisar inte en separat handshake-timeout. Kontrollera den faktiska utmatningen och CLI-hjälpen för den egna versionen.

CLI-referensen för SFOS 22/23 kopplar uttryckligen tcp-est-idle-timeout till redan etablerade TCP-anslutningar och tillåter 2700 till 432000 sekunder. Det avvikande fältnamnet används därför inte som en rekommendation att ändra en timeout för anslutningsetablering.

Endast om ett bekräftat fall av idle-timeout motiverar en global justering väljs 4. Device Console i CLI, det befintliga värdet sparas med show advanced-firewall och ett underhållsfönster planeras. Det dokumenterade exemplet ökar värdet till sex timmar, inte till ett generellt rekommenderat värde:

set advanced-firewall tcp-est-idle-timeout 21600
show advanced-firewall

Kontrollera det nya värdet och testa samma applikation igen över den relevanta inaktiva perioden. Färre Invalid traffic-poster bevisar inte i sig att felet är åtgärdat. För återställning används samma inställningskommando med det tidigare sparade antalet sekunder och värdet kontrolleras med show advanced-firewall; 10800 är rätt endast om det var ursprungsvärdet. Om CLI-utmatningen är oklar eller felet kvarstår, avbryt justeringarna och undersök paketvägen eller kontakta support. Arbetsflödet har kontrollerats mot dokumentationen, inte testats på en brandvägg.

Ändra regler från Log Viewer endast kontrollerat

Beroende på händelsen kan Log Viewer öppna Web Policies samt NAT-, brandväggs- eller SSL/TLS-regler direkt. Ett klick på en Web Policy, NAT-regel eller brandväggsregel erbjuder en länk till redigering i WebAdmin. Det är praktiskt, men ersätter inte den tekniska kontrollen. Innan redigering kontrolleras Rule ID, regelnamn, position, zoner, objekt, service, användarmatchning och befintliga sessioner; dessutom dokumenteras de aktuella värdena i fälten som ska ändras så att de kan återställas.

För ett SSL/TLS-undantag väljs SSL/TLS inspection, sedan rullas vyn till Manage och Exclude väljs. Kontrollera alternativet i dialogrutan innan det bekräftas med Exclude. Domain och Subdomain läggs till i URL-gruppen Local TLS exclusion list, som visas under Categories and websites i SSL/TLS-regler. Web category läggs till i Exclusions by website or category, synligt på listan över SSL/TLS-regler. För Other properties väljs SSL/TLS-regeln och lämpliga objekt, som användarnamn eller IP-adresser. Kontrollera målobjekt och omfattning före bekräftelse; ett domänundantag är inte detsamma som ett undantag avsett för bara en användare. Log Viewer erbjuder inte Exclude för 19004 (tillåten trafik) eller 19005 (blockerad av en Web Policy).

Ett klick på ett IPS Signature ID kan erbjuda Disable signature for this IPS policy. Det ändrar den aktiva IPS Policy och inte bara vyn. Dokumentera först berörd regel, policy, signatur, påverkan på skyddet och undantagets omfattning och testa sedan exakt det bekräftade flödet igen.

En bred Allow-regel, ett globalt webbundantag eller avstängd SSL/TLS inspection kan dölja symptomet och samtidigt skapa en ny säkerhetslucka. Begränsa därför ändringarna till det bekräftade flödet, testa dem i ett underhållsfönster och verifiera sedan ett nytt flöde på nytt i Log Viewer och vid behov i Packet Capture. Om testet misslyckas eller undantaget visar sig vara för brett återställs det tidigare dokumenterade läget i det länkade regel- eller policyobjektet, varefter ett nytt flöde testas.

När loggar saknas eller finns på den andra HA-noden

När förväntade loggar saknas

Ett tomt resultat kontrolleras i följande ordning:

1. Kontrollera Pause, modul, tidsintervall och filter, använd sedan Reset och Refresh.
2. Kontrollera Rule Logging och Local reporting för den nödvändiga loggtypen.
3. Skapa en ny, avsiktligt avslutad anslutning med känd tidsstämpel.
4. Bekräfta med Packet Capture att trafiken når brandväggen och vilken Rule ID som hanterar den.
5. Kontrollera andra moduler efter händelser för samma flöde.
6. Undersök viewer- eller loggtjänstens väg först om hela den lokala vyn inte tar emot några nya händelser.

Den versionsbundna diagnostiken för en helt stoppad viewer finns i Log Viewer visar inga nya loggar. En tjänsteomstart eller ett ingrepp i den lokala loggdatabasen ingår inte i normal användning.

Log Viewer i HA-miljöer

Varje HA-node lagrar endast loggar och rapporter för den trafik som den själv bearbetade. Särskilt i active-active eller efter en failover kan den förväntade posten därför finnas på den andra noden. Tidpunkt, nodroll och Connection served by dokumenteras tillsammans.

Central Firewall Reporting eller syslog kan ge en central vy. De ersätter dock inte den nodspecifika kontrollen när en konkret HA-rollväxling, ett lokalt tjänstefel eller trafikvägen vid tidpunkten för händelsen undersöks.