Chiffrement et sécurité

Chiffrement

Zabbix prend en charge les communications chiffrées entre les composants Zabbix à l'aide du protocole Transport Layer Security (TLS) v.1.2 et 1.3 (selon la bibliothèque cryptographique). Le chiffrement basé sur des certificats et le chiffrement basé sur une clé prépartagée sont pris en charge.

Le chiffrement peut être configuré pour les connexions :

  • Entre le serveur Zabbix, le proxy Zabbix, l'agent Zabbix, le service web Zabbix, les utilitaires zabbix_sender et zabbix_get
  • Vers la base de données Zabbix depuis l'interface Zabbix et serveur/proxy
  • Entre l'interface Zabbix et le serveur Zabbix

Le chiffrement est facultatif et configurable pour des composants individuels :

  • Certains proxies et agents peuvent être configurés pour utiliser un chiffrement basé sur des certificats avec le serveur, tandis que d'autres peuvent utiliser un chiffrement basé sur une clé prépartagée, et d'autres encore peuvent continuer à utiliser des communications non chiffrées (comme auparavant).
  • Le serveur (proxy) peut utiliser différentes configurations de chiffrement pour différents hôtes.

Les programmes démon de Zabbix utilisent un seul port d'écoute pour les connexions entrantes chiffrées et non chiffrées. L'ajout du chiffrement ne nécessite pas d'ouvrir de nouveaux ports sur les pare-feu.

Limitations
  • Les clés privées sont stockées en texte brut dans des fichiers lisibles par les composants Zabbix au démarrage.
  • Les clés prépartagées sont saisies dans l'interface Zabbix et stockées en texte brut dans la base de données Zabbix.
  • Le chiffrement intégré ne protège pas les communications entre le serveur web exécutant l'interface Zabbix et le navigateur web de l'utilisateur.
  • Actuellement, chaque connexion chiffrée s'ouvre avec une négociation TLS complète ; aucun cache de session ni ticket n'est implémenté.
  • L'ajout du chiffrement augmente le temps nécessaire aux vérifications d'éléments et aux actions, selon la latence du réseau :
    • Par exemple, si le délai des paquets est de 100 ms, l'ouverture d'une connexion TCP et l'envoi d'une requête non chiffrée prennent environ 200 ms. Avec le chiffrement, environ 1000 ms sont ajoutées pour l'établissement de la connexion TLS.
    • Il peut être nécessaire d'augmenter les délais d'attente, sinon certains éléments et actions exécutant des scripts distants sur les agents peuvent fonctionner avec des connexions non chiffrées, mais échouer par dépassement de délai avec le chiffrement.
  • Le chiffrement n'est pas pris en charge par la découverte réseau. Les vérifications de l'agent Zabbix effectuées par la découverte réseau seront non chiffrées et, si l'agent Zabbix est configuré pour refuser les connexions non chiffrées, ces vérifications échoueront.

Compilation de Zabbix avec prise en charge du chiffrement

Pour prendre en charge le chiffrement, Zabbix doit être compilé et lié avec l'une des bibliothèques cryptographiques prises en charge :

  • GnuTLS - à partir de la version 3.1.18
  • OpenSSL - versions 1.0.1, 1.0.2, 1.1.0, 1.1.1, 3.0.x - 3.5.x
  • LibreSSL - testé avec les versions 2.7.4, 2.8.2 :
    • LibreSSL 2.6.x n'est pas pris en charge
    • LibreSSL est pris en charge comme remplacement compatible d'OpenSSL ; les nouvelles fonctions d'API spécifiques à LibreSSL tls_*() ne sont pas utilisées. Les composants Zabbix compilés avec LibreSSL ne pourront pas utiliser PSK, seuls les certificats peuvent être utilisés.

Vous pouvez en savoir plus sur la configuration de SSL pour l'interface Zabbix en consultant ces bonnes pratiques.

La bibliothèque est sélectionnée en spécifiant l'option correspondante au script "configure" :

  • --with-gnutls[=DIR]
  • --with-openssl[=DIR] (également utilisé pour LibreSSL)

