Inviare Syslog da Sophos Firewall a un SIEM in sicurezza

Con Syslog, Sophos Firewall invia gli eventi a un server di log esterno, un SIEM o un SOC. Affinché l’integrazione sia realmente utile, quattro elementi devono essere coerenti: trasporto, selezione dei log, formato e parser. Questo articolo inizia quindi direttamente dalla configurazione e mostra poi come individuare log mancanti o interpretati in modo errato.

Il Log viewer locale rimane importante per l’analisi in tempo reale. Central Firewall Reporting è adatto ai report di Sophos Fusion (in precedenza Sophos Central); Syslog è la scelta corretta per una conservazione autonoma, la correlazione tra prodotti di diversi fornitori e il rilevamento tramite SIEM.

Configurare il server Syslog

Occorre prima definire l’IP di destinazione o il FQDN, la porta, il formato di log previsto e un parser adeguato. Il firewall deve disporre di una route verso il Collector ed entrambi i sistemi devono avere una sorgente oraria funzionante. SFOS utilizza normalmente UDP 514 per Syslog. La schermata non offre una selezione separata del trasporto: Secure log transmission attiva o disattiva la trasmissione cifrata TLS. Nell’esempio TLS ufficiale di Sophos per syslog-ng viene utilizzata la porta 6514; porta e listener devono sempre corrispondere al proprio Collector.

Aprire System services > Log settings.
Selezionare Add.
Assegnare un nome univoco, ad esempio siem-primary.
Inserire il Collector in IP address/domain.
Selezionare Port, Facility, Severity level e Format in base al sistema di destinazione.
Attivare Secure log transmission se il Collector TLS è stato preparato.
Salvare.
In Log settings, attivare i tipi di log desiderati nella colonna di questo server Syslog.

SFOS supporta fino a cinque server Syslog esterni. Più destinazioni hanno senso se svolgono compiti diversi, ad esempio un archivio locale e un Collector MDR. Inviare indiscriminatamente tutti i log a ogni destinazione aumenta invece volume, costi e rischi per la privacy.

Facility, severità e formato

Facility: Le opzioni includono DAEMON, KERNEL, USER e da LOCAL0 a LOCAL7. Ad esempio, si possono assegnare LOCAL1 e LOCAL2 a due firewall. L’assegnazione deve rimanere coerente nel Collector e nella documentazione operativa.
Severity level: La selezione indica la severità minima. Error invia anche Critical, Alert ed Emergency, ma non gli eventi Information o Notice. Debug include tutti i livelli. Una soglia troppo alta può quindi nascondere accessi ed eventi operativi ordinari.
Format: Sono disponibili Standard syslog protocol e Device standard format (legacy). È determinante il formato previsto dal parser del SIEM. Una modifica successiva può interrompere ricerche, dashboard e regole di rilevamento.

Secure log transmission

TLS è consigliabile per le connessioni produttive attraverso reti non sicure o condivise, perché i log possono contenere indirizzi interni, nomi utente, URL ed eventi di sicurezza. Tuttavia, non basta attivare l’opzione: il Collector deve accettare TLS sulla porta scelta ed entrambi i lati devono poter verificare i certificati.

Per la connessione Secure Syslog documentata da Sophos si applicano queste condizioni:

Il certificato server del Collector e la relativa catena di certificati devono essere considerati attendibili dal firewall.
Il FQDN configurato deve corrispondere al certificato. Senza LINCE, SFOS verifica il Common Name; con LINCE può corrispondere il Common Name o il Subject Alternative Name.
In Certificates > Certificate authorities viene scaricata la CA Sophos Default. Il Collector deve considerare attendibile il file Default.pem estratto da questa CA, perché Sophos la utilizza per il proprio lato della connessione.
Solo a questo punto si attiva Secure log transmission con la porta TLS preparata.

Nell’esempio ufficiale di syslog-ng, Default.pem e la CA esterna si trovano nella directory delle CA del Collector; peer_verify(required-trusted) impone la verifica del certificato. Altri prodotti Collector utilizzano Trust Store propri. Un FQDN presente solo nel SAN non funziona senza LINCE e un indirizzo IP configurato non corrisponde a un certificato contenente esclusivamente un nome DNS.

