Configurare il monitoraggio sFlow su Sophos Firewall

Con il monitoraggio sFlow, Sophos Firewall può inviare campioni di traffico a un collector esterno. Picchi di volume, flussi insoliti, destinazioni inattese e distribuzione del carico sulle interfacce diventano così più facili da individuare rispetto ai singoli log in tempo reale. La funzione è disponibile in 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.

Se al posto dei campioni di interfaccia servono record NetFlow v5 provenienti da regole firewall con logging attivo in modo mirato, è più adatto Configurare e testare NetFlow su Sophos Firewall. Se invece uno switch deve inviare passivamente al firewall un flusso di pacchetti replicato, Discover Mode con TAP e SPAN è il modello adatto e chiaramente separato.

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 in una pagina WebAdmin. In WebAdmin con SFOS 22, aprire il menu del nome utente (ad esempio admin) in alto a destra e scegliere Console; con SFOS 23, fare clic nello stesso punto sull’icona dell’account Account icon e scegliere Command line. In entrambe le versioni, scegliere quindi 4. Device Console ed eseguire system sflow. L’Advanced Shell non è la console corretta. L’articolo Troubleshooting di Sophos Firewall: servizi e log spiega la differenza.

Se si usa un client SSH, aprire Administration > Device access > Local service ACL, consentire SSH dalla zona sorgente necessaria e fare clic su Apply. Non aprire un’intera zona senza motivo: una Local service ACL exception rule è più restrittiva quando devono accedere solo host di gestione specifici. Verificare l’accesso esistente alla console o via SSH prima di modificare sFlow, non quando serve già il rollback.

Flusso minimo

La configurazione vera e propria è breve. La cosa importante è pianificare prima il percorso di monitoraggio e solo dopo attivare sFlow:

1. Definire collector, porta e percorso di rete.
2. Selezionare un’interfaccia hardware per il primo pilota.
3. Eseguire prima system sflow show per verificare se sono già configurati vecchi collector o interfacce di monitoraggio.
4. Configurare la Sampling Rate e, facoltativamente, l’intervallo di polling.
5. Usare system sflow show per verificare che collector e interfaccia siano configurati correttamente.
6. Attivare sFlow con system sflow on.
7. Nel collector, controllare che i dati arrivino dall’IP agente previsto del firewall.

Le sezioni seguenti spiegano i singoli passaggi e i limiti operativi.

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.

In SFOS 22, l’agente usa l’indirizzo IP di un’interfaccia hardware. In SFOS 23, questa è la scelta automatica quando non è configurato un IP agente con agent-ip. La guida di SFOS 22, tuttavia, non specifica quale indirizzo venga scelto quando sono disponibili più interfacce idonee. Non dedurre quindi l’IP dell’agente solo dal routing o dal nome dell’interfaccia. Dopo l’attivazione, identificare e documentare l’IP effettivamente ricevuto dal collector; eventuali allowlist del collector devono basarsi su questa osservazione.

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 di produzione peggiorano, non modificare contemporaneamente Sampling Rate, collector, routing e regole firewall. Prima disattivare sFlow o rimuovere l’interfaccia interessata dal monitoraggio, poi misurare di nuovo.

Per un primo pilota con i valori dell’esempio senza modificare l’identità dell’agente, il rollback è il seguente. Questo blocco non ripristina un’identità configurata con agent-ip; resta valida la limitazione del passaggio facoltativo di SFOS 23:

system sflow off
system sflow monitor delete interface-name Port1
system sflow collector delete ip-address 192.0.2.10 port 6343
system sflow polling-interval 60
system sflow show

In questo modo vengono rimosse solo le voci create nell’esempio e l’intervallo di polling viene ripristinato al valore predefinito documentato di 60 secondi. Se sFlow era già configurato, il blocco non è un rollback generale. Rimuovere soltanto le proprie aggiunte, ripristinare l’intervallo di polling e lo stato on/off annotati in precedenza con system sflow show, quindi eseguire di nuovo il comando per verificare lo stato finale. Se SSH è stato abilitato solo per questo progetto pilota, ripristinare anche la Local service ACL o la regola di eccezione precedentemente documentata senza rimuovere altri accessi di amministrazione.

