Analizzare i pacchetti scartati su Sophos Firewall

Un pacchetto scartato non indica automaticamente un errore. Il firewall può bloccare il traffico come previsto, scartare inaspettatamente traffico legittimo oppure non vedere affatto il flusso. La procedura seguente consente di capire rapidamente se la causa è una regola, NAT, il percorso di ritorno, un modulo di sicurezza o un sistema a monte del firewall.

Circoscrivere i drop in pochi minuti

1. Annotare il caso di test: Registrare IP sorgente, IP di destinazione, porta, protocollo, ora e direzione prevista. In caso di errori sporadici, annotare anche utente, applicazione e ultima modifica alla configurazione.
2. Filtrare Log Viewer: Nel modulo Firewall cercare indirizzo IP, porta e ora. A seconda del caso, aprire anche Web, SSL/TLS inspection, Application filter, IPS, Active threat response, Web server protection o VPN.
3. Avviare Packet Capture: In Diagnostics > Packet capture, impostare un filtro preciso, attivare la cattura ed eseguire un solo test riproducibile.
4. Leggere lo stato del pacchetto: Incoming, Forwarded, Consumed, Generated o Violation indicano se il pacchetto arriva, viene inoltrato, viene elaborato localmente, viene generato dal firewall o viene scartato.
5. Associare la decisione: Confrontare Rule ID, NAT ID e Reason con le regole firewall e NAT previste. Per i risultati Web, IPS o Application, controllare anche l’ID della policy interessata.
6. Catturare il ritorno: Se il traffico in uscita viene inoltrato ma non si vede alcuna risposta, verificare la route di ritorno, il sistema di destinazione, NAT, SD-WAN e il routing asimmetrico.
7. Modificare solo dopo: Non creare una regola Allow ampia o un’eccezione globale prima di aver identificato il modulo responsabile e la causa effettiva.

Per il matching generale delle regole e Policy Tester è disponibile la guida dettagliata Testare una regola Sophos Firewall con Log Viewer e Packet Capture.

Leggere insieme Log Viewer e Packet Capture

Log Viewer e Invalid traffic

Il Log Viewer si apre in alto a destra in WebAdmin. Mostra non solo le decisioni del firewall, ma anche gli eventi dei moduli di sicurezza coinvolti. Nel traffico Web Proxy, ad esempio, il modulo Firewall può segnalare Allowed mentre il modulo Web segnala contemporaneamente Blocked: la regola firewall consente la connessione al proxy, mentre la Web Policy blocca il contenuto. Occorre quindi correlare sempre i moduli relativi allo stesso momento del test. Filtri, Detailed view, tempistica della sessione e Log occurrence sono spiegati in Utilizzare correttamente il Log Viewer di Sophos Firewall.

Per il traffico firewall si devono verificare separatamente due requisiti:

• Nella regola interessata è attivato Log firewall traffic. Le regole SSL/TLS dispongono dell’opzione specifica Log connections.
• In System services > Log settings è attivata la destinazione di output necessaria per Log Viewer in Local reporting, Sophos Central o Syslog.

Le sessioni firewall compaiono normalmente quando il firewall riceve un evento Destroy durante la chiusura della connessione. Se una connessione termina senza questo evento, può mancare la voce prevista. Per una conservazione più lunga sono adatti Central Firewall Reporting o Syslog verso un SIEM.

Invalid traffic significa che Conntrack non riesce ad associare un pacchetto a una connessione corrente. Una sessione scaduta o pacchetti TCP RST e FIN aggiuntivi possono generare questi eventi e non indicano automaticamente un errore. Se contemporaneamente si verificano problemi di connessione, catturare entrambe le direzioni e verificare possibili cause come una route di ritorno mancante, un percorso asimmetrico o un cambio di ruolo HA. Un timeout Conntrack più lungo può soltanto ridurre le voci di log; non risolve la causa.

Se il motivo specifico del drop è Invalid TCP reserved bit, la causa può essere Accurate ECN anziché una regola firewall. Risolvere Invalid TCP reserved bit causato da Accurate ECN spiega come dimostrarlo e valutare l’impatto di sicurezza del workaround CLI globale.

Status, Rule ID, NAT ID e Reason

Packet Capture mostra i pacchetti che attraversano un’interfaccia e aggiunge le informazioni di elaborazione del firewall, di NAT e dei moduli di sicurezza. La documentazione attuale di SFOS 22 definisce questi valori di stato:

• Incoming: Il pacchetto arriva su un’interfaccia. Questo non dimostra ancora che venga inoltrato.
• Forwarded: Il firewall inoltra il pacchetto a un’interfaccia di uscita. Se manca la risposta, il passo successivo è concentrarsi sul sistema di destinazione e sul percorso di ritorno.
• Consumed: Il pacchetto è destinato al firewall stesso, ad esempio a WebAdmin, SSH, DNS o a un portale VPN.
• Generated: Il firewall genera il pacchetto, ad esempio come risposta o traffico di sistema.
• Violation: Una violazione della policy provoca il drop. Rule ID, Reason e il modulo responsabile indicano il controllo successivo.

Sono inoltre importanti Rule ID, NAT ID, Reason, Connection ID, Web filter ID, Application ID, IPS policy ID e Username. Un valore inatteso può indicare che si applica una regola più generale situata più in alto, che NAT modifica gli indirizzi visibili o che l’utente non è stato riconosciuto.

Reason è un’indicazione, non un rapporto completo sulla causa principale. A seconda della versione, valori come Firewall, LOCAL_ACL, INVALID_TRAFFIC, APPLICATION_FILTER, IPS, USER_IDENTITY, IP_SPOOF, SSL_VPN_ACL_VIOLATION o VIRTUAL_HOST possono condurre al modulo responsabile. Leggere prima lo stato e gli ID, quindi aprire l’area appropriata in Log Viewer. Sophos Firewall Packet Capture spiega l’uso e i filtri.

Firewall ID 0 e log dei drop mancanti

Se nessuna regola firewall esplicita corrisponde, alla fine della base regole si applica la regola integrata Drop all con Policy o Firewall ID 0. Non genera una normale voce di log del traffico firewall. Per rendere questi drop tracciabili in Log Viewer, Central Reporting o Syslog, creare in fondo alla base regole una regola separata con Action: Drop e Log firewall traffic attivato.

Selezionare singolarmente le Source e Destination Zones necessarie e non utilizzare Any indiscriminatamente per le zone. In questo modo i servizi locali rimangono raggiungibili. Se la regola finale riceve molto traffico legittimo, probabilmente manca una regola Allow appropriata più in alto oppure una rete è stata classificata in modo errato.

Per SFOS 22.0.1 MR1 Build 490, Sophos documenta inoltre il problema noto NC-178387: i drop predefiniti con ID 0 non compaiono in Dropped Packet Capture e in drppkt; nel normale Packet Capture può apparire soltanto Incoming senza la corrispondente voce Violation Firewall. Il traffico viene comunque scartato. Nell’elenco dei problemi noti Sophos non indica una versione con correzione confermata, quindi questo comportamento non deve essere dato per scontato al di fuori della build indicata.

Se si sospetta un drop predefinito:

1. Verificare l’ordine delle regole e Policy Test.
2. Confrontare il risultato con un vero Packet Capture.
3. Se è necessario il logging, creare una regola finale con zone specifiche e una propria Rule ID.
4. Ripetere il test e confermare la nuova Rule ID nel log o nella cattura.

Policy Tester in Diagnostics > Tools non considera le route SD-WAN e pertanto non costituisce mai l’unica prova. Su SFOS 22.0 GA, inoltre, NC-177587 poteva mostrare risultati di regola errati; i log di produzione e Packet Capture restano determinanti.

Circoscrivere la causa in base al risultato

Regola, NAT e percorso di ritorno

Se la Rule ID non corrisponde alla regola prevista, controllare Source e Destination Zone, oggetti di rete, servizio, protocollo, utente, pianificazione e ordine delle regole. Con DNAT è decisivo verificare se il test viene eseguito verso l’indirizzo pubblico e quale NAT ID si applica effettivamente. Le nozioni di base sono disponibili in Comprendere le regole firewall e Pubblicare un server tramite DNAT.

Se Packet Capture mostra Forwarded, ma non arriva alcuna risposta, un’altra regola Allow raramente è la soluzione. Spesso mancano SNAT/MASQ o la route di ritorno, una regola NAT collegata è disattivata, il sistema di destinazione blocca localmente oppure SD-WAN invia la risposta su un altro percorso. Entrambe le direzioni devono attraversare lo stesso firewall stateful.

Sessione, routing asimmetrico e HA

Messaggi come Could not associate packet to any connection indicano che non è stata trovata una voce Conntrack corrispondente. Le possibili cause includono una sessione scaduta, flag TCP inattesi, un percorso di ritorno asimmetrico o un flusso che il firewall vede in una sola direzione. Dopo un cambio di ruolo HA può inoltre essere rilevante sapere su quale nodo è stata stabilita la connessione.

Un singolo evento RST o FIN senza un problema per l’utente non richiede una modifica immediata. Per interruzioni riproducibili, controllare entrambe le direzioni con lo stesso filtro, quindi routing, SD-WAN, percorsi VPN e stato HA.