Prima di attivare LINCE a questo scopo, verificare il limite di certificazione, gli algoritmi consentiti e il riavvio SSH della modalità LINCE. La modalità non è un semplice interruttore syslog e non deve essere attivata senza un accesso amministrativo indipendente.

Se un SIEM cloud non supporta direttamente questa procedura, il firewall può inviare internamente i log a un Collector locale, che li inoltra in forma cifrata. Un tratto non cifrato deve essere breve, segmentato e documentato.

Definire i tipi di log e la visibilità

La destinazione viene attivata in due fasi:

La regola o la funzione corrispondente deve generare l’evento. Le regole firewall richiedono Log firewall traffic, mentre le regole di SSL/TLS Inspection richiedono Log connections.
In System services > Log settings, il tipo di log corrispondente deve essere selezionato nella colonna del server Syslog.

Se manca una delle due fasi, il Collector non può ricevere l’evento. Per un progetto pilota è sufficiente iniziare con un set ridotto e selezionato consapevolmente:

Firewall ed Events: eventi delle regole, attività di amministratori e utenti, nonché eventi di autenticazione, VPN, DHCP e DNS.
IPS, Content filtering, Web server protection e Zero-day protection: decisioni di sicurezza e delle policy.
Active threat response: corrispondenze di MDR, NDR Essentials, Sophos X-Ops e Third-Party Threat Feeds.
System health, Wireless, Heartbeat e SD-WAN: stato operativo aggiuntivo quando vengono utilizzati questi moduli.

Altri moduli vanno aggiunti solo quando esiste uno scopo di ricerca, allarme o audit. Se vengono analizzati eventi DoS, occorre verificare anche la configurazione di Spoof Protection e DoS. Per i Third-Party Threat Feeds e NDR e Active Threat Response, oltre al trasporto dei log sono necessarie ricerche e allarmi specifici.

Ambito di ATR: Abilitare la registrazione delle sorgenti remote solo per combinazioni di modulo e percorso del traffico il cui supporto è accertato. Il testo ATR di Sophos e la matrice SVG del traffico sono in contraddizione sulle direzioni di corrispondenza di X-Ops; il conflitto rimane irrisolto. Le indicazioni su MDR, NDR o feed di terze parti non dimostrano un supporto equivalente da parte di X-Ops. Mantenere controlli restrittivi di firewall, DNAT/WAF e Device Access indipendenti dal comportamento controverso del feed. I casi controversi richiedono una verifica autorizzata e controllata del modulo, della direzione di corrispondenza, dei log e dell’effetto reale, oltre a un chiarimento attendibile; nel frattempo, la protezione non deve dipendere da tale comportamento. NDR e Active Threat Response illustra il contesto sicuro.

Problemi comuni di visibilità

Log Suppression: SFOS può raggruppare eventi firewall identici e consecutivi. Questo influisce su Log Viewer, Sophos Fusion e Syslog. Il parser e il rilevamento devono quindi considerare anche log_occurrence.
Active Threat Response: Remote Source Match per il traffico DNAT o WAF in ingresso non è attivo per impostazione predefinita. Senza questa selezione mancano le relative corrispondenze della sorgente per moduli e percorsi del traffico supportati. Rispettare l’ambito di ATR descritto sopra anche quando si indaga sui tipi di corrispondenza mancanti; selezionare l’opzione non dimostra il supporto delle direzioni controverse di X-Ops.
Wireless: I log degli Access Point e degli SSID non sono disponibili nel Log Viewer locale. Devono essere inviati in modo mirato a Sophos Fusion o Syslog e verificati nella destinazione.
Content filtering e SSL/TLS: Il tipo di log selezionato non sostituisce il logging nella relativa regola firewall o di Inspection.
Web Proxy: Per il traffico web sulle porte 80 o 443, il log Firewall può indicare Allowed mentre Web Filter blocca la stessa richiesta. Per determinare la decisione effettiva della policy, occorre correlare gli eventi Firewall e Web Filter.

Verificare formato e parser

Un test del parser non deve limitarsi a dimostrare che arriva del testo. I valori principali devono essere ricercabili come campi separati. Questo esempio abbreviato e anonimizzato corrisponde allo Standard syslog protocol per un evento di una regola firewall:

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"

