🥇Check Point: optimalizácia CPU a RAM

Ahojte, kolegovia! Dnes by som rád prediskutoval veľmi aktuálnu tému pre mnohých administrátorov Check Point - „Optimalizácia CPU a RAM“. Nie je nezvyčajné, že brána a/alebo správa servera spotrebovávajú nečakane veľa týchto zdrojov, a bolo by dobré pochopiť, kam sa „strácajú“ a ako ich efektívnejšie využiť.

1. Analýza

Na analýzu záťaže procesora je užitočné použiť nasledujúce príkazy, ktoré sa zadávajú v expertnom režime:

top zobrazuje všetky procesy, množstvo spotrebúvaných prostriedkov CPU a RAM v percentách, uptime, prioritu procesu a iné v reálnom časea

cpwd_admin list demon Check Point WatchDog, ktorý zobrazuje všetky moduly appliances, ich PID, stav a počet spustení

cpstat -f cpu os využitie CPU, ich počet a rozdelenie procesorového času v percentách

cpstat -f memory os využitie virtuálnej RAM, koľko celkovej aktívnej, voľnej RAM a iné

Správnym poznámkou bude, že všetky príkazy cpstat je možné zobraziť pomocou utilitky cpview. Na to stačí zadať príkaz cpview z akéhokoľvek režimu v SSH relácii.

ps auxwf dlhý zoznam všetkých procesov, ich ID, obsadenú virtuálnu pamäť a pamäť v RAM, CPU

Iná variácia príkazu:

ps -aF zobrazí najnáročnejší proces

fw ctl affinity -l -a rozdeľovanie jadier pod rôzne inštancie firewallu, tj. technológia CoreXL

fw ctl pstat analýza RAM a celkové ukazovatele pripojení, cookies, NAT

free -m buffer RAM

Samostatnej pozornosti sa oplatí venovať príkazu netsat a jeho variáciám. Napríklad, netstat -i môže pomôcť riešiť úlohu monitorovania vyrovnávacej pamäte. Parameter, RX dropped packets (RX-DRP) v výstupe tohto príkazu zvyčajne rastie sám o sebe kvôli dropom nelegitímnych protokolov (IPv6, Bad / Unintended VLAN tags a iné). Avšak ak sa droppy vyskytujú z iného dôvodu, je potrebné využiť tento článkom, aby ste začali vyšetrovanie a pochopili, prečo tento sieťový rozhranie zahadzuje pakety. Zistením príčiny možno tiež optimalizovať prácu appliances.

Ak je povolený blade Monitoring, je možné tieto údaje sledovať graficky v SmartConsole, kliknutím na objekt a výberom položky „Device & License Information“.

Na trvalé používanie blade Monitoring sa neodporúča, ale na jeden deň pre testovanie je to celkom v poriadku.

Navyše je možné pridať viac parametrov na monitorovanie, jeden z nich je veľmi užitočný — Bytes Throughput (priepustnosť appliances).

Ak existuje iný monitorovací systém, napríklad bezplatný Zabbix, založený na SNMP, ten tiež bude vyhovovať na identifikáciu týchto problémov.

2. "Únik" RAM s časom

Často sa objavuje otázka, že časom brána alebo správcovský server začína čoraz viac a viac spotrebovávať RAM. Chcem vás upokojiť: to je normálny jav pre systémy podobné Linuxu.

Pozhliadnutím výstupu príkazov free -m a cpstat -f memory os na appliance z expertného režimu sa dajú spočítať a pozrieť všetky parametre, ktoré sa týkajú RAM.

Pokiaľ ide o dostupnú pamäť na bráne v súčasnosti Voľná pamäť + Pamäť buffera + Cached Memory = +-1.5 GB, ako obvykle.

Ako hovorí SR, časom sa brána / správcovský server optimalizuje a používa čoraz viac pamäte, dosahujúc približne 80% využitia, a zastaví sa. Môžete reštartovať zariadenie a ukazovateľ sa vráti späť. 1.5 GB voľnej RAM je pre bránu určite dostatočné na plnenie všetkých úloh, a správa zriedka dosahuje také prahové hodnoty.

Taktiež výstupy uvedených príkazov ukážu, koľko máte Nízka pamäť (operačná pamäť v užívateľskom priestore) a Vysoká pamäť (operačná pamäť v jadre) použitú.

