Skicka Syslog säkert från Sophos Firewall till SIEM

Med Syslog skickar en Sophos Firewall händelser till en extern loggserver, ett SIEM eller ett SOC. För att anslutningen verkligen ska vara användbar måste fyra delar passa ihop: transport, loggval, format och parser. Därför börjar den här artikeln direkt med konfigurationen och visar sedan hur man upptäcker loggar som saknas eller tolkas fel.

Den lokala Log viewer är fortsatt viktig för liveanalys. Central Firewall Reporting passar för rapporter i Sophos Fusion (tidigare Sophos Central); Syslog är rätt val för egen lagring, korrelation mellan olika tillverkare och detektion i SIEM.

Konfigurera Syslog-servern

Först måste mål-IP eller FQDN, port, förväntat loggformat och en lämplig parser vara fastställda. Brandväggen behöver en rutt till collectorn och båda systemen en fungerande tidskälla. SFOS använder normalt UDP 514 för Syslog. Formuläret har inget separat transportval: Secure log transmission aktiverar eller inaktiverar TLS-krypterad överföring. I Sophos officiella TLS-exempel för syslog-ng används port 6514; porten och lyssnaren måste alltid stämma överens med den egna collectorn.

Öppna System services > Log settings.
Välj Add.
Ange ett entydigt namn, till exempel siem-primary.
Ange collectorn under IP address/domain.
Välj Port, Facility, Severity level och Format så att de passar målsystemet.
Aktivera Secure log transmission för en förberedd TLS-collector.
Spara.
Aktivera önskade loggtyper under Log settings i kolumnen för den här Syslog-servern.

SFOS stöder upp till fem externa Syslog-servrar. Flera mål är lämpliga när de har olika uppgifter, till exempel ett lokalt arkiv och en MDR-collector. Att skicka alla loggar till varje mål utan urskiljning ökar däremot volym, kostnader och dataskyddsrisker.

Facility, Severity och Format

Facility: Alternativen omfattar DAEMON, KERNEL, USER och LOCAL0 till LOCAL7. Exempelvis kan LOCAL1 och LOCAL2 skilja två brandväggar åt. Tilldelningen måste vara konsekvent i collectorn och driftdokumentationen.
Severity level: Valet anger den lägsta allvarlighetsgraden. Error skickar även Critical, Alert och Emergency, men inga Information- eller Notice-händelser. Debug omfattar alla nivåer. En för hög lägstanivå kan dölja inloggningar och normala drifthändelser.
Format: Alternativen är Standard syslog protocol och Device standard format (legacy). Avgörande är vilket format SIEM-parsern förväntar sig. Ett senare byte kan bryta sökningar, dashboards och detektionsregler.

Secure log transmission

TLS är lämpligt för produktionsanslutningar över osäkra eller delade nätverk eftersom loggar kan innehålla interna adresser, användarnamn, URL:er och säkerhetshändelser. Det räcker dock inte att markera alternativet: collectorn måste ta emot TLS på den valda porten och båda sidor måste kunna verifiera certifikaten.

För den Secure Syslog-anslutning som Sophos dokumenterar gäller följande:

Collectorns servercertifikat och certifikatkedja måste vara betrodda av brandväggen.
Konfigurerat FQDN måste matcha certifikatet. Utan LINCE kontrollerar SFOS Common Name; med LINCE får Common Name eller Subject Alternative Name matcha.
Sophos-CA:n Default laddas ned under Certificates > Certificate authorities. Collectorn måste lita på den extraherade Default.pem, eftersom Sophos använder denna CA för sin sida av anslutningen.
Först därefter aktiveras Secure log transmission med den förberedda TLS-porten.

I Sophos officiella syslog-ng-exempel ligger Default.pem och den externa CA:n i collectorns CA-katalog; peer_verify(required-trusted) tvingar fram certifikatverifiering. Andra collectorprodukter har egna trust stores för detta. Ett FQDN som endast finns i SAN fungerar inte utan LINCE, och en angiven IP-adress matchar inte ett rent DNS-certifikat.

