Täpipunkt: CPU ja RAM optimeerimine

Tere, kolleegid! Täna sooviksin arutada väga aktuaalset teemat paljude Check Pointi administraatorite jaoks – "CPU ja RAM-i optimeerimine". Sageli esinevad juhtumid, kus värav ja/või juhtimissevers tarbivad ootamatult palju neid ressursse, ja tahaksin mõista, kuhu need "kaovad", ning vajadusel neid paremini kasutada.

1. Analüüs

Protsessori koormuse analüüsimiseks on kasulik kasutada järgmisi käske, mis sisestatakse ekspertrežiimis:

top näitab kõiki protsesse, tarbitud CPU ja RAM-i ressursse protsentides, tööaega, protsessi prioriteeti ja muid reaalses ajasja

cpwd_admin list Check Point WatchDog Daemon, mis näitab kõiki seadme mooduleid, nende PID-e, olekuid ja käivituste arvu

cpstat -f cpu os CPU kasutus, nende arv ja protsessorite aja jaotus protsentides

cpstat -f memory os virtuaalse RAM-i kasutus, kui palju on kokku aktiivset, vabade RAM ja muud

Õige märkuse kohaselt saab kõiki cpstat käske vaadata utiliidi cpview. Selleks sisestage lihtsalt käsk cpview mis tahes režiimist SSH-seansis.

ps auxwf pikk loetelu kõikidest protsessidest, nende ID-dest, monopoolsetest mälumahtudest ja RAM-i, CPU

Teine käsu variatsioon:

ps -aF näitab kõige ressursside kurnavamat protsessi

fw ctl affinity -l -a tuumade jaotamine erinevatele tulemüüride instantsidele, st CoreXL tehnoloogia

fw ctl pstat RAM-i analüüs ja ühenduste, küpsiste, NAT-i üldandmed

free -m RAM-i puhver

Erilist tähelepanu väärib käsk netsat ja selle variatsioonid. Näiteks, netstat -i võib aidata lahendada vahetusmälu jälgimise probleemi. Parameeter, RX dropped packets (RX-DRP) selle käsu väljundis, kasvab üldiselt iseenesest, kuna langevad illegitiimsete protokollide (IPv6, Bad / Unintended VLAN tags jmt) tõttu. Kui aga kukkumised toimuvad muul põhjusel, siis tasub kasutada selle käskluse artikkel, et alustada uurimist ja mõista, miks see võrgu liides pakette langeb. Põhjust teada saades on ka seadme tööd võimalik optimeerida.

Kui on aktiveeritud Monitoring blade, siis saab neid andmeid visuaalselt vaadata SmartConsole's, klõpsates objektil ja valides valiku "Device & License Information".

Pidevalt ei soovita Monitoring blade'i aktiivseks jätta, kuid testimiseks võib see olla päevaks täiesti sobiv.

Veelgi enam, saab jälgimiseks lisada rohkem parameetreid, üks neist on väga kasulik – Bytes Throughput (seadmest läbilaske võime).

Kui on mõni muu jälgimissüsteem, näiteks tasuta Zabbix, mis põhineb SNMP-l, sobib see samuti probleemide tuvastamiseks.

2. „Mälu leke“ aja jooksul

Tihti tekib küsimus, et ajaga hakkab värav või haldusserver üha rohkem RAM-i tarbima. Soovin rahustada: see on tavaline olukord Linuxi-sarnastes süsteemides.

Vaadates käskude väljundit free -m ja cpstat -f memory os ekspertrežiimist seadmes, saab välja arvutada ja vaadata kõiki RAM-iga seotud parameetreid.

Kohapeal olev mälu värava kohta praegu Vaba mälu + Puhvrimälu + Vahemälu = +-1.5 GB, tavaliselt.

Kuidas öeldakse, aja jooksul optimeerib värav/haldusserver ja kasutab üha rohkem mälu, jõudes umbes 80% kasutuseni, ja jääb seal. Saate seadet taaskäivitada, ja siis näitaja lähtestatakse. 1.5 GB vaba RAM-i on väravale kindlasti piisav kõigi ülesannete täitmiseks, kuid haldussüsteem harva jõuab sellistele piirväärtustele.

Samuti näitavad nimetatud käskude väljundid, kui palju teil on Madala mälu (operatiivmälu kasutaja ruumis) ja Kõrge mälu (operatiivmälu kernelis) kasutatud.

