Configurare e testare NetFlow su Sophos Firewall

Con NetFlow, Sophos Firewall invia i metadati delle connessioni a un Flow Collector esterno. In questo modo è possibile analizzare nel tempo le relazioni di comunicazione, il volume di traffico e le connessioni sospette. Il requisito più importante viene facilmente trascurato: viene esportato solo il traffico delle regole firewall in cui è attivo Log firewall traffic.

La procedura breve è la seguente:

1. Preparare nel Collector un listener NetFlow v5, ad esempio su UDP 2055.
2. Aggiungere il Collector in System > Administration > Netflow.
3. Attivare Log firewall traffic nella regola firewall interessata.
4. Generare un flusso di test chiaramente documentato.
5. Verificare separatamente il trasporto con Packet Capture e il contenuto nel Collector.

Per ottenere un risultato affidabile devono coincidere tre elementi: i campi della versione 5, la regola firewall effettivamente applicata e il percorso di rete verso il Collector.

Quando NetFlow è lo strumento giusto

NetFlow è adatto quando un Collector deve memorizzare i Flow Record delle connessioni elaborate da regole con logging attivo e analizzarli nel tempo. Le domande tipiche sono: quali indirizzi Source e Destination comunicano tra loro, quali porte vengono utilizzate e quanti pacchetti o byte appartengono al flusso?

Altri strumenti rispondono a domande diverse:

• Monitoraggio sFlow campiona il traffico e i contatori di interfaccia di determinate interfacce hardware. È particolarmente adatto per modelli di traffico e monitoraggio della capacità.
• Syslog a un SIEM trasporta eventi di log di firewall, VPN, IPS e altre funzioni con campi specifici del prodotto.
• Monitoraggio hardware SNMP monitora hardware, interfacce, temperatura, ventole o alimentatori.
• Central Firewall Reporting offre report, ricerca e conservazione Sophos in Sophos Fusion (in precedenza Sophos Central).
• Packet Capture rimane più preciso per un singolo percorso dei pacchetti, NAT o un errore di connessione.

NetFlow non sostituisce questi strumenti. Spesso il Collector segnala un flusso sospetto, mentre Log Viewer o Packet Capture spiega successivamente quale regola, decisione NAT o funzione di sicurezza è stata coinvolta.

Cosa mostra NetFlow v5 e cosa non mostra

SFOS 22 e SFOS 23 documentano NetFlow Version 5 e la possibilità di esportare tutti i parametri v5. Questa capacità documentata non conferma che ogni campo contenga un valore significativo per ogni flusso; occorre verificarlo nei record effettivamente ricevuti. Un record v5 può contenere, tra gli altri, i valori seguenti:

• indirizzo IPv4 Source e Destination;
• porta Source e Destination e protocollo IP;
• contatori di pacchetti e byte;
• ora iniziale e finale del flusso;
• interfaccia di ingresso e uscita come ifIndex;
• TCP flags, ToS e informazioni su AS e prefissi.

NetFlow v5 non contiene invece campi nativi per nome utente, Firewall Rule ID, URL, applicazione o contenuto dei pacchetti. Un Collector può correlare gli indirizzi IP con ulteriori fonti di dati, ma queste informazioni non provengono direttamente dal record v5.

La guida Sophos descrive anche l’obiettivo di identificare protocolli, policy, interfacce e utenti che consumano molta banda. I protocolli e gli indici delle interfacce possono essere analizzati a partire dai record v5; l’associazione a una policy o a un utente richiede dati aggiuntivi provenienti dai log o dall’inventario. Sophos cita PRTG e Open Source Data Analyzer come esempi per l’analisi dei report, non come elenco esaustivo di compatibilità.

In SFOS l’indirizzo del Collector può essere inserito come indirizzo IPv4, indirizzo IPv6 o FQDN. Questo non modifica il formato di esportazione: il firewall continua a inviare NetFlow v5. Questo formato non contiene campi per gli indirizzi IPv6 Source e Destination. Un indirizzo IPv6 del Collector riguarda quindi solo il trasporto verso il Collector e non rende il traffico utile IPv6 disponibile come flussi IPv6 nativi.