Kontrollera före aktivering för detta ändamål certifieringsgränsen, tillåtna algoritmer och SSH-omstarten för LINCE-läget. Läget är inte bara en syslogomkopplare och får inte aktiveras utan oberoende administrativ åtkomst.

Om ett molnbaserat SIEM inte stöder metoden direkt kan brandväggen skicka internt till en lokal collector som vidarebefordrar informationen krypterat. En okrypterad delsträcka bör vara kort, segmenterad och dokumenterad.

Ange loggtyper och synlighet

Målet aktiveras i två steg:

Den aktuella regeln eller funktionen måste generera händelsen. För brandväggsregler krävs Log firewall traffic, och för SSL/TLS Inspection Rules krävs Log connections.
Under System services > Log settings måste den tillhörande loggtypen väljas i Syslog-serverns kolumn.

Om ett av stegen saknas kan collectorn inte ta emot händelsen. För en pilot räcker till en början ett litet och medvetet valt urval:

Firewall och Events: regelhändelser, administratörs- och användaraktivitet samt autentiserings-, VPN-, DHCP- och DNS-händelser.
IPS, Content filtering, Web server protection och Zero-day protection: säkerhets- och policybeslut.
Active threat response: träffar från MDR, NDR Essentials, Sophos X-Ops och Third-Party Threat Feeds.
System health, Wireless, Heartbeat och SD-WAN: ytterligare driftstatus när dessa moduler används.

Fler moduler läggs till först när det finns ett syfte för sökning, larm eller revision. Den som utvärderar DoS-händelser bör även kontrollera konfigurationen för Spoof och DoS. För Third-Party Threat Feeds samt NDR och Active Threat Response krävs konkreta sökfrågor och larm utöver loggtransporten.

ATR:s omfattning: Aktivera loggning av fjärrkällor endast för kombinationer av modul och trafikväg med fastställt stöd. Sophos ATR-text och SVG-trafikmatris motsäger varandra om X-Ops-matchningsriktningar; konflikten är fortfarande olöst. Uppgifter om MDR, NDR eller tredjepartsfeeds bevisar inte motsvarande X-Ops-stöd. Behåll restriktiva brandväggs-, DNAT/WAF- och Device Access-kontroller oberoende av det omtvistade feedbeteendet. Omtvistade fall kräver auktoriserad, kontrollerad verifiering av modul, matchningsriktning, loggar och faktisk effekt samt ett tillförlitligt klargörande; tills dess får skyddet inte bero på detta beteende. NDR och Active Threat Response ger den säkra kontexten.

Vanliga synlighetsfällor

Log Suppression: SFOS kan slå samman identiska efterföljande brandväggshändelser. Detta påverkar Log Viewer, Sophos Fusion och Syslog. Parsers och detektion måste därför även ta hänsyn till log_occurrence.
Active Threat Response: Remote Source Match för inkommande DNAT- eller WAF-trafik är inte aktiverat som standard. Utan detta val saknas motsvarande källträffar för moduler och trafikvägar som stöds. Följ ATR:s omfattning ovan även när saknade matchningstyper undersöks; att välja alternativet bevisar inte stöd för omtvistade X-Ops-riktningar.
Wireless: Loggar för accesspunkter och SSID är inte tillgängliga i den lokala Log Viewer. De måste skickas specifikt till Sophos Fusion eller Syslog och kontrolleras där.
Content filtering och SSL/TLS: Den valda loggtypen ersätter inte loggning i den tillhörande brandväggs- eller Inspection Rule.
Webbproxy: För webbtrafik på port 80 eller 443 kan Firewall-loggen visa Allowed samtidigt som Web Filter blockerar samma begäran. Korrelera Firewall- och Web Filter-händelserna för att fastställa vilket policybeslut som faktiskt tillämpades.

Kontrollera format och parser

Ett parsertest får inte bara visa att någon text kommer fram. De centrala värdena måste kunna sökas som separata fält. Följande förkortade och anonymiserade exempel motsvarar Standard syslog protocol för en brandväggsregelhändelse:

