Hoppa till innehållet
Avanet

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

Sophos Firewall

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 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, transport, 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. UDP 514 är vanligt; med TLS används ofta TCP 6514, men collectorns konfiguration är avgörande.

  1. Öppna System services > Log settings.
  2. Välj Add.
  3. Ange ett entydigt namn, till exempel siem-primary.
  4. Ange collectorn under IP address/domain.
  5. Välj Port, Facility, Severity level och Format så att de passar målsystemet.
  6. Aktivera Secure log transmission för en förberedd TLS-collector.
  7. Spara.
  8. 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: LOCAL0 till LOCAL7 kan användas för att skilja brandväggar eller platsgrupper åt. Tilldelningen måste vara identisk i collectorn och dokumentationen.
  • Severity level: Valet anger den lägsta allvarlighetsgraden. Error skickar även Critical, Alert och Emergency, men inga Information- eller Notice-händelser. Framför allt kan inloggningar och normala drifthändelser då saknas.
  • 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:

  1. Collectorns servercertifikat och certifikatkedja måste vara betrodda av brandväggen.
  2. Konfigurerat FQDN måste matcha certifikatet. Utan LINCE kontrollerar SFOS Common Name; med LINCE får Common Name eller Subject Alternative Name matcha.
  3. 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.
  4. 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.

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:

  1. 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.
  2. 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.

Vanliga synlighetsfällor

  • Log Suppression: SFOS kan slå samman identiska efterföljande brandväggshändelser. Detta påverkar Log Viewer, Sophos Central 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.
  • Wireless: Loggar för accesspunkter och SSID är inte tillgängliga i den lokala Log Viewer. De måste skickas specifikt till Sophos Central 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.

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.

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.

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.

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:

  1. Dokumentera en pilotbrandvägg och det konfigurerade formatet.
  2. Skicka först Firewall och Events till målet.
  3. Utlös en loggad testregel med definierade Source, Destination och Service.
  4. Kontrollera enhet, tid, loggtyp, åtgärd, Rule ID, Source och Destination i SIEM.
  5. Generera ett definierat Drop samt en VPN-inloggning och utloggning.
  6. Testa minst en säkerhetshändelse från IPS, Content filtering eller Active threat response om modulen används i produktion.
  7. 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.

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.

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.