Usare correttamente Log Viewer su Sophos Firewall

In SFOS 22, Log Viewer è spesso il punto di partenza più rapido per un problema: quale regola firewall ha elaborato il traffico, quale regola NAT è stata coinvolta, quale utente è stato riconosciuto e quale modulo di sicurezza ha bloccato? Per ottenere la risposta corretta devono coincidere modulo, intervallo temporale, filtri e momento di creazione del log.

Log Viewer mostra eventi registrati. Non è Packet Capture e non è una cronologia completa delle connessioni. Un evento assente non dimostra quindi né un drop né che il pacchetto abbia raggiunto il firewall.

Per un’analisi affidabile si annotano sempre Source, Destination, servizio, ora esatta del test e direzione prevista. Poi si genera esattamente un nuovo flusso e lo si cerca nei moduli pertinenti.

Valutare un test in sette passaggi

1. Nella regola firewall interessata controllare Log firewall traffic oppure Log connections nella regola SSL/TLS.
2. In System services > Log settings, verificare che il tipo di log necessario sia attivo in Local reporting.
3. Aprire Log viewer (SFOS 22) o Logs and policy test (SFOS 23) in alto a destra in WebAdmin, quindi scegliere il modulo di log pertinente.
4. Impostare il filtro temporale e usare Add filter per restringere inizialmente il risultato per IP Source, IP Destination e servizio.
5. Generare un nuovo flusso breve e annotarne l’ora esatta.
6. In Detailed view, controllare Rule ID, NAT ID, azione, interfacce, utente e campi specifici del modulo.
7. Se l’evento non corrisponde al comportamento osservato, correlare lo stesso test con Packet Capture prima di modificare una regola.

Questo ordine separa tre domande spesso confuse: è stato generato un log? Quale policy ha deciso? I pacchetti sono realmente entrati e usciti?

Gli Event Logs registrano autenticazione, eventi di sistema e modifiche di configurazione oltre al traffico e vengono salvati localmente per impostazione predefinita. I Troubleshooting Logs sono invece log dettagliati dei servizi, accessibili da WebAdmin o CLI. La procedura per i log dei servizi spiega accesso e raccolta in debug. Debug occupa spazio aggiuntivo e va disattivato dopo la raccolta necessaria; non è un interruttore per recuperare Event Logs mancanti.

Per l’invio centralizzato, il firewall deve essere registrato per Sophos Central Firewall Management. Attivare poi i servizi Central e Send reports and logs to Sophos Central, quindi selezionare i tipi di log necessari in System services > Log settings. La documentazione SFOS 22 esaminata chiama la destinazione Sophos Fusion, quella SFOS 23 Sophos Central; fanno testo i campi dell’interfaccia indicati. La procedura Central Reporting copre configurazione e controllo della ricezione.

Leggere correttamente i log

Perché i log non compaiono sempre subito

Log Viewer aggiorna automaticamente la vista. Una sessione firewall viene però normalmente registrata solo quando il firewall riceve un evento Destroy e chiude la connessione. In una sessione lunga, l’evento può quindi comparire dopo la prima richiesta.

Se una connessione termina senza che il firewall riceva un evento Destroy, per esempio in caso di perdita della connettività internet, il log atteso della sessione può mancare del tutto. Le connessioni SSL/TLS vengono registrate dopo il completamento dell’handshake e alla chiusura. Per un test breve è quindi preferibile una connessione chiusa deliberatamente rispetto a una sessione permanente di browser, streaming o HTTP/2.

Un semplice refresh del browser non crea necessariamente una nuova connessione. A seconda dell’applicazione, per un test riproducibile sono adatti una finestra privata, un nuovo processo client o una breve richiesta come:

curl -I https://example.com/

Il comando si esegue sul client di test, non nella shell del firewall. example.com è un dominio di esempio riservato e può essere sostituito con un servizio noto e consentito.

Scegliere il modulo corretto

Un flusso può interessare più moduli di log. Il modulo Firewall può mostrare che una regola LAN-to-WAN consente la connessione, mentre Web filter, Application filter, IPS o SSL/TLS inspection blocca o tratta successivamente lo stesso flusso in modo diverso.

Un singolo evento verde nel modulo Firewall non è quindi sufficiente per problemi web o di sicurezza. I moduli vanno correlati per lo stesso flusso di test usando l’intervallo del test e gli indirizzi:

• Firewall: decisione della regola, NAT, interfacce, porte e stato di base della connessione.
• Web filter: decisioni su URL, categoria e Web Policy.
• SSL/TLS inspection: decisioni su certificato, handshake e decryption.
• Application filter: applicazione riconosciuta e azione di Application Control.
• IPS: eventi di firma o anomalia.
• VPN: creazione e stato del relativo componente VPN.
• Authentication: utente riconosciuto e autenticazione riuscita o fallita.
• System: eventi di sistema e attivati da amministratori.
• SD-WAN: utilizzo di profilo SD-WAN, SLA e rotta.

I tipi di log che compaiono localmente sono configurati in System services > Log settings, sotto Local reporting. Questi Event Logs non sono gli On-box Reports. Central reporting e syslog sono destinazioni separate da attivare indipendentemente. Gli eventi delle Web Policy richiedono inoltre Log firewall traffic nella regola firewall associata. I log Wireless non sono disponibili in Log Viewer e devono essere inviati a Sophos Fusion (in precedenza Sophos Central) o a un server syslog.

Limite del Web Proxy: La documentazione SFOS 22/23 sul comportamento dei log descrive questo percorso proxy per HTTP/HTTPS sulle porte 80 e 443: una regola Drop corrispondente inoltra i pacchetti in ingresso al Web Proxy, che invia all’utente una pagina di blocco; senza una Web Exception corrispondente, il log Firewall mostra Allowed e il log Web filter Blocked. Le Web Exceptions continuano ad applicarsi e possono consentire richieste nonostante Drop. Il percorso documentato per Reject termina il flusso prima dell’elaborazione del proxy. Verificare insieme la regola firewall, la Web Policy e le Web Exceptions; è uno scenario documentato, non una garanzia universale di pagina di blocco per qualsiasi build o modalità di ispezione.

Conflitto documentale irrisolto: La guida SFOS 22/23 al modulo delle regole descrive l’autenticazione degli utenti web sconosciuti quando Use web authentication for unknown users è attivo, consente le Web Exceptions corrispondenti e descrive altrimenti una pagina di blocco HTML. La guida al logging del traffico scartato descrive invece lo scarto silenzioso e collega la pagina di blocco web a questa opzione di autenticazione. Non dedurre che l’opzione da sola determini la risposta. Prima di affidarsi a Drop per bloccare il web, ottenere un chiarimento scritto da Sophos per la versione, il build e il percorso di elaborazione esatti, oppure eseguire una verifica isolata ed esplicitamente autorizzata. Registrare regola e impostazioni attuali per il rollback; verificare separatamente HTTP e HTTPS, utenti noti/sconosciuti, autenticazione attiva/disattiva ed eccezioni corrispondenti presenti/assenti. Correlare nuovi flussi con Rule ID, log, Packet Capture e risultati del browser. Né una pagina di blocco né un timeout dimostrano da soli il blocco. In caso di accesso inatteso o risultato incerto, annullare le modifiche di test ed effettuare un’escalation; non distribuire in produzione.

Sulle porte diverse da 80 e 443, una regola Drop corrispondente scarta direttamente i pacchetti; il log Firewall mostra dropped. Con Reject, il log Firewall mostra rejected, sia su 80/443 sia sulle altre porte. Queste osservazioni richiedono Log firewall traffic nella regola corrispondente. Una Web Exception può, per esempio, consentire gli aggiornamenti Windows di Microsoft nonostante una regola Drop; ciò non giustifica l’ampliamento della regola senza analisi.

Regola Allow e heartbeat mancante

Un caso diverso da Drop si verifica quando la regola firewall che corrisponde effettivamente ha Action Allow, Block clients with no Heartbeat è attivo e l’endpoint non invia heartbeat. Per osservare i log descritti, Log firewall traffic deve essere attivo in questa regola. Prima della ricerca, controllare anche i tipi di log necessari in System services > Log settings > Local reporting; attivare soltanto una destinazione esterna non basta per la vista locale.

• Porte diverse da 80 e 443: Il firewall scarta i pacchetti di questo endpoint. Il log Firewall mostra dropped.
• Porte 80 e 443 nel percorso Web Proxy documentato: Il firewall accetta i pacchetti in ingresso e li passa al Web Proxy. Poiché l’endpoint non invia heartbeat, il sistema heartbeat decide di bloccare; il proxy invia all’utente una pagina di blocco. Il log Firewall mostra allowed, un altro log Firewall mostra Heartbeat blocked e il log Web filter mostra blocked. Qui Heartbeat blocked appartiene quindi anch’esso al modulo Firewall, non a un modulo di log heartbeat separato.

