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

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

1. Анализ

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

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

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

cpstat -f cpu os Използване на процесора, техният брой и разпределение на процесорното време в проценти

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

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

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

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

ps-aF показват най-скъпия процес

fw ctl афинитет -l -a разпределение на ядра за различни екземпляри на защитната стена, тоест технологията CoreXL

fw ctl pstat Анализ на RAM и общи индикатори за връзки, бисквитки, NAT

безплатно -m RAM буфер

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

Ако блейдът за наблюдение е активиран, можете да видите тези показатели графично в SmartConsole, като щракнете върху обект и изберете Информация за устройство и лиценз.

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

Освен това можете да добавите още параметри за наблюдение, един от тях е много полезен - Bytes Throughput (широчина на честотната лента на приложението).

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

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

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

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

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

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

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

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

Трябва да се притеснявате само ако има грешки в регистрационните файлове "модули се рестартират или процеси се убиват, за да се възстанови паметта поради OOM (Недостиг на памет)". След това трябва да рестартирате шлюза и да се свържете с поддръжката, ако рестартирането не помогне.

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

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

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

3.1. Правилно ли е избрана горната линия? Имаше ли пилотен проект?

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

3.2. Активирана ли е проверката на HTTPS? Ако е така, технологията конфигурирана ли е според най-добрата практика?

Препоръчай на статияако сте наш клиент или до 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 в отделен профил и създаване на отделни правила за този блейд.

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

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

3.5. Колко подписа в режим на откриване в настройките на IPS?

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

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

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

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

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

Пояснение:

Първи правила - правилата с най-много съвпадения са поставени тук
Noise Rule - правило за премахване на фалшив трафик като NetBIOS
Stealth Rule - забрана за достъп до шлюзове и управление на всички, с изключение на онези източници, които са посочени в правилата за удостоверяване на шлюза
Правилата за почистване, последно и изхвърляне обикновено се комбинират в едно правило, за да забранят всичко, което не е било разрешено преди

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

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

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

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

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

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

По подразбиране Drop Templates не са активирани, разрешаването им ще има положителен ефект върху работата на SecureXL. За да направите това, отидете в настройките на шлюза и раздела Оптимизации:

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

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

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

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

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

Спасибо за внимание!

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