Interpretare correttamente i dati sulle prestazioni di Sophos Firewall

I dati sulle prestazioni di un Sophos Firewall sono importanti per il dimensionamento, ma spesso vengono interpretati erroneamente. Il massimo throughput del firewall nel datasheet non è automaticamente la prestazione che un sito raggiunge con IPS, Web Protection, ispezione TLS, VPN, NAT, reporting e molti utenti simultanei.

Per scegliere un modello, non si dovrebbe guardare solo a un singolo numero in Gbit/s. È cruciale quali funzioni di protezione sono attive, quale traffico attraversa il firewall e quali riserve l’ambiente necessita quotidianamente. La Guida al dimensionamento di Sophos Firewall spiega la scelta del modello; questo articolo spiega come interpretare le metriche di prestazione sottostanti.

Regola pratica per il dimensionamento

Nella pratica, spesso il puro throughput del firewall non è il miglior punto di partenza.

• Solo routing e semplici regole firewall: Considerare throughput del firewall e IMIX.
• Rete aziendale normale con IPS e Application Control: Dare maggiore peso ai valori NGFW o Threat Protection.
• Molte connessioni HTTPS con decrittazione: Pianificare la capacità di ispezione TLS e la riserva della CPU.
• Molte connessioni VPN: Considerare separatamente i requisiti IPsec o Remote Access.
• Firewall virtuale: Prendere sul serio hypervisor, CPU, RAM, storage e schede di rete virtuali tanto quanto la licenza Sophos.

Se non è chiaro se sia meglio un hardware o un’appliance virtuale, Sophos Firewall - Hardware o appliance virtuale? può aiutare nella decisione.

Perché i valori del datasheet non bastano da soli

I valori di prestazione vengono determinati in condizioni di laboratorio definite. Questo è utile perché rende i modelli comparabili. Tuttavia, un ambiente produttivo si comporta diversamente:

• Le dimensioni dei pacchetti sono miste.
• Gli utenti generano sessioni parallele.
• I profili di sicurezza esaminano il traffico a profondità diverse.
• Il traffico HTTPS richiede molte più risorse con l’ispezione TLS.
• VPN, SD-WAN, NAT, logging e reporting funzionano in parallelo.
• WLAN, switch, client, server e provider influenzano le prestazioni percepite.

Un valore del datasheet è quindi un valore di confronto, non una promessa per ogni singolo flusso. Per un dimensionamento solido, si dovrebbe pianificare con riserve e considerare le funzioni operative future non solo dopo l’acquisto.

Le metriche più importanti

• Throughput del firewall: Confronto per traffico semplice Layer-3/Layer-4 Spesso letto come throughput Internet reale con tutte le funzioni di sicurezza
• Firewall IMIX: Miscela più realistica di diverse dimensioni di pacchetto Ignorato, sebbene le reti reali raramente abbiano solo pacchetti grandi
• Throughput IPS: Traffico con Intrusion Prevention Sottovalutato se l’IPS è attivo per molte regole
• Throughput NGFW: Firewall con funzioni aggiuntive di nuova generazione come IPS e Application Control Confuso con il puro throughput del firewall
• Threat Protection: Valore di approssimazione più forte per funzioni di protezione attivate Inteso come valore minimo fisso anziché come metrica di confronto
• Ispezione TLS: Decrittazione e verifica HTTPS Dimenticata nel dimensionamento, sebbene possa essere molto intensiva in termini di risorse
• VPN IPsec: Collegamento di siti e tunnel crittografati Pianificato solo in base alla connessione Internet, senza considerare il punto finale, le dimensioni dei pacchetti e la CPU
• Sessioni e connessioni al secondo: Molti utenti, traffico web, pubblicazione server, connessioni brevi Raramente controllato, ma può essere rilevante con molti client o servizi pubblicati

Throughput del firewall e IMIX

Il puro throughput del firewall descrive un’elaborazione relativamente semplice del traffico. Questo valore è utile quando un firewall principalmente instrada, esegue NAT e gestisce regole firewall classiche.

