Inviare Syslog di Sophos Firewall a un SIEM

Con Syslog, un Sophos Firewall può inviare eventi a un server di log esterno, un SIEM o una piattaforma di sicurezza. Questo è particolarmente importante quando i log devono essere conservati più a lungo, cercati centralmente, correlati con altri sistemi o utilizzati per audit e risposta agli incidenti.

Il Log viewer locale è utile per un’analisi rapida direttamente sul firewall. Central Firewall Reporting è pratico quando Sophos Central viene utilizzato come piattaforma di reporting. Syslog è invece la scelta migliore quando si dispone di un proprio SIEM, un SOC, un processo di rilevamento gestito o un’architettura di log multi-vendor.

Quale articolo sul logging è adatto?

Il logging su Sophos Firewall è composto da diversi livelli. A seconda della domanda, Syslog non è sempre il miglior punto di partenza:

In questo modo, l’analisi rimane pulita: il Log Viewer risponde al caso attuale di pacchetto o policy, i log locali aiutano nella diagnosi più approfondita dei moduli, il Central Reporting è comodo per le analisi di Sophos, e Syslog fornisce il livello esterno a lungo termine e per il SIEM.

Quando è utile Syslog

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

Casi d’uso tipici:

• conservazione centralizzata dei log per settimane, mesi o anni
• correlazione con log di endpoint, server, identità, proxy, cloud o switch
• casi d’uso SIEM per attacchi, scansioni di porte, accessi VPN, eventi WAF o rilevamenti di feed di minacce
• analisi esterna da parte di SOC, MDR o team di sicurezza interni
• tracciabilità dopo aggiornamenti firmware, failover, ripristino o sostituzione hardware
• forense, quando i log locali del firewall non sono più sufficienti

Per i casi di risoluzione dei problemi acuti, i log locali rimangono comunque importanti. Quale file di log locale appartiene a quale modulo del firewall è indicato in Risoluzione dei problemi di Sophos Firewall: Servizi e Log. Se i log devono essere salvati per supporto o analisi esterna, è adatto Salvare i log di Sophos Firewall per supporto e analisi.

Syslog, Central Reporting o log locali?

I tre metodi rispondono a domande diverse. Nella pratica, spesso se ne utilizzano diversi in parallelo.

Syslog non sostituisce quindi il Log Viewer. Lo integra. Il Log Viewer mostra rapidamente quale regola o modulo ha deciso. Syslog assicura che queste informazioni siano disponibili anche esternamente in seguito.

Prerequisiti

Prima della configurazione, dovrebbero essere chiariti questi punti:

• Il server Syslog o SIEM è raggiungibile.
• L’IP di destinazione o FQDN è stabile e documentato.
• Porta e trasporto sono definiti, spesso UDP 514 o TLS su una porta dedicata.
• Il firewall può instradare e raggiungere il server Syslog.
• Nel sistema di destinazione esiste un parser adatto o almeno un archivio di dati grezzi.
• La durata di conservazione e i requisiti di protezione dei dati sono definiti.
• È chiaro quali tipi di log sono realmente necessari.

Per obiettivi SIEM esterni o basati su cloud, è importante prestare particolare attenzione alla crittografia del trasporto, all’IP di origine, al routing, al DNS e alla verifica dei certificati.

Chiarire protezione dei dati, conservazione e responsabilità

Syslog non è solo un inoltro tecnico. I log del firewall possono contenere indirizzi IP interni, nomi utente, sistemi di destinazione, URL, categorie, accessi VPN, eventi amministrativi e rilevamenti di sicurezza. Pertanto, prima del collegamento produttivo, dovrebbe essere chiaro chi può vedere questi dati e per quanto tempo devono essere conservati.

Prima del rollout, chiarire:

Soprattutto nei modelli MSP, SOC o MDR, questa responsabilità non dovrebbe rimanere aperta. Un SIEM senza proprietari chiari genera dati, ma non una reazione affidabile.

Pianificare il rollout in fasi

Per i firewall produttivi, un piccolo pilota è meglio che inviare subito tutti i tipi di log a tutte le destinazioni. In questo modo è possibile controllare parser, nomi dei campi, rumore e costi prima che il SIEM venga pianificato come fonte affidabile.

Un flusso di lavoro sensato:

