Interpretare correttamente Live Connections su Sophos Firewall

Live Connections mostra quali connessioni sono attualmente attive su Sophos Firewall. La vista permette di capire rapidamente quale client, utente o applicazione genera traffico, quali interfacce sono coinvolte e quale regola firewall o NAT gestisce la sessione. Per una singola connessione, Diagnostics > Connection list fornisce dettagli tecnici ancora più approfonditi.

Entrambe le viste sono istantanee. Non sostituiscono né Log Viewer per le decisioni registrate, né Packet Capture per il flusso effettivo dei pacchetti. Se usate correttamente insieme, consentono però di risparmiare molto tempo: prima si individua la sessione attiva, poi si controllano log e pacchetti quando necessario.

Live Connections in sette passaggi

1. Definire il flusso di test: IP sorgente, IP di destinazione, protocollo, porta sorgente se nota, porta di destinazione e ora esatta.
2. Generare una nuova connessione dal client di test, ad esempio HTTPS da 192.0.2.25 a 198.51.100.50 su TCP 443.
3. Aprire Current activities > Live connections e raggruppare per Source IP address.
4. Filtrare 192.0.2.25 e aprire le singole connessioni tramite Total.
5. Annotare Start time, In interface, Out interface, Source, Destination, porte, Firewall Rule ID e NAT Rule ID.
6. In Diagnostics > Connection list > Display filter, filtrare lo stesso flusso nel modo più preciso possibile e confrontare Translated source, Translated destination, Gateway ID, Policy ID e RX/TX.
7. In caso di differenze, correlare il flusso in Log Viewer e Packet Capture prima di modificare regole, NAT o routing.

Gli indirizzi 192.0.2.25 e 198.51.100.50 appartengono a reti di documentazione. Per un test reale vanno sostituiti con gli indirizzi effettivi del client e della destinazione. TCP 443 è adatto solo se si sta realmente verificando una connessione HTTPS.

⚠️ Le viste contengono indirizzi IP interni, nomi utente, applicazioni e relazioni di comunicazione. Limitare filtri e schermate allo stretto necessario e condividere i dati di supporto solo con destinatari autorizzati.

Distinguere Live Connections da Connection List

Le due viste accedono allo stato corrente delle connessioni, ma sono pensate per domande diverse.

Live Connections per una panoramica

In Current activities > Live connections è possibile raggruppare le connessioni attive per:

• Application
• Source IP address
• Username

La vista mostra upload, download, larghezza di banda media utilizzata, proprietà e numero di sessioni. Aiuta a rispondere a domande come: quale client sta generando molto traffico? Quale applicazione è attiva? Quale utente ha più connessioni aperte?

I valori di trasferimento visualizzati si riferiscono al periodo trascorso dall’apertura della connessione. Upstream bandwidth e Downstream bandwidth vengono calcolate in base ai byte trasferiti e alla durata della connessione fino a quel momento. Non rappresentano quindi un test della linea secondo per secondo. Per una prova delle prestazioni è più adatto usare correttamente iPerf3 con Sophos Firewall.

In Live Connections può essere attivo un solo filtro alla volta. L’IP sorgente è in genere il punto di partenza più chiaro. Username o Application sono utili quando il client è già correttamente autenticato o l’applicazione è stata riconosciuta.

Connection List per la singola sessione

In Diagnostics > Connection list ogni connessione corrente appare su una riga separata. Questa vista è più tecnica e mostra, tra l’altro:

• In interface e Out interface
• Source e Destination con le porte
• Protocol e Application
• Rule ID e NAT ID
• User e User group
• Policy ID Web, Application, IPS, Traffic Shaping e Remote Access
• Gateway ID
• Translated source e Translated destination
• Expiry, RX/TX bytes e RX/TX packets
• Connection served by

Il Display filter può includere più caratteristiche note del flusso di test. In questo modo una lista molto lunga viene ridotta a poche sessioni corrispondenti.

