Check Point: оптимизация на CPU и RAM

Здравейте, колеги! Днес бих искал да обсъдим една много актуална тема за много администратори на Check Point - „Оптимизация на CPU и RAM“. Често се срещат случаи, когато шлюзът и/или сървърът за управление консумират неочаквано много от тези ресурси и бих искал да разбера, къде „изтичат“ и как можем да ги използваме по-ефективно.

1. Анализ

За анализа на натоварването на процесора е полезно да се използват следните команди, които се въвеждат в експертен режим:

top показва всички процеси, количеството на консумираните ресурси CPU и RAM в проценти, uptime, приоритет на процеса и друго в реално времеи

cpwd_admin list Check Point WatchDog Daemon, който показва всички модули на устройството, техния PID, състояние и брой стартирания

cpstat -f cpu os използване на CPU, тяхното количество и разпределение на процесорното време в проценти

cpstat -f memory os използване на виртуална RAM, колко общо активна, свободна RAM и друго

Правилно е да се спомене, че всички команди cpstat могат да се видят с помощта на утилитата cpview. За целта просто трябва да се въведе командата cpview от всеки режим на SSH сесия.

ps auxwf дълъг списък на всички процеси, техните ID, заета виртуална памет и памет в RAM, CPU

Други вариации на командата:

ps -aF ще покаже най-ресурсозависимия процес

fw ctl affinity -l -a разпределение на ядрата под различни инстанции на фаервола, т.е. технологията CoreXL

fw ctl pstat анализ на RAM и общи показатели за съединения, cookies, NAT

free -m буфер RAM

Отделно внимание заслужава командата netsat и нейните вариации. Например, netstat -i може да помогне за решаване на задачата за мониторинг на буферите за обмен. Параметърът RX dropped packets (RX-DRP) в изхода на тази команда обикновено нараства самостоятелно поради дропове на нелегитимни протоколи (IPv6, Bad / Unintended VLAN tags и други). Въпреки това, ако дроповете се случват по друга причина, струва си да използвате тази статия, за да започнете разследване и да разберете защо даденият мрежов интерфейс сблъсква пакети. След като разберете причината, работата на устройството също може да бъде оптимизирана.

Ако блейд Monitoring е включен, можете да наблюдавате тези показатели графично в SmartConsole, като кликнете върху обекта и изберете пункта „Device & License Information“.

Не се препоръчва да оставяте блейд Monitoring включен постоянно, но за един ден за тест е напълно приемливо.

Освен това, можете да добавяте още параметри за мониторинг, един от които е много полезен - Bytes Throughput (пропускна способност на устройството).

Ако има друга система за мониторинг, например, безплатна, Zabbix, базирана на SNMP, тя също е подходяща за идентифициране на тези проблеми.

2. 'Изтичане' на RAM с времето

Често възниква въпросът защо с времето шлюзът или мениджмънт сървърът започват да консумират все повече RAM. Искам да успокоя: това е нормален случай за Linux подобни системи.

След като разгледате изхода на командите free -m и cpstat -f memory os на устройството в експертен режим, можете да изчислите и видите всички параметри, свързани с RAM.

По фактическата достъпна памет на шлюза в момента Свободна памет + Буферирана памет + Кеширана памет = +-1.5 Гб, като правило.

Както казва СР, с времето шлюзът/мениджмънт сървърът се оптимизира и използва все повече памет, достигаща около 80% от употребата, и спира. Можете да рестартирате устройството, и тогава показателят ще се върне. 1.5 Гб свободна RAM определено е достатъчна за изпълнение на всички задачи, а мениджмънтът рядко достига до такива гранични стойности.

Също така изходите на споменатите команди ще покажат колко имате Ниска памет (оперативна памет в потребителското пространство) и Висока памет (оперативна памет в ядрото) използвана.

Процесите на ядрото (включително активни модули, като модулите на Check Point) използват само Ниска памет. Въпреки това, потребителските процеси могат да използват както Ниска, така и Висока памет. Освен това, Ниската памет е приблизително равна на Обща памет.

Трябва да се притеснявате само ако в логовете се появят грешки ‘modules reboot or processes being killed to reclaim memory due to OOM (Out of memory)’. Тогава трябва да рестартирате шлюза и да се свържете с поддръжката, ако рестартирането не помогне.

Пълният описаниe можете да намерите в sk99547 и sk99593.

3. Оптимизация

По-долу са представени въпроси и отговори относно оптимизацията на CPU и RAM. На тях струва да се отговорите честно и да се вслушате в препоръките.

3.1. Правилно ли е подбран апллайнсът? Имаше ли пилотен проект?

Въпреки че сайтът е правилно проектиран, мрежата може просто да е нараснала, а това оборудване просто не справя с натоварването. Вторият вариант е, ако не е имало такова проектиране.

3.2. Включена ли е HTTPS инспекция? Ако да, настроена ли е технологията по Best Practice?

Свържете се с статията, ако сте наш клиент, или с sk108202.

Редът на правилата в политиката за HTTPS инспекция играе голяма роля в оптимизацията на отварянето на HTTPS сайтове.

Препоръчителен ред на правилата:

1. Правила за заобикаляне с категории/URL
2. Правила inspect с категории/URL
3. Правила inspect за всички останали категории

Подобно на политиката на фаервала, Check Point търси съвпадения по пакетите отгоре надолу, затова е по-добре правилата за заобикаляне да са разположени в горната част, тъй като шлюзът няма да харчи ресурси за преминаване по всички правила, ако този пакет трябва да бъде пропуснат.

3.3 Използват ли се обекти с адресен диапазон?

