
Dobrý den, kolegové! Dnes bych chtěl prodiskutovat téma, které je pro mnohé administrátory Check Point velmi aktuální, a to „Optimalizace CPU a RAM“. Není neobvyklé, že brána a/nebo server pro správu neočekávaně spotřebovávají hodně těchto zdrojů, a chtěl bych pochopit, kam „utíkají“, a pokud možno je využít efektivněji.
1. Analýza
Pro analýzu zatížení procesoru je užitečné použít následující příkazy, které se zadávají v expertním režimu:
top ukazuje všechny procesy, množství spotřebovávaných zdrojů CPU a RAM v procentech, uptime, prioritu procesu a v reálném časea

cpwd_admin list Check Point WatchDog Daemon, který zobrazuje všechny moduly zařízení, jejich PID, stav a počet spuštění

cpstat -f cpu os využití CPU, jejich počet a rozdělení procesorového času v procentech

cpstat -f memory os využití virtuální RAM, kolik je celkově aktivní, volné RAM a další

Správný poznatek je, že všechny příkazy cpstat lze zobrazit pomocí nástroje cpview. Stačí zadat příkaz cpview z jakéhokoli režimu v SSH relaci.


ps auxwf dlouhý seznam všech procesů, jejich ID, zabranou virtuální paměť a RAM, CPU

Další varianta příkazu:
ps -aF ukáže nejvíce náročný proces

fw ctl affinity -l -a rozložení jader pro různé instance firewallu, tedy technologie CoreXL

fw ctl pstat analýza RAM a celkové ukazatele připojení, cookies, NAT

free -m buffer RAM

Samostatné pozornosti si zaslouží příkaz netsat a jeho varianty. Například, netstat -i může pomoci při monitorování přenosových bufferů. Parametr RX dropped packets (RX-DRP) ve výstupu tohoto příkazu obvykle roste sám o sobě kvůli droppům ilegitimních protokolů (IPv6, špatné/neúmyslné VLAN tagy a další). Avšak pokud k droppům dochází z jiného důvodu, je dobré využít tento , abychom zahájili vyšetřování a pochopili, proč dané síťové rozhraní odhazuje pakety. Jakmile zjistíme příčinu, lze také optimalizovat práci zařízení.

Pokud je povolen blade Monitoring, mohou se tyto údaje zobrazit graficky ve SmartConsole, kliknutím na objekt a výběrem položky „Informace o zařízení a licenci“.
Blade Monitoring se nedoporučuje trvale aktivovat, ale na den pro testování to je zcela v pořádku.

Navíc je možné přidávat další parametry pro monitorování, jedním z velmi užitečných je Bytes Throughput (propustnost zařízení).

