Configurare il monitoraggio sFlow su Sophos Firewall

Con il monitoraggio sFlow, un Sophos Firewall può inviare campioni di traffico a un collector esterno. Ciò consente di vedere meglio picchi di volume, flussi anomali, destinazioni insolite o distribuzione del carico su interfacce rispetto ai singoli log live. Sophos ha aggiunto sFlow come funzione di monitoraggio con Sophos Firewall v22.

La funzione è particolarmente interessante per il troubleshooting, la pianificazione della capacità e il monitoraggio della sicurezza. Tuttavia, sFlow non sostituisce né il Log viewer né Packet Capture o una corretta conservazione dei log tramite Central Firewall Reporting o Syslog. sFlow risponde a domande diverse: non “quale regola è stata esattamente applicata?”, ma “quali flussi di traffico passano attraverso questa interfaccia e come si distribuiscono?”. Per lo stato dell’hardware, temperatura, ventole, alimentatori e PoE, invece, è adatto il monitoraggio hardware SNMP.

Quando sFlow è utile

sFlow è utile quando è presente un collector esterno o un sistema di monitoraggio e si desidera rendere visibili i modelli di traffico nel tempo.

Casi d’uso tipici:

• Rilevare picchi di larghezza di banda inaspettati su interfacce WAN, LAN o core.
• Migliorare la comprensione del traffico tra VLAN o sedi.
• Supportare la pianificazione della capacità per firewall, uplink o switching core.
• Trovare flussi sospetti come punto di partenza per ulteriori analisi.
• Confrontare i dati di monitoraggio con i log del firewall, Central Reporting o dati SIEM.

Se si desidera verificare solo una singola connessione, sFlow spesso non è lo strumento giusto. Per test di performance mirati è più adatto iPerf. Per problemi di connessione concreti, Log Viewer, Policy Test e Packet Capture sono solitamente più veloci.

Prerequisiti

Per sFlow è necessario:

• Sophos Firewall con SFOS 22.0 o successivo.
• Accesso amministrativo alla Device Console.
• Un collector sFlow raggiungibile, ad esempio un NMS, SIEM o strumento di analisi dei flussi.
• Una rete sicura tra firewall e collector.
• Una decisione chiara su quali interfacce hardware monitorare.

La configurazione non avviene nell’interfaccia WebAdmin normale, ma tramite la Device Console con system sflow. La Advanced Shell non è il luogo giusto per questo. La distinzione tra Device Console e Advanced Shell è spiegata nell’articolo Sophos Firewall Troubleshooting: Services e Logs.

Limiti importanti prima dell’attivazione

sFlow sembra innocuo, ma può avere impatti su operatività e sicurezza.

sFlow non è crittografato

Il traffico sFlow dal firewall al collector non è crittografato. Pertanto, il collector dovrebbe essere raggiungibile tramite una rete di gestione affidabile, una rete di monitoraggio interna o un percorso protetto in altro modo.

⚠️ sFlow non dovrebbe essere inviato senza protezione su reti non sicure. I dati di flusso possono rendere visibili indirizzi IP interni, relazioni di comunicazione e sistemi di destinazione.

FastPath viene disattivato sull’interfaccia monitorata

Quando sFlow è attivo su un’interfaccia, Fast Path viene disattivato su quell’interfaccia. Questo è particolarmente importante per interfacce WAN, LAN o core molto caricate.

Prima dell’attivazione, si dovrebbe verificare:

• Quanto è carica l’interfaccia?
• Vi è traffico ad alta velocità produttivo?
• C’è una finestra di manutenzione per il primo test?
• È possibile confrontare le prestazioni prima e dopo l’attivazione?

Per una comprensione di base delle prestazioni del firewall, l’articolo Comprendere correttamente i dati sulle prestazioni di Sophos Firewall è utile.

Cluster HA: sFlow funziona solo sul Primary

In un cluster HA, l’agente sFlow funziona sul Primary. Questo deve essere considerato nelle valutazioni e nei test di failover. Dopo un cambio di ruolo, si dovrebbe verificare se il collector continua a ricevere dati e se l’IP dell’agente rimane come previsto.

Per la pianificazione del funzionamento HA e del monitoraggio, è utile Configurare l’alta disponibilità di Sophos Firewall.

Pianificare interfaccia e collector