IMIX è più vicino al carico di rete reale perché mescola diverse dimensioni di pacchetto. Questo è importante perché i pacchetti piccoli caricano un firewall in modo diverso rispetto ai grandi download. Nelle reti aziendali, raramente c’è solo un grande flusso di dati pulito. Accessi web, DNS, VoIP, applicazioni cloud, aggiornamenti e trasferimenti di file generano modelli diversi.

Per i siti con traffico utente normale, IMIX è quindi spesso più significativo del massimo valore più bello.

IPS, NGFW e Threat Protection

Non appena IPS, Application Control, Web Protection o la verifica del malware sono attivi, il firewall deve fare più che inoltrare pacchetti. Deve classificare il traffico, riconoscere modelli, applicare regole e, a seconda della policy, verificare i contenuti.

I termini vengono spesso confusi:

• IPS valuta il traffico in base a firme e regole per modelli di attacco noti.
• NGFW descrive le prestazioni del firewall con funzioni aggiuntive come IPS e Application Control.
• Threat Protection è un valore di approssimazione più forte per ambienti in cui sono attive più funzioni di protezione contemporaneamente.

Per un’azienda che utilizza effettivamente Sophos Firewall come Security Gateway, i valori NGFW e Threat Protection sono generalmente più rilevanti del puro throughput del firewall.

Pianificare realisticamente l’ispezione TLS

L’ispezione TLS è uno dei maggiori fattori di prestazione. Il firewall decrittografa le connessioni HTTPS, verifica il contenuto e crittografa nuovamente la connessione. Questo genera carico sulla CPU e può essere notevolmente percepibile a seconda della suite di cifratura, del server di destinazione, del client, delle eccezioni e della policy.

L’ispezione TLS non dovrebbe quindi essere attivata casualmente. È sensato un rollout graduale con un gruppo pilota, eccezioni, monitoraggio e una chiara ricerca degli errori. L’articolo Implementare correttamente l’ispezione TLS di Sophos Firewall descrive il processo operativo.

Anche il certificato CA deve essere distribuito correttamente. Per i client, Installare il certificato CA di Sophos Firewall per la scansione HTTPS è il punto di partenza appropriato.

Considerare separatamente le prestazioni VPN

Le prestazioni VPN non dipendono solo dal modello di firewall. Sono rilevanti anche il punto finale, la connessione Internet, la latenza, le dimensioni dei pacchetti, MTU/MSS, i parametri di crittografia, il routing e i tunnel paralleli.

Per le connessioni site-to-site, si dovrebbero stimare realisticamente i flussi di dati pianificati: trasferimenti di file, backup, ERP, VoIP, RDP, monitoraggio e replica si comportano diversamente. Per l’accesso remoto, si aggiungono anche il dispositivo client, WLAN, provider e client VPN.

Se una connessione VPN sembra lenta, non si dovrebbe controllare solo il valore del datasheet. Un test di percorso definito con iPerf è generalmente più significativo di un test di velocità del browser.

Cosa influenza le prestazioni reali

Nella pratica, diversi fattori agiscono contemporaneamente:

• profili di sicurezza attivi per regola firewall
• ispezione TLS ed eccezioni
• policy IPS e portata delle firme
• Web Protection, Application Control e verifica del malware
• NAT, DNAT, pubblicazione server e WAF
• IPsec, SSL VPN, Sophos Connect e tunnel site-to-site
• logging, reporting, Central Reporting e Syslog
• molte piccole sessioni invece di pochi grandi download
• accelerazione del firewall, FastPath, accelerazione IPsec e traffico che non può essere offloadato
• operatività HA, versione firmware e hotfix
• risorse virtuali per appliance software o cloud

Pertanto, le prestazioni dovrebbero sempre essere verificate nel contesto della policy concreta. Una regola firewall senza profili di sicurezza si comporta diversamente da una regola con IPS, filtro web, Application Control e ispezione TLS.

Interpretare correttamente FastPath e Offloading