Pokud existuje jakýkoli jiný monitorovací systém, například bezplatný , založený na SNMP, také bude vyhovovat pro odhalení těchto problémů.
2. "Únik" RAM v průběhu času
Často se klade otázka, že v průběhu času brána nebo manažerský server začíná spotřebovávat stále více a více RAM. Chci uklidnit: to je normální jev pro systémy podobné Linuxu.
Podíval jsem se na výstup příkazů free -m a cpstat -f memory os na aplikačním zařízení z expertního režimu, kde lze započítat a prohlédnout všechny parametry související s RAM.
V současné době dostupné paměti na bráně Volná paměť + Paměť bufferů + Uložená paměť = +-1,5 GB, obvykle.
Jak říká SR, v průběhu času se brána/management server optimalizuje a používá stále více paměti, až dosáhne přibližně 80% využití, a pak se zastaví. Můžete restartovat zařízení, a tím se ukazatel resetuje. 1,5 GB volné RAM bráně určitě stačí k provádění všech úkolů a management zřídka dosahuje takových prahových hodnot.
Také výstupy zmíněných příkazů ukáží, kolik máte Nízká paměť (operační paměť v uživatelském prostoru) a Vysoká paměť (operační paměť v jádře) bylo použito.
Procesy jádra (včetně aktivních modulů, jako jsou moduly jádra Check Point) využívají pouze nízkou paměť. Uživatelské procesy však mohou využívat jak nízkou, tak vysokou paměť. Navíc je nízká paměť přibližně rovna Celková paměť.
O starosti byste měli mít pouze tehdy, pokud se v logách objevují chyby "moduly se restartují nebo procesy jsou zabíjeny kvůli propuštění paměti z důvodu OOM (Out of memory)".Pak byste měli restartovat bránu a obrátit se na podporu, pokud restart nepomůže.
Úplný popis najdete v a .
3. Optimalizace
Níže jsou uvedeny otázky a odpovědi na optimalizaci CPU a RAM. Na tyto otázky byste si měli poctivě odpovědět a poslechnout si doporučení.
3.1. Byla správně vybrána aplikační zařízení? Byl proveden pilotní projekt?
Přestože byl proveden správný sizing, síť se mohla jednoduše rozrůst a tato zařízení si s nákladem jednoduše neporadí. Druhá možnost je, že sizing jako takový nebyl proveden.
3.2. Je povolena HTTPS inspekce? Pokud ano, je technologie nastavena podle nejlepších praktik?
Obraťte se na , pokud jste naším klientem, nebo na .
Pořadí pravidel v politice HTTPS inspekce má velký význam pro optimalizaci načítání HTTPS webů.
Doporučené pořadí umístění pravidel:
- Pravidla bypass se kategoriemi/URL
- Pravidla inspect s kategoriemi/URL
- Pravidla inspect pro ostatní kategorie

Podobně jako u firewallové politiky, Check Point hledá shodu podle paketů shora dolů, takže pravidla bypass by měla být umístěna na vrchu, protože brána nebude plýtvat zdroji na procházení všemi pravidly, pokud je třeba tento paket přeskočit.
3.3 Používají se objekty address-range?
Objekty s využitím adresního rozsahu, například síť 192.168.0.0-192.168.5.0, spotřebovávají podstatně více RAM než 5 síťových objektů. Obecně se považuje za dobrou praxi odstraňovat nepoužívané objekty ve SmartConsole, protože při každém nasazení politiky brána a server pro správu spotřebovávají zdroje a, co je hlavní, čas na ověření a uplatnění politiky.
3.4. Jak je nastavena politika Threat Prevention?
V první řadě, Check Point doporučuje izolovat IPS do samostatného profilu a vytvářet samostatná pravidla pro tento blade.
Například, administrátor se domnívá, že segment DMZ by měl být chráněn pouze pomocí IPS. Proto je třeba vytvořit pravidlo specificky pro tento segment s profilem, ve kterém je zapnuto pouze IPS, aby brána nemusela plýtvat zdroji na zpracování paketů jinými blade.
Pokud jde o nastavení profilů, doporučuje se nastavit je podle nejlepších praktik v tomto (stránky 17-20).
3.5. Kolik podpisů je v režimu Detect v nastavení IPS?
Doporučuje se důkladně zpracovat podpisy s tím, že by měly být deaktivovány nepoužívané (například podpisy na exploataci produktů Adobe vyžadují mnoho výpočetního výkonu, a pokud u zákazníka takové produkty nejsou, má smysl tyto podpisy deaktivovat). Dále nastavte Prevent místo Detect, kde je to možné, protože brána spotřebovává zdroje na zpracování celého spojení v režimu Detect, v režimu Prevent okamžitě odmítá spojení a neplýtvá zdroji na úplné zpracování paketu.
3.6. Jaké soubory zpracovávají blade Threat Emulation, Threat Extraction, Anti-Virus?
Nemá smysl emulovat a analyzovat soubory s příponami, které si vaši uživatelé nestahují, nebo které považujete za zbytečné ve vaší síti (například soubory bat a exe lze snadno zablokovat pomocí technologie Content Awareness na úrovni firewallu, takže prostředky brány budou využity efektivněji). Navíc v nastavení Threat Emulation můžete vybírat Environment (operační systém) pro emulaci hrozeb v pískovišti a nastavovat Environment Windows 7, když všichni uživatelé pracují s verzí 10, také nedává smysl.
3.7. Jsou pravidla firewallu a pravidla na úrovni aplikace umístěna podle osvědčených praktik?
Pokud má pravidlo příliš mnoho zásahů (shod), doporučuje se umístit je nahoru, zatímco pravidla s malým počtem zásahů by měla být na spodní části. Hlavní je sledovat, aby se nepřekrývala a nekryla navzájem. Doporučená architektura pravidel firewallu:

