Skicka Sophos Firewall Syslog säkert till SIEM

Med Syslog kan en Sophos Firewall skicka händelser till en extern loggserver, en SIEM eller en säkerhetsplattform. Detta är särskilt viktigt om loggar ska sparas under längre tid, sökas centralt, korreleras med andra system eller användas för revisioner och incidenthantering.

Den lokala Loggvisaren är bra för snabb analys direkt på brandväggen. Central brandväggsrapportering är praktiskt när du använder Sophos Central som en rapporteringsplattform. Syslog, å andra sidan, är det bättre valet om du har din egen SIEM, en SOC, en hanterad detektionsprocess eller en loggarkitektur för flera tillverkare.

Vilken loggningsartikel passar?

Inloggning Sophos Firewall består av flera nivåer. Beroende på frågan är Syslog inte alltid det bästa sättet att börja:

• Analysera enkel anslutning, Rule ID eller webb/IPS-beslut live: Sophos Firewall Regeltestning med Log Viewer, Policytestare och Packet Capture
• Tilldela lokala loggfiler och tjänster: Sophos Firewall Felsökning: Services och loggar
• Säkerhetskopiera loggar för support eller extern analys: Sophos Firewall Säkerhetskopiera loggar för support och analys
• Spåra konfigurationsändringar och adminåtgärder: Sophos Firewall Kontrollera revisionsspårloggar
• Använd Sophos Central-baserade rapporter över flera brandväggar: Sophos Firewall Aktivera och använda central rapportering
• Skicka loggar på lång sikt 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årdvara och gränssnittsstatus via övervakning: Sophos Firewall Konfigurera SNMP-hårdvaruövervakning

Detta håller utvärderingen ren: Log Viewer svarar på det aktuella paketet eller policyfallet, lokala loggar hjälper till med djupare moduldiagnostik, central rapportering är bekvämt för Sophos-utvärderingar och Syslog tillhandahåller det externa långsiktiga och SIEM-lagret.

När Syslog är vettigt

Syslog är inte bara värt besväret för stora miljöer. Även med ett fåtal brandväggar kan en central loggserver hjälpa till att behålla händelser längre och oberoende av apparaten.

Typiska användningsfall:

• Central stocklagring i veckor, månader eller år
• Korrelation med slutpunkt, server, identitet, proxy, moln eller switchloggar
• SIEM användningsfall för attacker, portskanningar, VPN-inloggningar, WAF-händelser eller hotflödesträffar
• extern utvärdering av SOC, MDR eller interna säkerhetsteam
• Spårbarhet efter firmwareuppdateringar, failover, återställning eller byte av hårdvara – Forensics när lokala brandväggsloggar inte längre räcker till

Lokala loggar är fortfarande viktiga för akuta felsökningsfall. Vilken lokal loggfil som hör till vilken brandväggsmodul finns i Sophos Firewall Felsökning: Services och loggar. Om du vill säkerhetskopiera loggar för support eller extern analys, passar Sophos Firewall Säkerhetskopiera loggar för support och analys.

Syslog, Central Reporting eller lokala loggar?

De tre vägarna besvarar olika frågor. I praktiken används ofta flera av dem parallellt.

• Log viewer: snabb liveanalys på brandväggen, men ingen långsiktig central arkitektur.
• Lokala loggfiler: detaljerad analys via Advanced Shell eller supportärende, men beroende av brandväggens skick och lagring.
• Central Firewall Reporting: Sophos Central-rapporter och enkel översikt över flera brandväggar, men bundet till Sophos Central, licens och lagringsramar.
• Syslog / SIEM: egen lagring, korrelation, detektion och audit. Det kräver parsers, drift, övervakning och tydliga use cases.

Syslog ersätter alltså inte Log Viewer. Det kompletterar den. Log Viewer visar snabbt vilken regel eller modul som tog beslutet. Syslog ser till att informationen finns tillgänglig externt även senare.

Krav

Före konfigurering bör dessa punkter förtydligas:

• Syslog-servern eller SIEM kan nås.
• Mål-IP eller FQDN är stabilt och dokumenterat. – Hamn och transport är fast, ofta UDP 514 eller TLS på egen hamn.
• Brandväggen kan dirigera och nå Syslog-servern.
• Det finns en lämplig parser eller åtminstone en rådatalagring i målsystemet.
• NTP fungerar på brandvägg och målplattform.
• Lagringsperiod och krav på dataskydd definieras. – Det är tydligt vilka stocktyper som verkligen behövs.

För externa eller molnbaserade SIEM-destinationer bör särskild uppmärksamhet ägnas transportkryptering, käll-IP, routing, DNS och certifikatverifiering. Vissa SIEM- eller MDR-leverantörer förväntar sig medvetet okrypterad Syslog till en lokal samlare eller sensor som sedan vidarebefordrar data. Då ska den okrypterade rutten vara kort, internt segmenterad och dokumenterad.

Förtydliga dataskydd, lagring och ansvar

Syslog är inte bara en teknisk omdirigering. Brandväggsloggar kan innehålla interna IP-adresser, användarnamn, målsystem, URL:er, kategorier, VPN-inloggningar, adminhändelser och säkerhetsträffar. Därför, innan den produktiva anslutningen, bör det vara klart vem som får se denna data och hur länge den kommer att lagras.

Förtydliga innan lansering:

• Förvaring: Hur länge måste drift-, revisions- eller incidentresponsloggar vara tillgängliga?
• Tillgång: Vilka personer eller team kan se råloggar, sökfrågor och instrumentpaneler?
• Dataskydd: Innehåller loggar personlig information, användar-ID, käll-IP-adresser eller webbadresser?
• Möjlighet för flera klienter: Är platser, kunder, hyresgäster eller HA-kluster tydligt åtskilda i SIEM?
• Kostnad: Debiteras loggvolymer, EPS, lagring eller sökfrågor av SIEM-leverantören?
• Varning: Vem svarar på larm och inom vilken tidsram?
• Ta bort: Hur tas gamla loggar bort efter att lagringsperioden har löpt ut?

Detta ansvar bör inte lämnas öppet, särskilt med MSP-, SOC- eller MDR-modeller. En SIEM utan en tydlig ägare producerar data, men inget tillförlitligt svar.

Planera utbyggnaden i etapper

För produktiva brandväggar är en liten pilot bättre än att skicka alla loggtyper till alla destinationer omedelbart. Detta gör att parsare, fältnamn, brus och kostnader kan kontrolleras innan SIEM planeras som en pålitlig källa.

En vettig process:1. Först väljs en pilotbrandvägg. 2. Värdnamn, tidskälla, firmwareversion och loggformat dokumenteras. 3. Syslog-destinationen är konfigurerad med säker transport. 4. Det börjar med några loggtyper, till exempel brandvägg, händelser och VPN. 5. Definierade testhändelser genereras och kontrolleras i målsystemet. 6. Parser, fält, tidsstämpel, tidszon och device_name valideras. 7. Loggvolym och buller observeras under några dagar. 8. Ytterligare loggtyper som IPS, Web, WAF, Aktivt hotsvar eller Systemhälsa läggs sedan till. 9. Först efter en framgångsrik pilot kommer den att rullas ut till andra brandväggar.

Om du har flera brandväggar ska du inte bara kontrollera om data kommer in. Det som är viktigt är om varje händelse är tilldelad rätt plats, enhet, HA-nod, kund eller hyresgäst.

Piloten bör innehålla minst en normal operationshändelse, en säkerhetshändelse och en felhändelse. I övrigt verkar transporten vara frisk, men de senare viktiga fälten saknas bara i en nödsituation.

Lägg till Syslog-server

Konfigurationen sker i webbgränssnittet Sophos Firewall.

1. Öppna System services > Log settings.
2. Välj Lägg till.
3. Tilldela ett unikt namn, till exempel siem-primary eller syslog-soc.
4. Ange IP-adress/domän för Syslog-servern.
5. Ställ in Port för att matcha målsystemet.
6. Välj Facilitet medvetet.
7. Ställ in Svårhetsgrad.
8. Välj Formatera.
9. Aktivera eventuellt Secure log transmission om destinationen stöder TLS.
10. Spara.