Kerneliprotsessid (sealhulgas aktiivsed moodulid, nagu Check Point kernel moodulid) kasutavad ainult madalat mälu. Kuid kasutaja protsessid võivad kasutada nii madalat kui ka kõrget mälu. Lisaks on madala mälu summa umbes Kogu mälu.

Peaksite muretsema ainult juhul, kui logides hakkavad ilmuma vead „moodulid taaskäivituvad või protsessid tapetakse mälu vabastamiseks OOM (Vähe mälu) tõttu“. Siis tuleks värav taaskäivitada ja pöörduda toe poole, kui taaskäivitamine ei aita.

Täieliku kirjelduse leiate sk99547 ja sk99593.

3. Optimeerimine

Allpool on küsimused ja vastused CPU ja RAM-i optimeerimise kohta. Neile tasub ausalt vastata ja soovitusi kuulata.

3.1. Kas apllainss oli õigesti valitud? Kas pilotprojekt oli olemas?

Hoolimata õigesti teostatud mõõtmistest, võis võrk lihtsalt laieneda ja antud seadmed ei suuda koormusega toime tulla. Teine variant on see, et mõõtmisi üldse ei tehtud.

3.2. Kas HTTPS-i kontrollimine on sisse lülitatud? Kui jah, siis kas tehnoloogiat on seadistatud parimate praktikate järgi?

Pöörduge artikli, kui olete meie klient, või sk108202.

HTTPS-i kontrollimise poliitika reeglite paigutamine mängib suurt rolli HTTPS-i saitide avamise optimeerimisel.

Soovitatud reeglite paigutamine:

1. Bypass reeglid kategooriatega/URL-idega
2. Inspect reeglid kategooriate/URL-dega
3. Inspect reeglid teiste kategooriate jaoks

Sarnaselt tulemüüripoliitikaga otsib Check Point pakettide osas ühtivust ülevalt alla, seetõttu on bypass reeglid parem paigutada kõrgele, kuna värav ei kuluta ressursse kõigi reeglite läbi töötamiseks, kui paketti tuleb vahele jätta.

3.3 Kas on kasutusel address-range objektid?

Aadressivahemiku objekdid, näiteks võrk 192.168.0.0-192.168.5.0, võtavad oluliselt rohkem RAM-i kui 5 võrgueelikut. Üldiselt on heaks tavaks eemaldada kasutamata objekte SmartConsole'ist, kuna iga kord poliitika rakendamisel kulutab värav ja haldussüsteem ressursse ja, mis veelgi tähtsam, aega, et valideerida ja rakendada poliitikat.

3.4. Kuidas on seadistatud Threat Prevention poliitika?

Esiteks soovitab Check Point viia IPS eraldi profiilile ja luua selle bledi jaoks eraldi reeglid.

Näiteks peab haldur vajalikuks DMZ segmenti kaitsta ainult IPS-iga. Seetõttu ei tohiks värav kulutada ressursse teiste bleditega pakettide töötlemiseks, vaid tuleb luua reegel selle segmendi jaoks, kus on aktiveeritud ainult IPS.

Profiilide seadistamise osas soovitatakse seda seadistada parimate praktikate kohaselt selles dokument(lk 17-20).

3.5. IPS-i seadetes kui palju allkirju on Detect režiimis?

Soovitav on intensiivselt töötada allkirjade kallal, kuna tuleb välja lülitada kasutamata allkirjad (näiteks Adobe toodete ärakasutamise allkirjad vajavad palju arvutusvõimet ja kui kliendil ei ole neid tooteid, on mõistlik need allkirjad välja lülitada). Seejärel tuleks Prevent seada Detecti asemel seal, kus võimalik, kuna värav kulutab ressursse kõigi ühenduste töötlemiseks Detect režiimis; Prevent režiimis lükatakse ühendus kohe tagasi ja ei kulutata ressursse paketi täielikuks töötlemiseks.

3.6. Milliseid faile töötlevad Threat Emulation, Threat Extraction, Anti-Virus bleid?

