- Verschlüsselung und Sicherheit
- Verschlüsselung
- Kompilieren von Zabbix mit Verschlüsselungsunterstützung
- Verwaltung der Verbindungsverschlüsselung
- zabbix_get und zabbix_sender mit Verschlüsselung
- Ciphersuites
- Vom Benutzer konfigurierte Ciphersuites
- Fehlerbehebung bei Verschlüsselungsproblemen
- Fehlerbehebung bei Verbindungsart- oder Berechtigungsproblemen
- Versuch, Zabbix sender mit TLS-Unterstützung zu verwenden, um Daten an einen ohne TLS kompilierten Zabbix Server/Proxy zu senden
- Eine Seite verbindet sich mit PSK, die andere Seite verwendet LibreSSL oder wurde ohne Verschlüsselungsunterstützung kompiliert
- Eine Seite verbindet sich mit PSK, die andere Seite verwendet OpenSSL mit deaktivierter PSK-Unterstützung
Verschlüsselung und Sicherheit
Verschlüsselung
Zabbix unterstützt verschlüsselte Kommunikation zwischen Zabbix-Komponenten mithilfe des Transport Layer Security (TLS)-Protokolls v.1.2 und 1.3 (je nach Kryptobibliothek). Zertifikatsbasierte und auf vorab gemeinsam genutzten Schlüsseln basierende Verschlüsselung werden unterstützt.
Die Verschlüsselung kann für Verbindungen konfiguriert werden:
- Zwischen Zabbix Server, Zabbix Proxy, Zabbix Agent, Zabbix Webdienst, zabbix_sender und zabbix_get-Dienstprogrammen
- Zur Zabbix-Datenbank vom Zabbix Frontend und Server/Proxy
- Zwischen Zabbix Frontend und Zabbix Server
Die Verschlüsselung ist optional und für einzelne Komponenten konfigurierbar:
- Einige Proxies und Agents können so konfiguriert werden, dass sie mit dem Server eine zertifikatsbasierte Verschlüsselung verwenden, während andere eine auf vorab gemeinsam genutzten Schlüsseln basierende Verschlüsselung nutzen und wieder andere weiterhin unverschlüsselt kommunizieren (wie zuvor).
- Server (Proxy) kann für verschiedene Hosts unterschiedliche Verschlüsselungskonfigurationen verwenden.
Zabbix-Daemonprogramme verwenden einen einzigen Listening-Port für verschlüsselte und unverschlüsselte eingehende Verbindungen. Das Hinzufügen von Verschlüsselung erfordert keine neuen Ports in Firewalls.
Einschränkungen
- Private Schlüssel werden in Dateien im Klartext gespeichert, die von Zabbix-Komponenten während des Starts gelesen werden können.
- Vorab gemeinsam genutzte Schlüssel werden im Zabbix Frontend eingegeben und in der Zabbix-Datenbank im Klartext gespeichert.
- Die integrierte Verschlüsselung schützt die Kommunikation zwischen dem Webserver, auf dem das Zabbix Frontend läuft, und dem Webbrowser des Benutzers nicht.
- Derzeit wird jede verschlüsselte Verbindung mit einem vollständigen TLS-Handshake geöffnet; Session-Caching und Tickets sind nicht implementiert.
- Das Hinzufügen von Verschlüsselung erhöht die Zeit für Datenpunkt-Prüfungen und Aktionen, abhängig von der Netzwerklatenz:
- Wenn beispielsweise die Paketverzögerung 100 ms beträgt, dauert das Öffnen einer TCP-Verbindung und das Senden einer unverschlüsselten Anfrage etwa 200 ms. Mit Verschlüsselung werden etwa 1000 ms für den Aufbau der TLS-Verbindung hinzugefügt.
- Möglicherweise müssen Timeouts erhöht werden, andernfalls können einige Datenpunkte und Aktionen, die Remote-Skripte auf Agenten ausführen, mit unverschlüsselten Verbindungen funktionieren, aber bei verschlüsselten Verbindungen aufgrund eines Timeouts fehlschlagen.
- Verschlüsselung wird von der Netzwerkerkennung nicht unterstützt. Zabbix-Agent-Prüfungen, die von der Netzwerkerkennung durchgeführt werden, sind unverschlüsselt, und wenn der Zabbix Agent so konfiguriert ist, dass er unverschlüsselte Verbindungen ablehnt, werden solche Prüfungen nicht erfolgreich sein.
Kompilieren von Zabbix mit Verschlüsselungsunterstützung
Um Verschlüsselung zu unterstützen, muss Zabbix mit einer der unterstützten Kryptobibliotheken kompiliert und gelinkt werden:
- GnuTLS - ab Version 3.1.18
- OpenSSL - Versionen 1.0.1, 1.0.2, 1.1.0, 1.1.1, 3.0.x - 3.5.x
- LibreSSL - getestet mit den Versionen 2.7.4, 2.8.2:
- LibreSSL 2.6.x wird nicht unterstützt
- LibreSSL wird als kompatibler Ersatz für OpenSSL unterstützt;
die neuen LibreSSL-spezifischen API-Funktionen
tls_*()werden nicht verwendet. Mit LibreSSL kompilierte Zabbix-Komponenten können PSK nicht verwenden, es können nur Zertifikate verwendet werden.
Weitere Informationen zum Einrichten von SSL für das Zabbix Frontend finden Sie in diesen Best Practices.
Die Bibliothek wird durch Angabe der jeweiligen Option für das Skript "configure" ausgewählt:
--with-gnutls[=DIR]--with-openssl[=DIR](wird auch für LibreSSL verwendet)
Um beispielsweise die Quellen für Server und Agent mit OpenSSL zu konfigurieren, können Sie etwa Folgendes verwenden:
./configure --enable-server --enable-agent --with-mysql --enable-ipv6 --with-net-snmp --with-libcurl --with-libxml2 --with-opensslVerschiedene Zabbix-Komponenten können mit unterschiedlichen Kryptobibliotheken kompiliert werden (z. B. ein Server mit OpenSSL, ein Agent mit GnuTLS).
Wenn Sie vorab gemeinsam genutzte Schlüssel (PSK) verwenden möchten, sollten Sie in Zabbix-Komponenten, die PSKs verwenden, GnuTLS oder OpenSSL 1.1.0 (oder neuer) in Betracht ziehen. Die Bibliotheken GnuTLS und OpenSSL 1.1.0 unterstützen PSK-Verschlüsselungssammlungen mit Perfect Forward Secrecy. Ältere Versionen der OpenSSL-Bibliothek (1.0.1, 1.0.2c) unterstützen ebenfalls PSKs, die verfügbaren PSK-Verschlüsselungssammlungen bieten jedoch keine Perfect Forward Secrecy.
Verwaltung der Verbindungsverschlüsselung
Verbindungen in Zabbix können folgende Verschlüsselung verwenden:
- keine Verschlüsselung (Standard)
- RSA-Zertifikatsbasierte Verschlüsselung
- PSK-basierte Verschlüsselung
Es gibt zwei wichtige Parameter, mit denen die Verschlüsselung zwischen Zabbix-Komponenten festgelegt wird:
- TLSConnect - legt fest, welche Verschlüsselung für ausgehende Verbindungen verwendet wird (unverschlüsselt, PSK oder Zertifikat)
- TLSAccept - legt fest, welche Verbindungstypen für eingehende Verbindungen zulässig sind (unverschlüsselt, PSK oder Zertifikat). Es können ein oder mehrere Werte angegeben werden.
TLSConnect wird in den Konfigurationsdateien für Zabbix Proxy (im
aktiven Modus, legt nur Verbindungen zum Server fest) und Zabbix Agent
(für aktive Prüfungen) verwendet. Im Zabbix Frontend ist das Gegenstück
zu TLSConnect das Feld Verbindungen zum Host unter Datenerfassung >
Hosts > <some host> > Registerkarte Verschlüsselung sowie das Feld
Verbindungen zum Proxy unter Administration > Proxies > <some proxy> >
Registerkarte Verschlüsselung. Wenn der konfigurierte Verschlüsselungstyp
für eine Verbindung fehlschlägt, werden keine anderen
Verschlüsselungstypen ausprobiert.
TLSAccept wird in den Konfigurationsdateien für Zabbix Proxy (im
passiven Modus, legt nur Verbindungen vom Server fest) und Zabbix Agent
(für passive Prüfungen) verwendet. Im Zabbix Frontend ist das Gegenstück
zu TLSAccept das Feld Verbindungen vom Host unter Datenerfassung >
Hosts > <some host> > Registerkarte Verschlüsselung sowie das Feld
Verbindungen vom Proxy unter Administration > Proxies > <some proxy> >
Registerkarte Verschlüsselung.
Normalerweise konfigurieren Sie für eingehende Verbindungen nur einen Verschlüsselungstyp. Sie können jedoch den Verschlüsselungstyp wechseln, z. B. von unverschlüsselt zu zertifikatsbasiert, mit minimaler Ausfallzeit und der Möglichkeit zum Rollback. Gehen Sie dazu wie folgt vor:
- Setzen Sie
TLSAccept=unencrypted,certin der Konfigurationsdatei des Agent und starten Sie den Zabbix Agent neu - Testen Sie die Verbindung mit zabbix_get zum Agent unter Verwendung eines Zertifikats. Wenn dies funktioniert, können Sie die Verschlüsselung für diesen Agent im Zabbix Frontend unter Datenerfassung > Hosts > <some host> > Registerkarte Verschlüsselung neu konfigurieren, indem Sie Verbindungen zum Host auf "Certificate" setzen.
- Wenn der Konfigurationscache des Server aktualisiert wird (und die Proxy-Konfiguration aktualisiert wird, falls der Host über einen Proxy überwacht wird), werden Verbindungen zu diesem Agent verschlüsselt
- Wenn alles wie erwartet funktioniert, können Sie
TLSAccept=certin der Konfigurationsdatei des Agent setzen und den Zabbix Agent neu starten. Der Agent akzeptiert dann nur noch verschlüsselte, zertifikatsbasierte Verbindungen. Unverschlüsselte und PSK-basierte Verbindungen werden abgelehnt.
Auf ähnliche Weise funktioniert es auf Server und Proxy. Wenn im Zabbix Frontend in der Host-Konfiguration Verbindungen vom Host auf "Certificate" gesetzt ist, werden nur zertifikatsbasierte verschlüsselte Verbindungen vom Agent (aktive Prüfungen) und von zabbix_sender (Trapper-Datenpunkte) akzeptiert.
Wahrscheinlich konfigurieren Sie eingehende und ausgehende Verbindungen so, dass sie denselben Verschlüsselungstyp oder gar keine Verschlüsselung verwenden. Technisch ist es jedoch möglich, dies asymmetrisch zu konfigurieren, z. B. zertifikatsbasierte Verschlüsselung für eingehende und PSK-basierte Verschlüsselung für ausgehende Verbindungen.
Die Verschlüsselungskonfiguration für jeden Host wird im Zabbix Frontend unter Datenerfassung > Hosts in der Spalte Agent-Verschlüsselung angezeigt. Zum Beispiel:
| Example | Connections to host | Allowed connections from host | Rejected connections from host |
|---|---|---|---|
 |
