Invia Sophos Firewall Syslog in modo sicuro a SIEM

Con Syslog, uno Sophos Firewall può inviare eventi a un server di registro esterno, uno SIEM o una piattaforma di sicurezza. Ciò è particolarmente importante se i registri devono essere conservati per periodi di tempo più lunghi, ricercati a livello centrale, correlati con altri sistemi o utilizzati per audit e risposta agli incidenti.

Il Visualizzatore registro locale è utile per un’analisi rapida direttamente sul firewall. Segnalazione firewall centrale è utile quando si utilizza Sophos Central come piattaforma di segnalazione. Syslog, d’altro canto, è la scelta migliore se disponi del tuo SIEM, di un SOC, di un processo di rilevamento gestito o di un’architettura di registro di più produttori.

Quale articolo di registrazione è adatto?

L’accesso a Sophos Firewall è costituito da diversi livelli. A seconda della domanda, Syslog non è sempre il modo migliore per iniziare:

• Analizza la connessione singola, Rule ID o la decisione web/IPS in tempo reale: Test delle regole Sophos Firewall con Log Viewer, tester delle policy e Packet Capture
• Assegnare file di registro e servizi locali: Risoluzione dei problemi Sophos Firewall: Services e registri
• Eseguire il backup dei registri per supporto o analisi esterna: Sophos Firewall Backup dei registri per supporto e analisi
• Tieni traccia delle modifiche alla configurazione e delle azioni di amministrazione: Sophos Firewall Controllare i registri di audit trail
• Utilizzare i report basati su Sophos Central su più firewall: Sophos Firewall Attivare e gestire il reporting centrale
• Invia registri a lungo termine a SIEM, SOC o server di registro: Questo articolo
• Analizza i flussi di traffico anziché i singoli eventi del firewall: Configura il monitoraggio del flusso su Sophos Firewall
• Controllare lo stato dell’hardware e dell’interfaccia tramite il monitoraggio: Sophos Firewall Configurazione monitoraggio hardware SNMP

Ciò mantiene la valutazione pulita: Log Viewer risponde al pacchetto attuale o al caso di policy, i log locali aiutano con una diagnostica più approfondita del modulo, il reporting centrale è utile per le valutazioni Sophos e Syslog fornisce il livello esterno a lungo termine e SIEM.

Quando Syslog ha senso

Syslog non è utile solo per ambienti di grandi dimensioni. Anche con pochi firewall, un server di registro centrale può aiutare a conservare gli eventi più a lungo e indipendentemente dall’appliance.

Casi d’uso tipici:

• Archiviazione centralizzata dei registri per settimane, mesi o anni
• Correlazione con endpoint, server, identità, proxy, cloud o registri di switch
• Casi d’uso SIEM per attacchi, scansioni di porte, accessi VPN, eventi WAF o hit di feed di minacce
• valutazione esterna da parte di SOC, MDR o team di sicurezza interni
• Tracciabilità dopo aggiornamenti firmware, failover, ripristino o sostituzione hardware
• Analisi forense quando i registri del firewall locale non sono più sufficienti

I registri locali rimangono importanti per i casi gravi di risoluzione dei problemi. Quale file di registro locale appartiene a quale modulo firewall può essere trovato in Risoluzione dei problemi Sophos Firewall: Services e registri. Se desideri eseguire il backup dei registri per supporto o analisi esterna, Sophos Firewall Backup dei registri per supporto e analisi è adatto.

Syslog, Central Reporting o log locali?

I tre percorsi rispondono a domande diverse. Nella pratica se ne usano spesso diversi in parallelo.

• Log viewer: analisi live rapida sul firewall, ma nessuna architettura centrale a lungo termine.
• File di log locali: analisi dettagliata tramite Advanced Shell o caso di supporto, ma dipendente dallo stato e dallo spazio del firewall.
• Central Firewall Reporting: report Sophos Central e panoramica semplice su più firewall, ma vincolati a Sophos Central, licenza e limiti di archiviazione.
• Syslog / SIEM: conservazione propria, correlazione, detection e audit. Servono però parser, esercizio, monitoraggio e use case chiari.

Syslog quindi non sostituisce il Log Viewer. Lo completa. Il Log Viewer mostra rapidamente quale regola o quale modulo ha deciso. Syslog fa in modo che queste informazioni restino disponibili esternamente anche in seguito.

