Tere kolleegid! Täna tahaksin arutada paljude Check Pointi administraatorite jaoks väga asjakohast teemat: "CPU ja RAM-i optimeerimine". Tihti tuleb ette juhtumeid, kus lüüs ja/või haldusserver tarbib ootamatult palju neid ressursse ning tahaks aru saada, kuhu need “voolavad” ja võimalusel targemalt kasutada.
1. Analüüs
Protsessori koormuse analüüsimiseks on kasulik kasutada järgmisi ekspertrežiimis sisestatavaid käske:
ülemine näitab kõiki protsesse, tarbitud protsessori ja RAM-i ressursside hulka protsentides, tööaega, protsessi prioriteeti ja reaalajasи
cpwd_admin loend Check Point WatchDog Daemon, mis näitab kõiki rakenduse mooduleid, nende PID-i, olekut ja käivituste arvu
cpstat -f CPU os Protsessori kasutus, nende arv ja protsessori aja jaotus protsentides
cpstat -f mälu os virtuaalse RAM-i kasutus, kui palju aktiivset RAM-i, vaba RAM-i ja palju muud
Õige märkus on see, et kõiki cpstat-käske saab utiliidi abil vaadata cpview. Selleks peate lihtsalt sisestama SSH-seansi mis tahes režiimist käsu cpview.
ps auxwf pikk nimekiri kõigist protsessidest, nende ID, hõivatud virtuaalmälu ja mälu RAM-is, CPU-s
Muud käsuvariandid:
ps-aF näitab kõige kallimat protsessi
fw ctl afiinsus -l -a tuumade levitamine erinevate tulemüüri eksemplaride jaoks, see tähendab CoreXL-tehnoloogia
fw ctl pstat RAM-i analüüs ja üldised ühenduse indikaatorid, küpsised, NAT
tasuta -m RAM-i puhver
Meeskond väärib erilist tähelepanu netsat ja selle variatsioonid. Näiteks, netstat -i võib aidata lahendada lõikepuhvrite jälgimise probleemi. Selle käsu väljundis olev parameeter RX-i väljalangenud paketid (RX-DRP) kasvab reeglina ebaseaduslike protokollide (IPv6, halvad / soovimatud VLAN-sildid ja muud) tõttu iseenesest. Kui aga kukkumised juhtuvad muul põhjusel, peaksite seda kasutama et alustada uurimist ja mõista, miks antud võrguliides pakette välja kukub. Pärast põhjuse väljaselgitamist saab äpi tööd ka optimeerida.
Kui jälgimisriba on lubatud, saate neid mõõdikuid SmartConsole'is graafiliselt vaadata, klõpsates objektil ja valides "Seadme ja litsentsi teave".
Monitoring tera ei ole soovitatav püsivalt sisse lülitada, kuid päeva jooksul testimiseks on see täiesti võimalik.
Lisaks saate lisada jälgimiseks rohkem parameetreid, üks neist on väga kasulik - Bytes Throughput (rakenduse läbilaskevõime).
Kui on mõni muu jälgimissüsteem näiteks tasuta , mis põhineb SNMP-l, sobib see ka nende probleemide tuvastamiseks.
2. RAM lekib aja jooksul
Tihti kerkib küsimus, et aja jooksul hakkab lüüsi- või haldusserver üha rohkem muutmälu tarbima. Tahan teid rahustada: see on Linuxi-laadsete süsteemide jaoks tavaline lugu.
Vaadates käskude väljundit tasuta -m и cpstat -f mälu os rakenduses ekspertrežiimis saate arvutada ja vaadata kõiki RAM-iga seotud parameetreid.
Põhineb lüüsis hetkel saadaoleval mälul Vaba mälu + Puhver mälu + Vahemälu = +-1.5 GB, tavaliselt.
Nagu CP ütleb, aja jooksul lüüsi-/haldusserver optimeerib ja kasutab üha rohkem mälu, saavutades umbes 80% kasutuse, ja peatub. Saate seadme taaskäivitada ja siis indikaator lähtestatakse. 1.5 GB vaba RAM-ist piisab täpselt selleks, et lüüs saaks täita kõiki ülesandeid ja haldus jõuab selliste läviväärtusteni harva.
Samuti näitavad mainitud käskude väljundid, kui palju teil on Vähe mälu (RAM kasutaja ruumis) ja Kõrge mälu (RAM kerneli ruumis) kasutatud.
Kerneli protsessid (sh aktiivsed moodulid, nagu Check Pointi tuumamoodulid) kasutavad ainult vähest mälu. Kasutajaprotsessid võivad aga kasutada nii madalat kui ka kõrget mälu. Veelgi enam, vähe mälu on ligikaudu võrdne Mälu kokku.
Peaksite muretsema ainult siis, kui logides on vigu "moodulid taaskäivituvad või protsessid tapetakse mälu taastamiseks OOM-i tõttu (mälu on otsas)". Seejärel peaksite lüüsi taaskäivitama ja võtma ühendust toega, kui taaskäivitamine ei aita.
Täieliku kirjelduse leiate aadressilt и .
3. Optimeerimine
Allpool on küsimused ja vastused protsessori ja RAM-i optimeerimise kohta. Peaksite neile endale ausalt vastama ja soovitusi kuulama.
3.1. Kas rakendus valiti õigesti? Kas oli pilootprojekt?
Vaatamata õigele suurusele võib võrk lihtsalt kasvada ja see seade lihtsalt ei suuda koormusega toime tulla. Teine võimalus on see, kui suurust kui sellist ei olnud.
3.2. Kas HTTPS-i kontroll on lubatud? Kui jah, siis kas tehnoloogia on konfigureeritud parima tava järgi?
Viitama , kui olete meie klient või .
HTTPS-i kontrollipoliitika reeglite järjekord mängib HTTPS-i saitide avamise optimeerimisel suurt rolli.
Reeglite soovitatav järjekord:
- Kategooriate/URL-idega reeglitest möödaminek
- Kontrollige reegleid kategooriate/URL-idega
- Kontrollige kõigi teiste kategooriate reegleid
Analoogiliselt tulemüüripoliitikaga otsib Check Point vastet pakettide järgi ülalt alla, seega on parem paigutada möödaviigureeglid ülaossa, kuna lüüs ei raiska ressursse kõigi reeglite läbimiseks, kui see pakett seda vajab. läbida.
3.3 Kas kasutatakse aadressivahemiku objekte?
Aadressivahemikuga objektid, näiteks võrk 192.168.0.0-192.168.5.0, võtavad oluliselt rohkem RAM-i kui 5 võrguobjekti. Üldiselt peetakse heaks tavaks kasutamata objektide eemaldamist SmartConsole'ist, kuna iga kord, kui poliitika installitakse, kulutavad lüüs ja haldusserver poliitika kontrollimisele ja rakendamisele ressursse ja, mis kõige tähtsam, aega.
3.4. Kuidas on ohuennetuse poliitika konfigureeritud?
Esiteks soovitab Check Point paigutada IPS eraldi profiili ja luua selle tera jaoks eraldi reeglid.
Näiteks usub administraator, et DMZ segmenti tuleks kaitsta ainult IPS-i abil. Seetõttu, et lüüs ei raiskaks ressursse pakettide töötlemisele teiste labade poolt, on vaja luua spetsiaalselt selle segmendi jaoks reegel profiiliga, milles on lubatud ainult IPS.
Mis puudutab profiilide seadistamist, siis on soovitatav see seadistada vastavalt selle parimatele tavadele (lk 17-20).
3.5. Kui palju allkirju on IPS-i sätetes tuvastamisrežiimis?
Soovitatav on hoolikalt uurida allkirju selles mõttes, et kasutamata tuleks keelata (näiteks Adobe'i toodete töötamiseks mõeldud signatuurid nõuavad palju arvutusvõimsust ja kui kliendil selliseid tooteid pole, on mõttekas allkirjad keelata). Järgmiseks pange võimalusel tuvastamise asemel funktsioon Prevent, sest lüüs kulutab ressursse kogu ühenduse töötlemiseks tuvastusrežiimis, ennetusrežiimis loobib ühenduse koheselt ega raiska ressursse paketi täielikule töötlemisele.
3.6. Milliseid faile töötlevad ohuemuleerimine, ohu eemaldamine ja viirusetõrje labad?
Ei ole mõtet emuleerida ja analüüsida laienduste faile, mida kasutajad alla ei laadi või mida teie võrgus ei pea (näiteks nahkhiire, exe-faile saab tulemüüri tasemel sisuteadlikkuse tera abil hõlpsasti blokeerida, nii et vähem lüüsi ressursse kulutatakse). Veelgi enam, ohtude emuleerimise sätetes saate liivakastis ohtude emuleerimiseks valida keskkonna (operatsioonisüsteemi) ja keskkonna Windows 7 installimine, kui kõik kasutajad töötavad versiooniga 10, pole samuti mõttekas.
3.7. Kas tulemüüri ja rakenduse taseme reeglid on korraldatud parimate tavade kohaselt?
Kui reeglil on palju tabamusi (vasteid), on soovitatav need asetada kõige ülaossa ja väikese tabamuste arvuga reeglid päris alla. Peaasi on tagada, et need ei ristuks ega kattu üksteisega. Soovitatav tulemüüripoliitika arhitektuur:
Selgitus:
Esimesed reeglid – siia paigutatakse suurima vastete arvuga reeglid
Mürareegel – võltsliikluse, näiteks NetBIOS-i, kõrvaldamise reegel
Stealth Rule - keelab kõned lüüsidele ja haldustele kõigile, välja arvatud need allikad, mis on määratud lüüsi autentimise reeglites
Puhastamise, viimase ja mahajätmise reeglid ühendatakse tavaliselt üheks reegliks, et keelata kõik, mis varem polnud lubatud
Parimate tavade andmeid kirjeldatakse artiklis .
3.8. Millised seaded on administraatorite loodud teenustel?
Näiteks mõni TCP-teenus luuakse kindlas pordis ja teenuse täpsemates sätetes on mõttekas eemaldada märge „Match for any”. Sel juhul kuulub see teenus konkreetselt selle reegli alla, milles see kuvatakse, ega osale reeglites, mille veerus Teenused on loetletud Kõik.
Teenustest rääkides tasub mainida, et mõnikord on vaja aegumistähtajaid korrigeerida. See säte võimaldab teil kasutada lüüsi ressursse targalt, et mitte hoida lisaaega protokollide TCP/UDP seansside jaoks, mis ei vaja suurt ajalõppu. Näiteks alloleval ekraanipildil muutsin domeeni-udp teenuse ajalõpu 40 sekundilt 30 sekundile.
3.9. Kas SecureXL-i kasutatakse ja kui suur on kiiruse protsent?
SecureXL-i kvaliteeti saate kontrollida lüüsi ekspertrežiimis põhikäskude abil fwaccel stat и fw accel stats -s. Järgmiseks peate välja selgitama, millist liiklust kiirendatakse ja milliseid muid malle saab luua.
Drop Templates pole vaikimisi lubatud; nende lubamine toob kasu SecureXL-ile. Selleks avage lüüsi seaded ja vahekaart Optimeeringud:
Samuti saate CPU optimeerimiseks klastriga töötades keelata mittekriitiliste teenuste, näiteks UDP DNS, ICMP ja teiste sünkroonimise. Selleks minge teenuse seadetesse → Täpsemalt → Ühenduste sünkroonimine. Oleku sünkroonimine on klastris lubatud.
Kõiki parimaid tavasid on kirjeldatud artiklis .
3.10. Kuidas CoreXli kasutatakse?
Seadme tööd aitab kindlasti optimeerida CoreXL tehnoloogia, mis võimaldab tulemüüri eksemplaride (tulemüürimoodulite) jaoks kasutada mitut CPU-d. Meeskond kõigepealt fw ctl afiinsus -l -a näitab kasutatud tulemüüri eksemplare ja SND-le (moodul, mis jaotab liiklust tulemüüri olemitele) määratud protsessoreid. Kui kõiki protsessoreid ei kasutata, saab neid käsuga lisada cpconfig väravas.
Ka hea lugu on panna Multi-Queue lubamiseks. Multi-Queue lahendab probleemi, kui SND-ga protsessorit kasutatakse paljudes protsentides ja teiste protsessorite tulemüüri eksemplarid on jõude. Siis oleks SND-l võimalus luua ühele NIC-ile palju järjekordi ja seada kerneli tasemel erinevale liiklusele erinevad prioriteedid. Järelikult kasutatakse CPU tuumasid intelligentsemalt. Tehnikaid on kirjeldatud ka artiklis .
Kokkuvõtteks tahaksin öelda, et need pole kõik Check Pointi optimeerimise parimad tavad, kuid need on kõige populaarsemad. Kui soovite tellida oma turvapoliitika auditit või lahendada Check Pointiga seotud probleemi, võtke ühendust [meiliga kaitstud].
Tänan teid tähelepanu eest!
Allikas: www.habr.com