device_name="BRANCH-01" timestamp="2026-08-03T09:15:21+0200" device_model="XGS136" device_serial_id="C00000000000000" log_id="010101600001" log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" log_version=1 severity="Information" 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" protocol="TCP" src_port=53144 dst_port=443 con_event="Stop" log_occurrence="1"

Legacy-formatet använder däremot bland annat device, date, time, timezone, device_id och priority. Fält som status, user_name, nat_rule_id eller log_occurrence beror dessutom på loggtyp och händelse. De får inte behandlas som obligatoriska för varje händelse i standardformatet. Konfigurera parsern med endast kärnfälten nedan vid det första godkännandet; gör ytterligare loggtypsspecifika fält obligatoriska först när en verklig testhändelse har bekräftat dem.

Följande är särskilt viktigt vid godkännandet, beroende på use case:

Identitet: device_name, device_model, device_serial_id
Klassificering: log_id, log_type, log_component, log_subtype, severity
Policy: fw_rule_id, fw_rule_name, nat_rule_id
Anslutning: src_ip, dst_ip, portar, protokoll och användare
Tid och frekvens: timestamp, tidszon och log_occurrence

log_id innehåller loggtyp, komponent, undertyp, Severity och Message ID. Det gör detektionsregler stabilare än rena fritextsökningar. Vilka fält en viss modul levererar måste ändå kontrolleras mot en verklig händelse av den aktuella loggtypen.

De tolv tecknen har fasta positioner: tecken 1 och 2 utgör Log Type ID, 3 och 4 Component ID, 5 och 6 Subtype ID, tecken 7 Priority ID och tecken 8 till 12 Message ID. 010101600001 läses alltså som 01 / 01 / 01 / 6 / 00001. En parser måste bevara inledande nollor och fasta fältbredder; kontrollera dessutom log_type, log_component, log_subtype och severity.

Syslog-modulen Events är inte samma sak som configuration-audit.log. Före- och eftervärden finns där endast för nyckelobjekt som stöds, till exempel brandväggsregler, Interfaces och IP-hosts, inte för varje konfigurationsändring. Omfattning och utvärdering behandlas i artikeln om Audit Trail-loggar.

Flera brandväggar och HA

I en miljö med flera appliances måste varje händelse entydigt kunna knytas till brandvägg, plats, kund och HA-kluster. Hostname, serienummer, modell och Facility bör därför dokumenteras och kunna filtreras i SIEM. Från och med SFOS 22.0 identifierar device_name värdnamnet på den brandvägg som skapade loggen. Kontrollera efter en uppgradering att parsern behandlar det fältet i stället för att fortsätta använda enbart device_serial_id eller Syslog-huvudet som tillgångsnyckel.

Efter HA-failover, restore eller hårdvarubyte ska man kontrollera om händelser fortfarande tilldelas den befintliga tillgången eller visas som ett nytt eller dubblerat system. Detsamma gäller efter ändring av Hostname eller Syslog-format.

Testa anslutningen med verkliga händelser

En grön collector bevisar varken rätt loggval eller en fungerande parser. För godkännandet:

Dokumentera en pilotbrandvägg och utgångsläget: servernamn, mål, port, TLS, Facility, Severity, Format och alla loggtyper som är aktiverade i serverns kolumn.
Skicka först Firewall och Events till målet.
Utlös en loggad testregel med definierade Source, Destination och Service.
Kontrollera enhet, tid, loggtyp, åtgärd, Rule ID, Source och Destination i SIEM.
Generera ett definierat Drop samt en VPN-inloggning och utloggning.
Testa minst en säkerhetshändelse från IPS, Content filtering eller Active threat response om modulen används i produktion.
Aktivera därefter fler loggtyper stegvis och observera volymen och parserresultatet.

Vid regeltestning hjälper instruktionen för Log Viewer, Policy Test och Packet Capture. Ett negativt test är också viktigt: en förväntad anslutning blockeras avsiktligt och måste visas som Drop med rätt regel.

För HA- eller migreringsprojekt hör ett test av failover, restore eller hårdvarubyte till godkännandet. SOC måste därefter fortfarande kunna identifiera vilken enhet och plats som skapade händelsen.

Återställ en ändring utan datalucka