Nota sull’API: Il riferimento Configure Netflow di SFOS 23 documenta per NetflowServer i tipi di dati IPADDRESS e DOMAIN e un massimo di 255 caratteri. Il riferimento di SFOS 22 elenca anche STRING e non specifica una lunghezza massima per questo campo. Si tratta di una differenza nei metadati documentati dell’API, non di una prova di accettazione illimitata in SFOS 22 o di valori ora rifiutati in SFOS 23. Non consente di dedurre né una validazione in WebAdmin né un comportamento verificato durante l’esecuzione.

Preparare il Collector e il percorso di rete

Prima di configurare il firewall, il Collector necessita di un listener NetFlow v5 attivo. Sophos utilizza per impostazione predefinita UDP 2055; è possibile usare un’altra porta UDP valida se firewall e Collector sono configurati allo stesso modo. È possibile inserire fino a cinque server NetFlow.

L’esempio utilizza:

• Nome del Collector: flow-collector-primary
• Indirizzo del Collector: 192.0.2.50
• Trasporto: UDP
• Porta del Collector: 2055
• Regola di test: LAN_Test_to_WAN_HTTPS

192.0.2.50 è un indirizzo riservato alla documentazione e non può essere utilizzato come Collector reale. Nell’esempio mostra soltanto quale campo si intende. Deve essere inserito l’indirizzo IP reale o il FQDN del Collector sul quale è in esecuzione il listener v5 e che il firewall può raggiungere attraverso il percorso di rete previsto. Prima vanno chiariti questi punti:

• Il Collector supporta NetFlow v5 ed è effettivamente in ascolto su UDP 2055.
• Il firewall dispone di una route verso il Collector; se si utilizza un FQDN, deve funzionare anche il DNS.
• I componenti intermedi e l’Host Firewall del Collector consentono la porta UDP.
• Il Collector assegna l’indirizzo Source effettivamente utilizzato al firewall corretto.
• Sono definiti lo scopo, i diritti di accesso e il periodo di conservazione dei dati di flusso.

L’esportazione NetFlow è traffico di sistema generato dal firewall. Una regola firewall client non controlla questa esportazione. Sono rilevanti il percorso del traffico di sistema, il routing, il DNS in caso di FQDN e i filtri tra firewall e Collector.

⚠️ I riferimenti NetFlow esaminati non descrivono impostazioni TLS o di autenticazione e non costituiscono un inventario completo delle opzioni disponibili. I dati di flusso possono rivelare indirizzi interni, partner di comunicazione, porte, orari e volumi. Il Collector dovrebbe quindi essere raggiungibile tramite una rete di management affidabile o un percorso VPN protetto.

Esempio: preparare PRTG come Collector

In PRTG è la Probe a ricevere i flussi, non automaticamente il server web centrale. L’esempio seguente presuppone la presenza di una Probe locale o remota. Il sensore NetFlow v5 non supporta una Probe cluster; con PRTG Hosted Monitor è necessaria una Probe remota.

1. Aggiungere un sensore NetFlow v5 sulla Probe prevista.
2. Inserire 2055 in Receive Packets on UDP Port.
3. In Receive Packets on IP Address, selezionare l’indirizzo reale della Probe da inserire in SFOS come destinazione del Collector.
4. In Sender IP Address, inserire l’indirizzo sorgente effettivamente osservato per l’esportazione dal firewall. Un campo vuoto accetta dati da qualsiasi mittente su questa porta e non costituisce quindi un’alternativa permanente adeguata a un’associazione corretta.
5. Per il primo test, lasciare vuoti Include Filter ed Exclude Filter, in modo che nessun filtro del Collector escluda il flusso di riferimento. Consentire la ricezione sull’host della Probe solo dagli esportatori necessari.

Dopo il test di esportazione, confrontare Top Talkers, Top Connections e Top Protocols con i valori di test annotati. Se i pacchetti UDP arrivano all’host della Probe ma non compaiono risultati di analisi, verificare prima l’indirizzo di ricezione, il filtro dei mittenti e i filtri Include/Exclude. Lo stato Unknown può comparire allo scadere di Active Flow Timeout (Minutes) in assenza di nuovi dati di flusso. Da solo non dimostra un errore del firewall; qui non viene indicato per SFOS alcun timeout di esportazione non confermato.