Aggiungere un sFlow Collector

Per prima cosa, viene definito il collector. Se non è prevista un’altra porta, sFlow usa tipicamente 6343. Sophos consente valori porta da 1 a 65535; il default documentato è 6343. In ambienti produttivi, la porta deve comunque corrispondere al collector utilizzato e alle regole firewall sul percorso.

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

Facoltativo: impostare l’identità dell’agente in SFOS 23

Questo passaggio vale solo per SFOS 23; il flusso esistente di SFOS 22 resta invariato. Con agent-ip si può specificare un IP unicast valido come identità sFlow del firewall nel collector. È consentito un solo IP agente configurato per firewall. Non è l’indirizzo di destinazione del collector. Senza un’identità configurata, SFOS 23 usa automaticamente un IP di interfaccia hardware.

⚠️ Prima di modificare qualsiasi cosa, salvare la configurazione iniziale con system sflow show, incluso un eventuale IP agente esistente. Un’identità diversa può cambiare l’attribuzione e i filtri di identità nel collector. Non sostituire alla cieca un’identità esistente; confermare prima la procedura per la versione installata. La descrizione di SFOS 23 è contraddittoria sulla cancellazione: il riepilogo della sintassi richiede un indirizzo IP, mentre la descrizione dettagliata e l’esempio lo omettono. Qui non viene quindi fornito alcun comando di cancellazione né un rollback completo per una nuova identità configurata. Se è necessario tornare in modo affidabile all’identità automatica, saltare questo passaggio facoltativo finché la sintassi di cancellazione non sarà chiarita da una fonte autorevole per la versione installata. system sflow off interrompe l’esportazione, ma non dimostra che l’identità precedente sia stata ripristinata.

Solo dopo queste verifiche preliminari e in assenza di un’identità già configurata, si può adattare questo esempio nella Device Console:

system sflow show
system sflow agent-ip add 192.0.2.20
system sflow show

192.0.2.20 è un valore di documentazione: sostituirlo con un IP unicast valido destinato a identificare senza ambiguità il proprio firewall nel collector. 192.0.2.10 rimane la destinazione separata del collector nell’esempio. L’identità dell’agente non garantisce l’indirizzo sorgente UDP, il routing, l’assegnazione di interfaccia o il comportamento delle ACL di trasporto; verificare separatamente il percorso di rete.

Controllare la configurazione dopo la modifica e, dopo l’attivazione, confrontare l’IP agente realmente decodificato dal collector nei dati sFlow con il valore previsto. Adattare i filtri di identità solo sulla base di questa osservazione. In caso di differenza, verificare prima la configurazione e la decodifica del collector, senza improvvisare altre modifiche di identità. Ricontrollare ricezione e attribuzione anche dopo un failover HA; la stabilità dell’identità durante un cambio di ruolo non è garantita.

Configurare interfaccia e Sampling Rate

Successivamente, si stabilisce quale interfaccia monitorare e con quale Sampling Rate selezionare i pacchetti. In SFOS 22, l’agente sFlow usa un IP di interfaccia hardware; in SFOS 23, ciò vale solo senza una agent-ip configurata. Nel collector può quindi comparire un IP di interfaccia hardware, anche se l’analisi effettiva riguarda una VLAN o un alias sotto quella porta.

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; il default è 60 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. Per impostazione predefinita, sFlow è disattivato:

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

Controllare prima system sflow show, quindi l’IP del collector, la porta e il percorso di rete. Sul collector verificare se i pacchetti sFlow in ingresso vengono scartati o filtrati in base a un IP agente errato. Se il firewall ha più indirizzi IP su interfacce hardware, non presumere in anticipo quale sarà l’IP dell’agente.

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 ad 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