Requisiti

Prima della configurazione è opportuno chiarire questi punti:

• Il server Syslog o SIEM è raggiungibile.
• L’IP o il FQDN di destinazione sono stabili e documentati.
• Porto e trasporti sono fissi, spesso UDP 514 o TLS sul proprio porto.
• Il firewall può instradare e raggiungere il server Syslog.
• Nel sistema di destinazione è presente un parser adatto o almeno un archivio di dati grezzi.
• NTP funziona su firewall e piattaforma di destinazione.
• Sono definiti il ​​periodo di conservazione e i requisiti di protezione dei dati.
• È chiaro quali tipi di registro siano realmente necessari.

Per le destinazioni SIEM esterne o basate su cloud, è necessario prestare particolare attenzione alla crittografia del trasporto, all’IP di origine, al routing, al DNS e alla verifica del certificato. Alcuni fornitori di SIEM o MDR si aspettano deliberatamente Syslog non crittografato a un raccoglitore o sensore locale che poi inoltra i dati. Quindi il percorso non crittografato dovrebbe essere breve, segmentato internamente e documentato.

Chiarire la protezione, l’archiviazione e la responsabilità dei dati

Syslog non è solo un reindirizzamento tecnico. I registri del firewall possono contenere indirizzi IP interni, nomi utente, sistemi di destinazione, URL, categorie, accessi VPN, eventi di amministrazione e problemi di sicurezza. Pertanto, prima della connessione produttiva, dovrebbe essere chiaro chi è autorizzato a vedere questi dati e per quanto tempo verranno conservati.

Chiarire prima del lancio:

• Stoccaggio: Per quanto tempo devono rimanere disponibili i registri operativi, di audit o di risposta agli incidenti?
• Accesso: Quali persone o team possono visualizzare log non elaborati, query di ricerca e dashboard?
• Protezione dei dati: I registri contengono informazioni personali, ID utente, indirizzi IP di origine o URL?
• Funzionalità multi-cliente: Le sedi, i clienti, gli inquilini o i cluster HA sono chiaramente separati nello SIEM?
• Costo: I volumi di registro, gli EPS, l’archiviazione o le query di ricerca vengono fatturati dal fornitore SIEM?
• Avviso: Chi risponde agli allarmi e in quale arco di tempo?
• Cancellazione: Come vengono rimossi i vecchi registri una volta scaduto il periodo di conservazione?

Questa responsabilità non dovrebbe essere lasciata aperta, soprattutto con i modelli MSP, SOC o MDR. Uno SIEM senza un proprietario chiaro produce dati, ma nessuna risposta affidabile.

Pianifica l’implementazione in più fasi

Per i firewall produttivi, un piccolo progetto pilota è meglio dell’invio immediato di tutti i tipi di registro a tutte le destinazioni. Ciò consente di controllare i parser, i nomi dei campi, il rumore e i costi prima che lo SIEM venga progettato come fonte affidabile.

Un processo sensato:1. Innanzitutto viene selezionato un firewall pilota. 2. Il nome host, l’origine dell’ora, la versione del firmware e il formato del registro sono documentati. 3. La destinazione Syslog è configurata con trasporto sicuro. 4. Inizia con alcuni tipi di registro, ad esempio firewall, eventi e VPN. 5. Gli eventi di test definiti vengono generati e controllati nel sistema di destinazione. 6. Parser, campi, timestamp, fuso orario e device_name vengono convalidati. 7. Il volume e il rumore del registro vengono osservati per alcuni giorni. 8. Vengono quindi aggiunti ulteriori tipi di registro come IPS, Web, WAF, risposta attiva alle minacce o integrità del sistema. 9. Solo dopo il successo del progetto pilota verrà implementato su altri firewall.

Se disponi di più firewall, non dovresti semplicemente controllare se i dati arrivano. Ciò che è importante è se ciascun evento è assegnato alla posizione, al dispositivo, al nodo HA, al cliente o al locatario corretti.

Il pilota dovrebbe contenere almeno un evento operativo normale, un evento di sicurezza e un evento di errore. Per il resto i trasporti sembrano sani, ma i successivi settori importanti mancano solo in caso di emergenza.

Aggiungi il server Syslog