1. Viene selezionato un firewall pilota.
2. Nome host, fonte temporale, versione firmware e formato dei log vengono documentati.
3. La destinazione Syslog viene configurata con trasporto sicuro.
4. Si inizia con pochi tipi di log, ad esempio firewall, eventi e VPN.
5. Vengono generati eventi di test definiti e verificati nel sistema di destinazione.
6. Parser, campi, timestamp, fuso orario e device_name vengono convalidati.
7. Il volume dei log e il rumore vengono osservati per alcuni giorni.
8. Successivamente, vengono aggiunti altri tipi di log come IPS, Web, WAF, risposta attiva alle minacce o salute del sistema.
9. Solo dopo un pilota di successo si procede al rollout su altri firewall.

In presenza di più firewall, non si dovrebbe solo verificare se i dati arrivano. È importante verificare se ogni evento è assegnato correttamente alla posizione, al dispositivo, al nodo HA, al cliente o al tenant giusto.

Aggiungere un server Syslog

La configurazione avviene nell’interfaccia web di Sophos Firewall.

1. Aprire System services > Log settings.
2. Selezionare Add.
3. Assegnare un nome univoco, ad esempio siem-primary o syslog-soc.
4. Inserire l’IP address/domain del server Syslog.
5. Impostare la Port in base al sistema di destinazione.
6. Scegliere consapevolmente la Facility.
7. Definire il Severity level.
8. Selezionare il Format.
9. Facoltativamente, attivare Secure log transmission se la destinazione supporta TLS.
10. Salvare.

Sophos Firewall può configurare più server Syslog esterni. Nella documentazione attuale sono previsti fino a cinque server Syslog. Tuttavia, non si dovrebbe collegare indiscriminatamente ogni destinazione, ma stabilire per ciascuna quale scopo ha.

Impostazioni importanti

Facility

La Facility aiuta il server Syslog a distinguere le fonti o le categorie di log. In ambienti semplici, spesso è sufficiente un valore standard. In ambienti più grandi, può essere utile separare firewall o gruppi di sedi utilizzando diversi valori LOCAL0 a LOCAL7.

È importante che le regole SIEM, i parser e la documentazione utilizzino la stessa logica. Se ogni firewall utilizza casualmente una Facility diversa, l’analisi diventa inutilmente difficile.

Severity level

La Severity stabilisce a partire da quale gravità i log vengono inviati. Per scopi di sicurezza e risoluzione dei problemi, una soglia troppo alta è pericolosa, poiché potrebbero mancare eventi di informazione o avviso importanti. Per ambienti molto rumorosi, una soglia troppo bassa può invece generare troppo rumore inutile.

Di solito è utile un pilota con una selezione di log più ampia, seguito da una riduzione consapevole basata su rilevamenti reali e casi d’uso SIEM.

Format

Sophos Firewall offre, secondo la documentazione attuale, due formati:

• Standard syslog protocol
• Device standard format (legacy)

Per nuove integrazioni, dovrebbe essere verificato prima quale formato si aspetta il sistema di destinazione o il parser esistente. Se un SIEM ha già un parser per Sophos Firewall, la sua aspettativa è determinante. Un cambio di formato dopo l’avvio produttivo può interrompere dashboard, query di ricerca e regole di rilevamento.

Secure log transmission

Se Secure log transmission è attivo, i log vengono inviati crittografati al server Syslog. Per questo, 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 del go-live, non dovrebbe essere solo impostato il flag nel firewall, ma anche verificati il nome del certificato, la catena di fiducia, la porta, il parser e il processo di rinnovo della destinazione Syslog.

Per laboratori interni, tecnicamente può bastare UDP. Per collegamenti SIEM o SOC produttivi, tuttavia, Syslog non crittografato su reti non sicure non è una buona base, poiché i dati di log possono contenere indirizzi IP interni, utenti, destinazioni, URL o eventi di sicurezza.

Con TLS, il nome della destinazione Syslog è importante. Sophos verifica, a seconda della modalità, il Common Name o il Subject Alternative Name del certificato rispetto al dominio del server Syslog. Se nel firewall viene inserito un indirizzo IP, ma il certificato contiene solo un nome DNS, la connessione può fallire. Pertanto, per destinazioni TLS-Syslog produttive, si dovrebbe pianificare un FQDN stabile, un certificato server adeguato e un rinnovo del certificato documentato.

