Tere, kolleegid! Täna tahaksin arutada paljude Check Pointi administraatorite jaoks aktuaalset teemat „CPU ja RAM-i optimeerimine“. Tihti juhtub, et värav ja/või haldusserver tarbivad ootamatult palju neid ressursse, ja tahaks teada, kuhu need "kaovad", ning kasutada neid võimalikult tõhusalt.
1. Analüüs
Protsessori koormuse analüüsimiseks on kasulikud järgmised käsud, mis sisestatakse ekspertrežiimis:
top näitab kõiki protsesse, nende CPU ja RAM-i tarbimise protsentides, tööaega, protsessi prioriteeti ja reaalses ajasja
cpwd_admin list Check Point WatchDog Daemon, mis näitab kõiki seadme mooduleid, nende PID-e, olekut ja käivitamiste arvu
cpstat -f cpu os CPU kasutamine, nende arv ja protsentuaalne jaotus protsessoriga seotud ajast
cpstat -f memory os virtuaalse RAM-i kasutamine, kui palju on kokku aktiivset, vaba RAM-i ja muud
Õigeks märkuseks on see, et kõiki cpstat käske saab vaadata utiliidi cpview. Selleks piisab, kui sisestada käsk cpview mistahes režiimis SSH-seansis.
ps auxwf pikad loendid kõikidest protsessidest, nende ID-d, kasutatav virtuaalne mälu ja RAM, CPU
Teised käskvariatsioonid:
ps -aF näitab kõige ressursimahukamat protsessi
fw ctl affinity -l -a tuumikute jaotamine erinevate kohalike tulemüüri instantside vahel, see tähendab tehnoloogiat CoreXL
fw ctl pstat RAMi analüüs ja üldised ühenduste, küpsiste, NATi näitajad
free -m RAMi puhvrid
Eraldi tähelepanu väärib käsk netsat ja selle variatsioonid. Näiteks, netstat -i võib aidata vahetuste monitorimise ülesandes. Parameeter RX dropped packets (RX-DRP) selle käsu väljundis kasvab tavaliselt iseenesest kahjulike protokollide (IPv6, Vale / Mitte soovitud VLAN-i sildid ja teised) tõttu. Kuid kui kaotused toimuvad muudel põhjustel, siis tasub kasutada antud , et alustada uurimist ja mõista, miks see võrgu liides pakette loob. Põhjuse teada saades saab ka seadme tööd optimeerida.
Kui Monitoring blade on sisse lülitatud, saab neid näitajaid vaadata graafiliselt SmartConsole'is, klõpsates objektile ja valides 'Seade & Litsentsi teave'.
Pidevalt Monitoring blade'i sisse lülitamist ei soovitata, kuid üheks päevaks testimiseks on see täiesti võimalik.
Veelgi enam, saab jälgimiseks lisada rohkem parameetreid, millest üks on väga kasulik — Bytes Throughput (seadme 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. „Mälu“ lekke probleem aja jooksul
Sageli tekib küsimus, et ajaga hakkab värav või haldusserver järjest enam RAM-i tarbima. Tahaksin rahustada: see on normaalne käitumine Linuxi sarnastes süsteemides.
Vaadates käskude väljundit free -m ja cpstat -f memory os spetsialisti režiimis seadmes, saab lugeda ja vaadata kõiki RAM-iga seotud parameetreid.
Hetkel väraval saadaolev mälu Vaba mälu + Puhversüsteemi mälu + Vahepealset mälu = +-1,5 GB, enamasti.
Nagu ekspert ütleb, optimeerib värav/haldusserver aja jooksul ning tarbib järjest rohkem mälu, jõudes umbes 80% kasutamiseni ja peatudes. Saate seadme taaskäivitada, ja siis näitaja lähtestatakse. 1,5 GB vaba RAM-i on väravale piisav kõigi ülesannete täitmiseks, ja haldus harva jõuab sellistele piirangutele.
Samuti näitavad nende käskude väljundid, kui palju teil on Madala mälu (operatiivmälu kasutajasfääris) ja Kõrge mälu (operatiivmälu kernelis) kasutatud.
Kernel'i protsessid (sealhulgas aktiivsed moodulid nagu Check Point kernel moodulid) kasutavad ainult madalat mälu. Kuid kasutaja protsessid võivad kasutada nii madalat kui ka suurt mälu. Veelgi enam, madal mälu on ligikaudu võrdne Kogumälu.
Muretsemiseks on vaid juhtumid, kui logides ilmnevad vead «moodulite taaskäivitamine või protsesside lõpetamine, et taastada mälu OOM (Out of Memory) tõttu». Siis tuleks ruuter taaskäivitada ja pöörduda toe poole, kui taaskäivitamine ei aita.
Täispisikut leiate ja .
3. Optimeerimine
Allpool on küsimused ja vastused CPU ja RAM-i optimeerimise kohta. Neile tasub endalt ausalt vastata ja soovitusi kuulata.
3.1. Kas seadme valik on olnud õige? Kas pilootprojekt on toimunud?
Hoolimata korralikust suurendamisest, on võrk võinud lihtsalt laieneda ja see varustus ei suuda koormust taluda. Teine variant on see, et suurendamist ei olnud üldse.
3.2. Kas HTTPS-i kontroll on sisse lülitatud? Kui jah, kas tehnoloogia on seadistatud parimate praktikate kohaselt?
Pöörduda , kui olete meie klient, või .
HTTPS-i inspectimise poliitikas reeglite paigutus mängib olulist rolli HTTPS-i veebisaitide avamise optimeerimisel.
Soovitatav reeglite seadmine järjestus:
- BYPASS reeglid kategooriatele/URL-idele
- INSPECT reeglid kategooriatele/URL-idele
- INSPECT reeglid kõigile teistele kategooriatele
Sarnaselt tulemüüri poliitikale, otsib Check Point pakettide üksteise järel vastavusi, seetõttu on parem paigutada bypass reeglid ülespoole, et värav ei kulutaks ressursse kõigi reeglite läbi käimisele, kui see pakett tuleb lihtsalt vahele jätta.
3.3 Kas kasutatakse aadresside vahemike objekte?
Aadresside vahemiku objektid, näiteks võrk 192.168.0.0-192.168.5.0, nõuavad märksa rohkem RAM-i kui 5 võrgu objekti. Üldiselt peetakse heaks tavaks eemaldada kasutamata objekte SmartConsole's, kuna iga kord poliitika seadistamisel kulutab värav ja haldusteenus ressursse ja, mis kõige tähtsam, aega, et valideerida ja rakendada poliitikat.
3.4. Kuidas on seadistatud Threat Prevention poliitika?
Esiteks soovitab Check Point viia IPS eraldi profiili ja luua selle blade'i jaoks eraldi reeglid.
Näiteks arvab administreerija, et DMZ sektorit tuleb kaitsta ainult IPS-i abil. Seetõttu on vaja luua reegel, mis on suunatud just sellele sektorile koos profiiliga, kus on lubatud ainult IPS, et värav ei raiskaks ressursse pakettide töötlemiseks teiste bлейdide kaudu.
Profiilide seadistamise osas on soovitatav need seadistada parimate praktikate kohaselt, (leheküljed 17-20).
3.5. Kui palju allkirju on IPS-i seadetes režiimis Detect?
Soovitav on hoolikalt läheneda allkirjade seadistamisele, kuna tuleks välja lülitada kasutamata allkirjad (näiteks Adobe toodete ekspluateerimise allkirjad nõuavad palju arvutusvõimsust, ja kui kliendil selliseid tooteid pole, on mõistlik need välja lülitada). Edasi on soovitatav panna Prevent nende alla, kus see on võimalik, kuna värav kulutab ressursse kogu ühenduse töötlemiseks režiimis Detect, samas kui režiimis Prevent lükkab see ühenduse kohe tagasi ja ei raiska ressursse paketi täielikuks töötlemiseks.
3.6. Milliseid faile töötlevad Threat Emulation, Threat Extraction, Anti-Virus bлейdid?
Ei ole mõtet emuleerida ja analüüsida faililaiendeid, mida teie kasutajad ei laadi alla või mida peetakse teie võrgus ebavajalikuks (näiteks bat, exe faile saab kergesti blokeerida Content Awareness reed prääniku tasemel, seega kuluvad värava ressursid vähem). Veelgi enam, Threat Emulation seadetes saab valida keskkonda (operatsioonisüsteemi), et emuleerida ohte liivakastis, ja seada keskkond Windows 7, kui kõik kasutajad töötavad 10. versiooniga, ei ole samuti mõistlik.
3.7. Kas tulemüüri reeglid ja rakendustasandi reeglid on paigutatud vastavalt parimatele praktikatele?
Kui reegli kohta on palju hitte (kokkulangevusi), soovitatakse need asetada kõige kõrgemale, samas kui reeglid, millel on vähe hitte, tuleks paigutada kõige madalamale. Peamine on jälgida, et need ei kattuks ega segaks üksteist. Soovitatav tulemüüri poliitika arhitektuur:
Selgitused:
Esimese reeglid — siia paigutatakse reeglid, millel on suurim kokkulangevuste arv
Müra reegel — reegel, mis filtreerib välja parasiitset liiklust, nagu NetBIOS
Stealth Rule — keelatud on ühendused kõikide väravate ja halduritega, välja arvatud need allikad, mis on märgitud Authentication to Gateway Rules reeglites.
Clean-Up, Last ja Drop Rules koondatakse reeglina ühte reegli, et keelata kõik, mis varem ei olnud lubatud.
Parimate praktikate andmed on kirjeldatud .
3.8. Millised seaded on loodud administraatorite teenuste korral?
Näiteks luuakse mingi TCP teenus kindlal pordil, ning on mõistlik Advanced seadetes eemaldada märge "Match for Any". Sel juhul kuulub teenus konkreetsete reeglite alla, milles see esindatud on, ning ei osale reeglites, kus Services veerus on Any.
Rääkides teenustest, tuleks mainida, et mõnikord on vajalik ajutähtaegade täiendav seadistamine. See seadistus võimaldab paremat ressursside kasutamist väravas, et mitte hoida TCP/UDP seansse, mis ei vaja pikka ajavahemikku, liiga kaua. Näiteks, alloleval ekraanipildil, olen muutnud domain-udp teenuse ajutähtaega 40 sekundilt 30 sekundile.
3.9. Kas kasutatakse SecureXL-i ja kui suur on kiirusetõus?
SecureXL töö kvaliteeti saab kontrollida peamiste käskude kaudu ekspertrežiimis väravas. fwaccel stat ja fw accel stats -s. Edasi tuleb uurida, millist liiklust kiirendatakse, milliseid malli (templates) veel luua saab.
Vaikimisi ei ole Drop Templates sisse lülitatud, nende aktiveerimine toob SecureXL-ile kasu. Selleks minge seadistuste vahelehele ja valige Optimizations:
Samuti on klastritöös CPU optimeerimiseks võimalik keelata mitteoluliste teenuste sünkroniseerimine, nagu UDP DNS, ICMP ja teised. Selleks minge teenuse seadistustesse → Advanced → Synchronize connections of State Synchronization is enabled on the cluster.
Kõik parimad tavad on kirjeldatud .
3.10. Kuidas kasutatakse CoreXl-i?
CoreXL tehnoloogia, mis võimaldab kasutada mitmeid CPU-sid tulekahju seinte instantside (firewall instances) jaoks, aitab kindlasti seadme tööd optimeerida. Esiteks näitab käsk fw ctl affinity -l -a kasutatud tulekahju seinte instantsid ja protsessorid, mis on eraldatud SND (modul, mis jagab liiklust tulekahju seinte üksustele) jaoks. Kui kõik protsessorid ei ole kasutusel, saab need lisada käsuga cpconfig seadmes.
Samuti on hea variant installida Multi-Queue aktiveerimine. Multi-Queue lahendab probleemi, kus SND-ga protsessor on palju protsente kasutuses, samas kui tulemüüriteenused teistel protsessoritel seisavad. Seega saaks SND luua ühe NIC-i jaoks palju järjekordi ja seada erinevad prioriteedid eri liikluse jaoks tuuma tasandil. Järelikult kasutatakse CPU tuumasid tõhusamalt. Meetodid on kirjeldatud ka .
Kokkuvõtteks soovin öelda, et need ei ole kõik parimad tavad Check Pointi töö optimeerimiseks, vaid vaid kõige populaarsed. Kui soovite tellida oma turvapoliitika auditi või lahendada Check Pointiga seotud probleeme, palun pöörduge sales@tssolution.ru.
Aitäh tähelepanu eest!
Allikas: habr.com
