Zabbix 5.0 released with a list of crucial improvements in security. Arturs Lontons, Zabbix Technical Engineer and Trainer, unveiled what has been added or improved.
Contents
I. Improvements in Zabbix 5.0 (1:16:11)
01. TLS support for frontend communication with database (1:16:53)
02. TLS support for server/proxy communication with database (1:19:20)
03. Configurable ciphers (1:21:16)
04. Masker macros (1:23:35)
05. Frontend password hashing improvements (1:26:27)
06. Out-of-the-box SAML support (1:28:30)z
07. Blacklisting and whitelisting of item keys (1:30:03)
08. ODBC connection string support (1:32:53)
09. Legacy encryption library support dropped (1:35:11)
10. auditlog.get (1:36:13)
11. HTTP proxy in Webhooks (1:38:00)
12. DB character set check (1:38:54)
Improvements in Zabbix 5.0
In Zabbix 5.0 we provide many features that are really requested by security teams and will be life-saving for security policies, especially for large-scale corporate environments.
TLS support for front-end communication with the database
Now Zabbix supports encryption with the database from the front-end side using the familiar TLS certificate encryption.
Why encrypt at all? You might be afraid that someone will snoop on your communication data with the database. This risk depends on how your networking is set up, how accessible it is to external users, etc.
To configure TLS encryption in Zabbix, you should check TLS encryption box when setting up the initial configuration parameters.
Configuring encryption
To sum it up, in Zabbix 5.0 you can configure TLS certificate-based encryption, which is now supported for MySQL and PostgreSQL.
The database server certificate can be checked by comparing the hostname specified in the certificate with the name of the host to which it is connected by using the With host verification option.
If the TLS parameters point to files that are open for writing, a warning will be displayed that the files should be read-only.
TLS support for server/proxy communication with the database
Zabbix server back-end communication with the Zabbix database can now be encrypted. You should specify the encryption parameters in the server configuration file.
Encryption of server/proxy communication with the database
z
Making an encrypted connection to the DB with authenticating and verifying the host identity
- If we specify DBTLSConnect as required without specifying anything else, this will encrypt the connection to the DB without authenticating or verifying the host identity.
- If we set DBTLSConnect to verify_full this will make the encrypted connection from the backend to the database with authenticating and also verifying the host identity. In this case, you also have to specify the certificate authority file.
Configurable ciphers
Zabbix 5.0 provides some additional flexibility to customizing your encryption settings:
- Ability to override the built-in ciphersuit selection.
- Ability to override for certificates, PSK, and combined.
- Ability to override zabbix_get and zabbix_sender by passing ‘–tls_cipher13‘ or ‘–tls_cipher‘.
- Ability to select specific ciphers based on your security policy or additional requirements.
- Separate configuration parameters for TLS 1.3 and TLS 1.2.
- Configurable for incoming/outgoing connections per component.
New TLC configuration parameters
NOTE. Encryption is quite a complex feature, and it’s not recommended to interfere with it unless you are an advanced user.
Masked macros
In Zabbix 5.0, you now have the ability to mask your macros in the front-end. Just select the Secret text type via the drop-down.
Now you can choose not to display the macro value, for instance, if you are in an open space or you wish to hide your macro values from other Zabbix administrators.
Masking sensitive macro values
- If you attempt to clone a host or a template with a secret text macro, the values get reset, and you’ll see this warning message here:
Resetting secret macro value in case of cloning
- When exporting a host or a template, the value of a secret macro is not exported.
Secret macro value is not exported
- Once defined, the macro value cannot be edited — you have to completely replace the macro value.
Unedited macro values
Frontend password hashing improvements
In Zabbix 5.0, we have replaced the MD5 algorithm, which is quite old and insecure with bcrypt. Switching to bcrypt has a lot of benefits:
- Based on the Blowfish algorithm.
- A lot slower than MD5: not feasible for hardware acceleration — less vulnerable to brute-force attacks.
- Old MD5 hashes are replaced with bcrypt hashes after the initial login.
- The unique salt value is used.
- Not feasible for Rainbow table attacks.
Out-of-the-box SAML support
In Zabbix 5.0, SAML support is provided out of the box. You just have to configure some parameters on the SAML side and in the frontend.
Configuring Integration with SAML
When configuring integration with SAML, you have to keep in mind the following:
- A corresponding user must exist in Zabbix, however, its Zabbix password will not be used.
- You need to preconfigure the identity provider.
- The default location for private key and certificate is UI/conf/certs/.
- Some settings SP key, SP cert, IDP cert, and additional settings can be configured in zabbix.conf.php file.
Blacklisting and whitelisting of item keys
In Zabbix 5.0, you can restrict item keys execution, which ensures more security on the item level. Now it is possible to define key whitelist/blacklist per agent and specify individual keys or use wildcards.
How to configure key restrictions:
- EnableRemoteCommands still required – but might be deprecated in the upcoming versions.
- Rule check stops after the first match.
- AllowKey can be used only if DenyKey is specified.
- If a specific item key is disallowed in the agent configuration, the item will become unsupported
- Zabbix agent with ‘–print (-p)‘ command-line option will not show keys that are not allowed by configuration.
- Zabbix agent with ‘–test (-t)‘ command-line option will return ‘Unsupported item key‘ status for keys that are not allowed by configuration.
NOTE. Configuration order matters here, as it’s the first match that is used. For instance, if you specify the DenyKey and AllowKey afterward – the Deny key will take precedence over DenyKey
Wrong configuration order
Right configuration order
ODBC connection string support
We have improved ODBC checks, and now you can specify a connection string instead of using the dsn parameter, and specify ODBC keys on the item key level. We’ve made the dsn parameter optional.
Ability to specify a connection string is an improvement as:
-
- In some cases, users may not have access to the odc.ini file.
- Connection string works around that by defining the connection parameters on the item level.
- Either dsn or connection string should be present. If both are present — dsn will be ignored.
- The connection string may contain driver-specific arguments.
ODBC key changes
These changes simplify things and enable additional security when it comes to ODBC checks.
Legacy encryption library support dropped
MBED TLS support was discontinued for the following reasons:
- Previous versions supported MBED TLS 1.3.9 and later 1.3.x versions — by now support for these versions have reached the end of life.
- Lack of interest/use cases from the community.
- Saves the development overhead.
- Better focus on supporting OpenSSL and GnuTLS.
auditlog.get
In Zabbix 5.0 we have added the new audit log object and the auditlog.get method, that you now can use with the API to retrieve the audit log. This looks like a missing piece of the puzzle.
auditlog.get call
You can work with the response to the auditlog.get call to monitor the auditlog changes. Of course, this enables you to further filter and sort the response:
- Filter by audit IDs and/or user IDs.
- Ability to search by the old value and the new value.
The object contains information about Action type, Resource type, IP address, Resource ID’s, Names, and other details. It can be useful for parsing audit data and notifying you when critical changes have been made.
HTTP proxy in Webhooks
out-of-the-box integrations are a relatively new functionality of Zabbix. Now We’ve added the ability to specify an HTTP proxy for your integrations.
So, in Zabbix, 5.0 you have the ability to specify HTTPProxy parameter when defining a media type. The syntax is as follows:
[protocol://][username[:password]@]proxy.mycompany.com[:port].
HTTP proxy webhook configuration
The logic and syntax are exactly the same as in the HTTP agent configuration.
DB character set check
Normally, you need to use the correct character set and the correct collation when you’re setting up the Zabbix database. In Zabbix 5.0, we will be checking these on the initial setup, as well as for an existing instance upgraded to Zabbix 5.0.
Zabbix is case-sensitive and should support elements with names that use different casing, but the uniqueness check doesn’t work if you don’t specify the correct character set and their collation.
Misconfiguration example
In this case, an error message is displayed:
Message displayed during initial setup
In case of a misconfiguration, you’ll have to fix this for the existing instances using community resources or with the help of the Zabbix support team. We’re currently also working on providing a simple script to everyone who needs to fix this issue.
You can see the notification regarding the wrong character set or collation in the log files.
Displayed in the server log
Collation matters as:
-
- It ensures that the DB back-end is aware of object case sensitivity.
- There’s no way to detect this before Zabbix 5.0 but to take a look at the DB table structure from the DB side.
- If utf8_bin collation is not used, the user may eventually encounter duplicate SQL errors or other unexpected behavior in the front-end.
Main benefits of detecting misconfiguration:
-
- Letting users know that there’s DB misconfiguration.
- It’s better to catch any issues and fix them during the initial setup of the DB.
- Users should avoid running any extra queries on DB’s that have over time substantially grown in size. So fixing this ASAP is quite important!
