Тихон Усков, Инженер интеграции, Zabbix В Zabbix 5.0 появилась новая функция, которая позволяет улучшить безопасность в системах с использованием Zabbix Agent и заменяет старый параметр EnableRemoteCommands.  Усовершенствование безопасности систем с использованием агента обусловлено тем фактом, что агент может выполнять большое количество потенциально опасных действий. Например, с помощью утилиты zabbix_get можно получить доступ к списку пользователей, их домашним каталогам, файлам с паролями и т. д.  Доступ к данным с помощью утилиты zabbix_get ПРИМЕЧАНИЕ. Данные могут быть получены, только если агент имеет права на чтение соответствующего файла. Но, например, файл /etc/passwd/ доступен для чтения всем пользователям. В более ранних версиях параметр EnableRemoteCommands=0 позволял только отключать метрики с ключом *system.run[]** и выполнение скриптов из веб-интерфейса, но при этом не было возможности ограничить доступ к отдельным файлам, разрешить или запретить отдельные ключи, которые устанавливались вместе с агентом, или ограничить использование отдельных параметров.  Использование параметра EnableRemoteCommand в ранних версиях Zabbix 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.  Параметры должны быть заключены в квадратные скобки [].  Примеры использования wildcard.   Особенности написания ключей с параметрами  Правила заполнения параметров ПРИМЕЧАНИЕ. Если администратор запрещает какой-либо ключ, при запросе Zabbix не выдает информации о том, по какой причине метрика или ключ попадают в категорию 'NOTSUPPORTED'. В log-файлах агента информация о запретах на выполнение удаленных команд также не отображается. Это сделано из соображений безопасности, но может осложнить отладку, если метрики попадают в неподдерживаемую категорию по каким-либо причинам. После настройки правил необходимо удостовериться, что все настроено верно. Можно воспользоваться одним из трех вариантов: Вы можете запретить доступ к файлу и удостовериться, например, с помощью утилиты zabbix_get, что доступ к файлу запрещен.  ** ПРИМЕЧАНИЕ. Кавычки в параметре игнорируются.  При этом доступ к такому файлу может быть разрешен по другому пути. Например, если на него ведет симлинк.  Рекомендуется проверять различные варианты применения задаваемых правил, а также учитывать возможности обойти запреты.  Вопрос. Почему для описания правил, разрешений и запретов выбрана такая сложная схема паттерна со своим языком? Почему не было возможности воспользоваться, например, регулярными выражениями, которые использует Zabbix? Ответ. Это вопрос производительности regex, поскольку агент, как правило, один, и он проверяет огромное количество метрик. Regex — достаточно тяжелая операция, и мы не можем проверять тысячи метрик таким образом. Wildcards — универсальное, шороко применяемое и простое решение.  Вопрос. Разве файлы Include подключаются не в алфавитном порядке? Ответ. Насколько мне известно, предсказать последовательность применения правил, если вы разносите правила по разным файлам, фактически невозможно. Я рекомендую собрать все правила AllowKey/DenyKey в одном файле Include, потому что они взаимодействуют друг с другом, и подключать этот файл.  Вопрос. В Zabbix 5.0 опция 'EnableRemoteCommands=' в конфигурационном файле отсутствует, и доступны только AllowKey/DenyKey?  Ответ. Да, все верно.  Спасибо за внимание! Инженер-интегратор