Bună ziua, colegi! Astăzi aș dori să discutăm despre un subiect foarte important pentru mulți administratori Check Point: „Optimizarea CPU și RAM”. Nu sunt rare cazurile în care gateway-ul și/sau serverul de management consumă o cantitate neașteptată din aceste resurse, iar dorința este să înțelegem unde „se duc” acestea și, dacă este posibil, să le folosim mai eficient.
1. Analiză
Pentru analiza sarcinii procesorului, este util să folosiți următoarele comenzi, care sunt introduse în modul expert:
top arată toate procesele, cantitatea de resurse consumate de CPU și RAM în procente, uptime, prioritatea procesului și în timp realși
cpwd_admin list Check Point WatchDog Daemon, care arată toate modulele appliance-ului, PID-ul lor, starea și numărul de porniri
cpstat -f cpu os utilizarea CPU, numărul acestora și distribuirea timpului procesorului în procente
cpstat -f memory os utilizarea RAM-ului virtual, câtă memorie activă este disponibilă, memorie liberă și altele
O observație corectă ar fi că toate comenzile cpstat pot fi vizualizate cu ajutorul utilitarului cpview. Pentru aceasta, trebuie doar să introduceți comanda cpview din orice mod într-o sesiune SSH.
ps auxwf o listă lungă a tuturor proceselor, ID-urile lor, memoria virtuală ocupată și memoria din RAM, CPU
O altă variație a comenzii:
ps -aF va arăta cel mai costisitor proces
fw ctl affinity -l -a distribuția nucleelor pentru diferite instanțe ale firewall-ului, adică tehnologia CoreXL
fw ctl pstat analiza RAM-ului și statisticile generale ale conexiunilor, cookies, NAT
free -m buffer RAM
O comandă care merită menționată este netsat și variațiile acesteia. De exemplu, netstat -i poate ajuta la rezolvarea problemei monitorizării bufferelor de schimb. Parametrul RX dropped packets (RX-DRP) din ieșirea acestei comenzi, în general, crește de la sine din cauza dropurilor de protocoale ilegitime (IPv6, etichete VLAN eronate/neintenzionate și altele). Cu toate acestea, dacă dropurile apar dintr-un alt motiv, merită să folosiți această , pentru a începe o investigație și a înțelege de ce această interfață de rețea respinge pachetele. Odată ce cauza este identificată, funcționarea appliance-ului poate fi, de asemenea, optimizată.
Dacă blade-ul Monitoring este activat, este posibil să vizualizați aceste date grafic în SmartConsole, apăsând pe obiect și selectând „Device & License Information”.
Este recomandat să nu activați blade-ul Monitoring permanent, dar îl puteți activa pentru o zi pentru teste.
În plus, se pot adăuga mai multe parametrii pentru monitorizare, unul dintre aceștia fiind foarte util — Bytes Throughput (lățimea de bandă a appliance-ului).
Dacă există un alt sistem de monitorizare, de exemplu, un sistem gratuit , bazat pe SNMP, acesta se va potrivi pentru identificarea problemelor respective.
2. „Scurgerea” RAM în timp
Adesea apare întrebarea de ce, în timp, gateway-ul sau serverul de management încep să consume tot mai mult RAM. Vreau să te liniștesc: aceasta este o situație normală pentru sistemele asemănătoare Linux.
Privind ieșirea comenzii free -m și cpstat -f memory os de pe appliance din modul expert, poți calcula și vizualiza toți parametrii referitori la RAM.
De fapt, memoria disponibilă pe gateway în acest moment Memorie liberă + Memorie buffer + Memorie cache = +-1.5 GB, de obicei.
Așa cum spune SR, în timp, gateway-ul/serverul de management se optimizează și folosește din ce în ce mai multă memorie, ajungând la aproximativ 80% utilizare, și se oprește. Poți să repornești dispozitivul, iar atunci indicatorul se va reseta. 1.5 GB de RAM liberă este suficient pentru a îndeplini toate sarcinile, iar serverul de management rar ajunge la astfel de valori limită.
De asemenea, ieșirile comenzilor menționate vor arăta cât de mult ai Memorie slabă (memorie operativă în user space) și Memorie înaltă (memorie operativă în kernel space) utilizată.
Procesele kernel (inclusiv modulele active, cum ar fi modulele kernel Check Point) folosesc doar memorie slabă. Cu toate acestea, procesele utilizatorului pot folosi atât memorie slabă, cât și memorie înaltă. Mai mult, memorie slabă este aproximativ egală cu Memorie totală.
Trebuie să te îngrijorezi doar dacă în jurnale apar erori „module reboot sau procesele fiind închise pentru a recupera memorie din cauza OOM (Out of memory)”. Atunci ar trebui să repornești gateway-ul și să contactezi suportul dacă repornirea nu ajută.
O descriere completă poate fi găsită în și .
3. Optimizare
Mai jos sunt întrebări și răspunsuri despre optimizarea CPU și RAM. Acestea merită să fie analizate serios și să asculți recomandările.
3.1. A fost selectat corect appliance-ul? A existat un proiect pilot?
În ciuda dimensionării corecte, rețeaua ar fi putut pur și simplu să crească, iar acest echipament să nu facă față sarcinii. A doua variantă este că nu a existat o dimensionare efectivă.
3.2. Este activată inspecția HTTPS? Dacă da, este tehnologia configurată conform celor mai bune practici?
Contactează , dacă ești clientul nostru, sau .
Ordinea în care sunt plasate regulile în politica de inspecție HTTPS are o mare importanță în optimizarea deschiderii site-urilor HTTPS.
Ordinea recomandată a plasării regulilor:
- Reguli bypass cu categorii/URL
- Reguli inspect cu categorii/URL
- Reguli inspect pentru toate celelalte categorii
Asemenea politicii de firewall, Check Point caută potriviri în pachete de sus în jos, de aceea este mai bine să plasați regulile bypass în partea de sus, deoarece gateway-ul nu va consuma resurse pentru a verifica toate regulile dacă acel pachet trebuie să fie ocolit.
3.3 Sunt utilizate obiecte de tip address-range?
Obiectele cu un interval de adrese, de exemplu, rețeaua 192.168.0.0-192.168.5.0, consumă semnificativ mai mult RAM decât 5 obiecte de rețea. În general, se consideră o bună practică să eliminați obiectele neutilizate în SmartConsole, deoarece de fiecare dată când este implementată politica, gateway-ul și serverul de management consumă resurse și, mai ales, timp pentru a verifica și aplica politica.
3.4. Cum este configurată politica de prevenire a amenințărilor?
În primul rând, Check Point recomandă separarea IPS într-un profil distinct și crearea de reguli separate pentru acest blade.
De exemplu, administratorul consideră că segmentul DMZ trebuie protejat doar prin IPS. Astfel, pentru a nu consuma resursele gateway-ului pentru a procesa pachete cu alte blade-uri, este necesar să creați o regulă specifică pentru acest segment cu un profil în care este activat doar IPS.
Referitor la configurarea profilurilor, este recomandabil să fie configurate conform celor mai bune practici descrise în acest (pagini 17-20).
3.5. În setările IPS, câte semnături sunt în modul Detect?
Se recomandă să se lucreze intens la semnături, în sensul că ar trebui să se dezactiveze cele neutilizate (de exemplu, semnăturile legate de exploatarea produselor Adobe necesită multă putere computațională, iar dacă clientul nu are aceste produse, semnăturile ar trebui dezactivate). Apoi, ar trebui să se seteze Prevent în loc de Detect acolo unde este posibil, deoarece gateway-ul consumă resurse pentru a procesa întreaga conexiune în modul Detect, iar în modul Prevent respinge imediat conexiunea și nu consumă resurse pentru o procesare completă a pachetului.
3.6. Ce fișiere sunt procesate de blade-urile de Emulare a Amenințărilor, Extracție de Amenințări, Anti-Virus?
Nu are sens să emulați și să analizați fișierele de extensie pe care utilizatorii dvs. nu le descarcă sau pe care le considerați inutile în rețeaua dvs. (de exemplu, fișierele bat, exe pot fi ușor blocate cu ajutorul blade-ului de Conștientizare a Conținutului la nivelul firewall-ului, astfel încât resursele gateway-ului vor fi consumate mai puțin). În plus, în setările Emulației de Amenințări, puteți alege Mediul (sistemul de operare) pentru emularea amenințărilor în sandbox și alegerea Mediului Windows 7, când toți utilizatorii lucrează cu versiunea 10, de asemenea, nu are sens.
3.7. Sunt regulile firewall-ului și regulile nivelului Aplicare plasate conform celor mai bune practici?
Dacă o regulă are multe hituri (corelări), se recomandă să fie plasată în partea de sus, iar regulile cu un număr redus de hituri să fie plasate în partea de jos. Principalul lucru este să vă asigurați că acestea nu se suprapun și nu se intersectează între ele. Arhitectura recomandată a politicii de firewall este:
Explicații:
Reguli Inițiale — aici se plasează regulile cu cele mai multe corelări
Regula de Zgomot — regulă pentru a elimina traficul parazitar, cum ar fi NetBIOS
Regula Stealth — interzicerea accesului la gateway-uri și gestionări tuturor, cu excepția surselor specificate în regulile de Autentificare la Regulile Gateway
Regulile Clean-Up, Last și Drop sunt de obicei combinate într-o singură regulă pentru a interzice tot ce nu a fost anterior permis
Aceste date despre cele mai bune practici sunt descrise în .
3.8. Ce setări au fost stabilite pentru serviciile create de administratori?
De exemplu, se creează un anumit serviciu TCP pe un anumit port, și este de sens să debifați opțiunea „Match for Any” în setările Avansate ale serviciului. În acest caz, acest serviciu va cădea specific sub regula în care este menționat și nu va participa în regulile unde în coloana Servicii este specificat Any.
Vorbind despre servicii, merită menționat că uneori este necesar să ajustați timpii de așteptare. Această setare va permite o utilizare mai eficientă a resurselor gateway-ului, pentru a nu menține sesiuni TCP/UDP inutile pentru protocoalele care nu necesită un timp de așteptare mare. De exemplu, în captura de ecran de mai jos, am modificat timpul de așteptare al serviciului domain-udp de la 40 de secunde la 30 de secunde.
3.9. Este utilizat SecureXL și care este procentajul de accelerare?
Calitatea funcționării SecureXL poate fi verificată cu comenzile principale în modul expert pe gateway fwaccel stat și fw accel stats -s. Apoi, trebuie să înțelegeți ce trafic este accelerat, ce șabloane pot fi create suplimentar.
Implicit, șabloanele Drop nu sunt activate, activarea lor va avea un impact negativ asupra funcționării SecureXL. Pentru aceasta, accesați setările gateway-ului și tab-ul Optimizations:
De asemenea, atunci când lucrați cu un cluster, pentru a optimiza CPU, puteți dezactiva sincronizarea serviciilor non-critice, cum ar fi UDP DNS, ICMP și altele. Pentru aceasta, este necesar să accesați setările serviciului → Advanced → Synchronize connections of State Synchronization is enabled on the cluster.
Toate cele mai bune practici sunt descrise în .
3.10. Cum se utilizează CoreXl?
Tehnologia CoreXL, care permite utilizarea mai multor CPU pentru instanțele firewall (modulele firewall-ului), ajută deosebit la optimizarea funcționării dispozitivului. Mai întâi, comanda fw ctl affinity -l -a va arăta instanțele firewall utilizate și procesoarele alocate pentru necesitatea SND (modul care distribuie traficul către entitățile firewall). Dacă nu toate procesoarele sunt utilizate, acestea pot fi adăugate prin comanda cpconfig pe gateway.
De asemenea, o poveste bună este să instalați pentru activarea Multi-Queue. Multi-Queue rezolvă problema în care procesorul cu SND este utilizat într-un procent mare, în timp ce instanțele firewall-ului de pe celelalte procesoare sunt inactive. Prin urmare, SND ar avea posibilitatea de a crea multe cozi pentru un singur NIC și de a stabili diferite priorități pentru diferit trafic la nivel de kernel. Astfel, nuclee CPU vor fi utilizate mai eficient. Metodologiile sunt de asemenea descrise în .
În concluzie, aș dori să spun că acestea nu sunt toate cele mai bune practici pentru optimizarea funcționării Check Point, ci doar cele mai populare. Dacă doriți să solicitați un audit al politicii dumneavoastră de securitate sau să rezolvați o problemă legată de Check Point, vă rugăm să contactați sales@tssolution.ru.
Vă mulțumesc pentru atenție!
Sursa: habr.com