La configurazione avviene nell’interfaccia web Sophos Firewall.

1. Apri System services > Log settings.
2. Seleziona Aggiungi.
3. Assegnare un nome univoco, ad esempio siem-primary o syslog-soc.
4. Immettere indirizzo IP/dominio del server Syslog.
5. Impostare Porta in modo che corrisponda al sistema di destinazione.
6. Scegli consapevolmente Struttura.
7. Imposta il Livello di gravità.
8. Seleziona Formato.
9. Facoltativamente abilitare Secure log transmission se la destinazione supporta TLS.
10. Salva.

Sophos Firewall può configurare più server Syslog esterni. La documentazione attuale prevede fino a cinque server Syslog. Tuttavia, non dovresti collegare ogni obiettivo a caso, ma piuttosto determinare lo scopo dietro ogni obiettivo.

Se disponi di più destinazioni, dovresti separare consapevolmente la selezione del registro per ciascuna destinazione. Un server di log locale potrebbe aver bisogno di tutti i log firewall e VPN, mentre un raccoglitore MDR si aspetta solo tipi di log rilevanti per la sicurezza. Se tutti gli obiettivi ricevono ciecamente gli stessi dati, i costi, il rischio per la privacy e il rumore del parser aumentano.

Impostazioni importanti

Struttura

La funzione aiuta il server Syslog a distinguere le origini o le categorie di registro. In ambienti semplici, spesso è sufficiente un valore predefinito. In ambienti più grandi può avere senso separare firewall o gruppi di posizioni utilizzando valori diversi da LOCAL0 a LOCAL7.

È importante sottolineare che le regole, i parser e la documentazione SIEM utilizzano la stessa logica. Se ciascun firewall utilizza una struttura diversa, la valutazione diventa inutilmente difficile.

Livello di gravità

La gravità determina la gravità con cui vengono inviati i log. Per motivi di sicurezza e risoluzione dei problemi, una soglia troppo alta è pericolosa perché potrebbero essere persi informazioni importanti o eventi di avviso. Tuttavia, per ambienti molto rumorosi, una soglia troppo bassa può generare una quantità inutile di rumore.

Di solito ha senso avere un progetto pilota con una selezione più ampia di registri, quindi una riduzione consapevole basata su risultati reali e casi d’uso di SIEM.

La soglia va intesa come gravità minima. Per esempio, se viene selezionato Error, il firewall invia anche messaggi più critici come Critical, Alert ed Emergency, ma non normali eventi informativi. Per molti casi d’uso SIEM, gli eventi Information e Notice sono importanti, altrimenti possono mancare login VPN, eventi di regole o stati di sistema.

formato

Secondo la documentazione attuale, Sophos Firewall offre due formati:

• Protocollo syslog standard
• Formato standard del dispositivo (legacy)

Per le nuove integrazioni, dovresti prima verificare quale formato si aspetta il sistema di destinazione o il parser esistente. Se un SIEM dispone già di un parser firewall Sophos, le sue aspettative hanno la precedenza. Una modifica del formato dopo il go-live può compromettere dashboard, query di ricerca e regole di rilevamento.

Secure log transmission

Quando Secure log transmission è attivo, i registri vengono inviati crittografati al server Syslog. A tale scopo il sistema di destinazione deve accettare TLS sulla porta configurata, fornire un certificato server adeguato e utilizzare una catena di certificati di cui il firewall si fida. Prima di andare in diretta, non dovresti solo controllare il firewall, ma anche controllare il nome del certificato, la catena di fiducia, la porta, il parser e il processo di rinnovo del target Syslog.

L’UDP può tecnicamente essere sufficiente per i laboratori interni. Tuttavia, Syslog non crittografato su reti non sicure non è una buona base per connessioni SIEM o SOC produttive perché i dati di registro possono contenere indirizzi IP interni, utenti, destinazioni, URL o eventi di sicurezza.

Con TLS, il nome della destinazione Syslog è importante. Senza modalità di conformità LINCE attiva, Sophos Firewall verifica il Common Name del certificato rispetto al dominio del server Syslog; in questo caso standard il Subject Alternative Name non viene usato come sostituto. Con LINCE attivo può corrispondere il Common Name oppure il Subject Alternative Name. Se nel firewall viene inserito un indirizzo IP ma il certificato contiene solo un nome DNS, oppure se un certificato corrisponde solo tramite SAN, la connessione può fallire a seconda della modalità. Per destinazioni TLS Syslog produttive servono un FQDN stabile, un certificato server adatto e un processo di rinnovo documentato.

