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.

Facilities anger en loggs ursprung: DAEMON betyder processer som körs som tjänster, KERNEL kärnprocesser och USER processer startade av inloggade användare. LOCAL0 till LOCAL7 används för egna tilldelningar. För allvarlighetsgrad är Alert allvarligare än Critical och kräver omedelbara åtgärder. Standard syslog protocol hette tidigare Central Reporting Format; Central Reporting använder endast detta format. I Device standard format (legacy) varierar antalet datafält mellan modulerna.

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.

Förbered en TLS-collector med syslog-ng

Exemplet kräver en Linux-collector med syslog-ng, aktiverat TLS-stöd och ett servercertifikat utfärdat av en extern CA. Brandväggen är den sändande klienten. ExternalCertificate.pem är servercertifikatet, ExternalPrivateKey.key dess privata nyckel och ExternalCA.pem den utfärdande CA:n. Filnamnen är exempel; anpassa sökvägar och certifikat till den egna collectorn. Skydda den privata nyckeln på collectorn; brandväggens CA-privatnyckel behövs inte.

Kontrollera den befintliga CA:n under Certificates > Certificate authorities > Default. Namnet kan inte ändras. Country name, State och Locality name beskriver land, region och ort; Organization name och Organization unit name ägare och avdelning. Common name innehåller ett namn eller FQDN och Email address en kontakt. Private key password låter dig ändra ett befintligt CA-lösenord. Key type erbjuder RSA eller Elliptic curve: välj Key length för RSA eller Curve name för Elliptic curve; Secure hash anger hashalgoritmen. Key length är RSA-nyckelns längd i bitar; större nycklar ger mer säkerhetsmarginal men kräver mer beräkningsarbete. Exempel på CA-identitet är Example AG, IT Security och fw01.example.com; ersätt dem med den egna miljöns ägare, avdelning och godkända namnkonvention. Dessa CA-attribut är inte collectorns servercertifikat och ersätter inte dess matchande FQDN.

Skydda den befintliga CA:n: Ändra eller regenerera inte Default-CA:n enbart för Syslog. Planera nödvändiga CA-ändringar med säkerhetskopia, underhållsfönster och kontroll av beroende tjänster; förnya Default-CA:n förklarar konsekvenserna. Att uppdatera inställningarna med Save regenererar Default-CA:n automatiskt och ändrar förtroendeankaret. Spara endast godkända ändringar inom det planerade underhållsfönstret. Hämta därefter tar.gz-arkivet med nedladdningsknappen och extrahera det offentliga CA-certifikatet Default.pem.

Placera Default.pem och ExternalCA.pem i /etc/syslog-ng/ca.d/ på collectorn, och ExternalCertificate.pem samt ExternalPrivateKey.key i /etc/syslog-ng/cert.d/. Kontrollera först kataloger och befintliga filer; skriv inte över certifikat utan planering. Endast ansvarig tjänst och behöriga administratörer ska kunna läsa den privata nyckeln.

Kör följande kommandon på Linux-collectorn, inte i SFOS Device Console. Det första läser certifikatet. Det andra skapar en symbolisk länk i CA-katalogen och kräver skrivrättigheter där:

cd /etc/syslog-ng/ca.d/
openssl x509 -noout -hash -in Default.pem

Använd den hash som faktiskt returneras, inte blint 52412b66. För exempelresultatet 52412b66 är kommandot:

ln -s Default.pem 52412b66.0

Om en .0-post redan finns ska dess mål kontrolleras i stället för att skrivas över. Kontrollera hash och koppling igen efter ett certifikatbyte.

Detta syslog-ng.conf-exempel visar en TLS-lyssnare och två lokala utdatafiler. @version: 3.15 är det dokumenterade exemplets versionsdeklaration, inte en rekommendation att installera en föråldrad version. Kontrollera syntax, moduler och deklaration mot den installerade syslog-ng-versionen före användning. Integrera exemplet i befintlig konfiguration utan att ersätta andra källor och destinationer.

@version: 3.15
@include "scl.conf"
source s_src {
    network(ip(0.0.0.0) port(6514)
        transport("tls")
        tls( key-file("/etc/syslog-ng/cert.d/ExternalPrivateKey.key")
             cert-file("/etc/syslog-ng/cert.d/ExternalCertificate.pem")
             ca-dir("/etc/syslog-ng/ca.d")
             peer_verify(required-trusted))
    ); };
destination d_local {
    file("/var/log/messages");
    file("/var/log/messages-kv.log" template("$ISODATE $HOST $(format-welf --scope all-nv-pairs)\n") frac-digits(3));
};
log { source(s_src);
    destination(d_local);
};

