Üdvözlöm, kollégák! Ma egy nagyon aktuális Check Point témát szeretnék megvitatni, az „CPU és RAM optimalizálását”. Gyakori eset, hogy a gateway és/vagy a menedzsment szerver váratlanul sok erőforrást fogyaszt, és szeretnénk megérteni, hova „tűnnek el” ezek az erőforrások, valamint lehetőség szerint okosabban használni őket.
1. Elemzés
A processzor terhelésének elemzéséhez érdemes az alábbi parancsokat használni, amelyeket szakértői módban kell beírni:
top megmutatja az összes folyamatot, a CPU és RAM által fogyasztott erőforrások százalékos arányát, az uptime-ot, a folyamat prioritását és valós időbenés
cpwd_admin list Check Point WatchDog Daemon, amely megmutatja az összes modul PID-jét, állapotát és indításainak számát
cpstat -f cpu os CPU használat, azok száma és a processzoridő százalékos eloszlása
cpstat -f memory os virtuális RAM használat, mennyi az összes aktív és szabad RAM, egyebek
Helyes megjegyzés, hogy az összes cpstat parancsot meg lehet nézni a cpview. Ehhez egyszerűen írja be a cpview parancsot SSH munkamenet bármelyik módjából.
ps auxwf a folyamatok hosszú listája, azok azonosítója, használt virtuális memória és RAM, CPU
A parancs másik változata:
ps -aF a legnagyobb erőforrást fogyasztó folyamatot fogja megjeleníteni
fw ctl affinity -l -a a magok eloszlása a különböző tűzfal példányok között, azaz a CoreXL technológia
fw ctl pstat RAM elemzés és az összes kapcsolat, cookie-k, NAT általános statisztikái
free -m RAM puffer
Külön figyelmet érdemel a parancs netsat és annak változatai. Például, netstat -i segíthet a puffer monitorozásának megoldásában. Az RX dropped packets (RX-DRP) paraméter a parancs kimenetében általában önállóan nő az illegitim protokollok (IPv6, hibás / nem kívánt VLAN címkék stb.) miatt. Ha azonban a cseppentések más okból következnek be, érdemes használni ezt a , hogy elkezdjük a nyomozást, és megértsük, miért dobja el ez a hálózati interfész a csomagokat. A probléma megismerése után az eszköz munkáját is optimalizálhatjuk.
Ha a Monitoring blade be van kapcsolva, az adatokat grafikus formában is megtekintheti a SmartConsole-ban, az objektumra kattintva és a „Device & License Information” opciót választva.
A Monitoring blade folyamatosan történő engedélyezése nem ajánlott, de egy napos tesztre teljesen megfelelő.
Továbbá, további monitorozási paraméterek is hozzáadhatók, az egyik nagyon hasznos — Bytes Throughput (az eszköz áteresztőképessége).
Ha van egy másik monitorozó rendszer, például ingyenes , amely SNMP alapú, szintén nyújt adatokat a problémák azonosításához.
2. "RAM szivárgás" idővel
Gyakran felmerül a kérdés, hogy idővel a gateway vagy a menedzseri szerver egyre több RAM-ot fogyaszt. Megnyugtatlak, ez normális jelenség a Linux alapú rendszerek esetében.
A parancsok kimenetének megnézésével free -m és cpstat -f memory os az eszköz szakértői módjából, kiszámíthatók és megtekinthetők a RAM-ra vonatkozó összes paraméter.
Ami a jelenleg elérhető memóriát illeti a gateway-en Szabad memória + Puffer memória + Gyorsítótár memória = +-1.5 GB, jellemzően.
Ahogy az SR mondja, idővel a gateway/menedzseri szerver optimalizálódik és egyre több memóriát használ, elérve körülbelül 80%-os kihasználtságot, majd megáll. Újraindíthatod az eszközt, és akkor a mutató visszaáll. 1.5 GB szabad RAM bőven elegendő a feladatok elvégzéséhez, és a menedzser ritkán éri el az ilyen küszöbértékeket.
A fent említett parancsok kimenete azt is megmutatja, hogy mennyi a Alacsony memória (felhasználói térben lévő memória) és Magas memória (kernel térben lévő memória) felhasználva van.
A kernel folyamatok (beleértve az aktív modulokat, mint a Check Point kernel modulok) csak az Alacsony memóriát használják. Azonban a felhasználói folyamatok használhatják az Alacsony és Magas memóriát is. Továbbá, az Alacsony memória körülbelül megegyezik a Teljes memória.
Aggódni csak akkor érdemes, ha a naplókban hibák jelennek meg, mint például "modules reboot or processes being killed to reclaim memory due to OOM (Out of memory)". Akkor újra kell indítani a gateway-t, és támogatásért kell fordulni, ha az újraindítás nem segít.
A teljes leírás megtalálható a és .
3. Optimalizálás
Az alábbiakban a CPU és RAM optimalizálásával kapcsolatos kérdések és válaszok találhatók. E kérdésekre érdemes őszintén válaszolni és figyelni a javaslatokra.
3.1. Jól lett kiválasztva az eszköz? Volt próba projekt?
Annak ellenére, hogy a méretezés megfelelő volt, a hálózatban előfordulhatott, hogy az alapvetően megnőtt, és a berendezés egyszerűen nem bírja a terhelést. A másik eset, ha a méretezés egyáltalán nem történt meg.
3.2. Be van kapcsolva a HTTPS ellenőrzés? Ha igen, akkor be van állítva a legjobb gyakorlatok szerint?
Fordulj a , ha te ügyfél vagy, vagy a .
A HTTPS-inspection policy's rule arrangement is critical for optimizing the opening of HTTPS sites.
Recommended rule arrangement:
- Bypass rules with categories/URLs
- Inspect rules with categories/URLs
- Inspect rules for all other categories
Similar to firewall policy, Check Point searches for packet matches from top to bottom, so bypass rules should be placed at the top to prevent the gateway from wasting resources iterating through all rules if a packet needs to be skipped.
3.3 Are address-range objects used?
Address range objects, such as the network 192.168.0.0-192.168.5.0, consume significantly more RAM than 5 network objects. Generally, it is considered good practice to remove unused objects in SmartConsole, as each time the policy is installed, the gateway and management server use resources and, importantly, time to verify and apply the policy.
3.4 How is the Threat Prevention policy configured?
First, Check Point recommends placing IPS in a separate profile and creating separate rules for this blade.
For example, if an administrator believes that the DMZ segment should only be protected by IPS, then to prevent the gateway from wasting resources on processing packets by other blades, a specific rule needs to be created for this segment with a profile that includes only IPS.
Regarding profile configuration, it is recommended to set it up according to best practices in this (pages 17-20).
3.5 How many signatures are in Detect mode in IPS settings?
It is strongly recommended to review the signatures with the understanding that unused ones should be disabled (for example, signatures for exploiting Adobe products require a lot of computational power, and if the client does not have such products, it makes sense to disable those signatures). Moreover, switch to Prevent instead of Detect wherever possible, because the gateway spends resources processing the entire connection in Detect mode, while in Prevent mode, it immediately drops the connection and does not waste resources on full packet processing.
3.6 What files are processed by the Threat Emulation, Threat Extraction, and Anti-Virus blades?
Nincs értelme emulálni és elemezni olyan kiterjesztési fájlokat, amelyeket a felhasználók nem töltenek le, vagy amiket feleslegesnek tartanak a hálózatban (például a bat és exe fájlokat könnyen le lehet tiltani a Content Awareness blade segítségével a tűzfal szintjén, így a gateway erőforrásai kevesebb mértékben terhelődnek). Ráadásul a Threat Emulation beállításaiban választani lehet az Environment (operációs rendszer) emulálásához a sandboxban, így értelmetlen Windows 7 környezetet választani, ha minden felhasználó a 10-es verziót használja.
3.7. A tűzfal szabályok és az Application szintű szabályok a legjobb gyakorlatoknak megfelelően vannak elhelyezve?
Ha egy szabálynak sok találata (egyezése) van, akkor ajánlott ezeket a legfelső pozícióba helyezni, míg a kevés találattal rendelkező szabályokat a legaljára. Fontos, hogy ne kereszteződjenek és ne fedjék át egymást. A javasolt tűzfal politikai architektúra:
Magyarázatok:
Első Szabályok — ide kerülnek azok a szabályok, amelyek a legnagyobb számú egyezést mutatják.
Noise Rule — szabály a parazita forgalom elutasítására, mint például a NetBIOS.
Stealth Rule — a hozzáférések tilalma a gatewayekhez és a menedzsmenthez mindenkinek, kivéve azokat a forrásokat, amelyek fel vannak tüntetve az Authentication to Gateway Rules szabályokban.
A Clean-Up, Last és Drop Szabályokat általában egy szabályban egyesítik, ami mindent tiltanak, ami korábban nem volt engedélyezve.
A legjobb gyakorlatok az alábbiakban találhatók: .
3.8. Milyen beállítások vannak a rendszergazdák által létrehozott szolgáltatásoknál?
Például létrejön egy TCP szolgáltatás egy adott porton, és érdemes az Advanced szolgáltatásbeállításokban eltávolítani a “Match for Any” pipát. Így ez a szolgáltatás konkrétan abba a szabályba fog tartozni, amelyben szerepel, és nem fog részt venni azokban a szabályokban, ahol a Szolgáltatások oszlopban az Any szerepel.
A szolgáltatásokkal kapcsolatban érdemes megemlíteni, hogy néha szükséges lehet a timeoutok finomhangolása. Ez a beállítás lehetővé teszi a gateway erőforrásainak hatékonyabb felhasználását, hogy ne tartsunk feleslegesen TCP/UDP sessionöket, amelyeknek nem szükséges nagy timeout. Például, az alábbi képernyőfelvételen a domain-udp szolgáltatás timeoutját 40 másodperc helyett 30 másodpercre állítottam.
3.9. Használják a SecureXL-t, és mekkora a gyorsulás mértéke?
A SecureXL működésének minőségét az alábbi parancsokkal ellenőrizhetjük a gateway szakértői üzemmódban: fwaccel stat és fw accel stats -s. Ezután ki kell deríteni, hogy milyen forgalom gyorsul, és milyen templates (minták) hozhatók még létre.
Alapértelmezés szerint a Drop Templates nincsenek engedélyezve, ezek aktiválása kedvezően hat a SecureXL működésére. Ehhez lépjen be a gateway beállításaiba és az Optimalizálás fülre:
Clusterek használatakor a CPU optimalizálásához le lehet tiltani a nem kritikus szolgáltatások szinkronizálását, mint például az UDP DNS, ICMP és mások. Ehhez lépjen be a szolgáltatás beállításaiba → Haladó → Az állapot szinkronizálása kapcsoló engedélyezve van a klaszterben.
Minden Best Practice le van írva a .
3.10. Hogyan használjuk a CoreXL-t?
A CoreXL technológia, amely lehetővé teszi több CPU használatát a tűzfalpéldányok (tűzfal modulok) számára, egyértelműen segít optimalizálni az eszköz működését. Először a parancs fw ctl affinity -l -a megmutatja a használt tűzfalpéldányokat és a szükséges SND-hez (az a modul, amely elosztja a forgalmat a tűzfal entitások között) rendelt processzorokat. Ha nem minden processzor van használatban, a parancs segítségével hozzáadhatók: cpconfig a gateway-en.
Egy másik jó ötlet az a Multi-Queue aktiválására. A Multi-Queue megoldja azt a problémát, amikor egy processzor az SND-vel sok százalékban van használva, míg a tűzfalpéldányok más processzorokon tétlenkednek. Ekkor az SND lehetőséget kapna arra, hogy sok várakozási sort hozzon létre egy NIC-hez, és eltérő prioritásokat állítson be a különböző forgalmak számára a mag szintjén. Ennek következtében a CPU magok okosabban kezdik el használni. .
Összegzésként szeretném megjegyezni, hogy ez messze nem az összes Best Practice a Check Point működésének optimalizálására, de ezek a legnépszerűbbek. Ha auditálni szeretné biztonsági politikáját, vagy megoldana egy Check Point-tal kapcsolatos problémát, kérjük, keressen bennünket a sales@tssolution.ru címen.
Köszönöm a figyelmet!
Forrás: habr.com