Consumed e servizi locali del firewall

Consumed non è un normale drop di transito. La destinazione è il firewall stesso, ad esempio WebAdmin, User Portal, VPN Portal, SSH, DNS, DHCP, IPsec, SSL VPN o SNMP. Queste connessioni sono normalmente gestite da Administration > Device access e Local service ACL, non da una normale regola firewall. Proteggere Device Access su Sophos Firewall mostra la configurazione sicura.

Moduli di sicurezza, VPN e MTU

Una regola firewall può consentire il traffico prima che un modulo successivo lo blocchi. Se gli ID o i Reasons lo indicano, controllare quindi anche Web Policy, SSL/TLS inspection, Application Control, IPS, Active Threat Response e WAF. In caso di risultato IPS, valutare la firma e il contesto della regola prima di creare un’eccezione; la procedura è descritta in Testare in sicurezza IPS su Sophos Firewall.

Per problemi Web e TLS, QUIC su UDP 443 può modificare l’elaborazione prevista. Bloccare QUIC e HTTP/3 mostra il controllo appropriato.

Con VPN, PPPoE, SD-WAN o tunnel annidati, MTU, MSS e frammentazione tendono a causare blocchi o interruzioni parziali anziché un drop evidente. Sono disponibili le guide su MTU e MSS e sul troubleshooting delle VPN IPsec.

Quando i controlli standard non bastano

Nessuna voce in Log Viewer o Packet Capture

Se manca una voce di log, controllare prima il logging della regola, Log settings, il filtro temporale e il modulo responsabile. Se anche Packet Capture non mostra alcun pacchetto, prima di diagnosticare la rete verificare quanto segue:

• Packet Capture è realmente attivo e il test è stato eseguito solo dopo l’attivazione.
• Il filtro contiene indirizzi, porte, direzione e interfaccia corretti; ampliarlo leggermente per una prova.
• Il buffer da 2048 KB non è pieno. Quando il buffer è pieno, la registrazione si arresta automaticamente e deve essere riavviata dopo aver selezionato Clear.
• In System services > Services è in esecuzione Packet capture and Live connections; se non si avvia, riavviare questo servizio in modo controllato.

Solo quando un test riproducibile con una cattura funzionante non mostra alcun pacchetto in ingresso, l’analisi deve spostarsi a monte del firewall: client, VLAN, switch, gateway, router a monte o destinazione di test errata.

tcpdump, Drop Capture e archivi di log

Per catture più lunghe, file PCAP o filtri BPF precisi, accedere tramite SSH e selezionare Option 4: Device Console. Un esempio di cattura precisa per due host e HTTPS è:

tcpdump 'host 192.0.2.10 and host 198.51.100.20 and port 443'

Per i pacchetti scartati dalle regole firewall, lo stesso filtro può essere utilizzato con drop-packet-capture:

drop-packet-capture 'host 192.0.2.10 and host 198.51.100.20 and port 443'

drop-packet-capture non è utile per problemi a livello applicativo. Per creare un file PCAP, tcpdump supporta l’opzione filedump; il file viene archiviato temporaneamente in /tmp. Mantenere la cattura il più breve e precisa possibile, perché i pacchetti possono contenere dati sensibili, ed eliminare il file dopo l’analisi. Altri esempi sono disponibili in tcpdump su Sophos Firewall.

Se il supporto necessita anche dei log di servizio, identificare prima il log responsabile e raccogliere solo l’intervallo temporale necessario. Servizi e log di Sophos Firewall e Raccogliere i log per supporto e analisi descrivono la procedura.

Correggere e documentare in modo sicuro

Un’eccezione è appropriata solo quando sono noti il modulo, lo scopo legittimo e l’ambito più ristretto possibile. Non consentire un’eccezione TLS globale, una regola Allow con Any o intere reti solo perché il servizio torna a funzionare. Sono preferibili host, servizi e utenti specifici, oltre a una data di revisione o scadenza.

Prima di chiudere il caso, documentare:

• Source, destination, porta, protocollo, ora e utente.
• Rule ID e NAT ID previste e realmente visibili.
• Status, Reason e modulo di sicurezza coinvolto.
• Direzione di andata e ritorno oppure il punto in cui termina il flusso.
• Modifica, proprietario, ticket e data di revisione; annotare anche se si è scelto consapevolmente di non apportare modifiche.

Ripetere quindi lo stesso test. La connessione consentita deve funzionare e una sorgente di confronto non autorizzata deve rimanere bloccata. In questo modo una correzione rapida non diventa una lacuna di sicurezza permanente.

Domande frequenti