Check Point: аптымізацыя CPU і RAM

Check Point: аптымізацыя CPU і RAM
Добры дзень, калегі! Сёння я хацеў бы абмеркаваць вельмі актуальную для многіх адміністратараў Check Point тэму "Аптымізацыя CPU і RAM". Нярэдкія выпадкі, калі шлюз і / або менеджмент сервер спажываюць нечакана шмат гэтых рэсурсаў, і хацелася б зразумець, куды яны "выцякаюць", і па магчымасці пісьменней выкарыстоўваць іх.

1. Аналіз

Для аналізу загрузкі працэсара карысна выкарыстоўваць наступныя каманды, якія ўводзяцца ў экспертным рэжыме:

топ паказвае ўсе працэсы, колькасць спажываных рэсурсаў CPU і RAM у працэнтах, uptime, прыярытэт працэсу і іншае у рэальным часеи

Check Point: аптымізацыя CPU і RAM

cpwd_admin list Check Point WatchDog Daemon, які паказвае ўсе модулі апплайнсу, іх PID, стан і колькасць запускаў

Check Point: аптымізацыя CPU і RAM

cpstat -f cpu os выкарыстанне CPU, іх колькасць і размеркаванне працэсарнага часу ў працэнтах

Check Point: аптымізацыя CPU і RAM

cpstat -f memory os выкарыстанне віртуальнай RAM, колькі ўсяго актыўнай, свабоднай RAM і іншае

Check Point: аптымізацыя CPU і RAM

Правільнай заўвагай будзе тое, што ўсе каманды cpstat можна паглядзець з дапамогай утыліты cpview. Для гэтага проста трэба ўвесці каманду cpview з любога рэжыму ў SSH-сесіі.

Check Point: аптымізацыя CPU і RAM
Check Point: аптымізацыя CPU і RAM

ps auxwf доўгі спіс усіх працэсаў, іх ID, займаную віртуальную памяць і памяць у RAM, CPU

Check Point: аптымізацыя CPU і RAM

Іншая варыяцыі каманды:

ps -aF пакажа самы затратны працэс

Check Point: аптымізацыя CPU і RAM

fw ctl affinity -l -a размеркаванне ядраў пад розныя інстанцыі фаервала, гэта значыць тэхналогія CoreXL

Check Point: аптымізацыя CPU і RAM

fw ctl pstat аналіз RAM і агульныя паказчыкі злучэнняў, cookies, NAT

Check Point: аптымізацыя CPU і RAM

бясплатна -m буфер RAM

Check Point: аптымізацыя CPU і RAM

Асобнай увагі каштуе каманда netsat і яе варыяцыі. Напрыклад, netstat -i можа дапамагчы вырашыць задачу маніторынгу буфераў абмену. Параметр, RX dropped packets (RX-DRP) у выснове гэтай каманды, як правіла, расце сам па сабе з-за дропаў нелегітымных пратаколаў (IPv6, Bad / Unintended VLAN tags і іншыя). Аднак калі дропы здараюцца па іншым чынніку, то варта скарыстацца дадзенай артыкулам, Каб пачаць расследаванне і зразумець, чаму дадзены сеткавы інтэрфейс скідае пакеты. Даведаўшыся прычыну, працу аплайнса таксама можна аптымізаваць.

Check Point: аптымізацыя CPU і RAM

Калі ўключаны блейд Monitoring, то можна глядзець дадзеныя паказчыкі графічна ў SmartConsole, націснуўшы на аб'ект і выбраўшы пункт "Device & License Information".

На сталае аснове блейд Monitoring уключаць не рэкамендуецца, але на дзень для цеста суцэль можна.

Check Point: аптымізацыя CPU і RAM

Больш за тое, можна дадаваць больш параметраў для маніторынгу, адзін з іх вельмі карысны – Bytes Throughput (прапускная здольнасць апплайнсу).

Check Point: аптымізацыя CPU і RAM

Калі ёсць нейкая іншая сістэма маніторынгу, напрыклад, бясплатны Zabbix, заснаваная на SNMP, яна таксама падыдзе для выяўлення дадзеных праблем.

2. "Уцечка" RAM з часам

Часта ўстае пытанне, што з часам шлюз ці менеджмент сервер пачынае ўсё больш і больш спажываць RAM. Жадаю супакоіць: гэта звычайная гісторыя для Linux падобных сістэм.

Паглядзеўшы выснову каманд бясплатна -m и cpstat -f memory os на апплайнсе з экспертнага рэжыму, можна палічыць і паглядзець усе параметры, якія адносяцца да RAM.

Па факце даступнай памяці на шлюзе на дадзены момант Вольная памяць + Buffers Memory + Cached Memory = +-1.5 Гб, як правіла.