0.0.0.0 binder alla collectorns IPv4-adresser. Använd helst den avsedda mottagaradressen i produktion och begränsa TCP 6514 till de sändande brandväggarna med värdens brandvägg. Port 6514 måste matcha SFOS-posten. key-file och cert-file anger serveridentiteten, och ca-dir de två CA-certifikaten; inaktivera inte peer_verify(required-trusted) för att kringgå fel. Fildestinationerna ger råloggar och ytterligare nyckel-värde-utdata med millisekundprecision; anpassa sökvägar, rättigheter, rotation och lagringskapacitet till driften.

Kontrollera konfigurationen med den installerade versionens valideringsfunktion före start. Starta tjänsten eller tillämpa ändringar kontrollerat inom ett godkänt fönster; återgå till säkerhetskopierad konfiguration vid problem. Ange därefter collectorn, port 6514 och Secure log transmission under System services > Log settings > Add i SFOS och klicka på Save. Välj nödvändiga moduler i serverns kolumn. Framgång innebär en TLS-anslutning utan förtroendefel, en avsiktligt skapad brandväggshändelse i utdatafilerna och korrekt parsade SIEM-fält.

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.

XML-API: Håll collector, loggval och suppression åtskilda

Den som hanterar Syslog via XML-API måste behandla dessa tre nivåer separat. Exemplen för Add/Update i SFOS 22.0 och SFOS 23.0 skiljer mellan:

Collectorinställningar: Måladress, port, TLS, Facility, Severity och format bestämmer mottagare och överföring. En skapad eller vald collector aktiverar inte automatiskt alla loggar.
Sändning per grupp och submodul: Inom LogSettings avser SendLogs gruppnivån; enskilda submoduler kan åsidosätta detta val. Exemplet varnar uttryckligen för att ange SendLogs när alla submoduler är listade. Dessa former får därför inte slås ihop till en generell aktivering. För PolicyRules anger kommentaren i exemplet Disable som standardvärde; det innebär inte att sändning av alla regelhändelser automatiskt tillåts. Loggning i den aktuella regeln krävs dessutom fortfarande.
Suppression: Log_suppress anges i exemplet separat från sändningen. Att slå samman upprepade händelser är inte samma sak som att välja deras mottagare eller ett Severity-filter.

Parametertabellen listar Name två gånger och beskriver den andra raden som suppressionsstatus; dessutom anges bokstavligen uiui som standardvärde. Detta är inte ett tillförlitligt underlag för ett standardvärde i drift eller för att underförstått byta namn på fältet. Härled ingen fullständig suppressionspayload från detta; klargör först otydliga API-fält med hjälp av hjälpen för den aktuella builden eller Sophos Support. Generera samma representativa händelser före och efter en godkänd ändring och jämför råloggar på collectorn, parserfält i SIEM samt förväntade loggtyper och log_occurrence. En befintlig anslutning är i sig inget bevis för rätt loggval.

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. Följande lista är en användningsfallsberoende checklista, inte ett universellt obligatoriskt schema. Definiera obligatoriska fält separat för varje aktiverad loggtyp utifrån schemat för rätt version och en representativ verklig händelse. Regel- och NAT-fält gäller endast för motsvarande bekräftade händelsetyper; utvärdera anslutnings- och användarfält samt log_occurrence endast när de levereras. Saknade fält som inte gäller händelsetypen får inte leda till att giltiga händelser slängs eller klassificeras som parserfel.

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.

I det dokumenterade exemplet 010101600001 betyder första 01 Security policy, andra 01 Firewall rule, tredje 01 Allowed, 6 Information och 00001 Firewall traffic allowed. ID:n med fasta positioner och utmatade textfält har olika uppgifter; härled inte textfälten från ett numeriskt ID utan verifiering. Andra Message IDs kräver en Syslog-referenskatalog som passar den använda SFOS-versionen; uppdelningen ovan förklarar inte alla händelsetyper.

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.

Radering via API är inte detsamma som att inaktivera loggkolumnen: Delete-tabellerna för SFOS 22.0 och SFOS 23.0 anger endast Name som icke-obligatoriskt, men beskriver det som suppressionsstatus och visar ingen målselektor. Denna motsägelsefulla tabell belägger varken ett säkert målval när namnet utelämnas eller att radering av en collector är likvärdig med att inaktivera dess loggtyper. Behåll den fungerande collectorn under migreringen. Före radering via API måste den entydiga, godkända identiteten för posten som ska tas bort och raderingssyntaxen vara klargjorda utifrån API-hjälpen för den aktuella builden eller med Sophos Support; gissa inte någon selektor.

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.