Здравствуйте, коллеги! Сегодня я хотел бы обсудить очень актуальную для многих администраторов 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.
По факту доступной памяти на шлюзе на данный момент Free Memory + Buffers Memory + Cached Memory = +-1.5 Гб, как правило.
Как говорит СР, со временем шлюз/менеджмент сервер оптимизируется и использует все больше памяти, доходя до примерно 80% использования, и останавливается. Вы можете перезагрузить устройство, и тогда показатель сбросится. 1.5 Гб свободной ОЗУ шлюзу точно хватает на выполнение всех задач, а менеджмент редко доходит до таких пороговых значений.
Также выводы упомянутых команд покажут, сколько у вас Low memory (оперативная память в user space) и High memory (оперативная память в kernel space) использовано.
Процессы kernel (включая active modules, такие как Check Point kernel modules) используют только Low memory. Однако пользовательские процессы могут использовать как Low, так и High memory. Более того, Low memory примерно равна Total Memory.
Беспокоиться следует, только если в логах будут сыпаться ошибки «modules reboot or processes being killed to reclaim memory due to OOM (Out of memory)». Тогда следует перезагрузить шлюз и обратиться в поддержку, если перезагрузка не поможет.
Полное описание можно найти в sk99547 и sk99593.
3. Оптимизация
Ниже приведены вопросы и ответы по оптимизации CPU и RAM. На них стоит честно ответить самому себе и прислушаться к рекомендациям.
3.1. Правильно ли апллайнс был подобран? Был ли пилотный проект?
Несмотря на грамотный сайзинг, сеть могла банально разрастись, и данное оборудование просто не справляется с нагрузкой. Второй вариант, если сайзинга как такового не было.
3.2. Включена ли HTTPS инспекция? Если да, то настроена ли технология по Best Practice?
Обратиться к статьe, если вы наш клиент, или к sk108202.
Порядок расположения правил в политике HTTPS инспекции играет большое значение в оптимизации открытия HTTPS сайтов.
Рекомендуемый порядок расположения правил:
- Правила bypass с категориями/URL
- Правила inspect с категориями/URL
- Правила inspect для всех остальных категорий
По аналогии с фаервольной политикой, Check Point ищет совпадение по пакетам сверху вниз, поэтому bypass правила лучше расположить вверху, так как шлюз не будет тратить ресурсы на прогонку по всем правилам, если этот пакет надо пропустить.
3.3 Используются ли address-range объекты?
Объекты с диапазоном адресом, например, сеть 192.168.0.0-192.168.5.0, отнимают существенно больше RAM, чем 5 network объектов. В общем и целом, считается хорошей практикой удалять неиспользуемые объекты в SmartConsole, так как каждый раз во время установки политики шлюз и менеджмент сервер тратят ресурсы и, главное, время, на то, чтобы верифицировать и применить политику.
3.4. Как настроена политика Threat Prevention?
В первую очередь, 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 в соответствии с best practice?
Если у правила много хитов (совпадений), то их рекомендуется ставить в самый верх, а правила с малым количеством хитов — в самый низ. Главное — это следить за тем, чтобы они не пересекались и не перекрывали друг друга. Рекомендуемая архитектура фаервольной политики:
Пояснения:
First Rules — сюда помещаются правила с самым большим количеством совпадений
Noise Rule — правило для отбрасывания паразитного трафика, такого как NetBIOS
Stealth Rule — запрет обращений к шлюзам и менеджментам всем, кроме тех источников, которые были указаны в правилах Authentication to Gateway Rules
Clean-Up, Last и Drop Rules, как правило, объединяются в одно правило для запрета всего, что не разрешено было ранее
Данные Best practice описаны в 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 of State Synchronization is enabled on the cluster.
Все 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.
Спасибо за внимание!