Ciao, colleghi! Oggi vorrei discutere un tema molto attuale per molti amministratori di Check Point: «Ottimizzazione della CPU e della RAM». Non è raro che il gateway e/o il server di gestione consumino inaspettatamente molte risorse, e vorremmo capire dove esse “vanno”, e come utilizzarle più saggiamente.
1. Analisi
Per analizzare il carico della CPU, è utile utilizzare i seguenti comandi da inserire 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, numero di CPU e distribuzione del tempo di CPU in percentuale
cpstat -f memory os utilizzo della RAM virtuale, quantità totale di RAM attiva, RAM libera e altro ancora
È giusto notare che tutti i comandi cpstat possono essere visualizzati tramite l'utilità cpview. Per farlo, è sufficiente inserire il comando cpview da qualsiasi modalità in una sessione SSH.
ps auxwf lista dettagliata di tutti i processi, i loro ID, la memoria virtuale utilizzata e la memoria RAM, CPU
Un'altra variante del comando:
ps -aF mostrerà il processo più oneroso
fw ctl affinity -l -a distribuzione dei core su diverse istanze del firewall, ovvero tecnologia CoreXL
fw ctl pstat analisi della RAM e statistiche generali su connessioni, cookies, NAT
free -m buffer RAM
Merita menzione il comando netsat e le sue varianti. Ad esempio, netstat -i può aiutare a monitorare i buffer di scambio. Il parametro RX dropped packets (RX-DRP) nell'output di questo comando tende a crescere da solo a causa dei drop di protocolli illegittimi (IPv6, Bad / Unintended VLAN tags e altri). Tuttavia, se i drop si verificano per un'altra ragione, è opportuno utilizzare questo , per iniziare un'indagine e capire perché questa interfaccia di rete stia perdendo pacchetti. Una volta identificata la causa, è possibile ottimizzare anche il funzionamento dell'appliance.
Se è attivato il blade Monitoring, è possibile visualizzare questi dati graficamente in SmartConsole, cliccando sull'oggetto e selezionando l'opzione «Device & License Information».
Non è consigliato attivare il blade Monitoring in modo permanente, ma per un giorno per test è più che accettabile.
Inoltre, è possibile aggiungere ulteriori parametri per il monitoraggio, uno dei quali è molto utile: Bytes Throughput (capacità di throughput dell'appliance).
Se esiste un altro sistema di monitoraggio, ad esempio, gratuito , basato su SNMP, è adatto anche per identificare i problemi in questione.
2. “Perdita” di RAM nel tempo
Spesso ci si chiede perché nel tempo il gateway o il server di gestione inizi a consumare sempre più RAM. Voglio rassicurare: è una situazione normale per i sistemi simili a Linux.
Guardando l'output dei comandi free -m e cpstat -f memory os sull'appliance dalla modalità esperto, è possibile calcolare e visualizzare tutti i parametri relativi alla RAM.
In effetti, la memoria disponibile sul gateway al momento Memoria libera + Memoria buffer + Memoria cache = +-1.5 GB, di solito.
Come dice il SR, nel tempo il gateway/server di gestione si ottimizza e utilizza sempre più memoria, fino a circa l'80% di utilizzo, e poi si ferma. È possibile riavviare il dispositivo e allora il valore si azzererà. 1.5 GB di RAM libera sono sicuramente sufficienti per svolgere tutti i compiti, e la gestione raramente raggiunge tali valori soglia.
Inoltre, le uscite dei comandi menzionati mostreranno quanto avete Memoria bassa (memoria operativa nello user space) e Memoria alta (memoria operativa nello kernel space) utilizzato.
I processi del kernel (inclusi i moduli attivi, come i moduli del kernel di Check Point) utilizzano solo la memoria bassa. Tuttavia, i processi utente possono utilizzare sia la memoria bassa che quella alta. Inoltre, la memoria bassa è circa Memoria totale.
Dovreste preoccuparvi solo se nei log si presentano errori «moduli riavviati o processi terminati per recuperare memoria a causa di OOM (Out of memory)». In tal caso, è necessario riavviare il gateway e contattare il supporto, se il riavvio non aiuta.
Una descrizione completa può essere trovata in e .
3. Ottimizzazione
Di seguito sono riportate domande e risposte sull'ottimizzazione della CPU e della RAM. Vale la pena rispondere onestamente a queste domande e seguire le raccomandazioni.
3.1. L'appliance è stata scelta correttamente? È stato effettuato un progetto pilota?
Nonostante una corretta dimensione, la rete potrebbe semplicemente essersi espansa, e questo hardware non riesce a gestire il carico. La seconda possibilità è che non ci sia stata una dimensionamento appropriato.
3.2. È stata attivata l'ispezione HTTPS? Se sì, è stata configurata secondo le Best Practice?
Fare riferimento a , se siete nostri clienti, o a .
L'ordine delle regole nella politica di ispezione HTTPS ha un grande impatto sull'ottimizzazione dell'apertura dei siti HTTPS.
L'ordine raccomandato delle regole è:
- Regole bypass con categorie/URL
- Regole di ispezione con categorie/URL
- Regole di 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 spenderà risorse per controllare tutte le regole se quel pacchetto deve essere ignorato.
3.3 Vengono utilizzati oggetti address-range?
Gli oggetti con range di indirizzi, ad esempio, la rete 192.168.0.0-192.168.5.0, consumano notevolmente più RAM rispetto a 5 oggetti di rete. In generale, è considerata una buona pratica rimuovere oggetti non utilizzati in SmartConsole, poiché ogni volta che viene applicata una politica, il gateway e il server di gestione spendono risorse e, soprattutto, tempo, per verificare e applicare la politica.
3.4. Come è configurata la politica di prevenzione delle minacce?
In primo luogo, Check Point raccomanda di spostare l'IPS in un profilo separato e di creare regole separate per questo blade.
Ad esempio, l'amministratore ritiene che il segmento DMZ debba essere protetto solo tramite IPS. Pertanto, per evitare che il gateway spenda risorse per elaborare pacchetti con altri blade, è necessario creare una regola specifica per questo segmento con un profilo in cui sia attivato solo l'IPS.
Per quanto riguarda la configurazione dei profili, si raccomanda di configurarlo secondo le migliori pratiche in questo (pagine 17-20).
3.5. Quanti segnali ci sono nelle impostazioni IPS in modalità Detect?
Si consiglia di lavorare intensamente sulle firme, in particolare disabilitando quelle non utilizzate (ad esempio, le firme per l'exploitation di prodotti Adobe richiedono molta potenza di calcolo e, se il cliente non dispone di tali prodotti, ha senso disattivare le firme). Successivamente, è consigliabile impostare Prevent invece di Detect dove possibile, poiché il gateway spende 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 i file di estensione che i vostri utenti non scaricano, o che ritenete non necessari nella vostra rete (ad esempio, i file bat, exe possono essere facilmente bloccati tramite il blade Content Awareness a livello di firewall, quindi le risorse del gateway verranno spese meno). Inoltre, non ha senso selezionare Windows 7 come Environment (sistema operativo) per l'emulazione delle minacce nella sandbox quando tutti gli utenti utilizzano la versione 10.
3.7. Le regole del firewall e le regole di livello Application sono disposte secondo le best practice?
Se una regola ha molti hit (corrispondenze), è consigliabile posizionarla in cima, mentre le regole con poche corrispondenze dovrebbero andare in fondo. L'importante è assicurarsi che non si sovrappongano o si intersechino. L'architettura consigliata della politica firewall è:
Spiegazioni:
First Rules — qui si collocano le regole con il maggior numero di corrispondenze
Noise Rule — regola per scartare il traffico parassitario, come NetBIOS
Stealth Rule — vieta gli accessi ai gateway e ai manager a tutti, tranne le fonti specificate nelle regole di Authentication to Gateway Rules
Clean-Up, Last e Drop Rules, di solito, vengono unite in un'unica regola per vietare tutto ciò che non era stato precedentemente autorizzato
I dati sulle Best practice sono descritti in .
3.8. Quali impostazioni sono attive per i servizi creati dagli amministratori?
Ad esempio, se viene creato un servizio TCP su una porta specifica, ha senso nelle impostazioni avanzate del servizio deselezionare l'opzione 'Match for Any'. In questo caso, il servizio rientrerà specificamente nella regola in cui figura e non parteciperà alle regole in cui nella colonna Services è indicato Any.
Parlando di servizi, è importante menzionare che a volte è necessario ottimizzare i timeout. Questa impostazione consentirà di utilizzare meglio le risorse del gateway, evitando di mantenere a lungo sessioni TCP/UDP di protocolli che non richiedono un lungo timeout. Ad esempio, nello screenshot qui sotto, ho cambiato il timeout del servizio domain-udp da 40 secondi a 30 secondi.
3.9. È utilizzato SecureXL e qual è la percentuale di accelerazione?
È possibile verificare la qualità del lavoro di SecureXL con i comandi principali in modalità esperto sul gateway fwaccel stat e fw accel stats -s. Poi occorre analizzare che tipo di traffico viene accelerato, quali template (modelli) possono essere creati ulteriormente.
Per impostazione predefinita, i modelli di Drop non sono attivi; attivarli avrà un effetto positivo sul funzionamento di SecureXL. Per farlo, accedi alle impostazioni del gateway e alla scheda Ottimizzazioni:
Inoltre, durante l'uso di un cluster, per ottimizzare la CPU, è possibile disattivare la sincronizzazione dei servizi non critici, come UDP DNS, ICMP e altri. Per farlo, accedi alle impostazioni del servizio → Avanzate → Sincronizza le connessioni della sincronizzazione dello stato è abilitata nel cluster.
Tutte le Best Practice sono descritte in .
3.10. Come si utilizza CoreXl?
La tecnologia CoreXL, che consente di utilizzare più CPU per le istanze del firewall (moduli del firewall), aiuta sicuramente a ottimizzare le prestazioni del dispositivo. Innanzitutto, il comando fw ctl affinity -l -a mostrerà le istanze di firewall utilizzate e i processori assegnati alle necessità di SND (modulo che distribuisce il traffico tra le entità del firewall). Se non sono utilizzati tutti i processori, possono essere aggiunti con il comando cpconfig sul gateway.
Un'altra opzione utile è installare per abilitare Multi-Queue. Multi-Queue risolve il problema in cui il processore con SND è utilizzato per molte percentuali, mentre le istanze del firewall su altri processori rimangono inattive. Pertanto, a SND sarebbe permesso creare più code per una singola NIC e impostare diverse priorità per il traffico vario a livello di kernel. Di conseguenza, i nuclei della CPU vengono utilizzati in modo più efficiente. Le tecniche sono descritte anche in .
In conclusione, ci tengo a sottolineare che queste non sono tutte le Best Practices per ottimizzare il funzionamento di Check Point, ma sono le più popolari. Se desideri richiedere un audit della tua politica di sicurezza o risolvere un problema legato a Check Point, ti preghiamo di contattarci all'indirizzo sales@tssolution.ru.
Grazie per l'attenzione!
Fonte: habr.com