Unverschlüsselt | Unverschlüsselt | Verschlüsselt, zertifikatsbasiert und PSK-basiert verschlüsselt |
 |
Verschlüsselt, zertifikatsbasiert | Verschlüsselt, zertifikatsbasiert | Unverschlüsselt und PSK-basiert verschlüsselt |
 |
Verschlüsselt, PSK-basiert | Verschlüsselt, PSK-basiert | Unverschlüsselt und zertifikatsbasiert verschlüsselt |
 |
Verschlüsselt, PSK-basiert | Unverschlüsselt und PSK-basiert verschlüsselt | Zertifikatsbasiert verschlüsselt |
 |
Verschlüsselt, zertifikatsbasiert | Unverschlüsselt, PSK- oder zertifikatsbasiert verschlüsselt | - |
Verbindungen sind standardmäßig unverschlüsselt. Die Verschlüsselung muss für jeden Host und Proxy einzeln konfiguriert werden.
zabbix_get und zabbix_sender mit Verschlüsselung
Siehe die Manpages zabbix_get und zabbix_sender zur Verwendung mit Verschlüsselung.
Ciphersuites
Ciphersuites werden standardmäßig intern während des Zabbix-Starts konfiguriert.
Außerdem werden von Benutzern konfigurierte Ciphersuites für GnuTLS und OpenSSL unterstützt. Benutzer können konfigurieren Ciphersuites entsprechend ihren Sicherheitsrichtlinien. Die Verwendung dieser Funktion ist optional (die integrierten Standard-Ciphersuites funktionieren weiterhin).
Für Kryptobibliotheken, die mit den Standard-Einstellungen kompiliert wurden, führen die integrierten Zabbix-Regeln typischerweise zu den folgenden Ciphersuites (in Reihenfolge von höherer zu niedrigerer Priorität):
| Library | Certificate ciphersuites | PSK ciphersuites |
|---|---|---|
| GnuTLS 3.1.18 | TLS_ECDHE_RSA_AES_128_GCM_SHA256 TLS_ECDHE_RSA_AES_128_CBC_SHA256 TLS_ECDHE_RSA_AES_128_CBC_SHA1 TLS_RSA_AES_128_GCM_SHA256 TLS_RSA_AES_128_CBC_SHA256 TLS_RSA_AES_128_CBC_SHA1 |
TLS_ECDHE_PSK_AES_128_CBC_SHA256 TLS_ECDHE_PSK_AES_128_CBC_SHA1 TLS_PSK_AES_128_GCM_SHA256 TLS_PSK_AES_128_CBC_SHA256 TLS_PSK_AES_128_CBC_SHA1 |
| OpenSSL 1.0.2c | ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA AES128-GCM-SHA256 AES128-SHA256 AES128-SHA |
PSK-AES128-CBC-SHA |
| OpenSSL 1.1.0 | ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA AES128-GCM-SHA256 AES128-CCM8 AES128-CCM AES128-SHA256 AES128-SHA |
ECDHE-PSK-AES128-CBC-SHA256 ECDHE-PSK-AES128-CBC-SHA PSK-AES128-GCM-SHA256 PSK-AES128-CCM8 PSK-AES128-CCM PSK-AES128-CBC-SHA256 PSK-AES128-CBC-SHA |
| OpenSSL 1.1.1d | TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA AES128-GCM-SHA256 AES128-CCM8 AES128-CCM AES128-SHA256 AES128-SHA |
TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-PSK-AES128-CBC-SHA256 ECDHE-PSK-AES128-CBC-SHA PSK-AES128-GCM-SHA256 PSK-AES128-CCM8 PSK-AES128-CCM PSK-AES128-CBC-SHA256 PSK-AES128-CBC-SHA |
Vom Benutzer konfigurierte Ciphersuites
Die integrierten Auswahlkriterien für Ciphersuites können mit vom Benutzer konfigurierten Ciphersuites überschrieben werden.
Vom Benutzer konfigurierte Ciphersuites sind eine Funktion für fortgeschrittene Benutzer, die TLS-Ciphersuites, deren Sicherheit und die Folgen von Fehlern verstehen und sich mit der Fehlersuche bei TLS wohlfühlen.
Die integrierten Auswahlkriterien für Ciphersuites können mit den folgenden Parametern überschrieben werden:
| Überschreibungsbereich | Parameter | Wert | Beschreibung |
|---|---|---|---|
| Ciphersuite-Auswahl für Zertifikate | TLSCipherCert13 | Gültige OpenSSL 1.1.1 Cipher-Strings für das TLS-1.3-Protokoll (ihre Werte werden an die OpenSSL-Funktion SSL_CTX_set_ciphersuites() übergeben). |
Zertifikatsbasierte Auswahlkriterien für Ciphersuites für TLS 1.3 Nur OpenSSL 1.1.1 oder neuer. |
| TLSCipherCert | Gültige OpenSSL Cipher-Strings für TLS 1.2 oder gültige GnuTLS-Prioritätszeichenfolgen. Ihre Werte werden jeweils an die Funktionen SSL_CTX_set_cipher_list() bzw. gnutls_priority_init() übergeben. |
Zertifikatsbasierte Auswahlkriterien für Ciphersuites für TLS 1.2/1.3 (GnuTLS), TLS 1.2 (OpenSSL) | |
| Ciphersuite-Auswahl für PSK | TLSCipherPSK13 | Gültige OpenSSL 1.1.1 Cipher-Strings für das TLS-1.3-Protokoll (ihre Werte werden an die OpenSSL-Funktion SSL_CTX_set_ciphersuites() übergeben). |
PSK-basierte Auswahlkriterien für Ciphersuites für TLS 1.3 Nur OpenSSL 1.1.1 oder neuer. |
| TLSCipherPSK | Gültige OpenSSL Cipher-Strings für TLS 1.2 oder gültige GnuTLS-Prioritätszeichenfolgen. Ihre Werte werden jeweils an die Funktionen SSL_CTX_set_cipher_list() bzw. gnutls_priority_init() übergeben. |
PSK-basierte Auswahlkriterien für Ciphersuites für TLS 1.2/1.3 (GnuTLS), TLS 1.2 (OpenSSL) | |
| Kombinierte Ciphersuite-Liste für Zertifikat und PSK | TLSCipherAll13 | Gültige OpenSSL 1.1.1 Cipher-Strings für das TLS-1.3-Protokoll (ihre Werte werden an die OpenSSL-Funktion SSL_CTX_set_ciphersuites() übergeben). |
Auswahlkriterien für Ciphersuites für TLS 1.3 Nur OpenSSL 1.1.1 oder neuer. |
| TLSCipherAll | Gültige OpenSSL Cipher-Strings für TLS 1.2 oder gültige GnuTLS-Prioritätszeichenfolgen. Ihre Werte werden jeweils an die Funktionen SSL_CTX_set_cipher_list() bzw. gnutls_priority_init() übergeben. |
Auswahlkriterien für Ciphersuites für TLS 1.2/1.3 (GnuTLS), TLS 1.2 (OpenSSL) |
Um die Auswahl der Ciphersuite in den Dienstprogrammen zabbix_get und zabbix_sender zu überschreiben, verwenden Sie die Befehlszeilenparameter:
--tls-cipher13--tls-cipher
Die neuen Parameter sind optional. Wenn ein Parameter nicht angegeben wird, wird der interne Standardwert verwendet. Wenn ein Parameter definiert ist, darf er nicht leer sein.
Wenn das Setzen eines TLSCipher*-Werts in der Kryptobibliothek fehlschlägt, dann werden der Server, Proxy oder Agent nicht gestartet und ein Fehler wird protokolliert.
Es ist wichtig zu verstehen, wann jeder Parameter anwendbar ist.
Ausgehende Verbindungen
Der einfachste Fall sind ausgehende Verbindungen:
- Für ausgehende Verbindungen mit Zertifikat - verwenden Sie TLSCipherCert13 oder TLSCipherCert
- Für ausgehende Verbindungen mit PSK - verwenden Sie TLSCipherPSK13 oder TLSCipherPSK
- Bei den Dienstprogrammen zabbix_get und zabbix_sender können die Befehlszeilen-
parameter
--tls-cipher13oder--tls-cipherverwendet werden (die Verschlüsselung wird eindeutig mit dem Parameter--tls-connectangegeben)
Eingehende Verbindungen
Bei eingehenden Verbindungen ist es etwas komplizierter, da die Regeln für Komponenten und Konfiguration spezifisch sind.
Für Zabbix Agent:
| Agent connection setup | Cipher configuration |
|---|---|
| TLSConnect=cert | TLSCipherCert, TLSCipherCert13 |
| TLSConnect=psk | TLSCipherPSK, TLSCipherPSK13 |
| TLSAccept=cert | TLSCipherCert, TLSCipherCert13 |
| TLSAccept=psk | TLSCipherPSK, TLSCipherPSK13 |
| TLSAccept=cert,psk | TLSCipherAll, TLSCipherAll13 |
Für Zabbix Server und Proxy:
| Connection setup | Cipher configuration |
|---|---|
| Outgoing connections using PSK | TLSCipherPSK, TLSCipherPSK13 |
| Incoming connections using certificates | TLSCipherAll, TLSCipherAll13 |
| Incoming connections using PSK if server has no certificate | TLSCipherPSK, TLSCipherPSK13 |
| Incoming connections using PSK if server has certificate | TLSCipherAll, TLSCipherAll13 |
In den beiden obigen Tabellen ist ein Muster erkennbar:
- TLSCipherAll und TLSCipherAll13 können nur angegeben werden, wenn eine kombinierte Liste von Cipher Suites auf Basis von Zertifikaten und PSK verwendet wird. Dies ist in zwei Fällen der Fall: Server (Proxy) mit konfiguriertem Zertifikat (PSK-Cipher Suites sind auf dem Server immer konfiguriert, auf dem Proxy, wenn die Kryptobibliothek PSK unterstützt), Agent, der so konfiguriert ist, dass er sowohl eingehende Verbindungen auf Zertifikats- als auch auf PSK-Basis akzeptiert
- in anderen Fällen sind TLSCipherCert* und/oder TLSCipherPSK* ausreichend
Die folgenden Tabellen zeigen die integrierten Standardwerte für TLSCipher*.
Sie können ein guter Ausgangspunkt für Ihre eigenen benutzerdefinierten Werte sein.
| Parameter | GnuTLS 3.6.12 |
|---|---|
| TLSCipherCert | NONE:+VERS-TLS1.2:+ECDHE-RSA:+RSA:+AES-128-GCM:+AES-128-CBC:+AEAD:+SHA256:+SHA1:+CURVE-ALL:+COMP-NULL:+SIGN-ALL:+CTYPE-X.509 |
| TLSCipherPSK | NONE:+VERS-TLS1.2:+ECDHE-PSK:+PSK:+AES-128-GCM:+AES-128-CBC:+AEAD:+SHA256:+SHA1:+CURVE-ALL:+COMP-NULL:+SIGN-ALL |
| TLSCipherAll | NONE:+VERS-TLS1.2:+ECDHE-RSA:+RSA:+ECDHE-PSK:+PSK:+AES-128-GCM:+AES-128-CBC:+AEAD:+SHA256:+SHA1:+CURVE-ALL:+COMP-NULL:+SIGN-ALL:+CTYPE-X.509 |
| Parameter | OpenSSL 1.1.1d 1 |
|---|---|
| TLSCipherCert13 | |
| TLSCipherCert | EECDH+aRSA+AES128:RSA+aRSA+AES128 |
| TLSCipherPSK13 | TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 |
| TLSCipherPSK | kECDHEPSK+AES128:kPSK+AES128 |
| TLSCipherAll13 | |
| TLSCipherAll | EECDH+aRSA+AES128:RSA+aRSA+AES128:kECDHEPSK+AES128:kPSK+AES128 |
1 Die Standardwerte unterscheiden sich bei älteren OpenSSL-Versionen (1.0.1, 1.0.2, 1.1.0), bei LibreSSL und wenn OpenSSL ohne PSK-Unterstützung kompiliert wurde.
Beispiele für benutzerkonfigurierte Cipher Suites
Siehe unten die folgenden Beispiele für benutzerkonfigurierte Cipher Suites:
Testen von Cipher-Strings und Zulassen nur von PFS-Cipher-Suites
Um zu sehen, welche Cipher-Suites ausgewählt wurden, müssen Sie
'DebugLevel=4' in der Konfigurationsdatei setzen oder die Option
-vv für zabbix_sender verwenden.
Es kann etwas Experimentieren mit den Parametern TLSCipher* nötig sein,
bevor Sie die gewünschten Cipher-Suites erhalten. Es ist unpraktisch,
den Zabbix Server, Proxy oder Agent mehrfach neu zu starten, nur um
TLSCipher*-Parameter anzupassen. Bequemer ist die Verwendung von
zabbix_sender oder des Befehls openssl. Wir zeigen beides.
1. Verwendung von zabbix_sender.
Erstellen wir eine Test-Konfigurationsdatei, zum Beispiel
/home/zabbix/test.conf, mit der Syntax einer zabbix_agentd.conf-Datei:
Hostname=nonexisting
ServerActive=nonexisting
TLSConnect=cert
TLSCAFile=/home/zabbix/ca.crt
TLSCertFile=/home/zabbix/agent.crt
TLSKeyFile=/home/zabbix/agent.key
TLSPSKIdentity=nonexisting
TLSPSKFile=/home/zabbix/agent.pskFür dieses Beispiel benötigen Sie gültige CA- und Agent-Zertifikate sowie PSK. Passen Sie die Pfade und Namen der Zertifikats- und PSK-Dateien an Ihre Umgebung an.
Wenn Sie keine Zertifikate, sondern nur PSK verwenden, können Sie eine einfachere Testdatei erstellen:
Hostname=nonexisting
ServerActive=nonexisting
TLSConnect=psk
TLSPSKIdentity=nonexisting
TLSPSKFile=/home/zabbix/agentd.pskDie ausgewählten Cipher-Suites können durch Ausführen von zabbix_sender
angezeigt werden (Beispiel kompiliert mit OpenSSL 1.1.d):
$ zabbix_sender -vv -c /home/zabbix/test.conf -k nonexisting_item -o 1 2>&1 | grep ciphersuites
zabbix_sender [41271]: DEBUG: zbx_tls_init_child() certificate ciphersuites: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA AES128-GCM-SHA256 AES128-CCM8 AES128-CCM AES128-SHA256 AES128-SHA
zabbix_sender [41271]: DEBUG: zbx_tls_init_child() PSK ciphersuites: TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-PSK-AES128-CBC-SHA256 ECDHE-PSK-AES128-CBC-SHA PSK-AES128-GCM-SHA256 PSK-AES128-CCM8 PSK-AES128-CCM PSK-AES128-CBC-SHA256 PSK-AES128-CBC-SHA
zabbix_sender [41271]: DEBUG: zbx_tls_init_child() certificate and PSK ciphersuites: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA AES128-GCM-SHA256 AES128-CCM8 AES128-CCM AES128-SHA256 AES128-SHA ECDHE-PSK-AES128-CBC-SHA256 ECDHE-PSK-AES128-CBC-SHA PSK-AES128-GCM-SHA256 PSK-AES128-CCM8 PSK-AES128-CCM PSK-AES128-CBC-SHA256 PSK-AES128-CBC-SHAHier sehen Sie die standardmäßig ausgewählten Cipher-Suites. Diese Standardwerte werden gewählt, um die Interoperabilität mit Zabbix Agents auf Systemen mit älteren OpenSSL-Versionen (ab 1.0.1) sicherzustellen.
Auf neueren Systemen können Sie die Sicherheit erhöhen, indem Sie nur
wenige Cipher-Suites zulassen, z. B. nur Cipher-Suites mit PFS
(Perfect Forward Secrecy). Versuchen wir, nur Cipher-Suites mit PFS
mithilfe der Parameter TLSCipher* zuzulassen.
Das Ergebnis ist nicht interoperabel mit Systemen, die OpenSSL 1.0.1 und 1.0.2 verwenden, wenn PSK genutzt wird. Verschlüsselung auf Zertifikatsbasis sollte funktionieren.
Fügen Sie der Konfigurationsdatei test.conf zwei Zeilen hinzu:
TLSCipherCert=EECDH+aRSA+AES128
TLSCipherPSK=kECDHEPSK+AES128und testen Sie erneut:
$ zabbix_sender -vv -c /home/zabbix/test.conf -k nonexisting_item -o 1 2>&1 | grep ciphersuites
zabbix_sender [42892]: DEBUG: zbx_tls_init_child() certificate ciphersuites: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA
zabbix_sender [42892]: DEBUG: zbx_tls_init_child() PSK ciphersuites: TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-PSK-AES128-CBC-SHA256 ECDHE-PSK-AES128-CBC-SHA
zabbix_sender [42892]: DEBUG: zbx_tls_init_child() certificate and PSK ciphersuites: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA AES128-GCM-SHA256 AES128-CCM8 AES128-CCM AES128-SHA256 AES128-SHA ECDHE-PSK-AES128-CBC-SHA256 ECDHE-PSK-AES128-CBC-SHA PSK-AES128-GCM-SHA256 PSK-AES128-CCM8 PSK-AES128-CCM PSK-AES128-CBC-SHA256 PSK-AES128-CBC-SHA Die Listen "certificate ciphersuites" und "PSK ciphersuites" haben sich geändert - sie sind kürzer als zuvor und enthalten wie erwartet nur TLS-1.3-Cipher-Suites und TLS-1.2-ECDHE-*-Cipher-Suites.
2. TLSCipherAll und TLSCipherAll13 können mit
zabbix_sender nicht getestet werden; sie beeinflussen den im obigen
Beispiel angezeigten Wert "certificate and PSK ciphersuites" nicht. Um
TLSCipherAll und TLSCipherAll13 anzupassen, müssen Sie mit dem Agent,
Proxy oder Server experimentieren.
Um also nur PFS-Cipher-Suites zuzulassen, müssen Sie möglicherweise bis zu drei Parameter hinzufügen
TLSCipherCert=EECDH+aRSA+AES128
TLSCipherPSK=kECDHEPSK+AES128
TLSCipherAll=EECDH+aRSA+AES128:kECDHEPSK+AES128zu zabbix_agentd.conf, zabbix_proxy.conf und zabbix_server.conf,
wenn jeder davon ein konfiguriertes Zertifikat hat und der Agent zudem
PSK verwendet.
Wenn Ihre Zabbix-Umgebung nur PSK-basierte Verschlüsselung und keine Zertifikate verwendet, dann nur einen:
TLSCipherPSK=kECDHEPSK+AES128Jetzt, da Sie verstanden haben, wie es funktioniert, können Sie die
Auswahl der Cipher-Suite auch außerhalb von Zabbix mit dem Befehl
openssl testen. Testen wir alle drei Werte der Parameter TLSCipher*:
$ openssl ciphers EECDH+aRSA+AES128 | sed 's/:/ /g'
TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA
$ openssl ciphers kECDHEPSK+AES128 | sed 's/:/ /g'
TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-PSK-AES128-CBC-SHA256 ECDHE-PSK-AES128-CBC-SHA
$ openssl ciphers EECDH+aRSA+AES128:kECDHEPSK+AES128 | sed 's/:/ /g'
TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-PSK-AES128-CBC-SHA256 ECDHE-PSK-AES128-CBC-SHASie können openssl ciphers auch mit der Option -V verwenden, um eine
ausführlichere Ausgabe zu erhalten:
$ openssl ciphers -V EECDH+aRSA+AES128:kECDHEPSK+AES128
0x13,0x02 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
0x13,0x01 - TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
0xC0,0x13 - ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
0xC0,0x37 - ECDHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(128) Mac=SHA256
0xC0,0x35 - ECDHE-PSK-AES128-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(128) Mac=SHA1Ebenso können Sie die Prioritätszeichenfolgen für GnuTLS testen:
$ gnutls-cli -l --priority=NONE:+VERS-TLS1.2:+ECDHE-RSA:+AES-128-GCM:+AES-128-CBC:+AEAD:+SHA256:+CURVE-ALL:+COMP-NULL:+SIGN-ALL:+CTYPE-X.509
Cipher suites for NONE:+VERS-TLS1.2:+ECDHE-RSA:+AES-128-GCM:+AES-128-CBC:+AEAD:+SHA256:+CURVE-ALL:+COMP-NULL:+SIGN-ALL:+CTYPE-X.509
TLS_ECDHE_RSA_AES_128_GCM_SHA256 0xc0, 0x2f TLS1.2
TLS_ECDHE_RSA_AES_128_CBC_SHA256 0xc0, 0x27 TLS1.2
Protocols: VERS-TLS1.2
Ciphers: AES-128-GCM, AES-128-CBC
MACs: AEAD, SHA256
Key Exchange Algorithms: ECDHE-RSA
Groups: GROUP-SECP256R1, GROUP-SECP384R1, GROUP-SECP521R1, GROUP-X25519, GROUP-X448, GROUP-FFDHE2048, GROUP-FFDHE3072, GROUP-FFDHE4096, GROUP-FFDHE6144, GROUP-FFDHE8192
PK-signatures: SIGN-RSA-SHA256, SIGN-RSA-PSS-SHA256, SIGN-RSA-PSS-RSAE-SHA256, SIGN-ECDSA-SHA256, SIGN-ECDSA-SECP256R1-SHA256, SIGN-EdDSA-Ed25519, SIGN-RSA-SHA384, SIGN-RSA-PSS-SHA384, SIGN-RSA-PSS-RSAE-SHA384, SIGN-ECDSA-SHA384, SIGN-ECDSA-SECP384R1-SHA384, SIGN-EdDSA-Ed448, SIGN-RSA-SHA512, SIGN-RSA-PSS-SHA512, SIGN-RSA-PSS-RSAE-SHA512, SIGN-ECDSA-SHA512, SIGN-ECDSA-SECP521R1-SHA512, SIGN-RSA-SHA1, SIGN-ECDSA-SHA1Wechsel von AES128 zu AES256
Zabbix verwendet AES128 standardmäßig als integrierte Voreinstellung für Daten. Nehmen wir an, Sie verwenden Zertifikate und möchten auf AES256 umstellen, unter OpenSSL 1.1.1.
Dies kann erreicht werden, indem die entsprechenden Parameter in zabbix_server.conf hinzugefügt werden:
TLSCAFile=/home/zabbix/ca.crt
TLSCertFile=/home/zabbix/server.crt
TLSKeyFile=/home/zabbix/server.key
TLSCipherCert13=TLS_AES_256_GCM_SHA384
TLSCipherCert=EECDH+aRSA+AES256:-SHA1:-SHA384
TLSCipherPSK13=TLS_CHACHA20_POLY1305_SHA256
TLSCipherPSK=kECDHEPSK+AES256:-SHA1
TLSCipherAll13=TLS_AES_256_GCM_SHA384
TLSCipherAll=EECDH+aRSA+AES256:-SHA1:-SHA384Obwohl nur zertifikatsbezogene Cipher Suites verwendet werden,
werden auch die Parameter TLSCipherPSK* definiert, um ihre Standardwerte zu vermeiden, die weniger sichere Cipher für eine breitere Interoperabilität enthalten. PSK-Cipher Suites können auf Server/Proxy nicht vollständig deaktiviert werden.
Und in zabbix_agentd.conf:
TLSConnect=cert
TLSAccept=cert
TLSCAFile=/home/zabbix/ca.crt
TLSCertFile=/home/zabbix/agent.crt
TLSKeyFile=/home/zabbix/agent.key
TLSCipherCert13=TLS_AES_256_GCM_SHA384
TLSCipherCert=EECDH+aRSA+AES256:-SHA1:-SHA384Fehlerbehebung bei Verschlüsselungsproblemen
Allgemeine Empfehlungen:
- Beginnen Sie damit, zu verstehen, welche Komponente im Problemfall als TLS-Client und welche als TLS-Server fungiert.
Zabbix Server, Proxies und Agents können je nach Interaktion untereinander alle sowohl als TLS-Server als auch als TLS-Clients arbeiten.
Beispielsweise fungiert der Zabbix Server beim Verbinden mit einem Agent für eine passive Prüfung als TLS-Client. Der Agent übernimmt dabei die Rolle des TLS-Servers.
Der Zabbix Agent, der von einem Proxy eine Liste aktiver Prüfungen anfordert, fungiert als TLS-Client. Der Proxy übernimmt dabei die Rolle des TLS-Servers.
Die Dienstprogrammezabbix_getundzabbix_senderfungieren immer als TLS-Clients. - Zabbix verwendet gegenseitige Authentifizierung.
Jede Seite überprüft ihren Gegenpart und kann die Verbindung ablehnen.
Beispielsweise kann der Zabbix Server beim Verbinden mit einem Agent die Verbindung sofort schließen, wenn das Zertifikat des Agents ungültig ist. Umgekehrt kann der Zabbix Agent, der eine Verbindung vom Server annimmt, die Verbindung schließen, wenn der Server vom Agent nicht als vertrauenswürdig eingestuft wird. - Prüfen Sie die Protokolldateien auf beiden Seiten - beim TLS-Client und beim TLS-Server.
Die Seite, die die Verbindung ablehnt, kann den genauen Grund dafür protokollieren. Die andere Seite meldet oft nur einen allgemeinen Fehler (z. B. "Connection closed by peer", "connection was non-properly terminated"). - Manchmal führt eine falsch konfigurierte Verschlüsselung zu verwirrenden Fehlermeldungen, die in keiner Weise auf die eigentliche Ursache hinweisen.
In den folgenden Unterabschnitten versuchen wir, eine (bei weitem nicht vollständige) Sammlung von Meldungen und möglichen Ursachen bereitzustellen, die bei der Fehlerbehebung helfen können.
Bitte beachten Sie, dass unterschiedliche Kryptobibliotheken (OpenSSL, GnuTLS) in denselben Problemsituationen oft unterschiedliche Fehlermeldungen erzeugen.
Manchmal hängen die Fehlermeldungen sogar von der jeweiligen Kombination der Kryptobibliotheken auf beiden Seiten ab.
Fehlerbehebung bei Verbindungsart- oder Berechtigungsproblemen
Server ist so konfiguriert, dass es sich mit PSK mit dem Agent verbindet, der Agent akzeptiert jedoch nur unverschlüsselte Verbindungen
Im Server- oder Proxy-Log (mit GnuTLS 3.3.16)
Wert vom Agent konnte nicht abgerufen werden: zbx_tls_connect(): gnutls_handshake() failed: \
-110 Die TLS-Verbindung wurde nicht ordnungsgemäß beendet.Im Server- oder Proxy-Log (mit OpenSSL 1.0.2c)
Wert vom Agent konnte nicht abgerufen werden: TCP-Verbindung erfolgreich, TLS zu [[127.0.0.1]:10050] kann nicht hergestellt werden: \
Verbindung vom Peer geschlossen. Prüfen Sie die zulässigen Verbindungstypen und ZugriffsrechteEine Seite verbindet sich mit Zertifikat, die andere Seite akzeptiert jedoch nur PSK oder umgekehrt
In einem beliebigen Log (mit GnuTLS):
eingehende Verbindung konnte nicht akzeptiert werden: von 127.0.0.1: zbx_tls_accept(): gnutls_handshake() fehlgeschlagen:\
-21 Eine unterstützte Cipher Suite konnte nicht ausgehandelt werden.In einem beliebigen Log (mit OpenSSL 1.0.2c):
eingehende Verbindung konnte nicht akzeptiert werden: von 127.0.0.1: TLS-Handshake gab Fehlercode 1 zurück:\
Datei .\ssl\s3_srvr.c Zeile 1411: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher:\
TLS write fatal alert "handshake failure"Versuch, Zabbix sender mit TLS-Unterstützung zu verwenden, um Daten an einen ohne TLS kompilierten Zabbix Server/Proxy zu senden
Im Log auf der Verbindungsseite:
Linux:
...In zbx_tls_init_child()
...OpenSSL library (version OpenSSL 1.1.1 11 Sep 2018) initialized
...
...In zbx_tls_connect(): psk_identity:"PSK test sender"
...End of zbx_tls_connect():FAIL error:'connection closed by peer'
...send value error: TCP successful, cannot establish TLS to [[localhost]:10051]: connection closed by peerWindows:
...OpenSSL library (version OpenSSL 1.1.1a 20 Nov 2018) initialized
...
...In zbx_tls_connect(): psk_identity:"PSK test sender"
...zbx_psk_client_cb() requested PSK identity "PSK test sender"
...End of zbx_tls_connect():FAIL error:'SSL_connect() I/O error: [0x00000000] The operation completed successfully.'
...send value error: TCP successful, cannot establish TLS to [[192.168.1.2]:10051]: SSL_connect() I/O error: [0x00000000] The operation completed successfully.Im Log auf der empfangenden Seite:
...failed to accept an incoming connection: from 127.0.0.1: support for TLS was not compiled inEine Seite verbindet sich mit PSK, die andere Seite verwendet LibreSSL oder wurde ohne Verschlüsselungsunterstützung kompiliert
LibreSSL unterstützt PSK nicht.
Im Log der verbindenden Seite:
...TCP erfolgreich, TLS zu [[192.168.1.2]:10050] kann nicht aufgebaut werden: SSL_connect() I/O error: [0] SuccessIm Log der annehmenden Seite:
...eingehende Verbindung konnte nicht angenommen werden: von 192.168.1.2: Unterstützung für PSK wurde nicht kompiliertIm Zabbix Frontend:
Wert von Agent konnte nicht abgerufen werden: TCP erfolgreich, TLS zu [[192.168.1.2]:10050] kann nicht aufgebaut werden: SSL_connect() I/O error: [0] SuccessEine Seite verbindet sich mit PSK, die andere Seite verwendet OpenSSL mit deaktivierter PSK-Unterstützung
Im Log der verbindenden Seite:
...TCP erfolgreich, TLS kann zu [[192.168.1.2]:10050] nicht aufgebaut werden: SSL_connect() setzte den Ergebniscode auf SSL_ERROR_SSL: file ../ssl/record/rec_layer_s3.c line 1536: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure: SSL alert number 40: TLS read fatal alert "handshake failure"Im Log der annehmenden Seite:
...eingehende Verbindung konnte nicht angenommen werden: von 192.168.1.2: TLS handshake setzte den Ergebniscode auf 1: file ssl/statem/statem_srvr.c line 1422: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher: TLS write fatal alert "handshake failure"