I firewall Sophos moderni non elaborano ogni flusso di dati allo stesso modo. A seconda dell’appliance, del firmware, della regola, del profilo di sicurezza e del tipo di traffico, il traffico può essere parzialmente accelerato o verificato in un percorso di elaborazione più lento. Termini importanti per questo sono FastPath, accelerazione del firewall, accelerazione PKI e accelerazione IPsec.

La classificazione iniziale avviene comunque in SlowPath: il kernel e, dove applicabile, il motore DPI ispezionano la connessione. Al completamento dell’handshake TCP o dopo il passaggio di un pacchetto in ciascuna direzione, SFOS può inserire un flusso idoneo nella cache delle connessioni FastPath. FastPath non è quindi un bypass non ispezionato; elabora soltanto lo stato programmato dal kernel. I protocolli non idonei, come IP-in-IP, rimangono in SlowPath.

Per il dimensionamento questo è importante, perché un test veloce non dimostra che ogni flusso di produzione utilizzi lo stesso percorso. Sophos indica Firewall e IPsec Acceleration per tutte le appliance XGS. La PKI Acceleration dedicata all’elaborazione dei certificati dei flussi TLS ispezionati è documentata solo per XGS 4300, 4500, 5500, 6500, 7500 e 8500. I modelli desktop Gen. 2 XGS 88/88w, 108/108w, 118/118w e 128/128w usano Virtual FastPath nel kernel x86 invece di un Xstream Flow Processor dedicato.

I limiti sono più restrittivi per le appliance virtuali e software. Secondo la guida SFOS 22, Virtual FastPath è supportato solo con VMware ESXi e i driver NIC igc, e1000, e1000e e vmxnet3. VFP viene disattivato automaticamente su altri hypervisor, nei deployment cloud o con driver non supportati. Il firewall continua a funzionare, ma senza questo miglioramento FastPath. Per e1000 ed e1000e, Sophos indica una MTU massima di 3500 byte, e per gli altri driver supportati una MTU massima di 9000 byte. Sono limiti della piattaforma, non un motivo per attivare i jumbo frame senza un test end-to-end.

PKI Acceleration non accelera l’intera elaborazione TLS. Nei flussi TLS 1.2 e TLS 1.3 ispezionati dal motore DPI, trasferisce all’acceleratore soltanto l’operazione di rifirma dei certificati server X.509 con autenticazione RSA fino a 4096 bit. La cifratura simmetrica, il traffico web proxy e le connessioni SSL VPN terminate sul firewall non ne beneficiano.

Alcune funzioni o tipi di traffico possono limitare o impedire l’offloading, per esempio:

• SSL VPN
• WAF e traffico proxy
• QoS e DoS
• Wireless, RED, LAG e PPPoE
• traffico IP frammentato
• scenari specifici di bridge, HA o virtualizzazione

Per IPsec, lo stack XFRM trasferisce all’acceleratore incapsulamento, cifratura, decapsulamento e decifratura ESP in base alla SA di fase 2. Le SA che usano 3DES, BlowFish o MD5, le SA su interfacce virtuali come le VLAN e il traffico IPsec su interfacce VLAN o wireless non vengono offloaded. Il tunnel può comunque funzionare, ma in tal caso usa più CPU host.

Le policy di sicurezza non impediscono in modo assoluto l’offloading. Una regola senza IPS, web filtering, antivirus o application control può passare dopo l’handshake o i pacchetti iniziali; con application control, Sophos indica che la decisione avviene dopo circa otto pacchetti. Per STARTTLS con Don’t decrypt, avviene dopo circa 15 pacchetti. I primi pacchetti possono quindi essere ancora visibili in SlowPath anche se il flusso successivo viene accelerato.

Regola pratica: L’offloading non è un obiettivo di sicurezza. I profili di protezione e l’ispezione non vengono rimossi solo per raggiungere FastPath. Contano la protezione necessaria e misure riproducibili di throughput, CPU e applicazione.

