Check Point: optimizacija CPU in RAM

Pozdravljeni, kolegi! Danes bi želel razpravljati o zelo aktualni temi za mnoge skrbnike Check Point, 'Optimizacija CPU in RAM'. Ni redko, da prehod in/ali strežnik za upravljanje nepričakovano porabita veliko teh virov, zato bi želel razumeti, kam 'uhajajo' in po možnosti bolj učinkovito izkoristiti te vire.

1. Analiza

Za analizo obremenitve procesorja je koristno uporabiti naslednje ukaze, ki jih vnesemo v expert način:

top prikazuje vse procese, količino porabljenih virov CPU in RAM v odstotkih, uptime, prioritet procesa in drugo v realnem časuin

cpwd_admin list Check Point WatchDog Daemon, ki prikazuje vse module naprave, njihov PID, stanje in število zagonov

cpstat -f cpu os poraba CPU, njihovo število in razporeditev procesorskega časa v odstotkih

cpstat -f memory os poraba virtualne RAM, koliko je skupno aktivne, proste RAM in druge informacije

Pravilna opomba bi bila, da lahko vse ukaze cpstat pogledamo s pomočjo orodja cpview. Za to je samo treba vnesti ukaz cpview iz katerega koli načina v SSH seji.

ps auxwf dolga lista vseh procesov, njihovih ID-jev, zasedene virtualne pomnilnike in RAM, CPU

Druga variacija ukaza:

ps -aF prikazuje najbolj potratni proces

fw ctl affinity -l -a razporeditev jeder pod različne instance požarnega zidu, torej tehnologija CoreXL

fw ctl pstat analiza RAM in splošni kazalniki povezav, piškotkov, NAT

free -m pomnilniški predpomnilnik RAM

Posebne pozornosti vredno je ukaz netsat in njegove variacije. Na primer, netstat -i lahko pomaga rešiti nalogo spremljanja predpomnilnikov. Parameter, RX dropped packets (RX-DRP) v izhodu tega ukaza se običajno povečava sam od sebe zaradi izgub nezakonitih protokolov (IPv6, slabi/neželeni VLAN oznake in drugi). Vendar, če prihaja do izgub iz drugega razloga, je smiselno uporabiti to članek, da začnete preiskavo in razumete, zakaj ta omrežni vmesnik zavrača pakete. Po odkritju vzroka je tudi mogoče optimizirati delovanje naprave.

Če je vklopljen blade Monitoring, lahko te kazalnike ogledate grafično v SmartConsole, tako da kliknete na objekt in izberete točko 'Device & License Information'.

Na trajni osnovi vklapljanje blade Monitoring ni priporočljivo, vendar je za en dan za test povsem sprejemljivo.

Poleg tega je mogoče dodati še več parametrov za spremljanje, eden izmed njih je zelo koristen — Bytes Throughput (propustnost naprave).

Če obstaja kakšna druga monitorna sistema, na primer brezplačna Zabbix, ki temelji na SNMP, tudi to ustreza za zaznavanje teh težav.

2. "Uhajanje" RAM-a skozi čas

Pogosto se postavlja vprašanje, da začne prehod ali upravljalski strežnik skozi čas porabiti vedno več RAM-a. Želim pomiriti: to je normalno za sisteme, podobne Linuxu.

Če pogledate izhod ukazov free -m in cpstat -f memory os na napravi iz ekspertnega načina, lahko izračunate in si ogledate vse parametre, povezane z RAM-om.

Dejansko razpoložljive pomnilniške kapacitete na prehodu trenutno Prosta pomnilnost + Pomnilnost v medpredpomnilniku + Zgoščena pomnilnost = +-1.5 GB, kot pravilo.

Kot pravi SR, se skozi čas prehod/upravljalski strežnik optimizira in uporablja vedno več pomnilnika, dokler doseže približno 80% uporabe, in se ustavi. Napravo lahko znova zaženete, in takrat se vrednost ponastavi. 1.5 GB prostega RAM-a je prehodu povsem dovolj za izvajanje vseh nalog, upravljalski sistem pa redko doseže takšne meje.

Izhodi omenjenih ukazov bodo prav tako pokazali, koliko imate Nizka pomnilnost (operativna pomnilnost v uporabniškem prostoru) in Visoka pomnilnost (operativna pomnilnost v jedrnem prostoru) uporabljeno.