Allo stesso tempo, il sistema target deve comprendere realmente la procedura scelta. Alcune integrazioni SIEM richiedono un raccoglitore locale e non supportano direttamente il firewall Secure log transmission. Quindi la soluzione migliore è spesso: il firewall invia internamente al raccoglitore, il raccoglitore crittografa ulteriormente sul cloud o sulla piattaforma SOC. Questa architettura dovrebbe essere inclusa nel documento operativo, altrimenti in seguito si presumerà erroneamente che tutte le sezioni del percorso siano crittografate.

Seleziona i tipi di registro

Dopo aver aggiunto il server Syslog, il lavoro non è finito. È necessario specificare in System services > Log settings quali tipi di registro vengono inviati a questa destinazione.

Importante: una regola firewall crea log di traffico significativi solo se nella regola è attivato Log firewall traffic. Per SSL/TLS Inspection deve essere attivo anche Log connections nella regola di ispezione corretta. La selezione dei log in Log settings determina poi se questi log vengono inviati localmente, a Sophos Central o ai server Syslog.

Tipi di registro tipici per uno SIEM:

• Firewall: connessioni consentite e rifiutate, corrispondenza delle regole, eventi DoS
• IPS: Attacchi rilevati o bloccati
• Filtraggio Web/Contenuto: Traffico Web, Categorie, Eventi di policy Web
• Ispezione SSL/TLS: Decisioni ed errori di ispezione TLS
• Protezione del server Web: Eventi WAF per servizi pubblicati
• Autenticazione/Eventi: Eventi di amministrazione, utente e sistema
• VPN: Eventi di accesso remoto ed eventi da sito a sito VPN
• Risposta attiva alle minacce: Risultati dai feed delle minacce MDR, NDR Essentials, Sophos X-Ops e feed delle minacce di terze parti
• Salute del sistema: CPU, memoria, utenti, interfacce e partizioni

Se si devono valutare DoS o eventi di spoofing, è necessario testare anche l’hardening tecnico stesso. Il processo è in Sophos Firewall Controlla le impostazioni Spoof Protection e DoS.

Se vengono utilizzati Feed di minacce di terze parti, NDR e Active Threat Response o WAF, SIEM dovrebbe valutare in modo specifico questi eventi. Il semplice invio dei log non è sufficiente. Richiede query di ricerca, allarmi, responsabilità chiare e messa a punto contro i falsi allarmi.

Verificare consapevolmente i campi del parser

Gli eventi Syslog Sophos contengono campi diversi a seconda del tipo di log. Per parser e dashboard sono particolarmente rilevanti log_id, log_type, log_component, log_subtype, severity, status, device_name, device_model, device_serial_id, fw_rule_id, fw_rule_name, nat_rule_id, src_ip, dst_ip, user_name e timestamp.

log_id non è un numero casuale. L’ID è composto da tipo di log, componente, sottotipo, severity e Message ID. Questo aiuta quando uno SIEM deve creare regole di detection, dashboard o normalizzazioni stabili invece di cercare solo testo libero.

Per l’accettazione non basta quindi verificare che arrivino dati raw. Il punto decisivo è se i campi arrivano davvero come campi separati nello SIEM. Se fw_rule_id o nat_rule_id restano solo nel testo raw, ricerche e allarmi successivi spesso funzionano peggio del previsto.

Un evento firewall anonimizzato in formato raw può ad esempio apparire così:

date=2026-07-01 time=14:23:11 log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" status="Allow" device_name="SFOS-XGS" device_serial_id="C00000000000000" 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" dst_port="443" user_name="AVANET\\test.user"

L’esempio non sostituisce la reference ufficiale dei campi. Mostra però quali informazioni dovrebbero essere visibili come campi separati durante il test del parser.

Set iniziale tipico per il pilota SIEM

Per un pilota, un piccolo set iniziale deliberato è migliore dell’attivazione completa senza valutazione.