Vysvětlení:
První pravidla – sem se umísťují pravidla s největším počtem shod
Hlukové pravidlo – pravidlo pro odmítnutí parazitního provozu, jako je NetBIOS
Tajné pravidlo – zákaz přístupů k bránám a managementům pro všechny kromě těch zdrojů, které byly uvedeny v pravidlech pro autentizaci na bránu
Čistění, poslední a pravidla Drop se obvykle kombinují do jednoho pravidla pro odmítnutí všeho, co nebylo dříve povoleno
Osvědčené praktiky jsou popsány v .
3.8. Jaká nastavení mají služby vytvořené administrátory?
Například je vytvořena nějaká TCP služba na určitém portu a má smysl ve pokročilých nastaveních služby odškrtnout možnost „Match for Any“. V tomto případě bude tato služba konkrétně spadat pod pravidlo, ve kterém je uvedena, a nebude se účastnit pravidel, kde v sloupci Služby je napsáno Any.

Pokud mluvíme o službách, je třeba zmínit, že někdy je nezbytné dolaďovat časové limity. Toto nastavení umožní efektivněji využívat prostředky brány, aby se zbytečně neudržovaly TCP/UDP sezení protokolů, které nepotřebují dlouhý časový limit. Například na obrázku níže jsem přemístil časový limit služby domain-udp z 40 sekund na 30 sekund.

3.9. Používá se SecureXL a jaký je procentuální nárůst zrychlení?
Kvalitu práce SecureXL lze zkontrolovat pomocí základních příkazů v expertním režimu na bráně fwaccel stat a fw accel stats -s. Dále je třeba zjistit, jaký provoz je urychlován, jaké šablony (templates) lze ještě vytvořit.
Výchozí šablony Drop nejsou zapnuté, jejich aktivace pozitivně ovlivní fungování SecureXL. K tomu přejděte do nastavení brány a na kartu Optimalizace:

Při práci s clusterem můžete pro optimalizaci CPU také vypnout synchronizaci nekritických služeb, jako jsou UDP DNS, ICMP a další. K tomu je potřeba přejít do nastavení služby → Rozšířené → Synchronizovat připojení stavu synchronizace, pokud je v clusteru povoleno.

Všechny osvědčené postupy jsou popsány v .
3.10. Jak se používá CoreXL?
Technologie CoreXL umožňující využívat více CPU pro instance firewallu jednoznačně pomáhá optimalizovat fungování zařízení. Nejprve příkaz fw ctl affinity -l -a ukáže používané instance firewallu a procesory, které jsou přiděleny potřebám SND (modul, který rozděluje provoz mezi firewallové entity). Pokud nejsou zapojeny všechny procesory, můžete je přidat příkazem cpconfig na bráně.
Další dobrá věc je nainstalovat pro aktivaci Multi-Queue. Multi-Queue řeší problém, kdy se procesor s SND využívá na vysoké procento, zatímco instance firewallu na jiných procesorech nepracují. Tím by SND získala možnost vytvářet více front pro jednu NIC a nastavovat různé priority pro různý provoz na úrovni jádra. To znamená, že jádra CPU se budou využívat efektivněji. Metodiky jsou také popsány v .
Na závěr bych chtěl říci, že to rozhodně nejsou všechny osvědčené postupy pro optimalizaci práce Check Point, ale ty nejpopulárnější. Pokud si přejete objednat audity vaší bezpečnostní politiky nebo vyřešit problém související s Check Point, neváhejte se obrátit na sales@tssolution.ru.
Děkujeme za pozornost!
Zdroj: habr.com