Allowed da solo non dimostra che l’accesso sia riuscito. Prima di modificare una regola, correlare le voci dello stesso flusso di test: verificare insieme intervallo del test, source, destination, porte e regola corrispondente. Cercare la voce separata Heartbeat blocked e la voce Web filter con blocked. Non sono richiesti un ordine fisso degli eventi, timestamp identici o un numero universale di righe; se mancano voci attese, controllare prima logging, destinazioni locali e filtri e, se necessario, usare Packet Capture.

Questa interpretazione vale per questa precisa opzione della regola, un endpoint senza heartbeat e il percorso proxy descritto. Non è un’affermazione generale su tutte le regole Allow, sugli endpoint rossi o comunque non sani né su altri modi di ispezione. Non disattivare l’obbligo di heartbeat come soluzione generica; chiarire prima la corrispondenza della regola e la causa dell’heartbeat mancante.

Distinguere Standard view e Detailed view

Standard view è utile per una lettura rapida. È possibile aggiungere o rimuovere colonne e fare clic su un valore per usarlo direttamente come filtro. Per un collaudo tecnico è più importante Detailed view, perché mostra i nomi dei campi sottostanti e valori aggiuntivi.

Un dettaglio NAT importante: se viene usato un indirizzo Source tradotto diverso dall’indirizzo MASQ predefinito, Standard view può comunque mostrare l’indirizzo MASQ come indirizzo in uscita. Il Source realmente tradotto si trova in Detailed view nel campo src_trans_ip.

In Standard view, anche passando il puntatore sull’icona di un modulo si vedono dettagli. La funzione di copia trasferisce le informazioni del log negli appunti. Il viewer si apre in una nuova finestra a schermo intero; se non appare, controllare prima il blocco popup del browser.

I campi tipici di un test firewall includono:

• IP Source e Destination e relative porte
• In interface e Out interface
• Firewall Rule ID e NAT Rule ID
• Azione o stato
• Nome utente, se è stata riconosciuta un’identità
• Source e Destination tradotti
• Log component e Log subtype

Il nome di un campo o un ID non spiega automaticamente la causa. Rule ID va confrontato con la base delle regole corrente, NAT ID con la regola NAT corrispondente e un ID di security policy con il relativo modulo.

Se contemporaneamente è attivo un Packet Capture in Diagnostics > Packet capture, Open PCAP nella voce di log corrispondente può aprire le informazioni sui pacchetti associati. La funzione collega la decisione registrata ai dettagli dei pacchetti, ma non sostituisce un filtro di cattura ben delimitato: source, destination, porta e orario del test devono comunque corrispondere al flusso esaminato.

Isolare il flusso corretto

Impostare i filtri fino a isolare il flusso corretto

Log Viewer offre quattro livelli di filtro:

1. Module: limita la vista a Firewall, Web, IPS, VPN o un’altra area.
2. Time / Timer filter: limita gli eventi all’intervallo del test; fare clic su Timer filter e scegliere un’opzione temporale.
3. Add filter: combina un campo specifico, una condizione e un valore.
4. Free text search: cerca per esempio porte, indirizzi IP, utenti o nomi di regole e funziona anche con informazioni anonimizzate.

Per un normale test di connessione si inizia con IP Source, IP Destination e porta Destination. Poi si restringe ulteriormente con Rule ID, utente o azione. Reset rimuove tutti i filtri. Questo è importante perché un vecchio filtro temporale o di campo può dare l’impressione che il viewer non riceva più eventi.

Il numero di eventi disponibili dipende dalla dimensione del disco e dalla retention locale. Log Viewer non sostituisce quindi un archivio a lungo termine protetto da manipolazioni. A tale scopo sono adatti Central Firewall Reporting o Inviare syslog a un SIEM.

La quota locale degli Event Logs dipende dal modello di appliance: per i modelli di fascia alta, Sophos indica fino al 15 % dell’intera partizione /var o al 50 % del suo spazio libero, scegliendo il valore inferiore. Non è un periodo di conservazione garantito né una quota valida per ogni modello. L’analisi dello spazio distingue Event Logs, report e Troubleshooting Logs; non eliminare file per tentativi.

Usare correttamente Pause, Refresh ed esportazione CSV

Pause interrompe l’aggiornamento automatico della vista. È utile per leggere o copiare una riga senza che si sposti. Non interrompe la registrazione sul firewall. Refresh ricarica manualmente la vista e l’esportazione scarica in formato CSV i log attualmente disponibili.

