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 uppe till höger i WebAdmin och välj relevant modul.
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?

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 tidsstämpel och samma adresser:

• 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: För HTTP- och HTTPS-trafik på port 80 och 443 lämnar en matchande brandväggsregel med Drop över flödet till Web Proxy. Utan en matchande Web Exception visar Firewall-loggen då Allowed, medan Web filter-loggen visar Blocked. Konfigurerade Web Exceptions fortsätter att gälla, så en förfrågan kan tillåtas trots Drop. Reject avslutar däremot flödet före proxybearbetningen. Kontrollera därför alltid brandväggsregeln, Web Policy och Web Exceptions tillsammans.

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.

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: begränsar händelserna till testperioden.
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.

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ö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.

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.

Ändra regler från Log Viewer endast kontrollerat

Beroende på händelsen kan Log Viewer öppna Web Policies, brandväggsregler eller SSL/TLS-regler direkt. 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 SSL/TLS-händelser leder Manage > Exclude till olika konfigurationsmål beroende på matchningen: domäner och subdomäner läggs till i Local TLS exclusion list, webbkategorier i undantagen för den valda SSL/TLS-regeln och andra egenskaper i en SSL/TLS-regel med lämpliga användar- eller IP-objekt. Log Viewer erbjuder inte Exclude för fel-ID 19004 och 19005.

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.