Par exemple, pour configurer les sources du serveur et de l'agent avec OpenSSL, vous pouvez utiliser quelque chose comme :

./configure --enable-server --enable-agent --with-mysql --enable-ipv6 --with-net-snmp --with-libcurl --with-libxml2 --with-openssl

Différents composants Zabbix peuvent être compilés avec différentes bibliothèques cryptographiques (par exemple, un serveur avec OpenSSL, un agent avec GnuTLS).

Si vous prévoyez d'utiliser des clés prépartagées (PSK), envisagez d'utiliser les bibliothèques GnuTLS ou OpenSSL 1.1.0 (ou plus récentes) dans les composants Zabbix utilisant des PSK. Les bibliothèques GnuTLS et OpenSSL 1.1.0 prennent en charge les suites cryptographiques PSK avec Perfect Forward Secrecy. Les anciennes versions de la bibliothèque OpenSSL (1.0.1, 1.0.2c) prennent également en charge les PSK, mais les suites cryptographiques PSK disponibles n'offrent pas de Perfect Forward Secrecy.

Gestion du chiffrement des connexions

Les connexions dans Zabbix peuvent utiliser :

Deux paramètres importants sont utilisés pour spécifier le chiffrement entre les composants Zabbix :

  • TLSConnect - spécifie quel chiffrement utiliser pour les connexions sortantes (non chiffrées, PSK ou certificat)
  • TLSAccept - spécifie quels types de connexions sont autorisés pour les connexions entrantes (non chiffrées, PSK ou certificat). Une ou plusieurs valeurs peuvent être spécifiées.

TLSConnect est utilisé dans les fichiers de configuration du proxy Zabbix (en mode actif, spécifie uniquement les connexions vers le serveur) et de l'agent Zabbix (pour les vérifications actives). Dans l'interface Zabbix, l'équivalent de TLSConnect est le champ Connexions vers l'hôte dans Collecte de données > Hôtes > <some host> > onglet Chiffrement et le champ Connexions vers le proxy dans Administration > Proxies > <some proxy> > onglet Chiffrement. Si le type de chiffrement configuré pour la connexion échoue, aucun autre type de chiffrement ne sera essayé.

TLSAccept est utilisé dans les fichiers de configuration du proxy Zabbix (en mode passif, spécifie uniquement les connexions depuis le serveur) et de l'agent Zabbix (pour les vérifications passives). Dans l'interface Zabbix, l'équivalent de TLSAccept est le champ Connexions depuis l'hôte dans Collecte de données > Hôtes > <some host> > onglet Chiffrement et le champ Connexions depuis le proxy dans Administration > Proxies > <some proxy> > onglet Chiffrement.