Prima di esportare si documentano modulo, intervallo temporale e filtri. Il CSV può contenere indirizzi IP interni, nomi utente, URL e relazioni di comunicazione e deve quindi rimanere in un flusso di supporto o analisi protetto.

Quando Data anonymization è attiva, valori identificativi come utente, IP, MAC e indirizzo e-mail vengono mostrati in forma protetta. Sophos consiglia almeno due persone autorizzate: se la persona connessa è essa stessa configurata come Authorizer, la deanonimizzazione deve essere approvata da almeno un’altra persona. Anche uno screenshot o un’esportazione deve contenere solo le righe necessarie per il caso.

Per visualizzare le identità tramite la funzione di deanonimizzazione, occorre essere autorizzati e fornire le proprie credenziali di autenticazione. Copiare una riga non sostituisce tale autorizzazione.

Comprendere Log suppression e Log occurrence

In System services > Log settings, il firewall può sopprimere eventi firewall consecutivi e identici. Ciò riduce spazio e carico di elaborazione. La soppressione interessa non solo i log locali, ma anche Sophos Fusion e le destinazioni syslog configurate.

In Log Viewer, Log occurrence mostra quante volte si è verificato un evento aggregato. Una sola riga può quindi rappresentare molte ripetizioni. Non va conteggiata automaticamente come un solo pacchetto o una sola connessione.

Prima di modificare Log suppression si verifica se il volume corrente è davvero la causa di un problema. Per una diagnosi breve, di solito è sufficiente leggere consapevolmente Log occurrence. Una modifica globale influenza anche le destinazioni esterne e non va eseguita solo per ottenere uno screenshot.

Interpretare i risultati in modo sicuro

Interpretare correttamente Invalid traffic

Invalid traffic significa che conntrack non ha potuto associare un pacchetto a una connessione corrente. Può accadere con un percorso asimmetrico, una sessione scaduta, flag TCP inattesi o pacchetti RST e FIN aggiuntivi. Non indica automaticamente un attacco o un difetto del firewall.

Se contemporaneamente si verifica un problema di connessione, si acquisiscono entrambe le direzioni con Packet Capture. Source, Destination, flag TCP, interfacce e timestamp devono appartenere allo stesso flusso. Aumentare Tcp Connection Establishment Idle Timeout può ridurre il numero di questi log, ma non risolve la causa legata al percorso o alla sessione. Il valore non va modificato per tentativi.

La registrazione Invalid traffic è attiva per impostazione predefinita. Conntrack segue le sessioni TCP e determinate sessioni UDP e ICMP; i pacchetti iniziali, come un TCP SYN o una richiesta ICMP Echo, stabiliscono l’associazione alla connessione. I flag TCP si interpretano così:

• SYN: richiede la sincronizzazione.
• SYN-ACK: la conferma e concorda i parametri della connessione.
• ACK: conferma l’accordo; il trasferimento dati può iniziare.
• PSH: richiede la consegna immediata dei dati.
• FIN: richiede una chiusura ordinata; entrambe le parti confermano la conclusione.
• RST: termina la connessione senza attendere risposta, per esempio dopo un pacchetto inatteso.

Pacchetti RST e FIN aggiuntivi possono essere scartati e registrati come Invalid traffic. Correlare un singolo evento con il reale problema di connessione anziché considerarlo un attacco distinto.

Il comando di sola lettura show advanced-firewall nella Device Console mostra il valore globale corrente; Sophos documenta 10800 secondi, cioè tre ore, come valore predefinito. Una modifica influisce su tutte le sessioni TCP corrispondenti del firewall. Prima vanno correlati in modo univoco l’applicazione interessata, il suo effettivo tempo di inattività e l’evento Invalid traffic. Un timeout più alto è solo un adeguamento operativo motivato, non una correzione per routing asimmetrico o perdita di pacchetti.

La procedura completa per i drop con Reason, Rule ID e la speciale Firewall ID 0 è descritta in Analizzare i pacchetti scartati su Sophos Firewall.

La fonte chiama il campo Tcp Connection Establishment Idle Timeout, ma descrive la scadenza delle voci conntrack per inattività e utilizza il setter tcp-est-idle-timeout. Il nome è ambiguo; non dimostra l’esistenza di un timeout handshake separato. Controllare l’output effettivo e l’aiuto CLI del proprio build.

La guida CLI SFOS 22/23 assegna esplicitamente tcp-est-idle-timeout alle connessioni TCP già stabilite e consente da 2700 a 432000 secondi. Il diverso nome del campo non viene quindi usato come raccomandazione per modificare un timeout di instaurazione della connessione.