Як кажа СР, з часам шлюз / мэнэджмент сервер аптымізуецца і выкарыстоўвае ўсё больш памяці, даходзячы да прыкладна 80% выкарыстання, і спыняецца. Вы можаце перазагрузіць прыладу, і тады паказчык скінецца. 1.5/XNUMX Гб свабоднай АЗП шлюза сапраўды хапае на выкананне ўсіх задач, а менеджмент рэдка даходзіць да такіх парогавых значэнняў.

Таксама высновы згаданых каманд пакажуць, колькі ў вас Мала памяці (аператыўная памяць у user space) і High memory (аператыўная памяць у kernel space) скарыстана.

Працэсы kernel (уключаючы active modules, такія як Check Point kernel modules) выкарыстоўваюць толькі Low memory. Аднак карыстацкія працэсы могуць выкарыстоўваць як Low, так і High memory. Больш за тое, Low memory прыкладна роўная Поўная памяць.

Турбавацца трэба, толькі калі ў логах будуць сыпацца памылкі "modules reboot or processes be killed to reclaim memory due to OOM (Out of memory)". Тады трэба перазагрузіць шлюз і звярнуцца ў падтрымку, калі перазагрузка не дапаможа.

Поўнае апісанне можна знайсці ў sk99547 и sk99593.

3. Аптымізацыя

Ніжэй прыведзены пытанні і адказы па аптымізацыі CPU і RAM. На іх варта сапраўды адказаць самому сабе і прыслухацца да рэкамендацый.

3.1. Ці правільна апллайнс быў падабраны? Ці быў пілотны праект?

Нягледзячы на ​​пісьменны сайзінг, сетка магла банальна разрасціся, і дадзенае абсталяванне проста не спраўляецца з нагрузкай. Другі варыянт, калі сайзінгу як такога не было.

3.2. Ці ўключана HTTPS інспекцыя? Калі так, то ці настроена тэхналогія па Best Practice?

Звярнуцца да артыкуле, калі вы наш кліент, ці да sk108202.

Парадак размяшчэння правіл у палітыцы HTTPS інспекцыі гуляе вялікае значэнне ў аптымізацыі адкрыцця HTTPS сайтаў.

Рэкамендуемы парадак размяшчэння правіл:

  1. Правілы bypass з катэгорыямі/URL
  2. Правілы inspect з катэгорыямі/URL
  3. Правілы inspect для ўсіх астатніх катэгорый

Check Point: аптымізацыя CPU і RAM

Па аналогіі з фаервольнай палітыкай, 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?

Калі ў правіла шмат хітоў (супадзенняў), то іх рэкамендуецца ставіць у самы верх, а правілы з малой колькасцю хітоў - у самы ніз. Галоўнае - гэта сачыць за тым, каб яны не перасякаліся і не перакрывалі адзін аднаго. Рэкамендуемая архітэктура фаервольнай палітыкі:

Check Point: аптымізацыя CPU і RAM

Тлумачэнні:

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.

Check Point: аптымізацыя CPU і RAM

Кажучы аб сэрвісах, варта згадаць тое, што часам бывае неабходным падцюніць тайм-аўты. Гэтая настройка дазволіць пісьменней расходаваць рэсурсы шлюза, каб не трымаць лішні час TCP/UDP сесіі пратаколаў, якім не патрэбен вялікі тайм-аўт. Напрыклад, на скрыншоце ніжэй, я пераставіў тайм-аўт domain-udp сэрвісу з 40 секунд на 30 секунд.

Check Point: аптымізацыя CPU і RAM

3.9. Ці выкарыстоўваецца SecureXL і які працэнт паскарэння?

Праверыць якасць працы SecureXL можна асноўнымі камандамі ў экспертным рэжыме на шлюзе fwaccel stat и fw accel stats -s. Далей трэба разбірацца, што за трафік паскараецца, якія templates (шаблоны) можна стварыць яшчэ.

Па змаўчанні Drop Templates не ўключаны, іх уключэнне спрыяльна адаб'ецца на працы SecureXL. Для гэтага зайдзіце ў налады шлюза і ва ўкладку Optimizations:

Check Point: аптымізацыя CPU і RAM

Таксама пры працы з кластарам для аптымізацыі CPU можна адключыць сінхранізацыю некрытычных сэрвісаў, такіх як UDP DNS, ICMP і іншыя. Для гэтага варта зайсці ў налады сэрвісу → Advanced → Synchronize connections of State Synchronization is enabled on the cluster.

Check Point: аптымізацыя CPU і RAM

Усе 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, то звяртайцеся, калі ласка, на [электронная пошта абаронена].

Дзякуй за ўвагу!

Крыніца: habr.com

Дадаць каментар