Cosa non dimostra nessuna delle due viste

Una sessione visibile dimostra che esiste una voce corrente nel tracciamento delle connessioni. Non dimostra automaticamente:

• che ogni richiesta e ogni risposta siano state trasmesse completamente
• che il server di destinazione abbia elaborato correttamente l’applicazione
• che un errore precedente nello stesso flusso sia ancora disponibile nello storico
• che la regola firewall o NAT selezionata sia funzionalmente corretta
• che una voce verde non contenga perdita di pacchetti, ritrasmissioni o problemi MTU

Per le decisioni storiche servono i log. Per ingresso, uscita, risposte e drop serve Packet Capture. Per l’applicazione restano rilevanti i log del server, del client o del servizio SaaS.

Preparare un flusso di test controllato

Un test utile non inizia con un aggiornamento casuale del browser. Per prima cosa si definisce la quintupla:

• IP sorgente
• IP di destinazione
• protocollo
• porta sorgente
• porta di destinazione

La porta sorgente è spesso dinamica nelle connessioni client. Se non è ancora nota, per il primo filtro bastano IP sorgente, IP di destinazione, protocollo e porta di destinazione. Dopo aver trovato la voce, si può ricavare dalla sessione la porta sorgente specifica.

Definire inoltre i valori attesi:

• In interface e Out interface
• Firewall Rule ID e, se applicabile, NAT Rule ID
• utente o gruppo di utenti se la regola utilizza l’identità
• Gateway o percorso SD-WAN
• Source e Destination attese dopo il NAT
• ora esatta del test con fuso orario

Creare sempre una nuova connessione dopo le modifiche

Le sessioni esistenti conservano lo stato definito al momento della loro creazione. In particolare, le decisioni NAT non vengono rivalutate per ogni pacchetto successivo. Dopo una modifica a regole, NAT, routing o SD-WAN, chiudere quindi la sessione dell’applicazione e generare un nuovo flusso.

Un aggiornamento del browser può continuare a usare la stessa connessione TCP, HTTP/2 o HTTP/3. Per un collaudo affidabile è utile una nuova finestra privata del browser, il riavvio del processo client o un altro test controllato che apra sicuramente una nuova connessione. Il metodo deve essere adatto all’applicazione e non deve interrompere involontariamente una sessione di produzione.

Usare Live Connections per trovare la prima voce

1. Aprire Current activities > Live connections.
2. Scegliere un Automatic refresh interval adatto al test o aggiornare manualmente con Refresh.
3. Per un client noto, selezionare Source IP address.
4. Aprire il filtro, scegliere il modificatore appropriato e inserire l’IP sorgente.
5. Controllare Transfer, Bandwidth e Total nella riga.
6. Fare clic sul numero sotto Total per aprire le singole connessioni in una nuova scheda.
7. Identificare il flusso corretto tramite Start time, interfacce, indirizzi IP, porte e Protocol.

Una richiesta DNS, ICMP o Web molto breve potrebbe essere già scomparsa prima dell’aggiornamento della pagina. In tal caso, impostare prima il filtro, preparare Refresh e attivare nuovamente il test una sola volta.

Interpretare correttamente Other applications e DNS

Other applications contiene applicazioni non riconosciute e traffico generato dal sistema, ad esempio download delle firme, accesso alla console o richieste DNS generate dal firewall. Non è automaticamente una categoria di errore.

Il DNS richiede particolare attenzione: il traffico tra un client interno e un server DNS esterno è soggetto alle normali regole firewall e appare come DNS. Il traffico DNS generato dal firewall può invece apparire sia sotto DNS sia sotto Other applications.

Se un’applicazione non viene riconosciuta e Security Heartbeat è attivo, Connection List può offrire la risoluzione di Application Information per gli endpoint connessi. Senza un Sophos Endpoint connesso o senza Heartbeat, No information available rimane possibile. Un nome sconosciuto non indica quindi automaticamente traffico dannoso.

Firewall Rule ID 0 dipende dal contesto