Procesy jadra (vrátane aktívnych modulov, ako sú moduly jadra Check Point) používajú iba nízku pamäť. Avšak užívateľské procesy môžu používať ako nízku, tak aj vysokú pamäť. Navyše, nízka pamäť je približne rovná Celková pamäť.

Obávať sa treba len v prípade, že sa v logoch začnú hromadiť chyby "modules reboot or processes being killed to reclaim memory due to OOM (Out of memory)". Vtedy je potrebné reštartovať bránu a obrátiť sa na podporu, ak reštart nepomôže.

Úplný popis nájdete v sk99547 a sk99593.

3. Optimalizácia

Nižšie sú uvedené otázky a odpovede na optimalizáciu CPU a RAM. Na tieto je potrebné úprimne odpovedať samému sebe a počúvať odporúčania.

3.1. Bol appliance správne vybraný? Bol realizovaný pilotný projekt?

Napriek správnemu sizing, sa sieť mohla jednoducho rozrásť a toto vybavenie jednoducho nezvláda zaťaženie. Druhá možnosť je, že sizing ako taký neexistoval.

3.2. Je zapnutá HTTPS inspekcia? Ak áno, je nastavená technológia podľa najlepších praktik?

Obrátiť sa na článok, ak ste naším klientom, alebo na sk108202.

Poradie umiestnenia pravidiel v politike HTTPS inspekcie má veľký význam pri optimalizácii otvárania HTTPS stránok.

Odporúčané poradie umiestnenia pravidiel:

Pravidlá bypass s kategóriami / URL
Pravidlá inspect s kategóriami/URL
Pravidlá inspect pre všetky ostatné kategórie

Podobne ako pri firewallovej politike, Check Point hľadá zhodu podľa paketov zhora nadol, preto by mali byť bypass pravidlá umiestnené na vrchu, aby brána nemusela míňať zdroje na spracovanie všetkých pravidiel, ak je potrebné tento paket preskočiť.

3.3 Používajú sa objekty address-range?

Objekty s rozsahom adries, napríklad sieť 192.168.0.0-192.168.5.0, spotrebujú podstatne viac RAM než 5 sieťových objektov. Vo všeobecnosti sa považuje za dobrou praxou odstraňovať nepoužívané objekty v SmartConsole, pretože pri každom nasadení politiky brána a manažérsky server míňajú zdroje a, čo je dôležité, čas na overenie a aplikáciu politiky.

3.4. Ako je nastavená politika Threat Prevention?

Predovšetkým, Check Point odporúča vyčleniť IPS do samostatného profilu a vytvárať osobitné pravidlá pre tento blade.

Napríklad, administrátor považuje za potrebné chrániť segment DMZ iba pomocou IPS. Preto, aby brána nemíňala zdroje na spracovanie paketov inými blades, je potrebné vytvoriť pravidlo presne pre tento segment s profilom, v ktorom je zapnuté iba IPS.

Pokiaľ ide o nastavenie profilov, odporúča sa nastaviť ho podľa osvedčených postupov uvedených v tomto dokumente(strany 17-20).

3.5. Koľko podpisov v režime Detect je nastavených v IPS?

Odporúča sa detailne prepracovať podpisy v tom zmysle, že by sa mali vypnúť nepoužívané (napríklad podpisy na zraniteľnosti produktov Adobe vyžadujú veľa výpočtového výkonu, a ak zákazník takéto produkty nemá, má zmysel ich vypnúť). Ďalej je vhodné nastaviť Prevent namiesto Detect tam, kde je to možné, pretože brána míňa zdroje na spracovanie celej spojenia v režime Detect, v režime Prevent hneď odmietne spojenie a nemíňa zdroje na úplné spracovanie paketu.

3.6. Aké súboru spracovávajú blades Threat Emulation, Threat Extraction, Anti-Virus?

Nemá zmysel emulovať a analyzovať súbory s príponami, ktoré si vaši používatelia nestiahnu, alebo ich považujete za nepotrebné vo vašej sieti (napríklad, bat a exe súbory je možné ľahko zablokovať pomocou blesh Content Awareness na úrovni firewallu, takže zdroje zariadenia budú vyžadovať menej). Navyše, v nastaveniach Threat Emulation môžete vybrať Environment (operačný systém) na emuláciu hrozieb v pieskovisku, a nastaviť Environment Windows 7, keď všetci používatelia pracujú s verziou 10, tiež nemá zmysel.

