Skicka Sophos Firewall Syslog till SIEM
Med Syslog kan en Sophos Firewall skicka händelser till en extern loggserver, ett SIEM eller en säkerhetsplattform. Detta är särskilt viktigt när loggar behöver lagras längre, sökas centralt, korreleras med andra system eller användas för revisioner och incidenthantering.
Den lokala Log viewer är bra för snabb analys direkt på brandväggen. Central Firewall Reporting är praktiskt när Sophos Central används som rapporteringsplattform. Syslog är däremot det bättre valet när en egen SIEM, ett SOC, en Managed Detection-process eller en leverantörsövergripande loggarkitektur finns.
Vilken loggningsartikel passar?
Loggning på Sophos Firewall består av flera nivåer. Beroende på frågan är Syslog inte alltid den bästa utgångspunkten:
| Uppgift | Passande artikel |
|---|---|
| Analysera enskild anslutning, regel-ID eller webb-/IPS-beslut live | Testa Sophos Firewall-regel med Log Viewer, Policy tester och Packet Capture |
| Tilldela lokala loggfiler och tjänster | Felsökning av Sophos Firewall: Tjänster och loggar |
| Säkerhetskopiera loggar för support eller extern analys | Säkerhetskopiera Sophos Firewall-loggar för support och analys |
| Spåra konfigurationsändringar och admin-åtgärder | Granska Sophos Firewall Audit Trail Logs |
| Använd Sophos Central-baserade rapporter över flera brandväggar | Aktivera och driva Sophos Firewall Central Reporting |
| Skicka loggar långsiktigt till SIEM, SOC eller loggserver | Denna artikel |
| Analysera trafikflöden istället för enskilda brandväggshändelser | Konfigurera sFlow Monitoring på Sophos Firewall |
| Kontrollera hårdvaru- och gränssnittstillstånd via övervakning | Ställ in Sophos Firewall SNMP Hardware Monitoring |
Så här hålls utvärderingen ren: Log Viewer svarar på det aktuella paket- eller policyfallet, lokala loggar hjälper vid djupare modulfelsökning, Central Reporting är bekvämt för Sophos-utvärderingar, och Syslog levererar det externa långsiktiga och SIEM-lagret.
När Syslog är meningsfullt
Syslog är inte bara värt för stora miljöer. Även med få brandväggar kan en central loggserver hjälpa till att lagra händelser längre och oberoende av enheten.
Typiska användningsfall:
- central logglagring över veckor, månader eller år
- korrelation med endpoint-, server-, identitets-, proxy-, moln- eller switch-loggar
- SIEM-användningsfall för attacker, portskanningar, VPN-inloggningar, WAF-händelser eller Threat Feed-träffar
- extern utvärdering av SOC, MDR eller interna säkerhetsteam
- spårbarhet efter firmwareuppdateringar, failover, återställning eller hårdvarubyte
- forensik när lokala brandväggsloggar inte längre räcker till
För akuta felsökningsfall är lokala loggar fortfarande viktiga. Vilken lokal loggfil som hör till vilket brandväggsmodul finns i Felsökning av Sophos Firewall: Tjänster och loggar. Om loggar ska säkerhetskopieras för support eller extern analys, passar Säkerhetskopiera Sophos Firewall-loggar för support och analys.
Syslog, Central Reporting eller lokala loggar?
De tre vägarna svarar på olika frågor. I praktiken används ofta flera av dem parallellt.
| Mål | Styrka | Begränsning |
|---|---|---|
| Log viewer | snabb live-analys på brandväggen | ingen långsiktig central arkitektur |
| Lokala loggfiler | detaljanalys via Advanced Shell eller supportfall | beroende av brandväggens tillstånd och lagring |
| Central Firewall Reporting | Sophos Central-rapporter, enkel översikt över flera brandväggar | beroende av Sophos Central, licens och lagringsram |
| Syslog / SIEM | egen lagring, korrelation, detektion och revision | kräver parser, drift, övervakning och tydliga användningsfall |
Syslog ersätter alltså inte Log Viewer. Det kompletterar den. Log Viewer visar snabbt vilken regel eller vilket modul som beslutade. Syslog säkerställer att denna information senare är tillgänglig externt.
Förutsättningar
Innan konfigurationen bör dessa punkter klargöras:
- Syslog-server eller SIEM är tillgänglig.
- Mål-IP eller FQDN är stabil och dokumenterad.
- Port och transport är fastställda, ofta UDP 514 eller TLS på en egen port.
- Brandväggen kan routa och nå Syslog-servern.
- I målsystemet finns en passande parser eller åtminstone en rådataarkivering.
- Lagringstid och dataskyddskrav är definierade.
- Det är klart vilka loggtyper som verkligen behövs.
Vid externa eller molnbaserade SIEM-mål bör man särskilt uppmärksamma transportkryptering, käll-IP, routing, DNS och certifikatkontroll.
Klargör dataskydd, lagring och ansvar
Syslog är inte bara en teknisk vidarebefordran. Brandväggsloggar kan innehålla interna IP-adresser, användarnamn, målsystem, URL:er, kategorier, VPN-inloggningar, admin-händelser och säkerhetsträffar. Därför bör det innan produktiv anslutning vara klart vem som får se dessa data och hur länge de lagras.
Innan utrullning klargör:
| Punkt | Praktisk fråga |
|---|---|
| Lagring | Hur länge måste loggar vara tillgängliga för drift, revision eller incidenthantering? |
| Åtkomst | Vilka personer eller team får se råloggar, sökfrågor och dashboards? |
| Dataskydd | Innehåller loggar personuppgifter, användar-ID:n, käll-IP-adresser eller URL:er? |
| Multitenancy | Är platser, kunder, hyresgäster eller HA-kluster tydligt separerade i SIEM? |
| Kostnader | Debiteras loggvolym, EPS, lagring eller sökfrågor av SIEM-leverantören? |
| Larm | Vem reagerar på larm och inom vilket tidsfönster? |
| Radering | Hur tas gamla loggar bort efter lagringstidens utgång? |
Särskilt i MSP-, SOC- eller MDR-modeller bör detta ansvar inte lämnas öppet. Ett SIEM utan tydliga ägare genererar visserligen data, men ingen pålitlig reaktion.
Planera utrullning i faser
För produktiva brandväggar är en liten pilot bättre än att omedelbart skicka alla loggtyper till alla mål. Så kan man kontrollera parser, fältnamn, brus och kostnader innan SIEM planeras som en pålitlig källa.
En meningsfull process:
- Först väljs en pilot-brandvägg.
- Värdnamn, tidskälla, firmwareversion och loggformat dokumenteras.
- Syslog-målet konfigureras med säker transport.
- Starten sker med få loggtyper, till exempel brandvägg, händelser och VPN.
- Definierade testhändelser genereras och kontrolleras i målsystemet.
- Parser, fält, tidsstämplar, tidszon och
device_namevalideras. - Loggvolym och brus observeras under några dagar.
- Därefter läggs fler loggtyper som IPS, Web, WAF, Active threat response eller System health till.
- Först efter en lyckad pilot rullas det ut på fler brandväggar.
Vid flera brandväggar bör man inte bara kontrollera om data kommer fram. Viktigt är om varje händelse tilldelas rätt plats, enhet, HA-nod, kund eller hyresgäst.
Lägg till Syslog-server
Konfigurationen sker i Sophos Firewall-webbgränssnittet.
- Öppna System services > Log settings.
- Välj Add.
- Ge ett unikt namn, till exempel
siem-primaryellersyslog-soc. - Ange IP address/domain för Syslog-servern.
- Ställ in Port som passar målsystemet.
- Välj Facility medvetet.
- Ange Severity level.
- Välj Format.
- Aktivera valfritt Secure log transmission om målet stöder TLS.
- Spara.
Sophos Firewall kan konfigurera flera externa Syslog-servrar. I den aktuella dokumentationen är upp till fem Syslog-servrar möjliga. Trots detta bör man inte ansluta varje mål slumpmässigt, utan fastställa syftet för varje mål.
Viktiga inställningar
Facility
Facility hjälper Syslog-servern att skilja loggkällor eller kategorier. I enkla miljöer räcker ofta ett standardvärde. I större miljöer kan det vara meningsfullt att skilja brandväggar eller platsgrupper med olika LOCAL0 till LOCAL7 värden.
Viktigt är att SIEM-regler, parser och dokumentation använder samma logik. Om varje brandvägg använder en annan facility av en slump, blir utvärderingen onödigt svår.
Severity level
Severity bestämmer från vilken allvarlighetsgrad loggar skickas. För säkerhets- och felsökningsändamål är en för hög tröskel farlig, eftersom viktiga informations- eller notishändelser då kan saknas. För mycket bullriga miljöer kan en för låg tröskel däremot skapa onödigt mycket brus.
Det är oftast meningsfullt med en pilot med bredare loggval, följt av en medveten reduktion baserat på verkliga träffar och SIEM-användningsfall.
Format
Sophos Firewall erbjuder enligt aktuell dokumentation två format:
- Standard syslog protocol
- Device standard format (legacy)
För nya integrationer bör man först kontrollera vilket format målsystemet eller den befintliga parsern förväntar sig. Om ett SIEM redan har en Sophos Firewall-parser är dess förväntan avgörande. Ett formatbyte efter produktionsstart kan bryta dashboards, sökfrågor och detektionsregler.
Secure log transmission
När Secure log transmission är aktiv skickas loggar krypterade till Syslog-servern. För detta måste målsystemet acceptera TLS på den konfigurerade porten, leverera ett passande servercertifikat och använda en certifikatkedja som brandväggen litar på. Innan Go-live bör därför inte bara kryssrutan i brandväggen markeras, utan även certifikatnamn, trust chain, port, parser och förnyelseprocess för Syslog-målet kontrolleras.
För interna laboratorier kan UDP tekniskt sett räcka. För produktiva SIEM- eller SOC-anslutningar är dock okrypterad Syslog över osäkra nätverk ingen bra grund, eftersom loggdata kan innehålla interna IP-adresser, användare, mål, URL:er eller säkerhetshändelser.
Vid TLS är namnet på Syslog-målet viktigt. Sophos kontrollerar beroende på läge Common Name eller Subject Alternative Name på certifikatet mot domänen för Syslog-servern. Om en IP-adress anges i brandväggen men certifikatet endast innehåller ett DNS-namn kan anslutningen misslyckas. Därför bör man för produktiva TLS-Syslog-mål planera en stabil FQDN, ett passande servercertifikat och en dokumenterad certifikatförlängning.
Välj loggtyper
Efter att ha lagt till Syslog-servern är arbetet inte klart. Man måste under System services > Log settings fastställa vilka loggtyper som ska skickas till detta mål.
Viktigt: En brandväggsregel genererar endast meningsfulla trafikloggar om Log firewall traffic är aktiverat i regeln. För SSL/TLS Inspection måste även loggning vara aktiv i den passande inspektionsregeln. Loggvalet under Log settings bestämmer sedan vart dessa loggar skickas.
Typiska loggtyper för ett SIEM:
| Loggtyp | Varför den är användbar |
|---|---|
| Firewall | tillåtna och avvisade anslutningar, regelmatchning, DoS-händelser |
| IPS | upptäckta eller blockerade attacker |
| Web / Content filtering | webbåtkomst, kategorier, webbpolicyhändelser |
| SSL/TLS inspection | TLS-inspektionsbeslut och fel |
| Web server protection | WAF-händelser för publicerade tjänster |
| Authentication / Events | admin-, användar- och systemhändelser |
| VPN | fjärråtkomst och site-to-site VPN-händelser |
| Active threat response | träffar från MDR Threat Feeds, NDR Essentials, Sophos X-Ops och tredjeparts Threat Feeds |
| System health | CPU, minne, användare, gränssnitt och partitioner |
Om DoS- eller spoof-händelser ska utvärderas bör den tekniska härdningen själv också kontrolleras. Processen finns i Kontrollera Sophos Firewall Spoof Protection och DoS-inställningar.
Om Tredjeparts Threat Feeds, NDR och Active Threat Response eller WAF används bör SIEM utvärdera dessa händelser specifikt. Att bara skicka loggar räcker inte. Det behövs tydliga sökfrågor, larm, ansvar och justering mot falsklarm.
Viktiga synlighetsfällor
Vid Syslog-projekt uppstår många luckor inte i transporten, utan tidigare: Brandväggen genererar inte den förväntade händelsen, loggtypen skickas inte till Syslog-servern eller SIEM tolkar fälten fel.
Regel- och modul-loggning
Brandväggsregler och SSL/TLS-inspektionsregler måste själva generera loggning. Under System services > Log settings väljer man sedan om dessa loggar ska skickas lokalt, till Sophos Central eller till Syslog-servrar. Om en brandväggsregel inte har Log firewall traffic kan Syslog-servern inte visa en fullständig brandväggstrafikförlopp.
För webbpolicyhändelser är det också relevant om den tillhörande brandväggsregeln genererar trafikloggning. Annars kan man i SIEM se färre webb- eller innehållsfiltreringshändelser än förväntat.
Log Suppression
Sophos Firewall kan undertrycka flera likadana på varandra följande loggposter. Det sparar lagring och bearbetning, men kan förvirra vid SIEM-användningsfall när räknevärden, frekvens eller burst-beteende ska utvärderas. Funktionen påverkar Log Viewer, Sophos Central och externa Syslog-servrar.
Innan en produktiv SIEM-utrullning bör man därför fastställa:
- Vilka brandväggshändelser får undertryckas?
- Vilka detektionsregler behöver varje enskild anslutning?
- Arbetar SIEM med räknevärden eller bara med enskilda händelser?
- Hur dokumenteras att Log Suppression är aktiv?
Active Threat Response
Active-Threat-Response-loggar är särskilt användbara när Threat Feeds, NDR Essentials eller externa feeds används. Sophos skiljer mellan olika matchningstyper, till exempel målträffar vid utgående trafik och källträffar vid inkommande trafik.
Viktigt: Remote Source Match för inkommande trafik är inte automatiskt aktiv. Om WAF- eller DNAT-trafik ska övervakas mot Threat Feeds måste denna synlighet medvetet kontrolleras. Annars saknas precis de inkommande träffar som ett SOC ofta förväntar sig.
Trådlösa loggar
Trådlösa loggar är inte automatiskt synliga i den lokala Log Viewer. Access Point- och SSID-loggar bör skickas specifikt till Sophos Central eller Syslog och kontrolleras separat i målsystemet om trådlösa händelser är relevanta för drift, support eller efterlevnad.
Multi-Firewall-miljöer
I miljöer med flera brandväggar måste varje händelse tydligt kunna tilldelas en enhet. För detta är värdnamn, serienummer, modell och andra fält relevanta. SFOS-Syslog-guiden beskriver bland annat fält som device_name, device_model och device_serial_id.
Praktiska rekommendationer:
- Sätt brandväggens värdnamn korrekt.
- Beakta plats eller roll i värdnamnet.
- Definiera enhetlig facility- eller taggningsstrategi.
- Kontrollera i SIEM om händelser kan filtreras efter brandvägg, plats och kluster.
- Skilj tydligt mellan HA-kluster och fristående brandväggar.
Särskilt efter ett hårdvarubyte eller återställning är denna tilldelning viktig. Annars kan händelser i SIEM verka som nya eller dubbla system.
Testa konfigurationen
Efter att ha sparat bör anslutningen medvetet testas. Ett grönt målsystem bevisar inte att rätt loggar med rätt fält kommer fram.
Testpunkter:
- Öppna System services > Log settings på brandväggen.
- Säkerställ att Syslog-servern är synlig.
- Aktivera testvis Syslog för en ofarlig loggtyp.
- Utlös en definierad åtgärd, till exempel en loggad brandväggsregel eller ett teståtkomst.
- Kontrollera i målsystemet om händelsen kommer fram.
- Kontrollera fält som tid, värdnamn,
device_name, källa, destination, regel-ID, åtgärd och loggtyp. - Kontrollera tidsstämplar och tidszon i SIEM.
För regeltester är Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture användbart. Om inga händelser alls uppstår ligger orsaken ofta inte i Syslog-transporten, utan i inaktiverad loggning i regeln eller fel loggtyp.
Drift och övervakning
En Syslog-anslutning är inte en engångskryss. Driften måste övervakas och regelbundet kontrolleras.
Minst dessa punkter bör dokumenteras:
- Vem är ägare av loggplattformen?
- Vilka brandväggar skickar loggar?
- Vilka loggtyper skickas?
- Vilken lagringstid gäller?
- Vilka parser, dashboards och larm är kopplade till det?
- Hur upptäcker man att inga loggar längre kommer fram?
- Hur kontrolleras formatändringar efter firmwareuppdateringar?
- Vem utvärderar falsklarm och justerar SIEM-regler?
Efter firmwareuppdateringar bör man stickprovsvis kontrollera om viktiga händelser fortfarande tolkas korrekt. Detta gäller särskilt för produktiva SIEM-regler som är beroende av specifika fältnamn, loggtyper eller format.
Felsökning
Inga loggar kommer fram till SIEM
Kontrollera först IP-adress, port, routing och brandväggsregler mellan Sophos Firewall och Syslog-servern. Kontrollera sedan om rätt loggtyp för Syslog-servern är aktiverad under System services > Log settings.
Endast vissa händelser saknas
Då är ofta modul- eller regelloggning inte aktiv. För brandväggsregler måste Log firewall traffic vara aktiverat. För webb- eller SSL/TLS-händelser måste dessutom den passande policyn eller inspektionsregeln generera loggning.
Loggar kommer fram men tolkas fel
Kontrollera format, parser-version och firmwareversion. Om man har bytt mellan Standard syslog protocol och Device standard format (legacy) måste SIEM-parsern passa.
TLS-Syslog ansluter inte
Kontrollera FQDN, certifikat, Common Name, Subject Alternative Name, certifikatkedja och port. Om brandväggen förväntar sig ett DNS-namn men Syslog-servern endast är angiven med IP-adress kan certifikatkontrollen misslyckas. Kontrollera dessutom om målsystemet verkligen accepterar TLS på den konfigurerade porten.
Tidsstämplar stämmer inte
Kontrollera NTP på brandväggen, tidszon i SIEM och parser-logik. Felaktiga tider gör korrelation med endpoint-, server- eller identitetsloggar opålitlig.
För många loggar eller för mycket brus
Inaktivera inte allt omedelbart. Kontrollera först vilka loggtyper som verkligen behövs, vilka regler som loggar onödigt mycket och om loggsuppression är meningsfull. Reducera sedan målmedvetet.
Checklista
- Syslog-server eller SIEM är tillgänglig.
- Transport, port och kryptering är fastställda.
- Formatet passar SIEM-parsern.
- Facility-strategi är dokumenterad.
- Relevanta loggtyper är aktiverade under System services > Log settings.
- Viktiga brandväggsregler har Log firewall traffic aktiv.
- SSL/TLS-inspektionsregler genererar vid behov egna loggar.
- Log Suppression är medvetet utvärderad och dokumenterad.
- Active-Threat-Response-matchningstyper passar SIEM-användningsfallen.
- Dataskydd, åtkomst och lagringstid är klargjorda.
- Pilot-brandvägg, testhändelser och SIEM-parser har validerats.
- Testhändelser kommer fram i målsystemet.
- Fält som värdnamn,
device_name, källa, destination, åtgärd och regel-ID känns igen korrekt. - Tidsstämplar och tidszon stämmer.
- Övervakning upptäcker när inga loggar längre kommer fram.
- Efter firmwareuppdateringar kontrolleras parser-funktionen.