Il traffico generato dal sistema ha Firewall Rule ID 0 in Live Connections, perché le normali regole firewall non lo controllano. L’accesso ai servizi locali del firewall è invece controllato, tra le altre cose, da Administration > Device access e dalla Local Service ACL. Device Access e Local Service ACL spiega la configurazione sicura.

Questo 0 non va interpretato fuori contesto come una regola di drop implicita. Rule #0 in un log firewall o in Packet Capture può avere un diverso significato diagnostico. Sono determinanti la vista, Status, Reason e la distinzione tra traffico generato dal sistema e traffico client inoltrato.

Limitare Connection List a un singolo flusso

1. Aprire Diagnostics > Connection list.
2. Selezionare Display filter.
3. Impostare Network protocol su IPv4 o IPv6 in base al test.
4. Inserire l’IP sorgente e l’IP di destinazione.
5. Aggiungere Packet type e la porta sorgente o di destinazione, se note.
6. Inserire la Rule ID attesa se si cercano in modo specifico le sessioni attive che utilizzano quella regola.
7. Applicare il filtro con OK e confrontare i risultati con l’ora del test.

Un risultato vuoto non dimostra che il firewall stia bloccando il traffico. La sessione potrebbe essere già terminata, il client potrebbe usare un indirizzo di destinazione diverso ottenuto tramite DNS o CDN, il NAT potrebbe modificare l’indirizzo visibile oppure il test potrebbe essere stato elaborato dall’altro nodo HA. Verificare prima il flusso di test e il punto di osservazione, invece di ampliare la regola firewall.

Leggere insieme i campi più importanti

• Time: ora di inizio della connessione. Deve corrispondere al test controllato.
• In interface / Out interface: mostrano il percorso in ingresso e in uscita utilizzato dalla sessione.
• Source / Destination / Ports: definiscono il flusso visibile prima dell’interpretazione dei dettagli.
• Rule ID: mostra la regola firewall che consente la sessione.
• NAT ID: mostra la regola NAT coinvolta.
• Translated source / Translated destination: rendono visibili SNAT, MASQ, DNAT o PAT.
• Gateway ID: associa la sessione a un gateway ed è particolarmente importante per le verifiche WAN o SD-WAN.
• Username / User group: mostrano se alla sessione è associato il contesto utente atteso.
• Policy IDs: mostrano le policy Web, Application, IPS, Traffic Shaping o Remote Access assegnate.
• Expiry: mostra dopo quanti secondi scade una sessione inattiva.
• RX/TX bytes e packets: aiutano a capire se solo una direzione trasporta dati o se entrambe sono attive.
• Connection served by: mostra quale firewall elabora la connessione in un ambiente HA.

Rule ID e NAT ID vanno sempre lette insieme a interfacce, indirizzi e porte. Una Rule ID attesa con una NAT ID inattesa indica un problema di corrispondenza NAT. Se entrambe le ID sono corrette, ma Out interface o Gateway non lo sono, occorre verificare routing o SD-WAN. NAT su Sophos Firewall ne spiega i principi fondamentali.

Non sopravvalutare Related Connections

Facendo clic sulla Connection ID è possibile visualizzare connessioni dipendenti, ad esempio con Web Proxy, FTP, SIP o altri protocolli che creano sessioni correlate. Se non esiste alcun flusso dipendente, la vista rimane vuota. Una vista Related Connections vuota non dimostra quindi la presenza di un errore.

Correlare sessione attiva, Log Viewer e Packet Capture

I tre strumenti rispondono in sequenza a tre domande diverse:

1. Live Connections o Connection List: quale sessione è attualmente presente e quali ID, interfacce, indirizzi, policy e associazioni di gateway contiene?
2. Log Viewer: quale decisione firewall, NAT o di sicurezza è stata registrata?
3. Packet Capture: i pacchetti arrivano, vengono inoltrati e le risposte ritornano?

Per un confronto affidabile:

1. Annotare l’ora del test e la quintupla.
2. Annotare la sessione attiva e la Connection ID.
3. Documentare Rule ID, NAT ID, In/Out interface, Gateway e indirizzi tradotti.
4. Filtrare Log Viewer per sorgente, destinazione, porta e ora.
5. Se manca la risposta o il percorso non è chiaro, avviare Packet Capture con un filtro BPF ristretto.
6. Documentare il risultato prima di modificare la configurazione.

Se Live Connections mostra una sessione, ma in Log Viewer non compare alcun evento firewall corrispondente, controllare prima Log firewall traffic, Local reporting e i filtri. La procedura è descritta in Log Viewer non mostra nuovi log.

Device Console offre inoltre system diagnostics utilities connections. La guida pubblica attuale documenta lo strumento, ma non tutte le opzioni dipendenti dal build. Prima dell’uso verificare quindi la sintassi disponibile con ? e utilizzare l’output solo in lettura. Troubleshooting CLI di Sophos Firewall descrive il perimetro sicuro.

Sintomi tipici

La sessione attesa non appare

Verificare prima se il flusso è ancora attivo e se sorgente, destinazione e versione IP sono corrette. Con DNS, CDN, proxy, NAT o IPv6, l’indirizzo di destinazione effettivo può differire da quello previsto. Generare un nuovo test e avviare Packet Capture in parallelo se non è chiaro se il firewall riceva pacchetti.

È visibile una Rule ID o NAT ID errata

Potrebbe avere priorità una regola più generale posizionata più in alto. Confrontare ordine delle regole firewall e NAT, zone, sorgente, destinazione, servizio, utente e pianificazione. Non spostare più regole contemporaneamente. La procedura guidata è disponibile in Testare correttamente una regola Sophos Firewall.

Solo una direzione incrementa RX o TX

Questo può indicare un percorso di ritorno mancante, una traduzione NAT errata, un problema del sistema di destinazione o il firewall locale del server. Verificare interfacce, indirizzi tradotti e gateway, quindi cercare entrambe le direzioni in Packet Capture. Un singolo contatore non dimostra la causa.

I valori non cambiano dopo una modifica alla configurazione

Probabilmente la vista mostra ancora la sessione esistente. Chiudere correttamente la connessione del client, generare un nuovo flusso e controllare di nuovo Start time e Connection ID. Non utilizzare un flush globale delle sessioni o un riavvio del servizio come normale primo test.

In HA manca la sessione o la voce di log corrispondente

Annotare Connection served by e considerare il nodo che elaborava il traffico al momento dell’evento. I log sono archiviati localmente su ogni nodo HA e non vengono sincronizzati completamente tra i nodi. Non dedurre una continuità ininterrotta della sessione dalla Connection List visibile. Configurare HA su Sophos Firewall spiega i limiti.

Other applications è insolitamente grande

Raggruppare prima per IP sorgente e aprire le singole sessioni. In questo gruppo possono confluire applicazioni non riconosciute, traffico di sistema e cause diverse. Verificare Rule ID, destinazioni, porte, utente e contesto dell’applicazione prima di considerarlo un incidente di sicurezza.

Checklist

• Sorgente, destinazione, protocollo, porte e ora del test sono noti.
• È stata generata una nuova connessione per il test.
• Live Connections è stato raggruppato in modo appropriato per IP sorgente, utente o applicazione.
• Start time, In/Out interface, Rule ID e NAT ID corrispondono alle attese.
• Translated source/destination e Gateway ID corrispondono al percorso previsto.
• User e Policy ID sono stati attesi solo se il relativo riconoscimento è attivo.
• Rule ID 0 è stata interpretata nel corretto contesto di traffico di sistema.
• In HA è stato documentato Connection served by.
• Log Viewer e, se necessario, Packet Capture confermano la sessione.
• Non è stato usato alcun flush globale delle sessioni o riavvio di servizio come primo tentativo di diagnosi.

Domande frequenti