Con HA bisogna guardare con particolare attenzione. Active-Active HA non supporta Firewall Acceleration. In Active-Passive HA, Firewall e IPsec Acceleration vengono usate solo dal nodo primario. Un dimensionamento HA quindi non dovrebbe semplicemente proiettare valori di laboratorio standalone su entrambi i nodi.

Anche il troubleshooting può influenzare le misurazioni. Con Packet Capture o iftop, per impostazione predefinita SFOS invia temporaneamente il traffico attraverso SlowPath. Se l’offloading rimane attivo durante la cattura, un Packet Capture standard non può registrare il traffico FastPath. Un pacchetto assente non dimostra quindi che il firewall non abbia elaborato il flusso; Sophos rimanda a Support quando serve una cattura FastPath. Le misurazioni delle prestazioni e i risultati della cattura vanno sempre documentati con orario, metodo di test, versione del firmware, tipo di interfaccia e policy attiva.

Le accelerazioni sono attive per impostazione predefinita sulle piattaforme supportate. L’attivazione o disattivazione di Firewall o PKI Acceleration riavvia IPS o il motore DPI; una modifica di IPsec Acceleration riavvia tutti i tunnel IPsec. Questi cambiamenti appartengono a una finestra di manutenzione, non a un test prestazionale improvvisato. Prima si conferma il sospetto con Log Viewer, Packet Capture, Risoluzione dei problemi IPsec e un caso di test chiaro.

Leggere e controllare correttamente PKI Acceleration

Lo stato configurato e quello effettivo non sono la stessa cosa. La configurazione si legge con:

show ips-settings

PKI Acceleration è attiva per impostazione predefinita sui modelli XGS supportati. enabled è effettivo solo se è in funzione anche Firewall Acceleration. Se PKI Acceleration è attiva ma Firewall Acceleration è disattivata, SFOS mostra enabled (inactive). Sulle versioni SFOS o sui modelli non supportati appare come disabled; modificare l’impostazione nella CLI non può fornire il supporto hardware o di piattaforma mancante.

L’impostazione globale si modifica tramite l’albero dei comandi IPS:

set ips pki-acceleration disable
set ips pki-acceleration enable

La modifica riavvia IPS o il motore DPI e deve quindi essere eseguita in una finestra di manutenzione. Prima si registrano il valore corrente e lo stato di Firewall Acceleration. In seguito si controllano nuovamente show ips-settings, lo stato di IPS e DPI e un flusso TLS reale decifrato dal motore DPI. Solo così si può verificare che la rifirma dei certificati, la latenza, la CPU e l’applicazione continuino a funzionare correttamente. Se l’effetto previsto non si verifica, si ripristina il valore documentato in precedenza.

Verificare IPsec Acceleration in modo controllato

Leggere prima lo stato globale:

system ipsec-acceleration show

IPsec Acceleration è enabled per impostazione predefinita e sposta dal SlowPath le SA di fase 2 idonee. Uno stato globale attivo non dimostra che una SA specifica sia offloaded. 3DES, BlowFish e MD5 sono esclusi e restano validi i limiti di interfaccia e piattaforma descritti sopra.

La modifica si applica all’intero firewall e riavvia tutti i tunnel IPsec. disable non è quindi un test per un singolo tunnel. Se un errore chiaro giustifica un test A/B, documentare prima stato dei tunnel, SA, CPU, throughput e traffico di test. Nella finestra di manutenzione sono disponibili queste due modifiche opposte:

system ipsec-acceleration disable
system ipsec-acceleration enable

Dopo ogni modifica effettivamente eseguita, verificare di nuovo show, creazione dei tunnel, SA di fase 2, routing, regole e traffico reale in entrambe le direzioni. Senza un miglioramento riproducibile, ripristinare il valore originale. Non mantenere un profilo crittografico obsoleto solo per rendere possibile un confronto delle prestazioni.

Cambiare Firewall Acceleration solo in una finestra di manutenzione

Per prima cosa si legge lo stato corrente nella Device Console:

system firewall-acceleration show