En général, vous configurez un seul type de chiffrement pour les connexions entrantes. Mais vous pouvez vouloir changer le type de chiffrement, par exemple, passer d'une connexion non chiffrée à un chiffrement basé sur certificat avec un temps d'arrêt minimal et une possibilité de retour arrière. Pour y parvenir :

  • Définissez TLSAccept=unencrypted,cert dans le fichier de configuration de l'agent et redémarrez l'agent Zabbix
  • Testez la connexion avec zabbix_get vers l'agent en utilisant un certificat. Si cela fonctionne, vous pouvez reconfigurer le chiffrement pour cet agent dans l'interface Zabbix, dans l'onglet Collecte de données > Hôtes > <some host> > Chiffrement, en définissant Connexions vers l'hôte sur "Certificate".
  • Lorsque le cache de configuration du serveur est mis à jour (et que la configuration du proxy est mise à jour si l'hôte est surveillé par un proxy), les connexions vers cet agent seront chiffrées
  • Si tout fonctionne comme prévu, vous pouvez définir TLSAccept=cert dans le fichier de configuration de l'agent et redémarrer l'agent Zabbix. Désormais, l'agent n'acceptera que les connexions chiffrées basées sur certificat. Les connexions non chiffrées et celles basées sur PSK seront rejetées.

De la même manière, cela fonctionne sur le serveur et le proxy. Si, dans l'interface Zabbix, dans la configuration de l'hôte, Connexions depuis l'hôte est défini sur "Certificate", alors seules les connexions chiffrées basées sur certificat seront acceptées depuis l'agent (vérifications actives) et zabbix_sender (éléments trapper).

Le plus souvent, vous configurerez les connexions entrantes et sortantes pour utiliser le même type de chiffrement, ou aucun chiffrement du tout. Mais techniquement, il est possible de les configurer de manière asymétrique, par exemple un chiffrement basé sur certificat pour les connexions entrantes et basé sur PSK pour les connexions sortantes.

La configuration du chiffrement pour chaque hôte est affichée dans l'interface Zabbix, dans Collecte de données > Hôtes, dans la colonne Chiffrement de l'agent. Par exemple :

Example Connections to host Allowed connections from host Rejected connections from host
none\_none.png Non chiffré Non chiffré Chiffré, chiffré basé sur certificat et chiffré basé sur PSK
cert\_cert.png Chiffré, basé sur certificat Chiffré, basé sur certificat Non chiffré et chiffré basé sur PSK
psk\_psk.png Chiffré, basé sur PSK Chiffré, basé sur PSK Non chiffré et chiffré basé sur certificat
psk\_none\_psk.png Chiffré, basé sur PSK Non chiffré et chiffré basé sur PSK Chiffré basé sur certificat
cert\_all.png Chiffré, basé sur certificat Non chiffré, chiffré basé sur PSK ou certificat -

Les connexions sont non chiffrées par défaut. Le chiffrement doit être configuré individuellement pour chaque hôte et proxy.

zabbix_get et zabbix_sender avec chiffrement

Voir les pages de manuel zabbix_get et zabbix_sender pour leur utilisation avec le chiffrement.

Suites de chiffrement

Les suites de chiffrement sont configurées par défaut en interne lors du démarrage de Zabbix.

Les suites de chiffrement configurées par l'utilisateur sont également prises en charge pour GnuTLS et OpenSSL. Les utilisateurs peuvent configurer les suites de chiffrement selon leurs politiques de sécurité. L'utilisation de cette fonctionnalité est facultative (les suites de chiffrement par défaut intégrées continuent de fonctionner).

Pour les bibliothèques cryptographiques compilées avec les paramètres par défaut, les règles intégrées de Zabbix produisent généralement les suites de chiffrement suivantes (dans l'ordre de priorité décroissante) :

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

Suites de chiffrement configurées par l'utilisateur

Les critères de sélection des suites de chiffrement intégrés peuvent être remplacés par des suites de chiffrement configurées par l'utilisateur.

Les suites de chiffrement configurées par l'utilisateur sont une fonctionnalité destinée aux utilisateurs avancés qui comprennent les suites de chiffrement TLS, leur sécurité et les conséquences d'erreurs, et qui sont à l'aise avec le dépannage TLS.

Les critères de sélection des suites de chiffrement intégrés peuvent être remplacés à l'aide des paramètres suivants :

Portée du remplacement Paramètre Valeur Description
Sélection des suites de chiffrement pour les certificats TLSCipherCert13 Chaînes de chiffrement OpenSSL 1.1.1 valides cipher strings pour le protocole TLS 1.3 (leurs valeurs sont transmises à la fonction OpenSSL SSL_CTX_set_ciphersuites()). Critères de sélection des suites de chiffrement basés sur les certificats pour TLS 1.3

OpenSSL 1.1.1 ou version plus récente uniquement.
TLSCipherCert Chaînes de chiffrement OpenSSL valides cipher strings pour TLS 1.2 ou chaînes de priorité GnuTLS valides priority strings. Leurs valeurs sont transmises respectivement aux fonctions SSL_CTX_set_cipher_list() ou gnutls_priority_init(). Critères de sélection des suites de chiffrement basés sur les certificats pour TLS 1.2/1.3 (GnuTLS), TLS 1.2 (OpenSSL)
Sélection des suites de chiffrement pour PSK TLSCipherPSK13 Chaînes de chiffrement OpenSSL 1.1.1 valides cipher strings pour le protocole TLS 1.3 (leurs valeurs sont transmises à la fonction OpenSSL SSL_CTX_set_ciphersuites()). Critères de sélection des suites de chiffrement basés sur PSK pour TLS 1.3

OpenSSL 1.1.1 ou version plus récente uniquement.
TLSCipherPSK Chaînes de chiffrement OpenSSL valides cipher strings pour TLS 1.2 ou chaînes de priorité GnuTLS valides priority strings. Leurs valeurs sont transmises respectivement aux fonctions SSL_CTX_set_cipher_list() ou gnutls_priority_init(). Critères de sélection des suites de chiffrement basés sur PSK pour TLS 1.2/1.3 (GnuTLS), TLS 1.2 (OpenSSL)
Liste combinée des suites de chiffrement pour certificat et PSK TLSCipherAll13 Chaînes de chiffrement OpenSSL 1.1.1 valides cipher strings pour le protocole TLS 1.3 (leurs valeurs sont transmises à la fonction OpenSSL SSL_CTX_set_ciphersuites()). Critères de sélection des suites de chiffrement pour TLS 1.3

OpenSSL 1.1.1 ou version plus récente uniquement.
TLSCipherAll Chaînes de chiffrement OpenSSL valides cipher strings pour TLS 1.2 ou chaînes de priorité GnuTLS valides priority strings. Leurs valeurs sont transmises respectivement aux fonctions SSL_CTX_set_cipher_list() ou gnutls_priority_init(). Critères de sélection des suites de chiffrement pour TLS 1.2/1.3 (GnuTLS), TLS 1.2 (OpenSSL)

Pour remplacer la sélection des suites de chiffrement dans les utilitaires zabbix_get et zabbix_sender, utilisez les paramètres de ligne de commande :

  • --tls-cipher13
  • --tls-cipher

Les nouveaux paramètres sont facultatifs. Si un paramètre n'est pas spécifié, la valeur interne par défaut est utilisée. Si un paramètre est défini, il ne peut pas être vide.

Si la définition d'une valeur TLSCipher* dans la bibliothèque cryptographique échoue, le serveur, le proxy ou l'agent ne démarrera pas et une erreur sera consignée.

Il est important de comprendre quand chaque paramètre s'applique.

Connexions sortantes

Le cas le plus simple est celui des connexions sortantes :

  • Pour les connexions sortantes avec certificat - utilisez TLSCipherCert13 ou TLSCipherCert
  • Pour les connexions sortantes avec PSK - utilisez TLSCipherPSK13 ou TLSCipherPSK
  • Dans le cas des utilitaires zabbix_get et zabbix_sender, les paramètres de ligne de commande --tls-cipher13 ou --tls-cipher peuvent être utilisés (le chiffrement est spécifié sans ambiguïté avec un paramètre --tls-connect)
Connexions entrantes

La situation est un peu plus complexe pour les connexions entrantes, car les règles sont spécifiques aux composants et à la configuration.

Pour l'agent Zabbix :

Configuration de connexion de l'agent Configuration des chiffrements
TLSConnect=cert TLSCipherCert, TLSCipherCert13
TLSConnect=psk TLSCipherPSK, TLSCipherPSK13
TLSAccept=cert TLSCipherCert, TLSCipherCert13
TLSAccept=psk TLSCipherPSK, TLSCipherPSK13
TLSAccept=cert,psk TLSCipherAll, TLSCipherAll13

Pour le serveur et le proxy Zabbix :

Configuration de connexion Configuration des chiffrements
Connexions sortantes utilisant PSK TLSCipherPSK, TLSCipherPSK13
Connexions entrantes utilisant des certificats TLSCipherAll, TLSCipherAll13
Connexions entrantes utilisant PSK si le serveur n'a pas de certificat TLSCipherPSK, TLSCipherPSK13
Connexions entrantes utilisant PSK si le serveur a un certificat TLSCipherAll, TLSCipherAll13

On peut observer un certain schéma dans les deux tableaux ci-dessus :

  • TLSCipherAll et TLSCipherAll13 ne peuvent être spécifiés que si une liste combinée de suites de chiffrement basées sur les certificats et sur PSK est utilisée. Cela se produit dans deux cas : serveur (proxy) avec un certificat configuré (les suites de chiffrement PSK sont toujours configurées sur le serveur, et sur le proxy si la bibliothèque cryptographique prend en charge PSK), agent configuré pour accepter à la fois les connexions entrantes basées sur des certificats et celles basées sur PSK
  • dans les autres cas, TLSCipherCert* et/ou TLSCipherPSK* suffisent

Les tableaux suivants présentent les valeurs par défaut intégrées de TLSCipher*. Elles peuvent constituer un bon point de départ pour vos propres valeurs personnalisées.

Paramètre 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
Paramètre 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 Les valeurs par défaut sont différentes pour les versions plus anciennes d'OpenSSL (1.0.1, 1.0.2, 1.1.0), pour LibreSSL et si OpenSSL est compilé sans prise en charge de PSK.

Exemples de suites de chiffrement configurées par l'utilisateur

Voir ci-dessous les exemples suivants de suites de chiffrement configurées par l'utilisateur :

Test des chaînes de chiffrement et autorisation uniquement des suites de chiffrement PFS

Pour voir quelles suites de chiffrement ont été sélectionnées, vous devez définir DebugLevel=4 dans le fichier de configuration, ou utiliser l'option -vv pour zabbix_sender.

Quelques essais avec les paramètres TLSCipher* peuvent être nécessaires avant d'obtenir les suites de chiffrement souhaitées. Il est peu pratique de redémarrer plusieurs fois le serveur Zabbix, le proxy ou l'agent uniquement pour ajuster les paramètres TLSCipher*. Il est plus pratique d'utiliser zabbix_sender ou la commande openssl. Voyons les deux.

1. Utilisation de zabbix_sender.

Créons un fichier de configuration de test, par exemple /home/zabbix/test.conf, avec la syntaxe d'un fichier zabbix_agentd.conf :

  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.psk

Vous avez besoin de certificats CA et agent valides ainsi que d'une PSK pour cet exemple. Adaptez les chemins et les noms des fichiers de certificat et de PSK à votre environnement.

Si vous n'utilisez pas de certificats, mais uniquement une PSK, vous pouvez créer un fichier de test plus simple :

  Hostname=nonexisting
  ServerActive=nonexisting

  TLSConnect=psk
  TLSPSKIdentity=nonexisting
  TLSPSKFile=/home/zabbix/agentd.psk

Les suites de chiffrement sélectionnées peuvent être affichées en exécutant zabbix_sender (exemple compilé avec 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-SHA

Ici, vous voyez les suites de chiffrement sélectionnées par défaut. Ces valeurs par défaut sont choisies pour garantir l'interopérabilité avec les agents Zabbix exécutés sur des systèmes utilisant d'anciennes versions d'OpenSSL (à partir de 1.0.1).

Sur des systèmes plus récents, vous pouvez renforcer la sécurité en n'autorisant que quelques suites de chiffrement, par exemple uniquement celles avec PFS (Perfect Forward Secrecy). Essayons d'autoriser uniquement les suites de chiffrement avec PFS à l'aide des paramètres TLSCipher*.

Le résultat ne sera pas interopérable avec les systèmes utilisant OpenSSL 1.0.1 et 1.0.2 si PSK est utilisé. Le chiffrement basé sur les certificats devrait fonctionner.

Ajoutez deux lignes au fichier de configuration test.conf :

  TLSCipherCert=EECDH+aRSA+AES128
  TLSCipherPSK=kECDHEPSK+AES128

puis testez à nouveau :

  $ 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

Les listes "certificate ciphersuites" et "PSK ciphersuites" ont changé

  • elles sont plus courtes qu'auparavant et ne contiennent plus que les suites TLS 1.3 et les suites TLS 1.2 ECDHE-* comme prévu.

2. TLSCipherAll et TLSCipherAll13 ne peuvent pas être testés avec zabbix_sender ; ils n'affectent pas la valeur "certificate and PSK ciphersuites" affichée dans l'exemple ci-dessus. Pour ajuster TLSCipherAll et TLSCipherAll13, vous devez faire des essais avec l'agent, le proxy ou le serveur.

Ainsi, pour n'autoriser que les suites de chiffrement PFS, vous devrez peut-être ajouter jusqu'à trois paramètres

  TLSCipherCert=EECDH+aRSA+AES128
  TLSCipherPSK=kECDHEPSK+AES128
  TLSCipherAll=EECDH+aRSA+AES128:kECDHEPSK+AES128

dans zabbix_agentd.conf, zabbix_proxy.conf et zabbix_server.conf si chacun d'eux a un certificat configuré et si l'agent utilise également une PSK.

Si votre environnement Zabbix utilise uniquement un chiffrement basé sur PSK et aucun certificat, alors un seul paramètre suffit :

  TLSCipherPSK=kECDHEPSK+AES128

Maintenant que vous comprenez le fonctionnement, vous pouvez tester la sélection des suites de chiffrement même en dehors de Zabbix, avec la commande openssl. Testons les trois valeurs de paramètres 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-SHA

Vous pouvez préférer openssl ciphers avec l'option -V pour une sortie plus détaillée :

  $ 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=SHA1

De même, vous pouvez tester les chaînes de priorité pour GnuTLS :

  $ 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-SHA1
Passage de AES128 à AES256

Zabbix utilise AES128 comme valeur par défaut intégrée pour les données. Supposons que vous utilisiez des certificats et que vous souhaitiez passer à AES256, sur OpenSSL 1.1.1.

Cela peut être réalisé en ajoutant les paramètres correspondants dans zabbix_server.conf :

  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:-SHA384

Bien que seules les suites de chiffrement liées aux certificats seront utilisées, les paramètres TLSCipherPSK* sont également définis afin d'éviter leurs valeurs par défaut, qui incluent des chiffrements moins sécurisés pour une meilleure interopérabilité. Les suites de chiffrement PSK ne peuvent pas être complètement désactivées sur le serveur/proxy.

Et dans 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:-SHA384

Dépannage des problèmes de chiffrement

Recommandations générales :

  • Commencez par comprendre quel composant agit comme client TLS et lequel agit comme serveur TLS dans le cas problématique.
    Le serveur Zabbix, les proxies et les agents, selon leur interaction, peuvent tous fonctionner comme serveurs TLS et clients TLS.
    Par exemple, le serveur Zabbix se connectant à un agent pour une vérification passive agit comme client TLS. L'agent joue le rôle de serveur TLS.
    L'agent Zabbix, demandant une liste de vérifications actives au proxy, agit comme client TLS. Le proxy joue le rôle de serveur TLS.
    Les utilitaires zabbix_get et zabbix_sender agissent toujours comme clients TLS.
  • Zabbix utilise une authentification mutuelle.
    Chaque partie vérifie son pair et peut refuser la connexion.
    Par exemple, le serveur Zabbix se connectant à un agent peut fermer la connexion immédiatement si le certificat de l'agent n'est pas valide. Et inversement - l'agent Zabbix acceptant une connexion du serveur peut fermer la connexion si le serveur n'est pas approuvé par l'agent.
  • Examinez les fichiers journaux des deux côtés - côté client TLS et côté serveur TLS.
    Le côté qui refuse la connexion peut consigner une raison précise du refus. L'autre côté signale souvent une erreur plus générale (par exemple, "Connection closed by peer", "connection was non-properly terminated").
  • Parfois, une configuration incorrecte du chiffrement entraîne des messages d'erreur déroutants qui n'indiquent en rien la cause réelle.
    Dans les sous-sections ci-dessous, nous essayons de fournir une collection (loin d'être exhaustive) de messages et de causes possibles qui peuvent aider au dépannage.
    Veuillez noter que différents outils cryptographiques (OpenSSL, GnuTLS) produisent souvent des messages d'erreur différents dans les mêmes situations problématiques.
    Parfois, les messages d'erreur dépendent même de la combinaison particulière d'outils cryptographiques des deux côtés.

Dépannage des problèmes de type de connexion ou d'autorisation

Le serveur est configuré pour se connecter avec PSK à l'agent, mais l'agent n'accepte que des connexions non chiffrées

Dans le journal du serveur ou du proxy (avec GnuTLS 3.3.16)

Échec de l'obtention de la valeur depuis l'agent : zbx_tls_connect(): gnutls_handshake() failed: \
    -110 La connexion TLS a été interrompue de manière incorrecte.

Dans le journal du serveur ou du proxy (avec OpenSSL 1.0.2c)

Échec de l'obtention de la valeur depuis l'agent : connexion TCP réussie, impossible d'établir TLS vers [[127.0.0.1]:10050]: \
    Connexion fermée par le pair. Vérifiez les types de connexion autorisés et les droits d'accès
Un côté se connecte avec certificat, mais l'autre côté n'accepte que PSK, ou inversement

Dans n'importe quel journal (avec GnuTLS) :

failed to accept an incoming connection: from 127.0.0.1: zbx_tls_accept(): gnutls_handshake() failed:\
    -21 Could not negotiate a supported cipher suite.

Dans n'importe quel journal (avec OpenSSL 1.0.2c) :

failed to accept an incoming connection: from 127.0.0.1: TLS handshake returned error code 1:\
    file .\ssl\s3_srvr.c line 1411: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher:\
    TLS write fatal alert "handshake failure"

Tentative d'utilisation de Zabbix sender compilé avec la prise en charge TLS pour envoyer des données à un serveur/proxy Zabbix compilé sans TLS

Dans le journal du côté de la connexion :

Linux :

...Dans zbx_tls_init_child()
...Bibliothèque OpenSSL (version OpenSSL 1.1.1  11 Sep 2018) initialisée
...
...Dans zbx_tls_connect(): psk_identity:"PSK test sender"
...Fin de zbx_tls_connect():ÉCHEC erreur:'connexion fermée par le pair'
...erreur d'envoi de valeur : TCP réussi, impossible d'établir TLS vers [[localhost]:10051] : connexion fermée par le pair

Windows :

...Bibliothèque OpenSSL (version OpenSSL 1.1.1a  20 Nov 2018) initialisée
...
...Dans zbx_tls_connect(): psk_identity:"PSK test sender"
...zbx_psk_client_cb() a demandé l'identité PSK "PSK test sender"
...Fin de zbx_tls_connect():ÉCHEC erreur:'erreur d'E/S SSL_connect() : [0x00000000] L'opération s'est terminée avec succès.'
...erreur d'envoi de valeur : TCP réussi, impossible d'établir TLS vers [[192.168.1.2]:10051] : erreur d'E/S SSL_connect() : [0x00000000] L'opération s'est terminée avec succès.
Dans le journal du côté récepteur :
...échec de l'acceptation d'une connexion entrante : depuis 127.0.0.1 : la prise en charge de TLS n'a pas été compilée dans le binaire

Un côté se connecte avec PSK, mais l'autre côté utilise LibreSSL ou a été compilé sans prise en charge du chiffrement

LibreSSL ne prend pas en charge PSK.

Dans le journal du côté connectant :

...TCP successful, cannot establish TLS to [[192.168.1.2]:10050]: SSL_connect() I/O error: [0] Success

Dans le journal du côté acceptant :

...failed to accept an incoming connection: from 192.168.1.2: support for PSK was not compiled in

Dans l'interface Zabbix :

Get value from agent failed: TCP successful, cannot establish TLS to [[192.168.1.2]:10050]: SSL_connect() I/O error: [0] Success

Un côté se connecte avec PSK, mais l'autre côté utilise OpenSSL avec la prise en charge de PSK désactivée

Dans le journal du côté connectant :

...TCP réussi, impossible d'établir TLS vers [[192.168.1.2]:10050] : SSL_connect() a défini le code de résultat sur 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"

Dans le journal du côté acceptant :

...échec de l'acceptation d'une connexion entrante : depuis 192.168.1.2 : TLS handshake a défini le code de résultat sur 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"