Hoppa till innehållet
Avanet

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:

UppgiftPassande artikel
Analysera enskild anslutning, regel-ID eller webb-/IPS-beslut liveTesta Sophos Firewall-regel med Log Viewer, Policy tester och Packet Capture
Tilldela lokala loggfiler och tjänsterFelsökning av Sophos Firewall: Tjänster och loggar
Säkerhetskopiera loggar för support eller extern analysSäkerhetskopiera Sophos Firewall-loggar för support och analys
Spåra konfigurationsändringar och admin-åtgärderGranska Sophos Firewall Audit Trail Logs
Använd Sophos Central-baserade rapporter över flera brandväggarAktivera och driva Sophos Firewall Central Reporting
Skicka loggar långsiktigt till SIEM, SOC eller loggserverDenna artikel
Analysera trafikflöden istället för enskilda brandväggshändelserKonfigurera sFlow Monitoring på Sophos Firewall
Kontrollera hårdvaru- och gränssnittstillstånd via övervakningStä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ålStyrkaBegränsning
Log viewersnabb live-analys på brandväggeningen långsiktig central arkitektur
Lokala loggfilerdetaljanalys via Advanced Shell eller supportfallberoende av brandväggens tillstånd och lagring
Central Firewall ReportingSophos Central-rapporter, enkel översikt över flera brandväggarberoende av Sophos Central, licens och lagringsram
Syslog / SIEMegen lagring, korrelation, detektion och revisionkrä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:

PunktPraktisk fråga
LagringHur länge måste loggar vara tillgängliga för drift, revision eller incidenthantering?
ÅtkomstVilka personer eller team får se råloggar, sökfrågor och dashboards?
DataskyddInnehå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?
KostnaderDebiteras loggvolym, EPS, lagring eller sökfrågor av SIEM-leverantören?
LarmVem reagerar på larm och inom vilket tidsfönster?
RaderingHur 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:

  1. Först väljs en pilot-brandvägg.
  2. Värdnamn, tidskälla, firmwareversion och loggformat dokumenteras.
  3. Syslog-målet konfigureras med säker transport.
  4. Starten sker med få loggtyper, till exempel brandvägg, händelser och VPN.
  5. Definierade testhändelser genereras och kontrolleras i målsystemet.
  6. Parser, fält, tidsstämplar, tidszon och device_name valideras.
  7. Loggvolym och brus observeras under några dagar.
  8. Därefter läggs fler loggtyper som IPS, Web, WAF, Active threat response eller System health till.
  9. 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.

  1. Öppna System services > Log settings.
  2. Välj Add.
  3. Ge ett unikt namn, till exempel siem-primary eller syslog-soc.
  4. Ange IP address/domain för Syslog-servern.
  5. Ställ in Port som passar målsystemet.
  6. Välj Facility medvetet.
  7. Ange Severity level.
  8. Välj Format.
  9. Aktivera valfritt Secure log transmission om målet stöder TLS.
  10. 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:

LoggtypVarför den är användbar
Firewalltillåtna och avvisade anslutningar, regelmatchning, DoS-händelser
IPSupptäckta eller blockerade attacker
Web / Content filteringwebbåtkomst, kategorier, webbpolicyhändelser
SSL/TLS inspectionTLS-inspektionsbeslut och fel
Web server protectionWAF-händelser för publicerade tjänster
Authentication / Eventsadmin-, användar- och systemhändelser
VPNfjärråtkomst och site-to-site VPN-händelser
Active threat responseträffar från MDR Threat Feeds, NDR Essentials, Sophos X-Ops och tredjeparts Threat Feeds
System healthCPU, 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:

  1. Öppna System services > Log settings på brandväggen.
  2. Säkerställ att Syslog-servern är synlig.
  3. Aktivera testvis Syslog för en ofarlig loggtyp.
  4. Utlös en definierad åtgärd, till exempel en loggad brandväggsregel eller ett teståtkomst.
  5. Kontrollera i målsystemet om händelsen kommer fram.
  6. Kontrollera fält som tid, värdnamn, device_name, källa, destination, regel-ID, åtgärd och loggtyp.
  7. 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.

FAQ

Hur många Syslog-servrar stöder Sophos Firewall?

SFOS stöder för närvarande upp till fem externa Syslog-servrar. I praktiken bör man ändå bara konfigurera de mål som verkligen behövs och övervakas.

Räcker UDP 514 för Sophos Firewall Syslog?

UDP 514 är den klassiska Syslog-standarden och fungerar i många interna nätverk. För produktiva SIEM- eller SOC-anslutningar bör man kontrollera om TLS med Secure log transmission är möjligt, särskilt om loggar transporteras över osäkra eller delade nätverk.

Varför ser man inga brandväggsregel-händelser i SIEM?

Ofta är Log firewall traffic inte aktiverat i den berörda brandväggsregeln eller loggtypen Firewall skickas inte till Syslog-servern. Båda måste stämma överens.

Är Syslog bättre än Central Firewall Reporting?

Det är ett annat syfte. Central Firewall Reporting är bekvämt för Sophos Central-rapporter. Syslog är starkare när egen lagring, SIEM-korrelation, SOC-processer eller leverantörsövergripande utvärdering behövs.

Vilka loggar bör man skicka till ett SIEM?

Minst brandvägg, händelser, VPN, IPS, Web, Web server protection, Active threat response och System health bör utvärderas. Det konkreta valet beror på arkitektur, dataskydd, SIEM-kostnader, användningsfall och driftmodell.

Varför saknas enskilda webb- eller brandväggshändelser trots Syslog?

Ofta skickas rätt loggtyp till Syslog, men den berörda brandväggsregeln eller inspektionsregeln genererar inte själv några loggar. Dessutom kan loggsuppression, parserfilter eller en inte aktiverad matchningstyp vid Active Threat Response minska synligheten.