3.7. Sú pravidlá firewallu a pravidlá na úrovni aplikácie umiestnené v súlade s best practices?

Ak má pravidlo veľa hitov (zhod), odporúča sa umiestniť ich na vrchol, zatiaľ čo pravidlá s malým počtom hitov by mali byť na spodku. Hlavné je dbať na to, aby sa navzájom nekryli a neprekrývali. Odporúčaná architektúra pravidiel firewallu je:

Vysvetlenia:

First Rules — sem sa umiestňujú pravidlá s najväčším počtom zhôd
Noise Rule — pravidlo na odstránenie parazitného trafičení, ako je NetBIOS
Stealth Rule — zákaz prístupov k bránam a manažmentom pre všetkých okrem tých zdrojov, ktoré boli uvedené v pravidlách Authentication to Gateway Rules
Clean-Up, Last a Drop Rules sa zvyčajne kombinujú do jedného pravidla na zákaz všetkého, čo nebolo predtým povolené

Tieto best practices sú opísané v sk106597.

3.8. Aké nastavenia sú pri vytvorených službách správcami?

Napríklad, ak sa vytvára nejaká TCP služba na konkrétnom porte, má zmysel v Advanced nastaveniach služby zrušiť začiarknutie “Match for Any”. V tomto prípade sa táto služba dostane konkrétne pod pravidlo, v ktorom je uvedená, a nebude sa zúčastňovať v pravidlách, kde je v stĺpci Služby uvedené Any.

Pokiaľ ide o služby, stojí za to spomenúť, že niekedy môže byť potrebné jemne doladiť časové limity. Toto nastavenie umožní rozumnejšie využívať zdroje brány, aby sa neudržiavali zbytočne dlhé TCP/UDP relácie pre protokoly, ktoré nepotrebujú dlhé časové limity. Napríklad, na obrázku nižšie, som presunul časový limit službe domain-udp zo 40 sekúnd na 30 sekúnd.

3.9. Je používaný SecureXL a aký je percentuálny výkonový nárast?

Kvalitu práce SecureXL môžete skontrolovať pomocou hlavných príkazov v expertnom režime na bráne. fwaccel stat a fw accel stats -s. Potom je potrebné preskúmať, aký typ trafiku je urýchlený, a aké šablóny (templates) môžeme ešte vytvoriť.

Predvolené Drop Templates nie sú zapnuté, ich aktivácia pozitívne ovplyvní výkon SecureXL. Na to sa prihláste do nastavení brány a prejdite na kartu Optimalizácie:

Tiež pri práci s klastrom na optimalizáciu CPU môžete vypnúť synchronizáciu nekritických služieb, ako sú UDP DNS, ICMP a ďalšie. Na to prejdite do nastavení služby → Rozšírené → Synchronizácia pripojení je povolená na klietke.

Všetky Best Practice sú popísané v sk98348.

3.10. Ako sa používa CoreXL?

Technológia CoreXL, ktorá umožňuje využitie viacerých CPU pre firewall instances (moduly firewallu), jednoznačne pomáha optimalizovať výkon zariadenia. Najprv príkaz fw ctl affinity -l -a zobrazí používané firewall instances a procesory pridelené pre SND (modul, ktorý distribuuje prenos na firewallové entity). Ak nie sú všetky procesory nasadené, môžete ich pridať príkazom cpconfig na bráne.
Tiež je dobrý nápad nainštalovať hotfix na aktiváciu Multi-Queue. Multi-Queue rieši problém, keď je procesor s SND využívaný na vysoké percento, zatiaľ čo firewall instances na iných procesoroch sú nečinné. Potom by SND mohol vytvárať viacero front pre jedno NIC a nastavovať rôzne priority pre rôzny prenos na úrovni jadra. Tým pádom by sa procesory CPU používali efektívnejšie. Metódy sú tiež popísané v sk98348.

Na záver by som chcel povedať, že to nie sú všetky Best Practices na optimalizáciu práce Check Point, ale sú to najpopulárnejšie. Ak máte záujem o audit vašej bezpečnostnej politiky alebo chcete vyriešiť problém súvisiaci s Check Pointom, prosím, kontaktujte nás na sales@tssolution.ru.

Ďakujem za pozornosť!

Zdroj: habr.com