Hello kollégák! Ma egy nagyon fontos témát szeretnék megvitatni sok Check Point rendszergazdának: „CPU és RAM optimalizálása”. Gyakran vannak olyan esetek, amikor az átjáró és/vagy a felügyeleti szerver váratlanul sokat fogyaszt ezekből az erőforrásokból, és szeretném megérteni, hová „folynak”, és ha lehetséges, intelligensebben használni.
1. Elemzés
A processzorterhelés elemzéséhez hasznos a következő parancsok használata, amelyeket szakértői módban adnak meg:
felső megmutatja az összes folyamatot, a felhasznált CPU és RAM erőforrások mennyiségét százalékban, az üzemidőt, a folyamatprioritást és valós időbenи
cpwd_admin lista Check Point WatchDog Daemon, amely megmutatja az összes alkalmazásmodult, azok PID-jét, állapotát és az indítások számát
cpstat -f cpu os CPU-használat, számuk és a processzoridő százalékos megoszlása
cpstat -f memória operációs rendszer virtuális RAM használat, mennyi aktív, ingyenes RAM és még sok más
A helyes megjegyzés az, hogy az összes cpstat parancs megtekinthető a segédprogrammal cpview. Ehhez csak be kell írnia a cpview parancsot az SSH-munkamenet bármelyik módjából.
ps auxwf az összes folyamat hosszú listája, azonosítójuk, elfoglalt virtuális memória és memória a RAM-ban, CPU-ban
Egyéb parancsváltozatok:
ps-aF a legdrágább eljárást mutatja
fw ctl affinitás -l -a magok elosztása különböző tűzfalpéldányokhoz, vagyis a CoreXL technológiához
fw ctl pstat RAM elemzés és általános kapcsolatjelzők, cookie-k, NAT
szabad -m RAM puffer
A csapat külön figyelmet érdemel netsat és annak variációi. Például, netstat -i segíthet megoldani a vágólapok figyelésének problémáját. A parancs kimenetében szereplő RX-eldobott csomagok (RX-DRP) paraméter általában önmagában nő az illegitim protokollok (IPv6, rossz / nem szándékolt VLAN-címkék és mások) miatt. Ha azonban a cseppek más okból történnek, akkor ezt kell használnia hogy elkezdjük vizsgálni és megérteni, hogy egy adott hálózati interfész miért dob ki csomagokat. Az ok kiderítése után az alkalmazás működése is optimalizálható.
Ha a Monitoring blade engedélyezve van, megtekintheti ezeket a mutatókat grafikusan a SmartConsole-ban, ha rákattint az objektumra, és kiválasztja az „Eszköz- és licencinformáció” lehetőséget.
Nem ajánlott állandó jelleggel bekapcsolni a Monitoring blade-t, de egy napig tesztelésre ez teljesen lehetséges.
Sőt, további paramétereket is hozzáadhat a megfigyeléshez, ezek egyike nagyon hasznos - Bytes Throughput (alkalmazás átviteli sebessége).
Ha van más felügyeleti rendszer, például ingyenes , SNMP alapján ezeknek a problémáknak az azonosítására is alkalmas.
2. A RAM idővel szivárog
Gyakran felmerül a kérdés, hogy idővel az átjáró vagy a felügyeleti szerver egyre több RAM-ot fogyaszt. Szeretnélek megnyugtatni: ez egy normális történet a Linux-szerű rendszerek számára.
Nézzük a parancsok kimenetét szabad -m и cpstat -f memória operációs rendszer az alkalmazásban szakértői módból kiszámíthatja és megtekintheti a RAM-mal kapcsolatos összes paramétert.
Az átjárón jelenleg rendelkezésre álló memória alapján Szabad memória + Pufferek memória + Gyorsítótárazott memória = +-1.5 GB, általában.
Ahogy a CP mondja, az átjáró/felügyeleti szerver idővel optimalizálja és egyre több memóriát használ, elérve a 80%-os kihasználtságot, majd leáll. Újraindíthatja az eszközt, majd a jelző visszaáll. 1.5 GB szabad RAM pontosan elég ahhoz, hogy az átjáró minden feladatot elvégezzen, és a menedzsment ritkán éri el az ilyen küszöbértékeket.
Az említett parancsok kimenetei is megmutatják, hogy mennyi van Alacsony memória (RAM a felhasználói térben) és Nagy memória (RAM a kerneltérben) használt.
A kernelfolyamatok (beleértve az aktív modulokat, például a Check Point kernelmodulokat) csak kevés memóriát használnak. A felhasználói folyamatok azonban használhatnak alacsony és magas memóriát is. Ezenkívül az alacsony memória körülbelül egyenlő Total Memory.
Csak akkor kell aggódnia, ha hibák vannak a naplókban "A modulok újraindulnak, vagy a folyamatok leállnak, hogy visszanyerjék a memóriát az OOM miatt (Kifogyott a memória)". Ezután indítsa újra az átjárót, és lépjen kapcsolatba a támogatással, ha az újraindítás nem segít.
A teljes leírás megtalálható a и .
3. Optimalizálás
Az alábbiakban kérdések és válaszok találhatók a CPU és a RAM optimalizálásával kapcsolatban. Őszintén válaszolnia kell rájuk magának, és meg kell hallgatnia az ajánlásokat.
3.1. Helyesen választották ki a pályázatot? Volt kísérleti projekt?
A megfelelő méret ellenére a hálózat egyszerűen növekedhet, és ez a berendezés egyszerűen nem tud megbirkózni a terheléssel. A második lehetőség az, ha nem lenne méretezés.
3.2. A HTTPS ellenőrzés engedélyezve van? Ha igen, a technológia a legjobb gyakorlat szerint van konfigurálva?
Hivatkozni , ha Ön ügyfelünk, vagy a .
A HTTPS-ellenőrzési szabályzat szabályainak sorrendje nagy szerepet játszik a HTTPS-oldalak megnyitásának optimalizálásában.
A szabályok ajánlott sorrendje:
- A szabályok megkerülése kategóriákkal/URL-ekkel
- Ellenőrizze a szabályokat kategóriákkal/URL-ekkel
- Vizsgálja meg az összes többi kategória szabályait
A tűzfalszabályzathoz hasonlóan a Check Point felülről lefelé csomagok alapján keresi az egyezést, ezért jobb a bypass szabályokat a legfelülre helyezni, mivel az átjáró nem pazarolja az erőforrásokat az összes szabály átfutására, ha a csomagnak szüksége van rá. átadni.
3.3 Használnak-e címtartomány objektumokat?
A címtartományú objektumok, például a 192.168.0.0-192.168.5.0 hálózat lényegesen több RAM-ot foglalnak el, mint 5 hálózati objektum. Általában jó gyakorlatnak tekinthető a nem használt objektumok eltávolítása a SmartConsole-ból, mivel minden alkalommal, amikor egy házirendet telepítenek, az átjáró és a felügyeleti kiszolgáló erőforrásokat, és ami a legfontosabb, időt fordít a házirend ellenőrzésére és alkalmazására.
3.4. Hogyan van konfigurálva a fenyegetésmegelőzési házirend?
Mindenekelőtt a Check Point azt javasolja, hogy helyezze el az IPS-t egy külön profilba, és hozzon létre külön szabályokat ehhez a blade-hez.
Például egy rendszergazda úgy véli, hogy a DMZ szegmenst csak IPS-sel kell védeni. Ezért annak elkerülése érdekében, hogy az átjáró erőforrásokat pazaroljon a csomagok más pengék általi feldolgozására, létre kell hozni egy szabályt kifejezetten ehhez a szegmenshez, olyan profillal, amelyben csak az IPS engedélyezett.
A profilok beállítását illetően az itt bevált gyakorlatok szerint javasolt a beállítás (17-20. oldal).
3.5. Az IPS-beállításokban hány aláírás van Detect módban?
Javasoljuk, hogy alaposan tanulmányozza át az aláírásokat abban az értelemben, hogy a használaton kívülieket le kell tiltani (például az Adobe-termékek működéséhez szükséges aláírások nagy számítási teljesítményt igényelnek, és ha az ügyfél nem rendelkezik ilyen termékekkel, akkor érdemes letiltani az aláírásokat). Ezután tegye a Megakadályozást a Detect helyett, ahol lehetséges, mert az átjáró a teljes kapcsolat feldolgozására fordítja az erőforrásokat Detect módban; Megelőzés módban azonnal eldobja a kapcsolatot, és nem pazarolja az erőforrásokat a csomag teljes feldolgozására.
3.6. Milyen fájlokat dolgoz fel a fenyegetésemuláció, a fenyegetés-kivonás és a víruskereső pengék?
Nincs értelme emulálni és elemezni azokat a kiterjesztések fájljait, amelyeket a felhasználók nem töltenek le, vagy amelyeket szükségtelennek tartanak a hálózaton (például bat, exe fájlok könnyen blokkolhatók a tűzfalszintű Content Awareness blade segítségével, így kevesebb az átjáró forrásokat kell elkölteni). Ezenkívül a Fenyegetés-emuláció beállításaiban kiválaszthatja a Környezetet (operációs rendszer) a fenyegetések homokozóban történő emulálásához, és a Windows 7 környezet telepítése sem értelmes, amikor minden felhasználó a 10-es verzióval dolgozik.
3.7. A tűzfal és az alkalmazás szintű szabályok a legjobb gyakorlatnak megfelelően vannak elrendezve?
Ha egy szabálynak sok találata (egyezése) van, akkor ajánlatos ezeket a legfelülre, a kevés találatot tartalmazó szabályokat pedig a legvégére helyezni. A lényeg annak biztosítása, hogy ne metsszék egymást, és ne fedjék át egymást. Javasolt tűzfalházirend-architektúra:
Magyarázat:
Első szabályok – a legtöbb mérkőzést tartalmazó szabályok itt kerülnek elhelyezésre
Zajszabály – szabály a hamis forgalom, például a NetBIOS elvetésére
Lopakodó szabály – tiltja az átjárók és felügyeletek hívását az összeshez, kivéve azokat a forrásokat, amelyeket az átjáró hitelesítési szabályai határoztak meg.
A Clean-Up, Last and Drop szabályokat általában egyetlen szabályba egyesítik, hogy tiltsanak mindent, ami korábban nem volt engedélyezett
A bevált gyakorlat adatait a .
3.8. Milyen beállításokkal rendelkeznek a rendszergazdák által létrehozott szolgáltatások?
Például egyes TCP-szolgáltatások egy adott porton jönnek létre, és célszerű törölni a „Match for Any” jelölést a szolgáltatás Speciális beállításainál. Ebben az esetben ez a szolgáltatás kifejezetten annak a szabálynak a hatálya alá esik, amelyben megjelenik, és nem vesz részt azon szabályokban, ahol a Szolgáltatások oszlopban Bármelyik szerepel.
A szolgáltatásokról szólva érdemes megemlíteni, hogy időnként szükség van az időtúllépések módosítására. Ez a beállítás lehetővé teszi az átjáró erőforrásainak okos felhasználását, hogy ne tartson túl sok időt a protokollok TCP/UDP-munkameneteihez, amelyek nem igényelnek nagy időtúllépést. Például az alábbi képernyőképen a domain-udp szolgáltatás időtúllépését 40 másodpercről 30 másodpercre módosítottam.
3.9. Használják a SecureXL-t, és mennyi a gyorsulási százalék?
A SecureXL minőségét az alapparancsokkal ellenőrizheti szakértői módban az átjárón fwaccel stat и fw accel stats -s. Ezután ki kell találnia, hogy milyen forgalom gyorsul, és milyen más sablonokat lehet létrehozni.
A Drop Templates alapértelmezés szerint nincs engedélyezve; engedélyezésük a SecureXL számára előnyös. Ehhez nyissa meg az átjáró beállításait és az Optimalizálások lapot:
Ezenkívül, ha fürttel dolgozik a CPU optimalizálása érdekében, letilthatja a nem kritikus szolgáltatások, például az UDP DNS, ICMP és mások szinkronizálását. Ehhez lépjen a szolgáltatásbeállítások → Speciális → Kapcsolatok szinkronizálása menüpontra. Az állapotszinkronizálás engedélyezve van a fürtön.
Az összes bevált gyakorlat leírása a .
3.10. Hogyan kell használni a CoreXl-t?
A CoreXL technológia, amely lehetővé teszi több CPU használatát a tűzfalpéldányokhoz (tűzfalmodulokhoz), mindenképpen segíti az eszköz működésének optimalizálását. Csapat az első fw ctl affinitás -l -a megmutatja a használt tűzfalpéldányokat és az SND-hez rendelt processzorokat (egy modul, amely forgalmat oszt el a tűzfal entitások között). Ha nem minden processzort használunk, a paranccsal hozzáadhatók cpconfig az átjáróban.
Szintén jó történetet kell tenni a Multi-Queue engedélyezéséhez. A Multi-Queue megoldja a problémát, ha az SND-vel rendelkező processzort sok százalékban használják, és a többi processzor tűzfalpéldányai tétlenek. Ekkor az SND képes lenne sok sort létrehozni egy hálózati kártyához, és különböző prioritásokat beállítani a különböző forgalomhoz a kernel szintjén. Következésképpen a CPU magokat intelligensebben fogják használni. A módszerek leírása is a .
Végezetül szeretném elmondani, hogy ezek nem mind a Check Point optimalizálásának legjobb gyakorlatai, de ezek a legnépszerűbbek. Ha szeretné megrendelni biztonsági szabályzatának auditját vagy megoldani a Check Pointtal kapcsolatos problémát, kérjük, lépjen kapcsolatba velünk [e-mail védett].
Спасибо за внимание!
Forrás: will.com