Selezionare i tipi di log

Dopo aver aggiunto il server Syslog, il lavoro non è ancora finito. È necessario stabilire sotto System services > Log settings quali tipi di log inviare a questa destinazione.

Importante: una regola del firewall genera log di traffico significativi solo se nella regola è attivato Log firewall traffic. Anche per l’ispezione SSL/TLS, il logging deve essere attivo nella regola di ispezione appropriata. La selezione dei log sotto Log settings determina quindi dove vengono inviati questi log.

Tipi di log tipici per un SIEM:

Se si desidera analizzare eventi DoS o di spoofing, anche l’indurimento tecnico stesso dovrebbe essere verificato. Il flusso di lavoro è descritto in Verificare la protezione contro lo spoofing e le impostazioni DoS di Sophos Firewall.

Se si utilizzano Third-Party Threat Feeds, NDR e Active Threat Response o WAF, il SIEM dovrebbe analizzare questi eventi in modo mirato. Inviare solo i log non basta. Sono necessarie query di ricerca chiare, allarmi, responsabilità e tuning contro i falsi allarmi.

Trappole di visibilità importanti

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

Logging di regole e moduli

Le regole del firewall e le regole di ispezione SSL/TLS devono generare logging. Sotto System services > Log settings si sceglie quindi se questi log vengono inviati localmente, a Sophos Central o ai server Syslog. Se una regola del firewall non ha Log firewall traffic, il server Syslog non può mostrare un resoconto completo del traffico del firewall.

Per gli eventi di policy web, è anche rilevante se la regola del firewall associata genera logging del traffico. Altrimenti, nel SIEM si potrebbero vedere meno eventi di filtraggio web o contenuti di quanto ci si aspetti.

Log Suppression

Sophos Firewall può sopprimere più voci di log identiche consecutive. Questo risparmia memoria e elaborazione, ma può confondere nei casi d’uso SIEM se si desidera analizzare valori di conteggio, frequenza o comportamento di burst. La funzione influisce su Log Viewer, Sophos Central e server Syslog esterni.

Prima di un rollout SIEM produttivo, si dovrebbe quindi stabilire:

• Quali eventi del firewall possono essere soppressi?
• Quali regole di rilevamento necessitano di ogni singola connessione?
• Si lavora nel SIEM con valori di conteggio o solo con eventi singoli?
• Come viene documentato che la soppressione dei log è attiva?

Active Threat Response

I log di Active Threat Response sono particolarmente utili quando si utilizzano Threat Feeds, NDR Essentials o feed esterni. Sophos distingue tra diversi tipi di corrispondenza, ad esempio corrispondenza di destinazione per il traffico in uscita e corrispondenza di origine per il traffico in entrata.

Importante: la corrispondenza della sorgente remota per il traffico in entrata non è attiva automaticamente. Se si desidera monitorare il traffico WAF o DNAT contro i feed di minacce, questa visibilità deve essere verificata consapevolmente. Altrimenti, mancano proprio i rilevamenti in entrata che un SOC spesso si aspetta.

Log wireless

I log wireless non sono automaticamente visibili nel Log Viewer locale. I log di access point e SSID dovrebbero essere inviati in modo mirato a Sophos Central o Syslog e verificati separatamente nel sistema di destinazione, se gli eventi wireless sono rilevanti per operazioni, supporto o conformità.

Ambienti multi-firewall

In ambienti con più firewall, ogni evento deve poter essere assegnato in modo univoco a un’appliance. Per questo sono rilevanti nome host, numero di serie, modello e altri campi. La guida Syslog di SFOS descrive, tra l’altro, campi come device_name, device_model e device_serial_id.

Raccomandazioni pratiche:

• Impostare correttamente il nome host del firewall.
• Considerare la posizione o il ruolo nel nome host.
• Definire una strategia uniforme per Facility o tagging.
• Verificare nel SIEM se gli eventi possono essere filtrati per firewall, posizione e cluster.
• Distinguere chiaramente tra cluster HA e firewall standalone.

Soprattutto dopo una sostituzione hardware o un ripristino, questa assegnazione è importante. Altrimenti, gli eventi nel SIEM sembrano nuovi o sistemi duplicati.

Testare la configurazione