Sophos Firewall kan konfigurera flera externa Syslog-servrar. Den aktuella dokumentationen tillhandahåller upp till fem Syslog-servrar. Ändå bör du inte koppla varje mål slumpmässigt, utan snarare bestämma syftet bakom varje mål.

Om du har flera mål, bör du medvetet separera loggvalet för varje mål. En lokal loggserver kan behöva alla brandväggs- och VPN-loggar, medan en MDR-samlare bara förväntar sig säkerhetsrelevanta loggtyper. Om alla mål blint får samma data ökar kostnaderna, integritetsriskerna och parsarbruset.

Viktiga inställningar

Facilitet

Anläggningen hjälper Syslog-servern att särskilja loggkällor eller kategorier. I enkla miljöer räcker ofta ett standardvärde. I större miljöer kan det vara meningsfullt att separera brandväggar eller platsgrupper med olika LOCAL0 till LOCAL7 värden.

Viktigt är att SIEM-regler, tolkar och dokumentation använder samma logik. Om varje brandvägg råkar använda en annan anläggning blir utvärderingen onödigt svår.

Allvarlighetsgrad

Allvarlighetsgraden bestämmer hur allvarliga loggar skickas. För säkerhets- och felsökningsändamål är en för hög tröskel farlig eftersom viktig information eller meddelandehändelser kan missas. Men för mycket högljudda miljöer kan en för låg tröskel generera onödigt mycket ljud.

Det brukar vara vettigt att ha en pilot med ett bredare urval av loggar, sedan en medveten minskning baserat på verkliga träffar och SIEM användningsfall.

Tröskeln ska förstås som minsta severity. Om till exempel Error väljs skickar firewallen även mer kritiska meddelanden som Critical, Alert och Emergency, men inga normala informationshändelser. För många SIEM-use cases är just Information- och Notice-events viktiga, eftersom VPN-inloggningar, regelhändelser eller systemtillstånd annars kan saknas.

format

Enligt aktuell dokumentation erbjuder Sophos Firewall två format:

• Standard syslog-protokoll
• Enhetsstandardformat (legacy)

För nya integrationer bör du först kontrollera vilket format målsystemet eller den befintliga parsern förväntar sig. Om en SIEM redan har en Sophos brandväggsparser, har dess förväntningar företräde. En formatändring efter lanseringen kan bryta instrumentpaneler, sökfrågor och upptäcktsregler.

Secure log transmission

När Secure log transmission är aktivt skickas loggar krypterade till Syslog-servern. För att göra detta måste målsystemet acceptera TLS på den konfigurerade porten, leverera ett lämpligt servercertifikat och använda en certifikatkedja som brandväggen litar på. Innan du går live bör du inte bara kontrollera brandväggen, utan också kontrollera certifikatnamnet, förtroendekedjan, porten, analysen och förnyelseprocessen för Syslog-målet.

UDP kan tekniskt sett vara tillräckligt för interna laboratorier. Men okrypterad Syslog över osäkra nätverk är inte en bra grund för produktiva SIEM- eller SOC-anslutningar eftersom loggdata kan innehålla interna IP-adresser, användare, destinationer, URL:er eller säkerhetshändelser.

Med TLS är namnet på Syslog-destinationen viktigt. Utan aktiverat LINCE-compliance-läge kontrollerar Sophos Firewall certifikatets Common Name mot Syslog-serverns domän; i detta standardfall används Subject Alternative Name inte som ersättning. Med LINCE aktiverat kan Common Name eller Subject Alternative Name matcha. Om en IP-adress anges i firewallen men certifikatet bara innehåller ett DNS-namn, eller om ett certifikat bara matchar via SAN, kan anslutningen misslyckas beroende på läge. För produktiva TLS Syslog-mål bör ett stabilt FQDN, ett passande servercertifikat och en dokumenterad certifikatförnyelse planeras.