Il formato legacy utilizza invece, tra gli altri, device, date, time, timezone, device_id e priority. Campi come status, user_name, nat_rule_id o log_occurrence dipendono inoltre dal tipo di log e dall’evento. Non devono essere considerati obbligatori per ogni evento in formato standard. Per la prima accettazione, configurare il parser solo con i campi principali riportati di seguito; rendere obbligatori altri campi specifici del tipo di log solo dopo averli confermati con un evento di test reale.

Per l’accettazione sono particolarmente importanti, a seconda del caso d’uso:

Identità: device_name, device_model, device_serial_id
Classificazione: log_id, log_type, log_component, log_subtype, severity
Policy: fw_rule_id, fw_rule_name, nat_rule_id
Connessione: src_ip, dst_ip, porte, protocollo e utente
Ora e frequenza: timestamp, fuso orario e log_occurrence

log_id contiene tipo di log, componente, sottotipo, severità e Message ID. Le regole di rilevamento risultano quindi più stabili rispetto alle ricerche di testo libero. Occorre comunque verificare i campi forniti da ogni modulo mediante un evento reale del relativo tipo di log.

I dodici caratteri hanno posizioni fisse: i caratteri 1 e 2 formano il Log Type ID, 3 e 4 il Component ID, 5 e 6 il Subtype ID, il carattere 7 il Priority ID e i caratteri da 8 a 12 il Message ID. 010101600001 si legge quindi come 01 / 01 / 01 / 6 / 00001. Il parser deve conservare gli zeri iniziali e le larghezze fisse dei campi; come controllo aggiuntivo vanno valutati anche log_type, log_component, log_subtype e severity.

Il modulo Syslog Events non è identico a configuration-audit.log. I valori precedenti e successivi sono disponibili solo per gli oggetti chiave supportati, come regole firewall, interfacce e IP host, non per ogni modifica della configurazione. Ambito e analisi sono descritti nell’articolo sugli Audit Trail Logs.

Più firewall e HA

In un ambiente con più appliance, ogni evento deve poter essere attribuito chiaramente a firewall, sede, cliente e cluster HA. Hostname, numero di serie, modello e Facility devono quindi essere documentati e utilizzabili come filtri nel SIEM. Da SFOS 22.0, device_name identifica l’hostname del firewall che ha prodotto il log. Dopo un upgrade, verificare che il parser acquisisca questo campo invece di continuare a usare soltanto device_serial_id o l’header Syslog come chiave dell’asset.

Dopo un failover HA, un restore o una sostituzione hardware, occorre verificare se gli eventi continuano a essere assegnati all’asset esistente oppure se compaiono come un sistema nuovo o duplicato. Lo stesso vale dopo una modifica dell’hostname o del formato Syslog.

Testare l’integrazione con eventi reali

Un Collector con stato verde non dimostra né la corretta selezione dei log né il funzionamento del parser. Per l’accettazione:

Documentare un firewall pilota e lo stato iniziale: nome del server, destinazione, porta, TLS, Facility, Severity, Format e tutti i tipi di log attivi nella colonna del server.
Inviare inizialmente Firewall ed Events alla destinazione.
Generare traffico che attivi una regola di test con logging e Source, Destination e Service definiti.
Verificare nel SIEM dispositivo, ora, tipo di log, azione, Rule ID, Source e Destination.
Generare un drop definito e stabilire e chiudere una connessione VPN.
Testare almeno un evento di sicurezza di IPS, Content filtering o Active threat response, se il modulo viene utilizzato in produzione.
Attivare quindi altri tipi di log gradualmente e osservare il volume e il risultato del parser.

Per il test delle regole è utile la guida a Log Viewer, Policy Test e Packet Capture. È importante anche un test negativo: una connessione prevista viene bloccata deliberatamente e deve apparire come drop con la regola corretta.

Nei progetti HA o di migrazione, l’accettazione deve includere un test di failover, restore o sostituzione hardware. In seguito, il SOC deve continuare a riconoscere quale dispositivo e quale sede hanno generato l’evento.

Annullare una modifica senza creare interruzioni nei dati

