Hola companys! Avui m'agradaria parlar d'un tema molt rellevant per a molts administradors de Check Point, "Optimització de CPU i RAM". No és estrany que una passarel·la i/o un servidor de gestió consumeixi de manera inesperada molts d'aquests recursos, i s'agradaria entendre per on "fuguen" i, si és possible, utilitzar-los de manera més competent.
1. Anàlisi
Per analitzar la càrrega del processador, és útil utilitzar les ordres següents, que s'introdueixen en mode expert:
superior mostra tots els processos, la quantitat de recursos de CPU i RAM consumits en percentatge, temps de funcionament, prioritat del procés i en temps realи
llista cpwd_admin Check Point WatchDog Daemon, que mostra tots els mòduls de l'aplicació, el seu PID, estat i nombre d'execucions
cpstat -f CPU OS Ús de la CPU, el seu nombre i distribució del temps del processador en percentatge
cpstat -f memòria os ús de RAM virtual, quanta RAM activa, lliure i més
La observació correcta és que totes les ordres cpstat es poden veure mitjançant la utilitat cpview. Per fer-ho, només cal que introduïu l'ordre cpview des de qualsevol mode de la sessió SSH.
ps auxwf una llarga llista de tots els processos, el seu ID, la memòria virtual ocupada i la memòria RAM, CPU
Una altra variació de l'ordre:
ps-aF mostrar el procés més car
fw ctl afinitat -l -a distribució de nuclis per a diferents instàncies del tallafoc, és a dir, tecnologia CoreXL
fw ctl pstat Anàlisi de RAM i indicadors generals de connexions, cookies, NAT
lliure -m Buffer RAM
L'equip mereix una atenció especial. netsat i les seves variacions. Per exemple, netstat -i pot ajudar a resoldre el problema de la supervisió dels porta-retalls. El paràmetre, RX dropped packets (RX-DRP) a la sortida d'aquesta ordre tendeix a créixer per si mateix a causa de caigudes il·legítimes del protocol (IPv6, etiquetes VLAN incorrectes / no desitjades i altres). Tanmateix, si les gotes es produeixen per un altre motiu, hauríeu d'utilitzar-ho per començar a investigar per què aquesta interfície de xarxa deixa caure paquets. Coneixent la causa, també es pot optimitzar el funcionament de l'aplicació.
Si la fulla de supervisió està habilitada, podeu veure aquestes mètriques gràficament a la SmartConsole fent clic a un objecte i seleccionant Informació del dispositiu i de la llicència.
No es recomana habilitar la fulla de monitorització de manera continuada, però és molt possible que es faci una prova durant un dia.
A més, podeu afegir més paràmetres per al seguiment, un d'ells és molt útil: Bytes Throughput (ample de banda de l'aplicació).
Si hi ha algun altre sistema de control, per exemple, gratuït , que es basa en SNMP, també és adequat per identificar aquests problemes.
2. La memòria RAM "es filtra" amb el temps
Sovint sorgeix la pregunta que amb el temps, la passarel·la o el servidor de gestió comença a consumir cada cop més memòria RAM. Us vull tranquil·litzar: aquesta és una història normal per a sistemes semblants a Linux.
Mirant la sortida de l'ordre lliure -m и cpstat -f memòria os a l'aplicació des del mode expert, podeu calcular i veure tots els paràmetres relacionats amb la memòria RAM.
Basat en la memòria disponible a la passarel·la en aquest moment free Memory + Buffers de memòria + Memòria en memòria cau = +-1.5 GB, generalment.
Com diu CP, amb el temps la passarel·la/servidor de gestió s'optimitza i utilitza cada cop més memòria, fins a un 80% d'ús i s'atura. Podeu reiniciar el dispositiu i l'indicador es restablirà. 1.5 GB de RAM lliure són sens dubte suficients perquè la passarel·la realitzi totes les tasques, i la gestió rarament arriba a aquests valors llindars.
A més, la sortida de les ordres esmentades mostrarà quant teniu Memòria baixa (RAM a l'espai d'usuari) i memòria alta (RAM a l'espai del nucli) utilitzat.
Els processos del nucli (inclosos els mòduls actius com ara els mòduls del nucli de Check Point) només utilitzen memòria baixa. Tanmateix, els processos d'usuari poden utilitzar tant memòria baixa com alta. A més, la memòria baixa és aproximadament igual a Memòria total.
Només us hauríeu de preocupar si hi ha errors als registres "Els mòduls es reinicien o els processos s'eliminen per recuperar la memòria a causa de l'OOM (memòria sense)". Aleshores, hauríeu de reiniciar la passarel·la i contactar amb el servei d'assistència si el reinici no ajuda.
Es pot trobar una descripció completa a и .
3. Optimització
A continuació es mostren preguntes i respostes sobre l'optimització de CPU i RAM. Hauríeu de respondre-los sincerament a vosaltres mateixos i escoltar les recomanacions.
3.1. S'ha seleccionat correctament la línia ascendent? Hi va haver un projecte pilot?
Malgrat la mida competent, la xarxa simplement podria créixer i aquest equip simplement no pot fer front a la càrrega. La segona opció, si no hi havia mida com a tal.
3.2. La inspecció HTTPS està habilitada? En cas afirmatiu, la tecnologia està configurada segons les millors pràctiques?
Consulteu si ets el nostre client, o a .
L'ordre de les regles a la política d'inspecció HTTPS té un paper important en l'optimització de l'obertura dels llocs HTTPS.
Ordre recomanat de les normes:
- Omet les regles amb categories/URL
- inspeccioneu les regles amb categories/URL
- Inspeccioneu les regles de totes les altres categories
Per analogia amb la política del tallafoc, Check Point busca una coincidència de paquets de dalt a baix, de manera que les regles de derivació es col·loquen millor a la part superior, ja que la passarel·la no malgastarà recursos en executar totes les regles si cal ometre aquest paquet.
3.3 S'utilitzen objectes d'interval d'adreces?
Els objectes amb un rang d'adreces, com ara la xarxa 192.168.0.0-192.168.5.0, consumeixen molt més RAM que 5 objectes de xarxa. En general, es considera una bona pràctica eliminar objectes no utilitzats a la SmartConsole, ja que cada vegada que s'estableix una política, la passarel·la i el servidor de gestió gasten recursos i, el més important, temps per verificar i aplicar la política.
3.4. Com es configura la política de prevenció d'amenaces?
En primer lloc, Check Point recomana moure IPS a un perfil independent i crear regles separades per a aquesta fulla.
Per exemple, un administrador pensa que un segment DMZ només s'ha de protegir amb IPS. Per tant, per tal que la passarel·la no malgasti recursos en el processament de paquets per part d'altres blades, cal crear una regla específica per a aquest segment amb un perfil en què només estigui habilitat l'IPS.
Pel que fa a la configuració de perfils, es recomana configurar-lo segons les millors pràctiques en aquest (pàgines 17-20).
3.5. Quantes signatures en mode Detecta a la configuració IPS?
Es recomana treballar dur en les signatures en el sentit que les signatures no utilitzades s'han de desactivar (per exemple, les signatures per al funcionament dels productes Adobe requereixen molta potència de càlcul i, si el client no té aquests productes, té sentit desactivar-les). signatures). A continuació, poseu Prevent en comptes de Detectar quan sigui possible, perquè la passarel·la gasta recursos en processar tota la connexió en mode Detect, en mode Prevent deixa la connexió immediatament i no malgasta recursos en el processament complet del paquet.
3.6. Quins fitxers processen les fulles d'emulació d'amenaces, extracció d'amenaces i antivirus?
No té sentit emular i analitzar fitxers d'extensió que els usuaris no descarreguen o que considereu innecessaris a la vostra xarxa (per exemple, els fitxers bat, exe es poden bloquejar fàcilment mitjançant la fulla Coneixement del contingut al nivell del tallafoc, de manera que els recursos de la passarel·la seran gastat menys). A més, a la configuració de l'emulació d'amenaces, podeu seleccionar l'Entorn (sistema operatiu) per emular amenaces a la caixa de proves i instal·lar l'entorn Windows 7 quan tots els usuaris estan treballant amb la 10a versió, tampoc té sentit.
3.7. El tallafoc i les regles de la capa d'aplicació es col·loquen segons les millors pràctiques?
Si una regla té molts cops (partides), es recomana posar-los a la part superior i les regles amb un nombre reduït de cops, a la part inferior. El més important és assegurar-se que no s'entrecreuen i no es superposen. Arquitectura de política de tallafocs recomanada:
Explicació:
Primeres regles: aquí es col·loquen les regles amb més coincidències
Noise Rule: una regla per eliminar el trànsit espúre com ara NetBIOS
Regla furtiva: prohibició de trucades a passarel·les i gestions a tots, excepte aquelles fonts especificades a les regles d'autenticació de passarel·les.
Les regles de neteja, darrera i eliminació se solen combinar en una sola regla per prohibir tot allò que abans no estava permès
Les dades de les millors pràctiques es descriuen a .
3.8. Quina és la configuració dels serveis creats pels administradors?
Per exemple, s'està creant algun servei TCP en un port específic i té sentit desmarcar "Coincidir amb qualsevol" a la configuració avançada del servei. En aquest cas, aquest servei s'englobarà específicament a la norma en què apareix, i no participarà en les normes on Qualsevol es troba a la columna Serveis.
Parlant de serveis, val la pena esmentar que de vegades cal ajustar els temps d'espera. Aquesta configuració us permetrà utilitzar els recursos de la passarel·la de manera més intel·ligent, per no mantenir un temps de sessió TCP / UDP addicional per a protocols que no necessiten un temps d'espera important. Per exemple, a la captura de pantalla següent, vaig canviar el temps d'espera del servei de domini-udp de 40 segons a 30 segons.
3.9. S'utilitza SecureXL i quin és el percentatge d'acceleració?
Podeu comprovar la qualitat de SecureXL amb les ordres principals en mode expert a la passarel·la estat de fwaccel и fw accelstats -s. A continuació, heu d'esbrinar quin tipus de trànsit s'està accelerant, quines plantilles (plantilles) podeu crear més.
Per defecte, Drop Templates no estan habilitades, activar-les tindrà un efecte positiu en el funcionament de SecureXL. Per fer-ho, aneu a la configuració de la passarel·la i a la pestanya Optimitzacions:
A més, quan es treballa amb un clúster, per optimitzar la CPU, podeu desactivar la sincronització de serveis no crítics, com ara UDP DNS, ICMP i altres. Per fer-ho, aneu a la configuració del servei → Avançat → Sincronitza connexions de la sincronització de l'estat habilitat al clúster.
Totes les bones pràctiques es descriuen a .
3.10. Com s'utilitza CoreXl?
La tecnologia CoreXL, que us permet utilitzar diverses CPU per a instàncies de tallafoc (mòduls de tallafoc), sens dubte ajuda a optimitzar el rendiment del dispositiu. Primer equip fw ctl afinitat -l -a mostrarà les instàncies del tallafoc utilitzades i els processadors lliurats al SND necessari (un mòdul que distribueix el trànsit a les entitats del tallafoc). Si no hi participen tots els processadors, es poden afegir amb l'ordre cpconfig a la porta d'entrada.
També una bona història és posar per habilitar Multi-Queue. Multi-Queue soluciona el problema quan el processador amb SND s'utilitza en molts percentatges i les instàncies del tallafoc d'altres processadors estan inactives. Aleshores, SND podria crear moltes cues per a una NIC i establir diferents prioritats per a diferents tràfics al nivell del nucli. En conseqüència, els nuclis de la CPU s'utilitzaran de manera més intel·ligent. També es descriuen els mètodes a .
En conclusió, m'agradaria dir que aquestes són lluny de totes les millors pràctiques per optimitzar Check Point, però les més populars. Si voleu sol·licitar una auditoria de la vostra política de seguretat o resoldre un problema de Check Point, poseu-vos en contacte [protegit per correu electrònic].
Gràcies!
Font: www.habr.com