Samtidigt måste målsystemet verkligen förstå den valda proceduren. Vissa SIEM-integrationer kräver en lokal samlare och stöder inte direkt Secure log transmission-brandväggen. Då är den bättre lösningen ofta: Brandväggen skickar internt till samlaren, samlaren krypterar vidare till molnet eller SOC-plattformen. Denna arkitektur bör inkluderas i driftsdokumentet, annars kommer det senare felaktigt att antas att alla delar av rutten är krypterade.

Välj loggtyper

Efter att ha lagt till Syslog-servern är arbetet inte avslutat. Du måste ange under System services > Log settings vilka loggtyper som skickas till denna destination.

Viktigt: En brandväggsregel skapar bara meningsfulla trafikloggar om Log firewall traffic är aktiverat i regeln. För SSL/TLS Inspection måste även Log connections vara aktivt i den matchande inspektionsregeln. Loggvalet under Log settings avgör sedan om dessa loggar skickas lokalt, till Sophos Central eller till Syslog-servrar.

Typiska loggtyper för en SIEM:

• Brandvägg: tillåtna och avvisade anslutningar, regelmatchning, DoS-händelser
• IPS: Attacker upptäckta eller blockerade
• Webb-/innehållsfiltrering: Webbtrafik, kategorier, webbpolicyhändelser
• SSL/TLS-inspektion: TLS-inspektionsbeslut och fel
• Webbserverskydd: WAF-evenemang för publicerade tjänster
• Autentisering / Händelser: Admin-, användar- och systemhändelser
• VPN: Fjärråtkomst och Site-to-Site VPN-händelser
• Aktivt hotsvar: Träffar från MDR Hotfeeds, NDR Essentials, Sophos X-Ops och Tredjeparts Hotfeeds
• Systemhälsa: CPU, minne, användare, gränssnitt och partitioner

Om DoS eller spoof-händelser ska utvärderas bör även den tekniska härdningen i sig testas. Processen är i Sophos Firewall Kontrollera inställningar för Spoof Protection och DoS.

Om Third-Party Threat Feeds, NDR och Active Threat Response eller WAF används, bör SIEM specifikt utvärdera dessa händelser. Det räcker inte att bara skicka loggar. Det kräver tydliga sökfrågor, larm, ansvar och inställning mot falsklarm.

Kontrollera parserfält medvetet

Sophos Syslog-events innehåller olika fält beroende på loggtyp. För parsers och dashboards är särskilt log_id, log_type, log_component, log_subtype, severity, status, device_name, device_model, device_serial_id, fw_rule_id, fw_rule_name, nat_rule_id, src_ip, dst_ip, user_name och tidsstämplar relevanta.

log_id är mer än ett slumpmässigt nummer. ID:t består av loggtyp, komponent, undertyp, severity och Message ID. Det hjälper när ett SIEM inte bara ska söka fritext utan bygga stabila detection rules, dashboards eller normaliseringar.

Vid acceptans bör man därför inte bara kontrollera om raw data kommer fram. Avgörande är om fälten verkligen landar som separata fält i SIEM. Om fw_rule_id eller nat_rule_id bara finns i råtexten fungerar senare sökningar och larm ofta sämre än väntat.

Ett anonymiserat firewall-event kan i raw-format till exempel se ut så här:

date=2026-07-01 time=14:23:11 log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" status="Allow" device_name="SFOS-XGS" device_serial_id="C00000000000000" fw_rule_id="12" fw_rule_name="LAN_to_WAN_Web" nat_rule_id="4" src_ip="10.10.20.25" dst_ip="203.0.113.10" dst_port="443" user_name="AVANET\\test.user"

Exemplet ersätter inte den officiella fältreferensen. Det visar vilka uppgifter som bör vara synliga som separata fält vid parser-testet.

Typiskt startset för SIEM pilot

För en pilot är ett litet, medvetet startset bättre än full aktivering utan utvärdering.