• Inizio: Firewall, Eventi, VPN. Controlla il rumore di fondo, gli eventi delle regole, l’amministratore e la visibilità VPN
• Sicurezza: IPS, Web, Protezione server Web, Risposta attiva alle minacce. Convalidare i casi d’uso della sicurezza e i campi del parser
• Operazione: Integrità del sistema, DHCP, DNS, Autenticazione. Aggiungere contesto operativo e identitario
• Messa a punto: moduli aggiuntivi secondo necessità. attivare solo se esiste uno scopo di ricerca, allarme o audit

Dopo ogni fase è opportuno verificare se lo SIEM riconosce correttamente i campi e se qualcuno sta effettivamente utilizzando i nuovi eventi. I tipi di registro non controllati non rappresentano un valore aggiunto, ma solo un volume aggiuntivo.

Importanti trappole per la visibilità

Nei progetti Syslog molte lacune non si verificano nel trasporto, ma prima: il firewall non genera affatto l’evento previsto, il tipo di registro non viene inviato al server Syslog o lo SIEM interpreta i campi in modo errato.

Registrazione di regole e moduli

Le regole del firewall e le regole di ispezione SSL/TLS devono generare autonomamente la registrazione. In System services > Log settings puoi scegliere se questi registri vengono inviati localmente, in Sophos Central o al server Syslog. Se una regola firewall non dispone di Registra traffico firewall, il server Syslog non può visualizzare una cronologia completa del traffico firewall.

Per gli eventi dei criteri Web, è rilevante anche se la regola firewall associata genera la registrazione del traffico. In caso contrario, potresti visualizzare meno eventi di filtraggio web o contenuto nello SIEM del previsto.

Soppressione del registro

Sophos Firewall può sopprimere diverse voci di registro consecutive identiche. Ciò consente di risparmiare memoria ed elaborazione, ma può creare confusione nei casi d’uso di SIEM quando è necessario valutare i valori di conteggio, la frequenza o il comportamento del burst. La funzione è attiva sui server Log Viewer, Sophos Central e Syslog esterni.

Prima di un’implementazione produttiva dello SIEM, è quindi necessario determinare:

• Quali eventi del firewall possono essere soppressi?
• Di quali regole di rilevamento ha bisogno ogni singola connessione?
• Lo SIEM funziona con valori conteggiati o solo con eventi singoli?
• Come viene documentato che la soppressione dei log è attiva?

Active Threat Response

I registri di risposta attiva alle minacce sono particolarmente utili quando si utilizzano feed sulle minacce, NDR Essentials o feed esterni. Sophos distingue tra diversi tipi di corrispondenza, ad esempio hit di destinazione per il traffico in uscita e hit di origine per il traffico in entrata.

Importante: la corrispondenza della sorgente remota per il traffico in entrata non viene attivata automaticamente. Se il traffico WAF o DNAT deve essere monitorato rispetto ai feed di minacce, questa visibilità deve essere controllata consapevolmente. Altrimenti, i risultati in arrivo che un SOC spesso si aspetta andranno perduti.

Registri wireless

I registri wireless non sono automaticamente visibili nello Log Viewer locale. I registri del punto di accesso e dell’SSID devono essere inviati specificamente a Sophos Central o Syslog ed esaminati separatamente nel sistema di destinazione se gli eventi wireless sono rilevanti per operazioni, supporto o conformità.

Ambienti multi-firewall

Negli ambienti con più firewall, ogni evento deve essere assegnato in modo univoco a un’appliance. A questo scopo sono rilevanti il ​​nome host, il numero di serie, il modello e altri campi. A seconda del tipo di registro, campi come device_name, device_model e device_serial_id possono essere visualizzati negli eventi Syslog. Lo SIEM non dovrebbe solo memorizzare questi campi, ma anche renderli utilizzabili per filtri, dashboard e allarmi.

Consigli pratici:

• Imposta il nome host del firewall in modo pulito.
• Considera la posizione o il ruolo nel nome host.
• Definire una struttura uniforme o una strategia di etichettatura.
• Nello SIEM verificare se gli eventi possono essere filtrati tramite firewall, posizione e cluster.
• Distinguere chiaramente tra cluster HA e firewall autonomi.

Questa assegnazione è particolarmente importante dopo una sostituzione o un ripristino dell’hardware. Altrimenti, gli eventi nello SIEM sembrano sistemi nuovi o duplicati.

