Usare correttamente Log Viewer su Sophos Firewall
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
- Nella regola firewall interessata controllare Log firewall traffic oppure Log connections nella regola SSL/TLS.
- In System services > Log settings, verificare che il tipo di log necessario sia attivo in Local reporting.
- Aprire Log viewer in alto a destra in WebAdmin e scegliere il modulo pertinente.
- Impostare il filtro temporale e usare Add filter per restringere inizialmente il risultato per IP Source, IP Destination e servizio.
- Generare un nuovo flusso breve e annotarne l’ora esatta.
- In Detailed view, controllare Rule ID, NAT ID, azione, interfacce, utente e campi specifici del modulo.
- 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?
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 timestamp e le stesse destinazioni:
- 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.
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.
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.
Impostare i filtri fino a isolare il flusso corretto
Log Viewer offre quattro livelli di filtro:
- Module: limita la vista a Firewall, Web, IPS, VPN o un’altra area.
- Time: limita gli eventi all’intervallo del test.
- Add filter: combina un campo specifico, una condizione e un valore.
- 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.
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. La deanonimizzazione richiede una persona autorizzata e le sue credenziali. Anche uno screenshot o un’esportazione deve contenere solo le righe necessarie per il caso.
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 Central 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 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 procedura completa per i drop con Reason, Rule ID e la speciale Firewall ID 0 è descritta in Analizzare i pacchetti scartati su Sophos Firewall.
Modificare regole da Log Viewer solo in modo controllato
A seconda dell’evento, Log Viewer può aprire direttamente Web Policies, regole firewall o regole SSL/TLS. È comodo, ma non accorcia il controllo tecnico. Prima di modificare, verificare Rule ID, nome, posizione, zone, oggetti, servizio, riferimento utente e sessioni esistenti.
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.
Quando mancano i log attesi
Un risultato vuoto viene controllato in questo ordine:
- Controllare Pause, modulo, intervallo temporale e filtri, poi usare Reset e Refresh.
- Controllare il logging della regola e Local reporting per il tipo di log necessario.
- Creare una nuova connessione chiusa deliberatamente con timestamp noto.
- Confermare con Packet Capture che il traffico raggiunge il firewall e quale Rule ID lo elabora.
- Controllare gli altri moduli per eventi dello stesso flusso.
- 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.
Perché una connessione consentita compare più tardi in Log Viewer?
Destroy, alla fine della connessione. Una sessione lunga o riutilizzata può quindi comparire in ritardo. Per il test si crea una nuova connessione breve e chiusa deliberatamente.