Encryption support is one of the long-awaited features in Zabbix. There were various proposals to provide it: from pre-shared secret key (PSK) authentication to full TLS and Kerberos support. A year ago it was decided to go ahead and provide encryption support based on TLS.
Overview
With this change all connections between Zabbix server, proxies and agents can be selectively configured to use encryption or stay unencrypted as before. This opens up the possibility of using Zabbix in environments requiring data encryption between hosts. Encryption is also supported by command-line utilities.
Going technical
Zabbix components can use the OpenSSL, GnuTLS, or mbed TLS (PolarSSL) cryptographic toolkit. Different components can use different toolkits. This allows easy switching to another crypto toolkit if one of them has a critical vulnerability, changes license or its development stops. Another benefit of supporting several crypto toolkits is keeping the Zabbix codebase architecturally neutral to a particular toolkit.
Only the TLS 1.2 protocol is activated for using in Zabbix as vulnerabilities have been found in earlier SSL/TLS protocol versions and older Zabbix versions support none of earlier versions.
While encryption protects from intercepting data in plain text there is also a need for authentication (can we trust the data sender? can we trust the server we have connected to?). For authentication a connection can be configured to use a certificate or PSK. Users with small, closed Zabbix installations may find using PSKs easier. Users with stronger security requirements or a public key infrastructure in place may prefer certificates.
Encrypted connections use the same ports as unencrypted ones. There is no need to open additional ports on firewalls.
Users uninterested in encryption can use Zabbix as before. However their Zabbix installations will be upgraded to be ready to support encryption. They can start using encryption gradually at any time.
We added new fields into Zabbix database for keeping all these details, made them configurable from the frontend/API and added new parameters to configuration files.
Encryption configuration for a host is illustrated by the following screenshot.
There are two parts: how Zabbix server or proxy connects TO a host (for passive checks) and what connections are allowed FROM the host (active checks and zabbix_sender). The “From” part is used as a restriction to prevent connections with a stolen certificate or PSK.
Agents and command-line utilities zabbix_get and zabbix_sender provide similar possibilities via the new parameters in configuration files or new command-line options.
For upgrading the connection security it is possible to temporarily configure several types of allowed connections (e.g. encrypted and unencrypted), configure certificate or PSK based encryption and authentication, verify that encrypted connection works and disable unencrypted connections.
Future improvements
- Currently a TLS session reuse via caching or session tickets is not supported. Each connection starts with a TLS handshake which takes time and CPU power.
- Support encryption for communications with Zabbix Java gateway.
- Currently only X.509 certificates with RSA keys are supported. Supporting certificates with ECDSA keys could provide better performance.
- Certificate revocation is checked against CRL files, online verification with the issuer is currently not supported.
The newly added encryption support provides users with the ability to gradually and selectively improve security of their Zabbix installations. Encrypted data transfer and mutual authentication between components is a major new Zabbix 3.0 feature.
Get acquainted with Trend prediction in our previous blog post, and the new features of Zabbix 3.0 on our What’s New page, and see full specification of encryption in the documentation.
This article is available in Russian, on habrahabr.ru.