Procesi jedra (vključno z aktivnimi moduli, kot so moduli jedra Check Point) uporabljajo samo nizko pomnilnost. Uporabniški procesi pa lahko uporabljajo tako nizko kot visoko pomnilnost. Poleg tega je nizka pomnilnost približno Skupna pomnilnost.

Skrbeti je treba le, če se v dnevnikih pojavljajo napake "moduli se znova zaženejo ali procesi se uničijo, da se povrne pomnilnost zaradi OOM (Out of memory)". V takem primeru je treba znova zagnati prehod in se obrniti na podporo, če ponovni zagon ne pomaga.

Celoten opis lahko najdete v sk99547 in sk99593.

3. Optimizacija

Spodaj so navedena vprašanja in odgovori o optimizaciji CPU in RAM. Na njih je treba iskreno odgovoriti in upoštevati priporočila.

3.1. Ali je bil prehod pravilno izbran? Ali je bil pilotni projekt?

Kljub smiselnemu dimenzioniranju se je omrežje lahko preprosto razširilo in ta oprema preprosto ne zmore bremena. Druga možnost je, da dimenzioniranje kot takega ni bilo.

3.2. Ali je bila vklopljena HTTPS inspekcija? Če ja, ali je bila tehnologija nastavljena po najboljših praksah?

Obrnite se na članek, če ste naš stranka, ali pa na sk108202.

Postavitev pravil v politiki HTTPS inspekcije ima velik pomen pri optimizaciji odpiranja HTTPS spletnih strani.

Priporočeni vrstni red postavitve pravil:

1. Pravila bypass s kategorijami/URL
2. Pravila inšpekcije s kategorijami/URL-ji
3. Pravila inšpekcije za vse druge kategorije

Podobno kot pri požarno-zidni politiki, Check Point išče ujemanja po paketih od zgoraj navzdol, zato je bolje, da so pravila za prehitevanje na vrhu, saj ne bo potrebno, da prehod ne troši virov za preverjanje vseh pravil, če je treba ta paket preskočiti.

3.3 Ali se uporabljajo objekti za obseg naslovov?

Objekti z obsegom naslovov, na primer omrežje 192.168.0.0-192.168.5.0, zahtevajo bistveno več RAM-a kot 5 omrežnih objektov. Na splošno velja, da je dobra praksa odstraniti neuporabljene objekte v SmartConsole, saj prehod in upravljalni strežnik ob vsakem nastavitvi politike porabita vire in, kar je najpomembneje, čas za preverjanje in uporabo politike.

3.4 Kako je nastavljena politika preprečevanja groženj?

Najprej Check Point priporoča, da se IPS postavi v poseben profil in ustvari posebna pravila za ta blade.

Na primer, skrbnik meni, da je treba segment DMZ zaščititi le z IPS. Zato, da prehod ne troši virov na obdelavo paketov z drugimi bladi, je nujno ustvariti pravilo posebej za ta segment s profilom, v katerem je vključen le IPS.

Kar zadeva nastavitev profilov, je priporočljivo, da ga nastavite po najboljših praksah v tem dokumentu(strani 17-20).

3.5 Koliko podpisov je v načinu Detect v nastavitvah IPS?

Priporočljivo je temeljito obravnavati podpise v smislu, da bi bilo treba izklopiti neuporabljene (na primer, podpisi za izkoriščanje izdelkov Adobe zahtevajo veliko računalniških virov, in če pri naročniku takih izdelkov ni, ima smisel te podpise izklopiti). Prav tako nastavite Prevent namesto Detect, kjer je to mogoče, saj prehod porabi vire za obdelavo celotne povezave v načinu Detect, v načinu Prevent pa takoj zavrne povezavo in ne porabi virov za popolno obdelavo paketa.

3.6 Katere datoteke obdelujejo bladi Threat Emulation, Threat Extraction, Anti-Virus?

Ni smisla je emulirati i analizirati datoteke proširenja koje vaši korisnici ne preuzimaju, ili smatrate nepotrebnim u vašoj mreži (npr. bat, exe datoteke lako se mogu blokirati pomoću blade Content Awareness na razini vatrozida, stoga će resursi gateway-a biti manje opterećeni). Štoviše, u postavkama Threat Emulation možete odabrati Okruženje (operativni sustav) za emulaciju prijetnji u sandboxu i postavljanje Okruženja Windows 7 kada svi korisnici rade s verzijom 10 također nema smisla.

