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, Лоши/Неискан VLAN тагове и др.). Въпреки това, ако дроповете се случват по друга причина, е добре да се възползвате от това статия, за да започнете разследване и да разберете защо този мрежов интерфейс сбрасыва пакети. След като разберете причината, можете да оптимизирате работата на аплинса.

Ако е включен blade Monitoring, можете да гледате тези показатели графично в SmartConsole, като натиснете на обекта и изберете опцията „Device & License Information“.

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

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

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

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

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

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

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

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

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

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

Няма нужда да се безпокоите, само ако в логовете започнат да се появяват грешки „модули се рестартират или процеси се убиват, за да се възвърне памет поради OOM (няма памет)“. Тогава е необходимо да се рестартира шлюзът и да се свържете с поддръжката, ако рестартирането не помогне.

Подробно описание може да бъде намерено в sk99547 и sk99593.

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

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

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

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

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

Обърнете се към статията, ако сте наш клиент, или към sk108202.

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

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

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

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

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

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

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

На първо място, Check Point препоръчва да се постави IPS в отделен профил и да се създадат отделни правила за този blade.

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

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

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

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

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

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

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

Ако правилото има много попадения, то е препоръчително да го поставите в самия връх, а правилата с малък брой попадения — в самия низ. Основното е да следите да не се пресичат и да не се припокриват. Препоръчителна архитектура на политиката на firewall:

Обяснения:

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

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

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

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

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

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

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

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

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

Всички Best Practice са описани в sk98348.

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

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

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

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

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