12 Restricting agent checks
Overview
You can control which item keys Zabbix agent or agent 2 is allowed or denied to use when executing item checks, remote commands, or scripts.
To do that, use these agent configuration parameters to define allow/deny rules:
AllowKey=<pattern>DenyKey=<pattern>
The <pattern> must contain a single item key and supports wildcards (*).
The wildcard matches any number of any characters in its position, and can be used to match item keys or parameters (e.g., vfs.file.*[*]).
To improve security, it is recommended to use exact item keys instead of wildcards. For details, see Securing allow/deny rules.
In contrast to other agent configuration parameters, you can specify an unlimited number of AllowKey or DenyKey parameters.
Important notes
-
All
system.runitems are disabled by default (even whenDenyKeyis empty), as ifDenyKey=system.run[*]was set as the last rule. Because of this, you can allow specificsystem.runitems without explicitly denying othersystem.runitems. -
An item specified in
AllowKeymust also be specified inDenyKey(except forsystem.runitems); otherwise, Zabbix agent will not start. -
If possible, use
AllowKeyto allow only required items and deny everything else. Some keys can be abused to read unintended files via path traversal (e.g.,vfs.file.contents["../../../../etc/passwd"]), and new Zabbix agent versions may introduce keys not covered by yourDenyKeyrules. -
AllowKeyandDenyKeyconfiguration does not affectHostnameItem,HostMetadataItem, orHostInterfaceItemagent parameters. -
Denied items become unsupported without any hints or error messages; for example:
- Zabbix agent
--print (-p)command-line parameter will not show denied item keys. - Zabbix agent
--test (-t)command-line parameter will return "Unsupported item key." for denied item keys. - Zabbix agent log file will not log denied remote commands if
LogRemoteCommands=1.
- Zabbix agent
Allow/deny rule order
You can specify an unlimited number of AllowKey or DenyKey rules, though their order matters.
- Rules are evaluated one by one, from top to bottom.
- When an item key matches a rule, it is either allowed or denied, and rule evaluation stops.
For example, when evaluating vfs.file.contents[/etc/passwd], the rules are processed as follows:
AllowKey=vfs.file.contents[/tmp/app.log] # Item key pattern does not match, agent proceeds to the next rule.
AllowKey=vfs.file.contents[/etc/passwd] # Item key pattern matches; agent allows the item check and stops rule evaluation.
DenyKey=vfs.file.*[*] # Agent ignores the rule, as the evaluation has stopped.
The following rule order will deny the item check:
DenyKey=vfs.file.*[*] # Item key pattern matches; agent denies the item check and stops rule evaluation.
AllowKey=vfs.file.contents[/etc/passwd] # Agent ignores the rule, as the evaluation has stopped.
AllowKey=vfs.file.contents[/tmp/app.log] # Agent ignores the rule, as the evaluation has stopped.
Examples
The following examples show common configuration patterns for AllowKey and DenyKey.
Allowing specific checks and commands
Allow only two vfs.file item checks and two system.run commands:
AllowKey=vfs.file.contents[/tmp/app.log]
AllowKey=vfs.file.size[/tmp/app.log]
AllowKey=system.run[/usr/bin/uptime]
AllowKey=system.run[/usr/bin/df -h /]
DenyKey=vfs.file.*[*]
Setting DenyKey=system.run[*] is unnecessary, because all other system.run commands are denied by default.
Allowing scripts
Allow Zabbix agent to execute scripts on hosts via all available methods:
- Global scripts that can be executed in the frontend or via API (this method always uses the
system.run[myscript.sh]key) - Remote commands from action operations (this method always uses the
system.run[myscript.sh,nowait]key) system.runZabbix agent items with the script, for example:system.run[myscript.sh]system.run[myscript.sh,wait]system.run[myscript.sh,nowait]
AllowKey=system.run[myscript.sh,*]
To control the wait/nowait parameter, you must set a different rule.
For example, you can allow only system.run[myscript.sh,wait] items, thus excluding other methods:
AllowKey=system.run[myscript.sh,wait]
Securing allow/deny rules
This example shows how to secure overly permissive AllowKey or DenyKey rules.
Consider the following rules:
AllowKey=system.run["C:\Program^ Files\Zabbix^ Agent^ 2\scripts\test.bat*"]
DenyKey=vfs.file.*
DenyKey=system.cpu.load[*]
On Windows, you must escape spaces in the path using a caret (^).
These rules contain a wildcard (*), which can be misused:
- The
test.batscript can be executed with any arguments, including unintended ones. - The
vfs.file.*pattern matches only item keys without parameters; however, allvfs.fileitems require parameters. - The
system.cpu.load[*]pattern matches only item keys with parameters; howeversystem.cpu.loaditems do not require parameters.
To secure these rules, explicitly allow executing test.bat only with specific arguments, and deny correct item key patterns; for example:
AllowKey=system.run["C:\Program^ Files\Zabbix^ Agent^ 2\scripts\test.bat status"]
AllowKey=system.run["C:\Program^ Files\Zabbix^ Agent^ 2\scripts\test.bat version"]
DenyKey=vfs.file.*[*]
DenyKey=system.cpu.load
DenyKey=system.cpu.load[*]
You can test the rules by running the following commands, which will return ZBX_NOTSUPPORTED.
cd "C:\Program Files\Zabbix Agent 2"
zabbix_agent2.exe -t system.run["C:\Program^ Files\Zabbix^ Agent^ 2\scripts\test.bat debug"]
zabbix_agent2.exe -t vfs.file.size["C:\ProgramData\MyApp\config.ini"]
zabbix_agent2.exe -t vfs.file.contents["C:\Windows\System32\drivers\etc\hosts"]
zabbix_agent2.exe -t system.cpu.load
zabbix_agent2.exe -t system.cpu.load[all,avg1]
Pattern examples
The following table shows how item key patterns are matched:
- A key matches the pattern only if it meets all conditions in the Matches column.
- Parameters must be fully enclosed in square brackets (e.g.,
vfs.file.contents[*andvfs.file.contents*utf8]are invalid patterns).
| Pattern | Matches | Examples |
|---|---|---|
* |
Any key with or without parameters | |
vfs.file.* |
Key starts with vfs.file.No parameters |
Matches:vfs.file.sizevfs.file.contentsDoes not match: vfs.file.contents[]vfs.file.size[/var/log/app.log] |
vfs.*.contents |
Key starts with vfs.Key ends with .contentsNo parameters |
Matches: vfs..contentsvfs.mount.point.file.contentsDoes not match: vfs.contentsvfs.file.contents[] |
vfs.file.*[*] |
Key starts with vfs.file.Any or empty parameters |
Matchesvfs.file.get.custom[]vfs.file.size[/var/log/app.log, utf8]Does not match: vfs.file.get.custom |
vfs.file.contents |
Key is vfs.file.contentsNo parameters |
Matches:vfs.file.contentsDoes not match: vfs.file.contents[/etc/passwd] |
vfs.file.contents[] |
Key is vfs.file.contents[]Empty parameters |
Matches:vfs.file.contents[]Does not match: vfs.file.contents |
vfs.file.contents[*] |
Key is vfs.file.contentsAny or empty parameters |
Matches:vfs.file.contents[/path/to/file]Does not match: vfs.file.contents |
vfs.file.contents[/etc/passwd,*] |
Key is vfs.file.contentsFirst parameter is /etc/passwdAny or empty second parameter |
Matches:vfs.file.contents[/etc/passwd,]vfs.file.contents[/etc/passwd,utf8]Does not match: vfs.file.contents[]vfs.file.contents[/etc/passwd] |
vfs.file.contents[*passwd*] |
Key is vfs.file.contentsFirst parameter includes passwdNo second parameter |
Matches:vfs.file.contents[/etc/passwd]Does not match: vfs.file.contents[/etc/passwd,]vfs.file.contents[/etc/passwd,utf8] |
vfs.file.contents[*passwd*,*] |
Key is vfs.file.contentsFirst parameter includes passwdAny or empty second parameter |
Matches:vfs.file.contents[/etc/passwd,]vfs.file.contents[/etc/passwd,utf8]Does not match: vfs.file.contents[/etc/passwd]vfs.file.contents[/tmp/test] |
vfs.file.contents[/etc/passwd,utf8] |
Key is vfs.file.contentsFirst parameter is /etc/passwdSecond parameter is utf8 |
Matches:vfs.file.contents[/etc/passwd,utf8]Does not match: vfs.file.contents[/etc/passwd,]vfs.file.contents[/etc/passwd,utf16] |