Configurare il Collector NetFlow

1. Aprire System > Administration > Netflow in WebAdmin.
2. Fare clic su Add.
3. Inserire flow-collector-primary in Server name.
4. Inserire 192.0.2.50 in Netflow server IP/domain.
5. Inserire 2055 in Netflow server port.
6. Salvare con Save.

È possibile aggiornare anche le voci dei server NetFlow esistenti. Dopo una modifica, ripetere il test controllato dell’esportazione descritto di seguito: verificare separatamente la corrispondenza della regola, il trasporto UDP e la decodifica v5.

La schermata non offre alcun test di connessione documentato. Una voce salvata conferma quindi soltanto la configurazione, non il trasporto o la decodifica nel Collector.

Attivare Rule Logging come fonte dati

NetFlow esporta solo le connessioni delle regole firewall in cui è attivo Log firewall traffic. Questa impostazione si verifica nella regola appropriata in Rules and policies > Firewall rules.

Per il primo test dovrebbe essere utilizzata una regola chiaramente delimitata. Nell’esempio, LAN_Test_to_WAN_HTTPS elabora un test HTTPS da un client noto verso una Destination autorizzata. Non è importante il nome di esempio, ma che l’amministratore possa identificare senza ambiguità nel Log Viewer quale regola elabora effettivamente il flusso.

Creare correttamente le regole Sophos Firewall spiega come strutturare e registrare correttamente una regola. In caso di dubbi sulla corrispondenza, può essere utile Testare una regola con Log Viewer, Policy Tester e Packet Capture.

Testare l’esportazione in modo controllato

Il test separa tre domande: è stata applicata la regola corretta, un pacchetto UDP lascia il firewall e il Collector riesce a leggere il contenuto come NetFlow v5?

Prima di iniziare, definire una finestra di osservazione finita adatta all’ambiente locale e annotarne l’ora di fine. Le fonti esaminate non specificano una pianificazione dell’esportazione SFOS; l’esportazione potrebbe essere osservata solo dopo un ritardo rispetto alla fine della connessione. Durante la finestra, monitorare lo stato della cattura, l’utilizzo del buffer e l’elaborazione nel Collector. La cattura WebAdmin ha un buffer di 2048 KB e si arresta automaticamente quando è pieno, salvo che sia attivo Wrap capture buffer once full. Questa opzione mantiene la cattura attiva, ma sovrascrive i pacchetti precedenti. Salvare le evidenze necessarie prima che vadano perse e non considerare una cattura interrotta in anticipo o sovrascritta come un’osservazione continua.

1. Verificare nel Collector che il listener v5 sia in esecuzione su UDP 2055.
2. Annotare l’ora, il client di test, l’indirizzo di destinazione, la porta di destinazione e la regola firewall prevista.
3. In Diagnostics > Packet capture, fare clic su Configure, inserire dst host 192.0.2.50 and dst port 2055 in Enter BPF string, fare clic su Save e avviare la cattura con Trace On.
4. Generare un unico flusso di test identificabile e limitato dal client, ad esempio una richiesta HTTPS consentita, e terminare la connessione quando possibile. Annotarne l’ora di fine.
5. Verificare nel Log Viewer se è stata applicata LAN_Test_to_WAN_HTTPS o la Rule ID prevista.
6. Continuare l’osservazione fino alla fine della finestra prevista e cercare i pacchetti UDP diretti al Collector; poi interrompere la cattura con Trace Off.
7. Durante la stessa finestra, verificare se compare nel Collector un record v5 con i valori di origine e destinazione previsti e annotare il risultato. L’assenza di dati in una finestra breve non è conclusiva senza conoscere i tempi di esportazione; da sola non dimostra un errore di esportazione.

Per un ulteriore controllo in sola lettura, è possibile eseguire una breve acquisizione nella Device Console:

tcpdump 'host 192.0.2.50 and port 2055'

Sostituire 192.0.2.50 e 2055 con il Collector e la porta reali. Interrompere l’acquisizione con Ctrl+C. I pacchetti UDP visibili confermano il trasporto fino all’interfaccia osservata, ma non ancora che il Collector decodifichi i record come versione 5.