Sulle piattaforme supportate, Firewall Acceleration è in enable per impostazione predefinita. Secondo Sophos, ogni modifica causa un’interruzione e riavvia IPS o il motore DPI. disable non è quindi un test A/B occasionale durante la produzione. Il firewall continua a elaborare tutto il traffico, ma senza i vantaggi prestazionali di FastPath.

Per una modifica pianificata sono disponibili questi due comandi. Non vengono eseguiti immediatamente uno dopo l’altro come blocco di prova, perché ogni transizione può interrompere nuovamente il traffico:

system firewall-acceleration disable
system firewall-acceleration enable

Dopo ogni transizione realmente necessaria si controllano di nuovo show, stato IPS e DPI, nuove sessioni, servizi pubblicati, VPN, throughput, CPU e Log Viewer. Un valore disabled visualizzato non viene sovrascritto alla cieca con enable: DoS, HA active-active, FastPath non caricato o una combinazione non supportata di VM, hypervisor o driver NIC possono impedire l’accelerazione. enable non può forzare un FastPath funzionante su una piattaforma tecnicamente non supportata.

Verificare le prestazioni in esercizio

I valori del datasheet aiutano prima dell’acquisto. In esercizio, sono necessari altri strumenti. È importante distinguere i concetti: il Control Center non mostra la performance del datasheet, ma indicatori operativi attuali. Il riquadro Performance si basa sul load average distribuito sui core CPU. Valori superiori al numero di core disponibili significano che in quel momento c’è più lavoro in coda di quanto il sistema possa elaborare.

Il colore del riquadro segue soglie Sophos fisse: Normal con un load average inferiore a 2, Warning da 2 a 5 e Alert oltre 5 core CPU. Questo semaforo è un indicatore rapido, ma non coincide con la soglia di sovraccarico specifica dell’appliance. Lo stato del riquadro deve quindi essere interpretato insieme al numero effettivo di core e all’andamento temporale.

Sono inoltre rilevanti CPU, memoria, bandwidth, sessions, Decryption Capacity e Decrypt Sessions. Decryption Capacity è particolarmente utile con TLS Inspection, perché mostra quanto la decifratura SSL/TLS attuale utilizza la capacità di decifratura disponibile. I dettagli di decryption non vengono aggiornati come misura live al secondo, ma tipicamente ogni cinque minuti. Questi valori vanno sempre letti insieme a policy, regola, profilo di sicurezza, ora e tipo di traffico.

Usare System Graphs come sequenza temporale

In Diagnostics > System graphs è possibile confrontare CPU Usage, Memory Usage, Load Average, Disk Usage, Live Users, Data Transfer Speed through WAN Zone e le singole interfacce su intervalli di tempo diversi. Si seleziona prima il periodo dell’incidente e poi solo i grafici pertinenti alla funzione interessata.

Un picco è una correlazione, non ancora una causa. CPU, memoria o load average devono quindi essere confrontati con il traffico delle interfacce, il numero di utenti, i log, la policy e l’ora esatta del test. L’andamento è particolarmente utile per distinguere un breve valore anomalo da un carico elevato ricorrente o persistente; da solo non dimostra né che l’appliance sia sottodimensionata né che un servizio specifico sia guasto.

Leggere correttamente unità e aggregazione

Il grafico CPU separa l’utilizzo da parte dei processi utente, dei componenti di sistema e il tempo inattivo rimanente. Memory mostra Used, Free e Total in MB. Load Average, invece, non è una percentuale: le tre curve rappresentano le medie su uno, cinque e quindici minuti. Va quindi interpretato insieme al numero di core CPU disponibili.

Disk Usage mostra la percentuale occupata da firme, file di configurazione, report e dati temporanei. È una suddivisione funzionale del grafico e non la stessa vista delle partizioni mostrate da df -kh o del watermark dei report. Live Users conta gli utenti connessi a Internet nel periodo selezionato e mostra inoltre minimo, massimo e media. Non è il numero di account utente configurati.