Pole ei ole mõtet emuleerida ja analüüsida laiendeid, mida teie kasutajad ei laadige alla, või mida te oma võrgus vajamatuks peate (nt bat, exe faile saab hõlpsasti blokeerida Content Awareness blade'i abil tulemüüris, seega väheneb ka väravate ressursikasutus). Veelgi enam, Threat Emulation seadetes saate valida Emuleerimise keskkonna (operatsioonisüsteemi), ja kui kõik kasutajad töötavad 10. versioonil, pole ka mõtet valida Windows 7 keskkonda.

3.7. Kas tulemüürireeglid ja rakendustaseme reeglid on vastavuses parimate praktikate nõuetega?

Kui reegli puhul on palju klikke (vastavusi), soovitatakse need asetada kõige ülemisse ritta, ja väheste klikkidega reeglid — kõige alumisse. Peamine on jälgida, et need ei kataks ega takistaks üksteist. Soovitatav tulemüüripoliitika arhitektuur:

Selgitused:

Esimese reegli — siia paigutatakse reeglid, millel on kõige rohkem vastavusi
Müra reegel — reegel, mis sünnib kõrvalise liikluse, näiteks NetBIOS, eemaldamiseks
Salajane reegel — keelata juurdepääs väravatele ja haldusteenustele, välja arvatud need allikad, mis on määratud Authentication to Gateway Reeglite seadetes
Clean-Up, Last ja Drop Reeglid, tavaliselt, ühendatakse üheks reegliks, et keelata kõik, mis ei olnud eelnevalt lubatud

Need parimate praktikate andmed on kirjas sk106597.

3.8. Millised seadistused on loodud administraatorite teenustele?

Näiteks, luuakse mõni TCP teenus kindlal pordil, ja Advanced seadetest tuleb eemaldada märge “Match for Any”. Sel juhul allub see teenus konkreetselt reeglile, milles ta esineb, ja ei osale reeglites, kus Services veerus on Any.

Rääkides teenustest, tuleb mainida, et mõnikord on vajalik timmida ajakohastusi. See seadistus võimaldab tõhusamalt kasutada värava ressursse, et mitte hoida TCP/UDP sessioone kauem, kui suurt ajapuudutust nad ei vaja. Näiteks, alloleval ekraanipildil, viisin domain-udp teenuse ajakohastuse 40 sekundilt 30 sekundile.

3.9. Kas kasutatakse SecureXL-i ja kui suur on kiiruskasv?

SecureXL-i töö kvaliteeti saab kontrollida peamiste käskudega eksperdirežiimis väravas fwaccel stat ja fw accel stats -s. Edasi tuleb arutada, millist liiklust kiirusel kiirendatakse, milliseid malle (templates) saab veel luua.

Vaikimisi ei ole Drop Templates lubatud, nende lubamine parandab SecureXL'i töö. Selleks minge luku seadistustesse ja vahekaardile Optimizations:

Klastri töötamise korral, et optimeerida CPU-d, on võimalik keelata mitte kriitiliste teenuste sünkroonimine, nagu UDP DNS, ICMP ja teised. Selleks peaksite minema teenuse seadistustesse → Täiendav → Sünkroniseeri ühendusi, kui Stateful Synchronization on klastris lubatud.

Kõik parimad praktikad on kirjeldatud sk98348.

3.10. Kuidas kasutatakse CoreXl?

CoreXL tehnoloogia, mis võimaldab kasutada mitmeid CPU-sid firewall'i instantside (firewall'i moodulite) jaoks, aitab kindlasti seadme tööd optimeerida. Esiteks käsk fw ctl affinity -l -a näitab kasutatavaid firewall'i instantside ja protsessorite arvu, mis on suunatud SND (moodul, mis jaotab liiklust firewall'i elementide vahel). Kui kasutada ei ole kõiki protsessoreid, on võimalik neid lisada käsuga cpconfig lukus.
Samuti on hea mõte paigaldada kuumapatch Multi-Queue lubamiseks. Multi-Queue lahendab probleemi, kui SND kasutab protsessorit kõrge protsendi ulatuses, samas kui firewall'i instantsid teistel protsessoritel seisavad idle. Siis oleks SND-l võimalus luua palju järjekordi ühe NIC-i jaoks ja määrata erinevad prioriteedid erinevale liiklusele tuuma tasemel. Seega hakkavad CPU tuumad olema ratsionaalsemalt kasutatud. Meetodid on samuti kirjeldatud sk98348.

Kokkuvõttes tahaksin öelda, et need ei ole kaugeltki kõik parimad praktikad Check Pointi töö optimeerimisel, kuid kindlasti kõige populaarsemad. Kui soovite tellida oma turvapoliitika auditi või lahendada probleem, mis on seotud Check Pointiga, võtke meiega palun ühendust aadressil sales@tssolution.ru.

Aitäh tähelepanu eest!

Allikas: habr.com