3.7. Jesu li pravila vatrozida i pravila razine aplikacije postavljena u skladu s najboljim praksama?

Ako pravilo ima mnogo pogodaka (podudaranja), preporučuje se postaviti ih najviše, dok pravila s malim brojem pogodaka treba staviti najniže. Glavno je pratiti da se ne preklapaju i ne zatvaraju jedno drugo. Preporučena arhitektura vatrozdne politike:

Pojasnila:

First Rules — ovdje se postavljaju pravila s najvećim brojem podudaranja
Noise Rule — pravilo za odbacivanje parazitskog prometa, poput NetBIOS-a
Stealth Rule — zabranjuje pristup gateway-ima i upravljačkim sustavima svima, osim onim izvorima koji su navedeni u pravilima Authentication to Gateway Rules
Clean-Up, Last i Drop Rules obično se kombiniraju u jedno pravilo za zabranu svega što nije prethodno dopušteno

Ove najbolje prakse opisane su u sk106597.

3.8. Koje postavke imaju usluge koje su stvorili administratori?

Na primjer, stvara se određena TCP usluga preko određenog porta, i ima smisla u naprednim postavkama usluge isključiti opciju “Match for Any”. U tom slučaju, ova usluga će se konkretno uklapati pod pravilo u kojem se navodi, te neće sudjelovati u pravilima gdje je u koloni Usluge postavljeno Any.

Kada govorimo o uslugama, valja spomenuti da ponekad treba fino podešavati vrijeme isteka (timeout). Ova postavka omogućava racionalnije korištenje resursa gateway-a, kako ne bi trajale nepotrebno dugo TCP/UDP sesije protokola kojima ne trebaju duge posljedice. Na primjer, na prikazu ispod, premjestio sam vrijeme isteka domain-udp usluge s 40 sekundi na 30 sekundi.

3.9. Koristi li se SecureXL i koliki je postotak ubrzanja?

Kvalitetu rada SecureXL možete provjeriti osnovnim komandama u ekspertnom režimu na gateway-u fwaccel stat in fw accel stats -s. Zatim treba istražiti koji promet se ubrzava, koje šablone (templates) se mogu još stvoriti.

Privzeto Drop Templates niso vključeni, njihovo vključitev pa bo pozitivno vplivalo na delovanje SecureXL. Za to dostopajte do nastavitev prehoda in na zavihek Optimizacije:

Prav tako lahko pri delu s klasterjem za optimizacijo CPU onemogočite sinhronizacijo nekritičnih storitev, kot so UDP DNS, ICMP in druge. Za to se odpravite do nastavitev storitve → Napredno → Sinhronizacija povezav, ko je Sinhronizacija stanja omogočena na klasterju.

Vsi najboljši praks so opisani v sk98348.

3.10. Kako se uporablja CoreXL?

Tehnologija CoreXL, ki omogoča uporabo večih CPU za instance požarnih zidov (module požarnega zidu), nedvomno pripomore k optimizaciji delovanja naprave. Najprej bo ekipa fw ctl affinity -l -a pokazala uporabljene instance požarnih zidov in procesorje, dodeljene potrebnim SND (modul, ki distribuira promet na požarne entitete). Če niso vključeni vsi procesorji, jih lahko dodate z ukazom cpconfig na prehodu.
Tudi dobra rešitev je namestitev popravka za omogočanje Multi-Queue. Multi-Queue rešuje težavo, ko je procesor s SND obremenjen, medtem ko druge instance požarnega zidu na drugih procesorjih presegajo. Tako bi imel SND možnost ustvarjanja več prioritet za eno NIC ter dodeljevanja različnih prioritet različnemu prometu na ravni jedra. Posledično se bodo jedra CPU bolje uporabljala. Te metodike so prav tako opisane v sk98348.

Na koncu bi želeli poudariti, da to niso vse najboljše prakse za optimizacijo delovanja Check Point, ampak le najbolj priljubljene. Če želite naročiti revizijo vaše varnostne politike ali rešiti težavo, povezano s Check Point, nas prosimo kontaktirajte na sales@tssolution.ru.

Hvala za pozornost!

Izvor: habr.com