Per la zona WAN sono disponibili grafici separati per upload e download, per la velocità totale combinata e per la velocità di ciascun gateway. A seconda della vista vengono mostrati i valori corrente, minimo, massimo e medio. Sophos documenta un importante errore di etichettatura: WebAdmin mostra KBps, ma i valori sono in realtà espressi in kbit/s. Leggerli come kilobyte al secondo introduce un errore di fattore otto.

Importante per le VLAN: Sono disponibili grafici di interfaccia separati per interfacce fisiche, Wireless LAN, interfacce WAN e interfacce VLAN nella zona WAN. Le VLAN in altre zone vengono aggregate nel grafico dell’interfaccia fisica principale. Un picco sulla porta principale non può quindi essere attribuito a una singola VLAN interna senza un’ulteriore misurazione.

I grafici delle interfacce mostrano bit ricevuti e trasmessi, oltre a drop, errori e collisioni. La risoluzione viene aggregata per periodi più lunghi: oggi e ieri usano medie di cinque minuti, la settimana di 15 minuti, il mese di sei ore e l’anno di un giorno. I picchi brevi possono quindi scomparire nelle viste mensili o annuali; per un incidente si sceglie prima il periodo adatto più breve.

Procedura pratica:

1. Controllare il Control Center: Monitorare CPU, RAM, utilizzo delle interfacce e avvisi.
2. Aprire il Log Viewer: La regola firewall prevista viene applicata e il logging è attivato?
3. Controllare policy e profili di sicurezza: Quali funzioni influenzano il traffico interessato?
4. Utilizzare Packet Capture: Si vedono pacchetti, pacchetti di risposta, NAT e drop?
5. Eseguire un test di percorso: Verificare con iPerf o un download definito quale percorso è veramente lento.
6. Annotare il contesto di offloading: Tipo di interfaccia, modalità HA, tipo di VPN, PPPoE, WAF, SSL VPN o Packet Capture possono influenzare la misurazione.
7. Annotare il momento: Picchi di carico, backup, aggiornamenti o report possono falsare i risultati.

Per una rapida delimitazione della connessione WAN, Eseguire un test di velocità Internet di Sophos Firewall tramite SSH è utile. Per test end-to-end tra due sistemi, Testare le prestazioni di Sophos Firewall con iPerf è più adatto. Se una regola non viene applicata come previsto, Testare le regole di Sophos Firewall in modo mirato è appropriato.

La checklist quotidiana di amministrazione di Sophos Firewall mostra come riunire Control Center, System graphs, report ed eventi amministrativi in una breve procedura ricorrente.

Errori tipici di dimensionamento

• Si confronta solo il massimo throughput del firewall.
• L’ispezione TLS viene pianificata, ma non viene inclusa nella riserva di prestazioni.
• VPN e Remote Access vengono valutati in base al numero di utenti anziché all’uso reale.
• Si considera la connessione Internet, ma non il traffico interno Est-Ovest.
• I firewall virtuali vengono eseguiti su host sovraccarichi.
• Reporting, logging e connessione Central vengono considerati solo successivamente.
• Crescita, nuovi siti, VLAN aggiuntive o pubblicazione server mancano nella pianificazione.
• Non si fa distinzione tra valore di laboratorio, valore reale ed esperienza utente.

Lista di controllo pratica per il dimensionamento

Prima di scegliere un modello, questi punti dovrebbero essere chiariti:

1. Larghezza di banda Internet attuale e pianificata nei prossimi anni.
2. Numero di utenti, dispositivi, server e siti.
3. Percentuale di traffico web, applicazioni cloud, VoIP, backup e trasferimenti di file.
4. Funzioni di sicurezza pianificate per gruppo di traffico.
5. Portata dell’ispezione TLS ed eccezioni necessarie.
6. Numero e utilizzo delle connessioni IPsec, SSL VPN e Sophos Connect.
7. Necessità di WAF, Mail Protection, RED, WLAN o Central Reporting.
8. Riserve previste per aggiornamenti, crescita e picchi di carico.
9. Modello operativo: hardware XGS, appliance virtuale, cloud o cluster HA.

FAQ