Solo se un caso confermato di timeout per inattività giustifica un adeguamento globale, scegliere 4. Device Console nella CLI, annotare il valore attuale con show advanced-firewall e concordare una finestra di manutenzione. L’esempio documentato aumenta il valore a sei ore, non a un valore generalmente consigliato:

set advanced-firewall tcp-est-idle-timeout 21600
show advanced-firewall

Controllare il nuovo valore e ripetere il test della stessa applicazione durante il periodo di inattività pertinente. Meno eventi Invalid traffic non dimostrano da soli una correzione. Per il ripristino, usare lo stesso setter con i secondi precedentemente annotati e controllare con show advanced-firewall; 10800 è appropriato solo se era il valore iniziale. Se l’output CLI non è chiaro o il problema persiste, interrompere gli adeguamenti e analizzare il percorso dei pacchetti o coinvolgere il supporto.

Modificare regole da Log Viewer solo in modo controllato

A seconda dell’evento, Log Viewer può aprire direttamente Web Policies o regole NAT, firewall o SSL/TLS. Un clic sulla Web Policy, sulla regola NAT o sulla regola firewall offre il collegamento all’editor in WebAdmin. È comodo, ma non accorcia il controllo tecnico. Prima di modificare, verificare Rule ID, nome, posizione, zone, oggetti, servizio, riferimento utente e sessioni esistenti; annotare inoltre i valori correnti dei campi da modificare per poterli ripristinare.

Per un’eccezione SSL/TLS, selezionare SSL/TLS inspection, scorrere fino a Manage, scegliere Exclude, verificare l’opzione nel dialogo e solo dopo confermare con Exclude. Domain e Subdomain vengono aggiunti al gruppo URL Local TLS exclusion list, visibile in Categories and websites nelle regole SSL/TLS. Web category viene aggiunto a Exclusions by website or category, visibile nella lista delle regole SSL/TLS. Per Other properties, scegliere la regola SSL/TLS e oggetti appropriati, come utenti o indirizzi IP. Controllare oggetto di destinazione e ambito prima di confermare; un’esclusione di dominio non equivale a un’eccezione pensata per un solo utente. Log Viewer non offre Exclude per 19004 (traffico consentito) o 19005 (bloccato da una Web Policy).

Facendo clic su una IPS Signature ID può comparire Disable signature for this IPS policy. Questa azione modifica la IPS Policy attiva, non soltanto la vista. Prima si documentano la regola, la policy, la firma, l’effetto sulla protezione e l’ambito dell’eccezione; poi si ripete il test esattamente sul flusso confermato.

Una regola Allow ampia, un’eccezione web globale o la disattivazione di TLS inspection possono nascondere il sintomo e creare una nuova falla di sicurezza. Le modifiche vanno limitate al flusso confermato, testate in una finestra di manutenzione e poi validate con un nuovo flusso in Log Viewer e, se necessario, Packet Capture. Se il test fallisce o l’eccezione risulta troppo ampia, ripristinare lo stato annotato in precedenza nell’oggetto regola o policy collegato e ripetere la prova con un nuovo flusso.

Quando i log mancano o si trovano sull’altro nodo HA

Quando mancano i log attesi

Un risultato vuoto viene controllato in questo ordine:

1. Controllare Pause, modulo, intervallo temporale e filtri, poi usare Reset e Refresh.
2. Controllare il logging della regola e Local reporting per il tipo di log necessario.
3. Creare una nuova connessione chiusa deliberatamente con timestamp noto.
4. Confermare con Packet Capture che il traffico raggiunge il firewall e quale Rule ID lo elabora.
5. Controllare gli altri moduli per eventi dello stesso flusso.
6. Analizzare il viewer o il percorso del servizio di logging solo se l’intera vista locale non riceve più nuovi eventi.

La procedura specifica per versione per un viewer completamente fermo è descritta in Log Viewer non mostra nuovi log. Riavviare un servizio o intervenire nel database locale dei log non fa parte dell’utilizzo generale.

Log Viewer negli ambienti HA

Ogni nodo HA memorizza solo i log e i report del traffico che ha elaborato. Soprattutto in active-active o dopo un failover, l’evento atteso può quindi trovarsi sull’altro nodo. Ora, ruolo del nodo e Connection served by vengono documentati insieme.

Central Firewall Reporting o syslog possono offrire una vista centrale. Non sostituiscono però il controllo specifico del nodo quando si analizza un determinato cambio di ruolo HA, un guasto di un servizio locale o il percorso dati al momento dell’evento.