Обектите с адресен диапазон, например, мрежата 192.168.0.0-192.168.5.0, заемат значително повече RAM от 5 мрежови обекта. Обикновено се счита за добра практика да се премахват неизползваемите обекти в SmartConsole, тъй като всеки път при внедряване на политиката шлюзът и мениджърският сървър харчат ресурси и, най-важното, време, за да проверят и приложат политиката.

3.4. Как е настроена политиката за предотвратяване на заплахи?

Преди всичко, Check Point препоръчва да се изведе IPS в отделен профил и да се създадат отделни правила за този блейд.

Например, администраторът смята, че сегментът DMZ трябва да бъде защитен само с IPS. Следователно, за да не харчи шлюзът ресурси за обработка на пакети от други блейдове, е необходимо да се създаде правило специално за този сегмент с профил, в който е активен само IPS.

Що се отнася до настройката на профилите, се препоръчва да се настроят по най-добрите практики в този документ(страници 17-20).

3.5. В настройките на IPS колко много сигнатури са в режим Detect?

Препоръчва се усилено да се обмислят сигнатурите, като трябва да се деактивират неизползваните (например, сигнатурите, свързани с уязвимости в продуктите на Adobe, изискват много изчислителна мощност, и ако клиентът няма такива продукти, има смисъл да се изключат). След това да се постави Prevent вместо Detect, където е възможно, защото шлюзът харчи ресурси за обработка на цялата сесия в режим Detect, а в режим Prevent веднага отхвърля сесията и не харчи ресурси за пълна обработка на пакета.

3.6. Кои файлове се обработват от блейдовете Threat Emulation, Threat Extraction, Anti-Virus?

Няма смисъл да емулирате и анализирате файлове с разширения, които вашите потребители не изтеглят, или които смятате за ненужни в мрежата си (например, bat и exe файлове лесно могат да бъдат блокирани с помощта на Content Awareness на нивото на защитната стена, така че ресурсите на шлюза ще се използват по-малко). Освен това, в настройките за Threat Emulation можете да изберете Environment (операционна система) за емулация на заплахи в пясъчника и да зададете Environment Windows 7, когато всички потребители работят с версия 10, също няма смисъл.

3.7. Разположени ли са правилата на защитната стена и правилата на ниво Application в съответствие с най-добрите практики?

Ако едно правило има много хитовe (съвпадения), то се препоръчва да бъде поставено най-горе, а правилата с малко хитовe — най-долу. Най-важното е да се следи те да не се припокриват и да не се засенчват взаимно. Препоръчителната архитектура на политика на защитната стена:

Обяснения:

First Rules — тук се поставят правилата с най-голям брой съвпадения
Noise Rule — правило за отхвърляне на паразитен трафик, като NetBIOS
Stealth Rule — забрана за достъп до шлюзовете и мениджмънтите за всички, освен за тези източници, които са посочени в правилата за разпознаване на шлюзовете
Clean-Up, Last и Drop Rules обикновено се обединяват в едно правило за забрана на всичко, което не е разрешено преди

Данните относно най-добрите практики са описани в sk106597.

3.8. Какви настройки имат създадените от администраторите услуги?

Например, създава се услуга TCP по определен порт и има смисъл в разширените настройки да се махне отметката "Match for Any". В този случай услугата ще попада точно под правилото, в което фигурира, и няма да участва в правилата, където в колоната Services е написано Any.

Говорейки за услугите, трябва да се спомене, че понякога е необходимо да се настроят тайм-аутите. Тази настройка ще позволи по-ефективно използване на ресурсите на шлюза, за да не се задържат за дълго времето на TCP/UDP сесии, на протоколи, на които не е нужен голям тайм-аут. Например, на екрана по-долу, промених тайм-аута на domain-udp услугата от 40 секунди на 30 секунди.

3.9. Използва ли се SecureXL и какъв е процента на ускорение?

Качеството на работата на SecureXL може да се провери с основните команди в експертен режим на шлюза fwaccel stat и fw accel stats -s. След това трябва да се проучи какъв трафик се ускорява, какви шаблони могат да бъдат създадени.

По подразбиране шаблоните Drop не са активирани; тяхното активиране ще благоприятства работата на SecureXL. За целта, влезте в настройките на шлюза и в раздела Оптимизации:

Също така, при работа с клъстери, за оптимизация на CPU можете да изключите синхронизацията на некритични услуги, като UDP DNS, ICMP и други. За целта, отидете в настройките на услугата → Разширено → Синхронизиране на връзките на Синхронизацията на състоянието е активирано в клъстера.

Всички добри практики са описани в sk98348.

3.10. Как се използва CoreXl?

Технологията CoreXL, която позволява използването на многобройни CPU за инстанции на фаервола, безспорно помага за оптимизиране на работата на устройството. Първо, командата fw ctl affinity -l -a ще покаже използваните инстанции на фаервола и процесорите, отделени за нуждите на SND (модула, който разпределя трафика на фаерволни същности). Ако не всички процесори са задействани, можете да ги добавите с командата cpconfig на шлюза.
Също така, добро решение е да инсталирате горещ фикс за активиране на Multi-Queue. Multi-Queue решава проблема, когато CPU с SND се използва в голяма степен, докато инстанциите на фаервола на другите процесори остават незаети. В този случай SND би могла да създаде множество опашки за един NIC и да зададе различни приоритети за различния трафик на ниво ядро. Следователно, ядрата на CPU ще бъдат използвани по-ефективно. Методите са описани също в sk98348.

В заключение, бих искал да кажа, че това не е всичко относно добрите практики за оптимизация на работата на Check Point, а само най-популярните. Ако искате да поръчате одит на вашата политика за сигурност или да разрешите проблем, свързан с Check Point, моля, свържете се с нас на sales@tssolution.ru.

Благодаря за вниманието!

Източник: habr.com