Dopo il salvataggio, il collegamento dovrebbe essere testato consapevolmente. Un sistema di destinazione verde da solo non dimostra ancora che i log corretti arrivano con i campi corretti.

Punti di test:

1. Aprire System services > Log settings sul firewall.
2. Assicurarsi che il server Syslog sia visibile.
3. Attivare temporaneamente Syslog per un tipo di log non pericoloso.
4. Attivare un’azione definita, ad esempio una regola del firewall registrata o un accesso di prova.
5. Verificare nel sistema di destinazione se l’evento arriva.
6. Verificare campi come tempo, nome host, device_name, origine, destinazione, ID regola, azione e tipo di log.
7. Controllare timestamp e fuso orario nel SIEM.

Per i test delle regole, è utile Testare le regole del firewall con Log Viewer, Policy Test e Packet Capture. Se non si generano eventi, spesso la causa non è nel trasporto Syslog, ma nel logging disattivato nella regola o nel tipo di log errato.

Operatività e monitoraggio

Un collegamento Syslog non è un’operazione una tantum. L’operatività deve essere monitorata e verificata regolarmente.

Almeno questi punti dovrebbero essere documentati:

• Chi è il proprietario della piattaforma di log?
• Quali firewall inviano log?
• Quali tipi di log vengono inviati?
• Qual è la durata di conservazione?
• Quali parser, dashboard e allarmi sono collegati?
• Come si riconosce che non arrivano più log?
• Come vengono verificate le modifiche di formato dopo gli aggiornamenti firmware?
• Chi valuta i falsi allarmi e adatta le regole SIEM?

Dopo gli aggiornamenti firmware, dovrebbe essere verificato a campione se gli eventi importanti vengono ancora interpretati correttamente. Questo è particolarmente vero per le regole SIEM produttive che dipendono da nomi di campi, tipi di log o formati specifici.

Risoluzione dei problemi

Nessun log arriva nel SIEM

Verificare prima l’indirizzo IP, la porta, il routing e le regole del firewall tra Sophos Firewall e il server Syslog. Quindi controllare se sotto System services > Log settings è attivato il tipo di log corretto per il server Syslog.

Mancano solo determinati eventi

Spesso il logging del modulo o della regola non è attivo. Per le regole del firewall, deve essere impostato Log firewall traffic. Per gli eventi Web o SSL/TLS, la policy o la regola di ispezione appropriata deve inoltre generare logging.

I log arrivano, ma vengono interpretati male

Verificare formato, versione del parser e versione firmware. Se si è passati tra Standard syslog protocol e Device standard format (legacy), il parser SIEM deve corrispondere.

Syslog TLS non si connette

Verificare FQDN, certificato, Common Name, Subject Alternative Name, catena di certificati e porta. Se il firewall si aspetta un nome DNS, ma il server Syslog è inserito solo tramite indirizzo IP, la verifica del certificato può fallire. Inoltre, controllare se il sistema di destinazione accetta davvero TLS sulla porta configurata.

I timestamp non sono corretti

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

Troppi log o troppo rumore

Non disattivare tutto immediatamente. Verificare prima quali tipi di log sono realmente necessari, quali regole generano troppi log e se la soppressione dei log è utile. Quindi ridurre in modo mirato.

Checklist

• Il server Syslog o SIEM è raggiungibile.
• Trasporto, porta e crittografia sono definiti.
• Il formato corrisponde al parser SIEM.
• La strategia Facility è documentata.
• I tipi di log rilevanti sono attivati sotto System services > Log settings.
• Le regole del firewall importanti hanno Log firewall traffic attivo.
• Le regole di ispezione SSL/TLS generano log propri se necessario.
• La soppressione dei log è valutata e documentata consapevolmente.
• I tipi di corrispondenza di Active Threat Response corrispondono ai casi d’uso SIEM.
• Protezione dei dati, accesso e durata di conservazione sono chiariti.
• Firewall pilota, eventi di test e parser SIEM sono stati convalidati.
• Gli eventi di test arrivano nel sistema di destinazione.
• Campi come nome host, device_name, origine, destinazione, azione e ID regola vengono riconosciuti correttamente.
• Timestamp e fuso orario sono corretti.
• Il monitoraggio rileva quando non arrivano più log.
• Dopo gli aggiornamenti firmware, viene verificata la funzione del parser.

FAQ