Вітаю колеги! Сьогодні я хотів би обговорити дуже актуальну для багатьох адміністраторів Check Point тему «Оптимізація CPU та RAM». Непоодинокі випадки, коли шлюз та/або менеджмент сервер споживають несподівано багато цих ресурсів, і хотілося б зрозуміти, куди вони "витікають", і по можливості грамотніше використовувати їх.
1. Аналіз
Для аналізу завантаження процесора корисно використовувати такі команди, які вводяться в експертному режимі:
топ показує всі процеси, кількість споживаних ресурсів 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
безкоштовно -m буфер RAM
Окремої уваги вартує команда netsat та її варіації. Наприклад, netstat -i може допомогти вирішити завдання моніторингу буферів обміну. Параметр, RX dropped packets (RX-DRP) у виведенні цієї команди, як правило, росте сам по собі через дропи нелегітимних протоколів (IPv6, Bad / Unintended VLAN tags та інші). Однак якщо дропи трапляються з іншої причини, то варто скористатися даною , щоб розпочати розслідування та зрозуміти, чому цей мережний інтерфейс скидає пакети. Дізнавшись причину, роботу апплайнса можна оптимізувати.
Якщо включений блейд Monitoring, можна дивитися дані показники графічно в SmartConsole, натиснувши на об'єкт і вибравши пункт «Device & License Information».
На постійній основі блейд Monitoring не рекомендується включати, але на день для тесту цілком можна.
Більше того, можна додавати більше параметрів для моніторингу, один із них дуже корисний - Bytes Throughput (пропускна спроможність апплайнсу).
Якщо є якась інша система моніторингу, наприклад безкоштовний , заснована на SNMP, вона теж підійде виявлення даних проблем.
2. "Виток" RAM з часом
Часто постає питання, що згодом шлюз чи менеджмент сервер починає дедалі більше споживати RAM. Хочу заспокоїти: це нормальна історія для Linux таких систем.
Подивившись висновок команд безкоштовно -m и cpstat -f memory os на апплайнсі з експертного режиму, можна порахувати та подивитися всі параметри, що стосуються RAM.
За фактом доступної пам'яті на шлюзі на даний момент Вільна пам’ять + Buffers Memory + Cached Memory = +-1.5 Гб, як правило.
Як каже СР, згодом шлюз/менеджмент сервер оптимізується та використовує все більше пам'яті, доходячи до приблизно 80% використання, і зупиняється. Ви можете перезавантажити пристрій, тоді показник скинеться. 1.5 Гб вільної ОЗУ шлюзу точно вистачає виконання всіх завдань, а менеджмент рідко сягає таких порогових значень.
Також висновки згаданих команд покажуть, скільки у вас Мало пам'яті (оперативна пам'ять у user space) та High memory (оперативна пам'ять у kernel space) використано.
Процеси kernel (включаючи active modules, такі як Check Point kernel modules) використовують лише Low memory. Однак процеси користувача можуть використовувати як Low, так і High memory. Більш того, Low memory приблизно дорівнює Загальна пам'ять.
Треба турбуватися, тільки якщо в логах сипатимуться помилки «Modules reboot or processes being killed to reclaim memory due to OOM (Out of memory)». Тоді слід перезавантажити шлюз і звернутися на підтримку, якщо перезавантаження не допоможе.
Повний опис можна знайти у и .
3. Оптимізація
Нижче наведені питання та відповіді щодо оптимізації CPU та RAM. На них варто відповісти самому собі і прислухатися до рекомендацій.
3.1. Чи правильно апллайнс був підібраний? Чи був пілотний проект?
Незважаючи на грамотний сайзинг, мережа могла банально розроститися, і це обладнання просто не справляється із навантаженням. Другий варіант, якщо сайзингу як такого не було.
3.2. Чи ввімкнена HTTPS інспекція? Якщо так, то чи налаштована технологія з Best Practice?
Звернутися до , якщо ви наш клієнт, або до .
Порядок розташування правил політики HTTPS інспекції відіграє велике значення в оптимізації відкриття HTTPS сайтів.
Рекомендований порядок розташування правил:
- Правила bypass з категоріями/URL
- Правила inspect з категоріями/URL
- Правила inspect для всіх інших категорій
За аналогією з фаєрвольною політикою, Check Point шукає збіг по пакетах зверху вниз, тому правила правила краще розташувати вгорі, так як шлюз не витрачатиме ресурси на прогін за всіма правилами, якщо цей пакет треба пропустити.
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 описані в .
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 описані в .
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 будуть використовуватися грамотніше. Методики описані також у .
Насамкінець хотілося б сказати, що це далеко не всі Best Practices з оптимізації роботи Check Point, проте найпопулярніші. Якщо ви хочете замовити аудит вашої політики безпеки або вирішити проблему, пов'язану з Check Point, звертайтеся, будь ласка, на [захищено електронною поштою].
Дякуємо за увагу!
Джерело: habr.com