Per i cluster HA, dovrebbe essere testato anche il modo in cui appaiono gli eventi dopo un failover. Ciò che conta è se le operazioni e il SOC continuano a riconoscere la stessa posizione o se nello SIEM appare improvvisamente un nome host, un numero di serie o una nuova risorsa diversi.

Prova la configurazione

Dopo il salvataggio, la connessione dovrebbe essere testata deliberatamente. Un sistema di destinazione verde da solo non dimostra che arrivino i registri giusti con i campi giusti.

Punti di prova:

1. Apri System services > Log settings sul firewall.
2. Assicurarsi che il server Syslog sia visibile.
3. Per un tipo di registro sicuro, attivare Syslog come prova.
4. Attivare un’azione definita, ad esempio una regola firewall registrata o testare l’accesso.
5. Controllare nel sistema di destinazione se l’evento arriva.
6. Controlla campi come ora, nome host, device_name, origine, destinazione, Rule ID, azione e tipo di registro.
7. Controllare l’indicazione dell’ora e del fuso orario nello SIEM.
8. Per eventi firewall, verificare se fw_rule_id, fw_rule_name, nat_rule_id, src_ip, dst_ip, status e log_occurrence sono ricercabili separatamente.

Per testare le regole, è utile Verifica regola firewall con Log Viewer, Policy Test e Packet Capture. Se non si verifica alcun evento, la causa spesso non è il trasporto Syslog, bensì il logging normalmente disattivato o il tipo di log sbagliato.

Eventi di test significativi

Un buon test di accettazione crea non un registro qualsiasi, ma esattamente gli eventi che verranno cercati in seguito.

• La regola di test registrata consente una connessione: Sorgente, Destinazione, Servizio, Azione, Rule ID e Firewall chiaramente visibili
• Riscontri della regola di rilascio definiti: L’evento Drop viene visualizzato con la direzione e l’ora corrette
• L’utente VPN si connette e si disconnette: Vengono rilevati utente, tipo di tunnel, ora e firewall
• Criteri Web o evento di test IPS: Il tipo di registro, la categoria o la firma sono stati risolti correttamente dal parser
• ATR o test del feed delle minacce, se disponibile: Il colpo appare nel caso d’uso previsto e non genera un falso allarme
• HA failover o test di ripristino se pianificato: Gli eventi rimangono assegnati in modo tracciabile alla posizione, al cluster e all’appliance

Per le regole SIEM produttive, dovresti anche documentare un risultato negativo del test: cosa succede se un evento previsto non si verifica? Solo allora sarà evidente se un parser, un raccoglitore o un tipo di registro ha fallito silenziosamente.

Operazioni e monitoraggio

Una connessione Syslog non è una cattura una tantum. Il funzionamento deve essere monitorato e controllato regolarmente.

Almeno questi punti dovrebbero essere documentati:

• Chi è il proprietario della piattaforma di log?
• Quali firewall inviano i log?
• Quali tipi di log vengono inviati?
• Quale periodo di conservazione si applica?
• Quali parser, dashboard e allarmi sono collegati?
• Come si riconosce che i log non arrivano più?
• Come vengono controllate le modifiche al formato dopo gli aggiornamenti del firmware?
• Come vengono monitorate le scadenze dei certificati, gli aggiornamenti del raccoglitore e le modifiche del parser?
• Chi valuta i falsi positivi e regola le regole SIEM?

Dopo gli aggiornamenti del firmware, dovrebbero essere effettuati controlli casuali per verificare se gli eventi importanti vengono ancora analizzati correttamente. Ciò è particolarmente vero per le regole SIEM produttive che si basano su nomi di campi, tipi di registro o formati specifici.

Rilevare un’interruzione silenziosa dei log

Per l’operatività dovrebbe esistere un indicatore di guasto semplice:

• Per firewall: definire un numero minimo atteso di eventi per periodo, ad esempio eventi Firewall o System.
• Per tipo di log importante: verificare se Firewall, VPN, Web, IPS o Active threat response generano ancora eventi regolarmente.
• Per parser: monitorare se campi centrali come device_name, Source, Destination, Action e Rule ID continuano a essere compilati.
• Per collector: rilevare se un collector locale non accetta più dati o non li inoltra più.
• Dopo modifiche: utilizzare aggiornamento firmware, aggiornamento parser, cambio certificato, restore firewall e failover HA come occasione per un nuovo test di accettazione.

