Vai al contenuto
Avanet

Inviare Syslog da Sophos Firewall a un SIEM in sicurezza

Sophos Firewall

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 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 trasporto, 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. UDP 514 è comune; con TLS si utilizza spesso TCP 6514, ma fa fede la configurazione del Collector.

  1. Aprire System services > Log settings.
  2. Selezionare Add.
  3. Assegnare un nome univoco, ad esempio siem-primary.
  4. Inserire il Collector in IP address/domain.
  5. Selezionare Port, Facility, Severity level e Format in base al sistema di destinazione.
  6. Attivare Secure log transmission se il Collector TLS è stato preparato.
  7. Salvare.
  8. 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: I valori da LOCAL0 a LOCAL7 possono distinguere firewall o gruppi di sedi. L’assegnazione deve essere identica nel Collector e nella documentazione.
  • Severity level: La selezione indica la severità minima. Error invia anche Critical, Alert ed Emergency, ma non gli eventi Information o Notice. Possono quindi mancare accessi ed eventi operativi normali.
  • 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:

  1. Il certificato server del Collector e la relativa catena di certificati devono essere considerati attendibili dal firewall.
  2. 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.
  3. 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.
  4. 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.

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:

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

Problemi comuni di visibilità

  • Log Suppression: SFOS può raggruppare eventi firewall identici e consecutivi. Questo influisce su Log Viewer, Sophos Central 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.
  • Wireless: I log degli Access Point e degli SSID non sono disponibili nel Log Viewer locale. Devono essere inviati in modo mirato a Sophos Central 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.

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

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.

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:

  1. Documentare un firewall pilota e il formato configurato.
  2. Inviare inizialmente Firewall ed Events alla destinazione.
  3. Generare traffico che attivi una regola di test con logging e Source, Destination e Service definiti.
  4. Verificare nel SIEM dispositivo, ora, tipo di log, azione, Rule ID, Source e Destination.
  5. Generare un drop definito e stabilire e chiudere una connessione VPN.
  6. Testare almeno un evento di sicurezza di IPS, Content filtering o Active threat response, se il modulo viene utilizzato in produzione.
  7. 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.

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.

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.