Un test riuscito è completo solo quando la corrispondenza della regola, il trasporto UDP e la decodifica v5 coincidono. In questo modo rimane anche chiaro in quale punto si verifica un errore.

Circoscrivere flussi mancanti o incompleti

Nessun pacchetto UDP verso l’indirizzo del Collector

Verificare l’indirizzo e la porta del Collector in System > Administration > Netflow. Controllare quindi il DNS in caso di FQDN, la route, l’interfaccia di uscita e i filtri sui componenti intermedi. Anche l’Host Firewall del Collector deve accettare UDP 2055.

Se vengono modificate contemporaneamente altre regole o percorsi di routing, è difficile attribuire il risultato. Occorre quindi iniziare con una regola registrata nota e un unico flusso di test.

I pacchetti UDP arrivano, ma il Collector non mostra nulla

Il listener deve elaborare espressamente NetFlow v5. Un ingresso configurato solo per NetFlow v9, IPFIX o sFlow può ricevere i pacchetti UDP senza mostrare flussi utilizzabili. Verificare i log del Collector, il parser e l’indirizzo Source previsto.

In questo caso, Packet Capture dimostra solo il trasporto. La decodifica riuscita deve essere visibile nel Collector stesso.

È visibile solo una parte delle connessioni

Verificare innanzitutto quale regola firewall elabora effettivamente il traffico mancante e se in tale regola è attivo Log firewall traffic. Un’altra regola potrebbe essere applicata prima del previsto. Anche la perdita di pacchetti UDP può causare lacune.

NetFlow v5 presenta limiti tecnici. L’assenza di nomi utente, Rule IDs, URL o nomi di applicazioni non è un errore di esportazione. Il formato non può inoltre rappresentare il traffico utile IPv6 con indirizzi IPv6 Source e Destination nativi; un indirizzo IPv6 del Collector non cambia questa limitazione.

L’indirizzo Source è inatteso

I riferimenti NetFlow esaminati non descrivono un’impostazione dedicata all’indirizzo sorgente dell’esportazione. Una Packet Capture limitata nel tempo mostra l’indirizzo effettivamente utilizzato quando si osservano pacchetti di esportazione. Confrontarlo con l’associazione e i filtri in ingresso del Collector; se è diverso da quello previsto, controllare poi la route e l’interfaccia di uscita.

Failover HA o modifica del firmware

I riferimenti esaminati non stabiliscono garanzie di esportazione NetFlow senza interruzioni o duplicati durante un failover HA. Eseguire il failover solo come esercitazione operativa pianificata e autorizzata. Prima, durante il normale funzionamento, e dopo, usare lo stesso test limitato per verificare la ricezione dei record, eventuali lacune o duplicati, l’indirizzo sorgente e l’associazione al firewall corretto.

Dopo modifiche al firmware, al routing, al DNS, al Collector o alle regole, viene ripetuto lo stesso test documentato. Un breve flusso di riferimento è più affidabile dell’ipotesi che una voce NetFlow salvata continui a funzionare.

Operatività e privacy

Come i log del firewall, i dati NetFlow richiedono un responsabile e una conservazione definita. L’operatività dovrebbe coprire almeno questi punti:

• monitorare la ricezione sul Collector per ogni firewall e segnalare le interruzioni;
• documentare indirizzi Source, assegnazione delle interfacce e sincronizzazione dell’ora;
• limitare l’accesso ai metadati di comunicazione interni;
• definire conservazione e cancellazione nel Collector;
• ripetere il test dopo modifiche a routing, HA, firmware o Rule Logging;
• verificare i flussi sospetti con Log Viewer o Packet Capture.

NetFlow mostra relazioni nel tempo, ma non dimostra la causa di una connessione bloccata o lenta. Per una sessione specifica rimangono decisivi Rule ID, NAT ID, percorso dei pacchetti e funzioni di sicurezza coinvolte.

Annullare la modifica

Per interrompere l’esportazione, eliminare il server interessato in System > Administration > Netflow. Verificare quindi, con lo stesso filtro Packet Capture ristretto, che non vengano più inviati pacchetti UDP a quel Collector. Ripristinare Log firewall traffic solo allo stato precedente: disattivarlo non interrompe soltanto NetFlow per quella regola, ma impedisce anche nuove voci nel log del firewall.

Domande frequenti