Ändra inte format, lägsta allvarlighetsgrad och loggval samtidigt. Om någon av de fem serverplatserna är ledig lägger du till ett andra mål för en parser- eller collectormigrering och kör först båda parallellt. Då kan rådata, ifyllda fält, tidsstämplar och volym jämföras utan att det fungerande målet påverkas.

Inaktivera loggtyperna i det gamla målets kolumn först efter godkännandet. Behåll serverposten under en överenskommen observationsperiod. Om händelser saknas, parsningen misslyckas eller volymen är oväntad aktiverar du exakt de tidigare dokumenterade loggtyperna där igen och återställer valet för det nya målet. Om ingen serverplats är ledig dokumenterar du de aktuella värdena före varje enskild ändring och återställer dem helt om ändringen misslyckas; ta inte bort posten och ändra inte parsern samtidigt.

Drift, lagring och avbrott

En Syslog-anslutning behöver en ägare, definierad lagringstid och en reaktion på larm. Det måste också vara fastställt vem som bedömer falsklarm och anpassar detektionsregler. Brandväggsloggar kan innehålla personuppgifter, interna adresser, användarnamn, URL:er och VPN-aktivitet. Åtkomsträttigheter, raderingsfrister, tenantseparering och SIEM-kostnader bör därför klargöras före en bred utrullning.

Driften måste inte bara upptäcka attacker utan även data som saknas:

övervaka en förväntad minsta aktivitet per brandvägg;
kontrollera aktualiteten separat för viktiga loggtyper som Firewall, Events, IPS eller Active threat response;
övervaka centrala parserfält för tomma eller plötsligt ändrade värden;
larma om certifikatens utgång och collectorns status;
generera nya testhändelser efter uppdateringar av firmware, parser och certifikat.

Själva övervakningen måste också testas: om en förväntad loggtyp eller en brandvägg avsiktligt slutar skicka data måste det definierade bortfallslarmet utlösas.

Rådata utan parsade fält är också ett avbrott. En parseruppdatering kan lämna transporten intakt medan dashboards och detektionsregler inte längre hittar några träffar.

Syslog ersätter varken lokala serviceloggar eller ett felsökningsarkiv för support. För NetFlow v5-poster från brandväggsregler med riktad loggning passar NetFlow, och för gränssnittsprover och trafikmönster sFlow. Hårdvaru- och interfacestatus kan dessutom övervakas med SNMP.

Avgränsa fel systematiskt

Inga loggar kommer fram: Kontrollera mål, port, transport, routing och motstående brandvägg. Kontrollera sedan om önskad loggtyp är aktiverad i Syslog-kolumnen. Om collectorn finns bakom VPN eller i ett managementnät måste även rutt, SD-WAN Policy och Source NAT beaktas.

Endast vissa händelser saknas: Kontrollera först loggningen i den berörda brandväggs- eller Inspection Rule och därefter loggtypen under Log settings. För ATR måste dessutom den matchningstyp som krävs kontrolleras.

Fastställ först om modulen och trafikvägen stöds. Följ ATR:s omfattning ovan: saknade loggar löser inte X-Ops-konflikten, och omtvistade riktningar är inte ett skäl att bara aktivera fler matchningstyper.

Råloggar kommer fram men fält saknas: Jämför inställt format, parser-version och firmware-version. Standard- och legacy-fält får inte förväntas i samma parserprofil.

TLS ansluter inte: Kontrollera TLS-port och servertjänst, därefter certifikatkedja, FQDN, Common Name, SAN och LINCE-läge. Collectorn måste dessutom lita på Sophos-CA:n Default.pem. Vid certifikatbyten ska båda trust stores och förnyelseprocessen kontrolleras.

Tidsstämplarna är fel: Kontrollera NTP på brandvägg och collector, SIEM-systemets tidszon samt parsernormalisering. Felaktiga tider förhindrar tillförlitlig korrelation med endpoint-, server- och identitetsloggar.

För många loggar eller för mycket brus: Inaktivera inte allt generellt. Utvärdera först oanvända loggtyper, onödigt högljudda regler, SIEM-use cases och log_occurrence; minska därefter urvalet specifikt.