Non modificare contemporaneamente formato, severità minima e selezione dei log. Se uno dei cinque slot server è libero, per la migrazione del parser o del Collector si aggiunge una seconda destinazione e inizialmente si mantengono entrambe in parallelo. In questo modo è possibile confrontare dati grezzi, campi valorizzati, timestamp e volume senza toccare la destinazione funzionante.

Solo dopo l’accettazione si disattivano i tipi di log nella colonna della vecchia destinazione. La relativa voce server rimane disponibile per un periodo di osservazione concordato. Se mancano eventi, il parsing non riesce o il volume è inatteso, si riattivano lì esattamente i tipi di log documentati in precedenza e si annulla la selezione sulla nuova destinazione. Se non vi sono slot liberi, registrare i valori esistenti prima di ogni singola modifica e ripristinarli integralmente in caso di errore; non eliminare la voce né cambiare contemporaneamente il parser.

Funzionamento, conservazione e guasti

Un’integrazione Syslog richiede un Owner, una durata di conservazione definita e una risposta agli allarmi. Deve inoltre essere chiaro chi valuta i falsi positivi e adatta le regole di rilevamento. I log del firewall possono contenere dati personali, indirizzi interni, nomi utente, URL e attività VPN. Diritti di accesso, termini di cancellazione, separazione dei tenant e costi del SIEM devono quindi essere chiariti prima di un rollout esteso.

Il funzionamento deve rilevare non solo gli attacchi, ma anche l’assenza di dati:

monitorare un’attività minima prevista per ogni firewall;
verificare separatamente che tipi di log importanti come Firewall, Events, IPS o Active threat response siano aggiornati;
monitorare i campi centrali del parser per individuare valori vuoti o rinominati in modo imprevisto;
generare allarmi per la scadenza dei certificati e lo stato del Collector;
generare nuovamente eventi di test dopo aggiornamenti di firmware, parser o certificati.

Anche il monitoraggio stesso deve essere testato: se un tipo di log previsto o un firewall smettono deliberatamente di inviare dati, deve scattare l’allarme di assenza definito.

Anche i dati grezzi privi di campi interpretati rappresentano un guasto. Un aggiornamento del parser può lasciare intatto il trasporto mentre dashboard e regole di rilevamento non producono più risultati.

Syslog non sostituisce i Service Logs locali né un archivio di troubleshooting per il supporto. Per i record v5 provenienti da regole firewall con logging attivo in modo mirato è adatto NetFlow, mentre per i campioni di interfaccia e i modelli di traffico è adatto sFlow. Lo stato dell’hardware e delle interfacce può essere monitorato anche tramite SNMP.

Isolare gli errori in modo mirato

Non arriva alcun log: Controllare destinazione, porta, trasporto, routing e firewall sul lato opposto. Verificare quindi se il tipo di log desiderato è attivo nella colonna Syslog. Se il Collector si trova dietro una VPN o in una rete di management, considerare anche route, SD-WAN Policy e Source NAT.

Mancano solo determinati eventi: Controllare prima il logging nella regola firewall o di Inspection interessata, quindi il tipo di log in Log settings. Per ATR verificare inoltre il Match Type necessario.

Accertare prima che il modulo e il percorso del traffico siano supportati. Rispettare l’ambito di ATR descritto sopra: l’assenza di log non risolve il conflitto X-Ops e le direzioni controverse non giustificano la semplice attivazione di altri tipi di corrispondenza.

Arrivano log grezzi, ma mancano i campi: Confrontare il formato configurato, la versione del parser e la versione del firmware. I campi standard e legacy non devono essere previsti nello stesso profilo parser.

TLS non si connette: Controllare la porta TLS e il servizio server, quindi catena di certificati, FQDN, Common Name, SAN e modalità LINCE. Il Collector deve inoltre considerare attendibile la CA Sophos Default.pem. In caso di cambio dei certificati, verificare entrambi i Trust Store e il processo di rinnovo.

I timestamp non corrispondono: Controllare NTP sul firewall e sul Collector, il fuso orario del SIEM e la normalizzazione del parser. Orari errati impediscono una correlazione affidabile con i log di Endpoint, server e identità.

Troppi log o troppo rumore: Non disattivare tutto indiscriminatamente. Valutare prima i tipi di log inutilizzati, le regole inutilmente rumorose, i casi d’uso del SIEM e log_occurrence; quindi ridurre la selezione in modo mirato.