• Starta: Brandvägg, evenemang, VPN. Kontrollera bullergolv, regelhändelser, admin och VPN synlighet
• Säkerhet: IPS, webb, webbserverskydd, aktivt hotsvar. Validera säkerhetsanvändningsfall och parserfält
• Operation: Systemhälsa, DHCP, DNS, Autentisering. Lägg till drifts- och identitetskontext
• Finjustering: ytterligare moduler efter behov. aktiveras endast om det finns ett söknings-, larm- eller revisionssyfte

Efter varje fas bör det kontrolleras om SIEM känner igen fälten korrekt och om någon faktiskt använder de nya händelserna. Omarkerade loggtyper är inget mervärde, bara extra volym.

Viktiga siktfällor

I Syslog-projekt uppstår inte många luckor i transporten, men i förväg: brandväggen genererar inte alls den förväntade händelsen, loggtypen skickas inte till Syslog-servern eller så tolkar SIEM fälten felaktigt.

Regel- och modulloggning

Brandväggsregler och SSL/TLS-inspektionsregler måste själva generera loggning. Under System services > Log settings kan du välja om dessa loggar ska skickas lokalt, i Sophos Central eller till Syslog server. Om en brandväggsregel inte har Logga brandväggstrafik, kan Syslog-servern inte visa en fullständig brandväggstrafikhistorik.

För webbpolicyhändelser är det också relevant om den associerade brandväggsregeln genererar trafikloggning. Annars kan du se färre webb- eller innehållsfiltreringshändelser i SIEM än förväntat.

Loggundertryckning

Sophos Firewall kan undertrycka flera identiska på varandra följande loggposter. Detta sparar minne och bearbetning, men kan vara förvirrande i SIEM användningsfall när räkningsvärden, frekvens eller burstbeteende måste utvärderas. Funktionen fungerar på Log Viewer, Sophos Central och externa Syslog-servrar.

Innan en produktiv SIEM lansering bör du därför fastställa:

• Vilka brandväggshändelser kan undertryckas?
• Vilka detektionsregler behöver varje enskild anslutning?
• Fungerar SIEM med räknade värden eller bara med enskilda händelser?
• Hur dokumenteras att loggundertryckning är aktiv?

Active Threat Response

Active Threat Response-loggar är särskilt användbara när du använder Threat Feeds, NDR Essentials eller externa flöden. Sophos skiljer på olika matchningstyper, till exempel målträffar för utgående trafik och källträffar för inkommande trafik.

Viktigt: Remote Source Match för inkommande trafik aktiveras inte automatiskt. Om WAF- eller DNAT-trafik ska övervakas mot hotflöden måste denna synlighet kontrolleras medvetet. Annars kommer de inkommande träffar som en SOC ofta förväntar sig att saknas.

Trådlösa loggar

Trådlösa loggar är inte automatiskt synliga i den lokala Log Viewer. Accesspunkts- och SSID-loggar ska skickas specifikt till Sophos Central eller Syslog och undersökas separat i målsystemet om trådlösa händelser är relevanta för drift, support eller efterlevnad.

Miljöer med flera brandväggar

I miljöer med flera brandväggar måste varje händelse vara unikt tilldelad en apparat. Värdnamn, serienummer, modell och andra fält är relevanta för detta. Beroende på loggtyp kan fält som device_name, device_model och device_serial_id visas i Syslog-händelser. SIEM ska inte bara lagra dessa fält, utan också göra dem användbara för filter, instrumentpaneler och larm.

Praktiska rekommendationer:

• Ställ in brandväggsvärdnamnet rent.
• Överväg plats eller roll i värdnamnet.
• Definiera en enhetlig anläggning eller märkningsstrategi.
• Kontrollera i SIEM om händelser kan filtreras efter brandvägg, plats och kluster.
• Skilj tydligt mellan HA-kluster och fristående brandväggar.

Denna uppgift är särskilt viktig efter ett byte eller återställning av hårdvara. Annars ser händelser i SIEM ut som nya eller dubbla system.