sFlow viene configurato su interfacce hardware. Anche le interfacce dipendenti come alias e VLAN dell’interfaccia hardware scelta possono essere visibili nei campioni. La selezione dell’interfaccia dovrebbe quindi sempre corrispondere al percorso di traffico effettivo, non solo al nome della VLAN o alla valutazione desiderata nel collector.

Questo è pratico, ma può portare a interpretazioni errate:

• Se si monitora Port1, anche le interfacce VLAN o alias associate possono essere visibili nel campionamento.
• Se interessa solo una specifica VLAN, è necessario filtrare correttamente nel collector.
• Se esistono più porte core o WAN, non si dovrebbero attivare immediatamente tutte le interfacce.
• Nei design LAG, Bridge o VLAN, dovrebbe essere chiaro in anticipo dove scorre effettivamente il traffico rilevante.

La base pulita per questo è una pianificazione comprensibile delle interfacce e delle zone. L’articolo Configurare zone e interfacce di Sophos Firewall aiuta a classificare interfacce fisiche, VLAN, Bridge, LAG e RED.

Pianificare pilota, privacy e ritorno

Prima della prima attivazione, sFlow dovrebbe essere trattato come una modifica di monitoraggio produttiva. La funzione genera dati aggiuntivi, modifica FastPath sull’interfaccia monitorata e invia informazioni sui flussi a un altro sistema. Pertanto, non basta inserire solo l’IP del collector e la Sampling Rate.

Prima del pilota, questi punti dovrebbero essere chiari:

• Quale problema concreto dovrebbe risolvere sFlow: pianificazione della capacità, picchi di larghezza di banda, monitoraggio della sicurezza o ricerca guasti?
• Chi gestisce il collector e chi può vedere i dati di flusso?
• Per quanto tempo vengono conservati i dati di flusso?
• Attraverso quale percorso di rete i pacchetti sFlow raggiungono il collector?
• Quale interfaccia verrà testata per prima?
• Quali valori di misurazione sono considerati baseline prima dell’attivazione?
• Quando sFlow verrà disattivato o spostato su un’altra interfaccia?

I dati di flusso possono rendere visibili indirizzi IP interni, relazioni di comunicazione, sistemi di destinazione, porte e volumi di traffico. Questi dati sono quindi meno dettagliati di un Packet Capture completo, ma comunque rilevanti per operatività e sicurezza. Se il collector è collegato a un SIEM o a una piattaforma di monitoraggio centrale, la responsabilità dovrebbe essere chiarita in modo simile a Inviare Syslog di Sophos Firewall a SIEM.

Per il primo test è utile un pilota limitato:

1. Documentare lo stato iniziale: carico dell’interfaccia, carico della CPU, servizi interessati, dati di monitoraggio esistenti.
2. Selezionare un’unica interfaccia non massimamente caricata.
3. Impostare la Sampling Rate in modo conservativo.
4. Verificare la ricezione del collector e la quantità di dati.
5. Osservare le prestazioni, la latenza e il throughput dopo l’attivazione.
6. Testare il ritorno: system sflow off o rimuovere l’interfaccia di monitoraggio.

Il ritorno dovrebbe essere chiaro prima dell’attivazione. Se le prestazioni su un’interfaccia produttiva peggiorano, non si dovrebbero modificare contemporaneamente Sampling Rate, collector, routing e regole del firewall. Prima disattivare sFlow o rimuovere l’interfaccia interessata dalla sorveglianza con system sflow monitor delete interface-name ..., poi misurare nuovamente.

Aggiungere un sFlow Collector

Per prima cosa, viene definito il collector. La porta standard per sFlow è spesso 6343; in ambienti produttivi, la porta deve corrispondere al collector utilizzato.

Esempio:

system sflow collector add ip-address 192.0.2.10 port 6343

Sophos supporta fino a cinque collector. Ogni collector viene aggiunto separatamente.

Lo stato attuale può essere verificato successivamente:

system sflow show

Se si desidera rimuovere un collector:

system sflow collector delete ip-address 192.0.2.10 port 6343

Configurare interfaccia e Sampling Rate

Successivamente, si stabilisce quale interfaccia monitorare e con quale Sampling Rate selezionare i pacchetti.

Esempio:

system sflow monitor add interface-name Port1 sampling-rate 1000

La Sampling Rate determina con quale frequenza i pacchetti vengono selezionati come campioni. Un numero più basso genera più campioni e quindi più dettagli, ma anche più carico e più dati sul collector. Un numero più alto riduce la quantità di dati, ma può rendere meno visibili flussi brevi o piccoli.

I limiti rilevanti sono:

Per iniziare, è consigliabile un valore conservativo, ad esempio 1000 o superiore. Successivamente, si dovrebbe verificare nel collector se la quantità di dati, il livello di dettaglio e le prestazioni corrispondono all’obiettivo.

Un’interfaccia di monitoraggio può essere rimossa:

system sflow monitor delete interface-name Port1

Impostare l’intervallo di polling

Oltre al Packet Sampling, sFlow può anche interrogare statistiche e contatori di interfaccia a intervalli. Sophos consente un intervallo di polling tra 30 e 300 secondi. Con 0 il polling viene disattivato.

Esempio:

system sflow polling-interval 80

Disattivare il polling:

system sflow polling-interval 0

Per la maggior parte degli ambienti, è consigliabile un intervallo medio. Intervalli troppo brevi generano più dati e non sono automaticamente più utili.

Attivare sFlow

Quando collector, interfaccia e polling sono pianificati, sFlow viene attivato:

system sflow on

Verificare lo stato:

system sflow show

Disattivare sFlow:

system sflow off

Dopo l’attivazione, non si dovrebbe solo controllare il firewall, ma anche il collector. Lì devono arrivare dati dall’IP dell’agente del firewall e devono essere risolti in modo sensato.

Validazione dopo l’attivazione

Dopo l’accensione, si dovrebbero verificare questi punti:

1. system sflow show mostra correttamente collector, interfaccia, Sampling Rate e stato.
2. Il collector riceve dati sFlow dall’IP del firewall previsto.
3. L’ora su firewall e collector è corretta.
4. I nomi delle interfacce e la direzione del flusso sono comprensibili nel collector.
5. Il carico su firewall e collector rimane non critico.
6. La quantità di dati corrisponde alla conservazione e all’elaborazione pianificate.
7. Il percorso di ritorno definito è stato testato una volta o almeno documentato come comando concreto.
8. Nei cluster HA, dopo un failover si verifica se i dati continuano ad arrivare.

Se si analizzano contemporaneamente regole del firewall, NAT, VPN o TLS Inspection, sFlow non dovrebbe essere considerato isolatamente. Per decisioni di connessione concrete, Log Viewer e Packet Capture rimangono fondamentali. Per valutazioni a lungo termine, si dovrebbe verificare se sono necessari anche Syslog o Central Reporting.

Risoluzione dei problemi

Nessun traffico nel collector

Prima controllare system sflow show. Poi verificare se IP del collector, porta, routing e regole del firewall corrispondono al collector. Inoltre, si dovrebbe controllare sul collector se la porta UDP è raggiungibile e se i pacchetti sFlow in arrivo vengono scartati.

Solo una parte del traffico è visibile

sFlow lavora con il campionamento. È normale che non ogni singolo pacchetto sia visibile. Se mancano flussi importanti, si può regolare la Sampling Rate o scegliere un’altra interfaccia. Con VLAN e alias, si dovrebbe verificare se l’interfaccia hardware corretta è monitorata.

Le prestazioni cambiano dopo l’attivazione

Se si monitora un’interfaccia molto utilizzata, la disattivazione di FastPath può essere rilevante. In questo caso, sFlow dovrebbe essere disattivato per test e le prestazioni confrontate. Per interfacce core o WAN produttive, un test pianificato è migliore di un’attivazione spontanea.

I dati HA sembrano incompleti

In ambienti HA, l’agente sFlow funziona sul Primary. Dopo un failover, si dovrebbe verificare quale firewall è attualmente Primary, quale IP viene utilizzato come IP dell’agente e se il collector continua a assegnare correttamente i dati.

Lista di controllo operativa

• Posizionare il collector in una rete sicura.
• Documentare proprietario, scopo, accesso e conservazione dei dati di flusso.
• Verificare porta UDP e routing verso il collector.
• Iniziare con una o poche interfacce.
• Raccogliere baseline prima e dopo per carico dell’interfaccia, CPU, latenza e throughput.
• Scegliere la Sampling Rate in modo conservativo e poi adattarla.
• Considerare l’impatto di FastPath su interfacce critiche.
• Documentare il ritorno: system sflow off o rimuovere l’interfaccia di monitoraggio.
• Testare il failover HA se sFlow viene utilizzato nel cluster.
• Confrontare i dati di flusso con Log Viewer, Packet Capture e Reporting.
• Verificare regolarmente se i dati vengono ancora valutati o solo raccolti inutilmente.

FAQ