Ciao colleghi! Oggi vorrei discutere un tema molto attuale per molti amministratori di Check Point: "Ottimizzazione CPU e RAM". Non sono rari i casi in cui il gateway e/o il server di gestione consumano inaspettatamente molte di queste risorse e vorrei capire dove "vanno a finire" e, se possibile, utilizzarle in modo più intelligente.
1. Analisi
Per analizzare il carico della CPU, è utile utilizzare i seguenti comandi che vengono inseriti in modalità esperto:
top mostra tutti i processi, la quantità di risorse CPU e RAM consumate in percentuale, uptime, priorità del processo e in tempo realee
cpwd_admin list Check Point WatchDog Daemon, che mostra tutti i moduli dell'appliance, il loro PID, stato e numero di avvii
cpstat -f cpu os utilizzo della CPU, il numero di CPU e la distribuzione del tempo di elaborazione in percentuale
cpstat -f memory os utilizzo della RAM virtuale, totale RAM attiva, RAM libera e altro
È corretto notare che tutti i comandi cpstat possono essere visualizzati tramite l'utilità cpview. Per fare questo, basta inserire il comando cpview da qualsiasi modalità durante la sessione SSH.
ps auxwf un lungo elenco di tutti i processi, i loro ID, la memoria virtuale utilizzata e la memoria in RAM, CPU
Una variazione alternativa del comando:
ps -aF mostrerà il processo più esigente
fw ctl affinity -l -a allocazione dei core per diverse istanze del firewall, ovvero la tecnologia CoreXL
fw ctl pstat analisi della RAM e statistiche generali delle connessioni, cookies, NAT
free -m buffer RAM
Merita attenzione il comando netsat e le sue variazioni. Ad esempio, netstat -i può aiutare a risolvere problemi di monitoraggio dei buffer. Il parametro RX dropped packets (RX-DRP) nell'output di questo comando tende a crescere autonomamente a causa del drop di protocolli illegittimi (IPv6, Bad / Unintended VLAN tags e altri). Tuttavia, se i drop si verificano per altre ragioni, è opportuno consultare questa , per avviare un'indagine e capire perché questa interfaccia di rete sta perdendo pacchetti. Una volta identificata la causa, è possibile ottimizzare anche il funzionamento dell'appliance.
Se il blade Monitoring è attivo, è possibile visualizzare queste informazioni graficamente in SmartConsole, cliccando sull'oggetto e selezionando l'opzione "Device & License Information."
Non è consigliabile attivare il blade Monitoring in modo permanente, ma può essere utile tenerlo attivo per un giorno per testare.
Inoltre, è possibile aggiungere ulteriori parametri per il monitoraggio, uno dei quali è molto utile: Bytes Throughput (la larghezza di banda dell'appliance).
Se c'è qualche altro sistema di monitoraggio, come un gratuito , basato su SNMP, è adatto anche per identificare questi problemi.
2. “Fuga” di RAM nel tempo
Spesso ci si pone la domanda del perché, col passare del tempo, il gateway o il server di gestione cominci a consumare sempre più RAM. Voglio rassicurarti: è una situazione normale per i sistemi simili a Linux.
Guardando l'output dei comandi free -m e cpstat -f memory os sull'appliance in modalità esperta, è possibile calcolare e vedere tutti i parametri relativi alla RAM.
Di fatto, la memoria disponibile sul gateway attualmente è Memoria libera + Memoria dei buffer + Memoria cache = +-1.5 GB, di solito.
Come dice il SR, col passare del tempo il gateway/server di gestione si ottimizza e utilizza sempre più memoria, arrivando a circa l'80% di utilizzo, e si ferma. Puoi riavviare il dispositivo e allora il valore si azzera. 1.5 GB di RAM libera è sicuramente sufficiente per eseguire tutte le operazioni, e il management raramente raggiunge tali soglie.
Inoltre, l'output dei comandi menzionati mostrerà quanto hai Bassa memoria (memoria operativa nello user space) e Memoria alta (memoria operativa nello kernel space) utilizzata.
I processi del kernel (inclusi i moduli attivi, come i moduli kernel di Check Point) utilizzano solo memoria bassa. Tuttavia, i processi utente possono utilizzare sia memoria bassa che alta. Inoltre, la memoria bassa è approssimativamente pari a Memoria totale.
Dovresti preoccuparti solo se nei log iniziano a comparire errori «moduli riavviati o processi terminati per recuperare memoria a causa di OOM (Out of memory)». In tal caso, dovresti riavviare il gateway e contattare il supporto se il riavvio non risolve il problema.
Puoi trovare una descrizione completa in e .
3. Ottimizzazione
Di seguito sono riportate domande e risposte sull'ottimizzazione della CPU e della RAM. È importante rispondere onestamente a queste domande e seguire le raccomandazioni.
3.1. È stato selezionato correttamente l'appliance? È stato fatto un progetto pilota?
Nonostante un corretto sizing, la rete potrebbe semplicemente essersi espansa, e questo hardware non riesce a gestire il carico. L'altra possibilità è che non sia stato effettuato alcun sizing.
3.2. È stata abilitata l'ispezione HTTPS? In tal caso, la tecnologia è configurata secondo le Best Practice?
Contatta , se sei un nostro cliente, oppure .
L'ordine delle regole nella politica di ispezione HTTPS è fondamentale per ottimizzare il caricamento dei siti HTTPS.
Ordine raccomandato delle regole:
- Regole bypass con categorie/URL
- Regole ispezione con categorie/URL
- Regole ispezione per tutte le altre categorie
Analogamente alla politica del firewall, Check Point cerca corrispondenze nei pacchetti dall'alto verso il basso, quindi è meglio posizionare le regole di bypass nella parte superiore, poiché il gateway non spreccherà risorse per esaminare tutte le regole se il pacchetto deve essere saltato.
3.3 Vengono utilizzati oggetti address-range?
Gli oggetti con intervallo di indirizzi, ad esempio, la rete 192.168.0.0-192.168.5.0, consumano significativamente più RAM rispetto a 5 oggetti di rete. In generale, è considerato una buona pratica rimuovere oggetti non utilizzati in SmartConsole, poiché ogni volta che la politica viene applicata, il gateway e il server di gestione sprecano risorse e, soprattutto, tempo per verificare e applicare la politica.
3.4. Come è configurata la politica di Threat Prevention?
In primo luogo, Check Point raccomanda di separare l'IPS in un profilo a parte e di creare regole distinte per questo blade.
Ad esempio, l'amministratore ritiene che il segmento DMZ debba essere protetto solo tramite IPS. Pertanto, per evitare che il gateway consumi risorse per elaborare pacchetti con altri blade, è necessario creare una regola appositamente per questo segmento con un profilo in cui sia attivato solo IPS.
Per quanto riguarda la configurazione dei profili, si raccomanda di impostarlo secondo le migliori pratiche di questo (pagine 17-20).
3.5. Quante firme nel modo Detect nelle impostazioni IPS?
Si raccomanda di lavorare intensamente sulle firme in modo da disattivare quelle non utilizzate (ad esempio, le firme per l'exploitation dei prodotti Adobe richiedono molte risorse di calcolo, e se il cliente non possiede tali prodotti, ha senso disattivare le firme). Inoltre, impostare Prevent invece di Detect dove possibile, perché il gateway consuma risorse per elaborare l'intera connessione in modalità Detect, mentre in modalità Prevent scarta immediatamente la connessione e non spende risorse per l'elaborazione completa del pacchetto.
3.6. Quali file vengono elaborati dai blade Threat Emulation, Threat Extraction, Anti-Virus?
Non ha senso emulare e analizzare file di estensione che gli utenti non scaricano o che consideri superflui nella tua rete (ad esempio, i file bat ed exe possono essere facilmente bloccati tramite il blade Content Awareness a livello di firewall, riducendo così l'uso delle risorse del gateway). Inoltre, nelle impostazioni di Threat Emulation, puoi selezionare l'Environment (sistema operativo) per l'emulazione delle minacce in un ambiente sandbox. Non ha senso impostare Environment Windows 7 quando tutti gli utenti utilizzano la versione 10.
3.7. Le regole del firewall e le regole a livello di Application sono impostate secondo le best practice?
Se una regola ha molti hit (corrispondenze), è consigliabile posizionarla in cima, mentre le regole con pochi hit dovrebbero andare in basso. L'importante è assicurarsi che non si sovrappongano o confliggano tra loro. Architettura raccomandata della politica del firewall:
Explanations:
First Rules — qui vengono collocate le regole con il maggior numero di corrispondenze
Noise Rule — regola per filtrare il traffico indesiderato, come NetBIOS
Regola di Stealth — divieto di accesso ai gateway e ai manager da fonti diverse da quelle specificate nelle regole di autenticazione ai gateway
Le regole Clean-Up, Last e Drop sono solitamente unite in un'unica regola per vietare tutto ciò che non è stato precedentemente autorizzato
I dati delle Best practice sono descritti in .
3.8. Quali impostazioni hanno i servizi creati dagli amministratori?
Ad esempio, se viene creato un servizio TCP su una certa porta, ha senso, nelle impostazioni avanzate del servizio, disattivare l'opzione “Match for Any”. In questo caso, il servizio sarà specificamente soggetto alla regola in cui è menzionato e non parteciperà alle regole in cui nella colonna Servizi è indicato Any.
Parlando di servizi, è importante menzionare che a volte può essere necessario ottimizzare i timeout. Questa impostazione permetterà di gestire meglio le risorse del gateway, per evitare di mantenere sessioni TCP/UDP per un tempo eccessivo per i protocolli che non richiedono timeout prolungati. Ad esempio, nello screenshot sottostante, ho ridotto il timeout del servizio domain-udp da 40 secondi a 30 secondi.
3.9. Viene utilizzato SecureXL e quale è la percentuale di accelerazione?
La qualità del funzionamento di SecureXL può essere verificata tramite i comandi principali in modalità esperto sul gateway fwaccel stat e fw accel stats -s. È quindi necessario capire che tipo di traffico viene accelerato, quali templates possono essere creati ulteriormente.
Per impostazione predefinita, i Drop Templates non sono abilitati; la loro attivazione avrà un impatto positivo sull'operato di SecureXL. A tal fine, accedi alle impostazioni del gateway e sulla scheda Ottimizzazioni:
Inoltre, durante il funzionamento con un cluster, per ottimizzare la CPU è possibile disabilitare la sincronizzazione dei servizi non critici come UDP DNS, ICMP e altri. Per farlo, è necessario accedere alle impostazioni del servizio → Avanzate → Sincronizzazione delle connessioni di State Synchronization attivata sul cluster.
Tutte le Best Practice sono descritte in .
3.10. Come viene utilizzato CoreXL?
La tecnologia CoreXL, che consente l'utilizzo di più CPU per le istanze di firewall, contribuisce senza dubbio a ottimizzare il funzionamento del dispositivo. Inizialmente, il comando fw ctl affinity -l -a mostrerà le istanze di firewall utilizzate e le CPU dedicate ai bisogni di SND (il modulo che distribuisce il traffico tra le entità firewall). Se non tutte le CPU sono in uso, è possibile aggiungerle con il comando cpconfig sul gateway.
Una buona pratica è anche quella di applicare per attivare Multi-Queue. Multi-Queue risolve il problema quando la CPU con SND è utilizzata per una grande percentuale, mentre le istanze del firewall su altre CPU rimangono inattive. In questo modo, SND avrà la possibilità di creare più queue per un'unica NIC e assegnare diverse priorità per il traffico differente a livello di kernel. Di conseguenza, i core CPU verranno utilizzati in modo più efficiente. Le tecniche sono descritte anche in .
In conclusione, vorrei dire che queste sono solo alcune delle Best Practices per ottimizzare il funzionamento di Check Point, ma sono le più popolari. Se desiderate richiedere un audit della vostra politica di sicurezza o risolvere un problema relativo a Check Point, non esitate a contattare sales@tssolution.ru.
Grazie per l'attenzione!
Fonte: habr.com