För HA-kluster bör det också testas hur händelser visas efter en failover. Det som spelar roll är om operationer och SOC fortsätter att känna igen samma plats eller om ett annat värdnamn, serienummer eller ny tillgång plötsligt dyker upp i SIEM.

Testa konfigurationen

Efter att ha sparats bör anslutningen testas medvetet. Enbart ett grönt målsystem bevisar inte att rätt stockar med rätt fält kommer fram.

Testpunkter:

1. Öppna System services > Log settings på brandväggen.
2. Se till att Syslog-servern är synlig.
3. För en säker loggtyp, aktivera Syslog som ett test.
4. Utlösa en definierad åtgärd, till exempel en loggad brandväggsregel eller teståtkomst.
5. Kontrollera i målsystemet om händelsen anländer.
6. Kontrollera fält som tid, värdnamn, device_name, källa, destination, Rule ID, åtgärd och loggtyp.
7. Kontrollera tidsstämpeln och tidszonen i SIEM.
8. För firewall-events, kontrollera om fw_rule_id, fw_rule_name, nat_rule_id, src_ip, dst_ip, status och log_occurrence är separat sökbara.

För regeltestning är Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture användbar. Om inga händelser inträffar alls är orsaken ofta inte Syslog-transporten, utan snarare inaktiverad loggning som regel eller fel loggtyp.

Meningsfulla testhändelser

Ett bra acceptanstest skapar inte vilken logg som helst, utan exakt de händelser som kommer att sökas efter senare.

• Loggad testregel tillåter en anslutning: Källa, Destination, Service, Action, Rule ID och Brandvägg tydligt synliga
• Definierade fallregelträffar: Drop-händelse visas med rätt riktning och tid
• VPN användare ansluter och kopplar från: Användare, tunneltyp, tid och brandvägg identifieras
• Webbpolicy eller IPS-testhändelse: Loggtyp, kategori eller signatur är korrekt löst av parsern
• ATR eller hot feed test om tillgängligt: Hit visas i det förväntade användningsfallet och genererar inget falskt larm
• HA failover eller återställningstest om planerat: Händelser förblir spårbart tilldelade till plats, kluster och apparat. För produktiva SIEM-regler bör du också dokumentera ett negativt testresultat: Vad händer om en förväntad händelse inte inträffar? Först då kommer det att bli uppenbart senare om en parser, samlare eller loggtyp har misslyckats tyst.

Drift och övervakning

En Syslog-anslutning är inte en engångsfångare. Driften måste övervakas och kontrolleras regelbundet.

Åtminstone dessa punkter bör dokumenteras:

– Vem är ägaren till stockplattformen?

• Vilka brandväggar skickar loggar?
• Vilka loggtyper skickas?
• Vilken lagringstid gäller?
• Vilka analyser, instrumentpaneler och larm är kopplade till den? – Hur känner du igen att stockar inte längre kommer fram?
• Hur kontrolleras formatändringar efter firmwareuppdateringar?
• Hur övervakas certifikatets utgång, samlaruppdateringar och parserändringar?
• Vem utvärderar falska positiva och justerar SIEM regler?

Efter firmwareuppdateringar bör slumpmässiga kontroller göras för att se om viktiga händelser fortfarande analyseras korrekt. Detta gäller särskilt för produktiva SIEM-regler som förlitar sig på specifika fältnamn, loggtyper eller format.

Identifiera tyst loggbortfall

För driften bör det finnas en enkel bortfallsindikator:

• Per firewall: definiera förväntat minsta antal händelser per tidsperiod, till exempel Firewall- eller System-händelser.
• Per viktig loggtyp: kontrollera om Firewall, VPN, Web, IPS eller Active threat response fortfarande regelbundet levererar händelser.
• Per parser: övervaka om centrala fält som device_name, Source, Destination, Action och Rule ID fortfarande fylls i.
• Per collector: upptäck om en lokal collector inte längre tar emot data eller inte längre vidarebefordrar dem.
• Efter ändringar: använd firmwareuppdatering, parseruppdatering, certifikatbyte, firewall-restore och HA-failover som anledning till ett nytt acceptanstest.