Una buona gestione SIEM quindi non avvisa solo sugli eventi sospetti, ma anche sugli eventi mancanti. Se un firewall produttivo smette improvvisamente di inviare log, questo è a sua volta un evento operativo.

Risoluzione dei problemi

Nessun registro arriva nello SIEM

Per prima cosa controlla l’indirizzo IP, la porta, il routing e le regole del firewall tra il server Sophos Firewall e Syslog. Quindi verificare se è attivato il tipo di registro corretto per il server Syslog in System services > Log settings.

Se il server Syslog è accessibile tramite un tunnel VPN o una rete di gestione separata, controllare anche il percorso, la policy SD-WAN, il NAT di origine e il contatore firewall. Dal punto di vista Sophos Firewall, Syslog è il normale traffico in uscita; deve effettivamente raggiungere il collezionista.

Mancano solo alcuni eventi

Quindi il modulo o la registrazione delle regole spesso non sono attivi. Per le regole firewall, è necessario impostare Registra traffico firewall. Per gli eventi Web o SSL/TLS, è necessario generare anche la registrazione della policy o delle regole di ispezione appropriata.

I log arrivano ma vengono analizzati in modo errato

Controlla il formato, la versione del parser e la versione del firmware. Se si passa dal protocollo syslog standard al formato standard del dispositivo (legacy), il parser SIEM deve corrispondere.

TLS-Syslog non si connette

Controllare FQDN, certificato, Common Name, Subject Alternative Name, modalità LINCE, catena di certificati e porta. Nella maggior parte degli ambienti senza LINCE, il Common Name deve corrispondere al dominio configurato; un nome che corrisponde solo nel SAN non basta. Se il firewall prevede un nome DNS, ma il server Syslog è stato inserito solo tramite indirizzo IP, anche il controllo del certificato può fallire. Controllare inoltre se il sistema di destinazione accetta realmente TLS sulla porta configurata.

Se un provider SIEM non supporta direttamente Secure log transmission, non si dovrebbe provare a salvare il parser con formati casuali. È meglio avere un raccoglitore locale supportato, una diversa progettazione dei trasporti o una decisione chiara su quale percorso interno rimanga non crittografato.

I timestamp non sono corretti

Controlla NTP sul firewall, fuso orario in SIEM e logica del parser. Tempi errati rendono inaffidabile la correlazione con endpoint, server o log di identità.

Troppi tronchi o troppo rumore

Non disattivare tutto immediatamente. Innanzitutto controlla quali tipi di log sono realmente necessari, quali regole registrano inutilmente e se la soppressione dei log ha senso. Quindi ridurre in modo specifico.

Lista di controllo

• Il server Syslog o SIEM è raggiungibile.
• Il trasporto, la porta e la crittografia sono fissi.
• Per TLS: vengono controllati FQDN, certificato, catena di fiducia e rinnovo.
• Il formato corrisponde al parser SIEM.
• La strategia della struttura è documentata.
• I tipi di registro pertinenti sono attivati ​​in System services > Log settings.
• Le regole firewall importanti hanno la funzione Registra traffico firewall attiva.
• Le regole di ispezione SSL/TLS generano i propri log, se necessario.
• La soppressione dei log viene valutata e documentata consapevolmente.
• I tipi di corrispondenza della risposta attiva alle minacce corrispondono ai casi d’uso SIEM.
• La protezione dei dati, l’accesso e il periodo di conservazione sono stati chiariti.
• Il firewall pilota, gli eventi di test e il parser SIEM sono stati convalidati.
• Gli eventi di test arrivano nel sistema di destinazione.
• Campi come Nome host, device_name, Origine, Destinazione, Azione e Rule ID vengono riconosciuti correttamente.
• Campi importanti del parser come log_id, log_type, log_component, fw_rule_id, nat_rule_id, src_ip, dst_ip, user_name, severity e status sono ricercabili separatamente.
• HA, lo scenario di ripristino o sostituzione dell’hardware è incluso nel modello di mappatura SIEM, se necessario.
• Il timestamp e il fuso orario sono corretti.
• Il monitoraggio rileva quando non arrivano più registri.
• La funzione parser viene controllata dopo gli aggiornamenti del firmware.

Domande frequenti