En bra SIEM-drift larmar alltså inte bara vid misstänkta händelser, utan också vid saknade händelser. Om en produktionsfirewall plötsligt slutar leverera loggar är det i sig en driftshändelse.

Felsökning

Inga loggar kommer in i SIEM

Kontrollera först IP-adress, port, routing och brandväggsregler mellan Sophos Firewall och Syslog server. Kontrollera sedan om rätt loggtyp är aktiverad för Syslog-servern under System services > Log settings.

Om Syslog-servern är tillgänglig via en VPN-tunnel eller ett separat hanteringsnätverk, kontrollera även rutten, SD-WAN-policyn, käll-NAT och motbrandvägg. Ur Sophos Firewall perspektiv är Syslog normal utgående trafik; den måste faktiskt nå samlaren.

Endast vissa händelser saknas

Då är modulen eller regelloggningen ofta inte aktiv. För brandväggsregler måste Loggbrandväggstrafik ställas in. För webb- eller SSL/TLS-händelser måste lämplig policy- eller inspektionsregelloggning också genereras.

Loggar anländer men analyseras felaktigt

Kontrollera format, parserversion och firmwareversion. Om du växlar mellan Standard syslog-protokoll och Enhetsstandardformat (legacy) måste SIEM-parsern matcha det.

TLS-Syslog ansluter inte

Kontrollera FQDN, certifikat, Common Name, Subject Alternative Name, LINCE-läge, certifikatkedja och port. I de flesta miljöer utan LINCE måste Common Name matcha den konfigurerade domänen; ett namn som bara matchar i SAN räcker inte. Om firewallen förväntar sig ett DNS-namn, men Syslog-servern endast angavs via IP-adress, kan certifikatkontrollen också misslyckas. Kontrollera dessutom om målsystemet verkligen accepterar TLS på den konfigurerade porten.

Om en SIEM-leverantör inte direkt stöder Secure log transmission, bör man inte försöka rädda parsern med slumpmässiga format. Det är bättre att ha en lokal samlare som stöds, en annan transportdesign eller ett tydligt beslut om vilken intern rutt som förblir okrypterad.

Tidsstämplarna är felaktiga

Kontrollera NTP på brandväggen, tidszon i SIEM och parserlogik. Felaktiga tider gör korrelation med slutpunkt, server eller identitetsloggar opålitliga.

För många stockar eller för mycket brus

Inaktivera inte allt omedelbart. Kontrollera först vilka loggtyper som verkligen behövs, vilka regler som loggar i onödan och om loggundertryckning är vettigt. Minska sedan specifikt.

Checklista

• Syslog-servern eller SIEM kan nås. – Transport, port och kryptering är fasta.
• För TLS: FQDN, certifikat, förtroendekedja och förnyelse kontrolleras.
• Formatet matchar SIEM parser. – Facilitetsstrategi är dokumenterad.
• Relevanta loggtyper aktiveras under System services > Log settings.
• Viktiga brandväggsregler har Loggbrandväggstrafik aktiv.
• SSL/TLS-inspektionsregler genererar sina egna loggar vid behov.
• Loggundertryckning utvärderas och dokumenteras medvetet.
• Matchningstyper för aktiva hotsvar matchar användningsfallen för SIEM. – Dataskydd, åtkomst och lagringstid har förtydligats.
• Pilotbrandvägg, testhändelser och SIEM-parser har validerats.
• Testhändelser anländer till målsystemet.
• Fält som värdnamn, device_name, Källa, Destination, Åtgärd och Rule ID känns igen korrekt.
• Viktiga parserfält som log_id, log_type, log_component, fw_rule_id, nat_rule_id, src_ip, dst_ip, user_name, severity och status är separat sökbara.
• HA, återställning eller ersättning av hårdvara ingår i SIEM-mappningsmodellen om det behövs.
• Tidsstämpel och tidszon är korrekta.
• Övervakning upptäcker när inga fler loggar kommer.
• Parserfunktionen kontrolleras efter firmwareuppdateringar.

Vanliga frågor