15 Chiffrement

Vue d’ensemble

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 sur des clés pré-partagées est pris en charge.

Le chiffrement peut être configuré pour les connexions :

• Entre Zabbix server, Zabbix proxy, Zabbix agent, Zabbix web service, les utilitaires zabbix_sender et zabbix_get
• Vers la base de données Zabbix depuis Zabbix frontend et server/proxy
• Entre Zabbix frontend et Zabbix server

Le chiffrement est facultatif et configurable pour chaque composant individuellement :

• 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 des clés pré-partagées, et d’autres encore peuvent continuer à utiliser des communications non chiffrées (comme auparavant).
• Le serveur (proxy) peut utiliser des configurations de chiffrement différentes pour différents hôtes.

Les programmes daemon 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 l’ouverture 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 le frontend 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 le frontend 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 des éléments et aux actions, en fonction de 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 supplémentaires sont ajoutées pour établir la connexion TLS.
  • Il peut être nécessaire d'augmenter les délais d'expiration ; 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 des connexions chiffrées.
• 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 ne seront pas chiffrées et, si l'agent Zabbix est configuré pour rejeter les connexions non chiffrées, ces vérifications n'aboutiront pas.

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
• 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 tls_*() spécifiques à LibreSSL ne sont pas utilisées. Les composants Zabbix compilés avec LibreSSL ne pourront pas utiliser PSK, seuls les certificats pourront être utilisés.

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 une commande comme :

./configure --enable-server --enable-agent --with-mysql --enable-agent --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).

Gestion du chiffrement des connexions

Les connexions dans Zabbix peuvent utiliser :

• aucun chiffrement (par défaut)
• le chiffrement basé sur des certificats RSA
• le chiffrement basé sur PSK

Il existe deux paramètres importants 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 de Zabbix proxy (en mode actif, il spécifie uniquement les connexions vers le serveur) et de Zabbix agent (pour les vérifications actives). Dans le frontend Zabbix, l’équivalent de TLSConnect est le champ Connections to host dans l’onglet Data collection → Hosts → <some host> → Encryption et le champ Connections to proxy dans l’onglet Administration → Proxies → <some proxy> → Encryption. 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 de Zabbix proxy (en mode passif, il spécifie uniquement les connexions provenant du serveur) et de Zabbix agent (pour les vérifications passives). Dans le frontend Zabbix, l’équivalent de TLSAccept est le champ Connections from host dans l’onglet Data collection → Hosts → <some host> → Encryption et le champ Connections from proxy dans l’onglet Administration → Proxies → <some proxy> → Encryption.

Normalement, vous ne configurez qu’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 en arrière. Pour y parvenir :

• Définissez TLSAccept=unencrypted,cert dans le fichier de configuration de l’agent et redémarrez Zabbix agent
• 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 le frontend Zabbix, dans l’onglet Data collection → Hosts → <some host> → Encryption, en définissant Connections to host 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 supervisé par un proxy), les connexions vers cet agent seront alors 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 Zabbix agent. L’agent n’acceptera alors plus que les connexions chiffrées basées sur certificat. Les connexions non chiffrées et basées sur PSK seront rejetées.

De manière similaire, cela fonctionne sur le serveur et le proxy. Si, dans le frontend Zabbix, dans la configuration de l’hôte, Connections from host 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. Mais techniquement, il est possible de le configurer de manière asymétrique, par exemple un chiffrement basé sur certificat pour les connexions entrantes et un chiffrement basé sur PSK pour les connexions sortantes.

La configuration du chiffrement pour chaque hôte est affichée dans le frontend Zabbix, dans Data collection → Hosts, dans la colonne Agent encryption. Par exemple :

Example	Connections to host	Allowed connections from host	Rejected connections from host
	Non chiffré	Non chiffré	Chiffré, chiffré basé sur certificat et chiffré basé sur PSK
	Chiffré, basé sur certificat	Chiffré, basé sur certificat	Non chiffré et chiffré basé sur PSK
	Chiffré, basé sur PSK	Chiffré, basé sur PSK	Non chiffré et chiffré basé sur certificat
	Chiffré, basé sur PSK	Non chiffré et chiffré basé sur PSK	Chiffré basé sur certificat
	Chiffré, basé sur certificat	Non chiffré, chiffré basé sur PSK ou basé sur certificat	-

zabbix_get et zabbix_sender avec chiffrement

Voir les man-pages zabbix_get et zabbix_sender pour une utilisation avec chiffrement.

Suites de chiffrement

Par défaut, les suites de chiffrement sont configurées 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 conformément à leurs politiques de sécurité. L'utilisation de cette fonctionnalité est facultative (les suites de chiffrement intégrées par défaut 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 aboutissent généralement aux suites de chiffrement suivantes (par ordre de priorité décroissant) :

Suites cryptographiques configurées par l'utilisateur

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

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

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

• --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, alors le serveur, le proxy ou l'agent ne démarrera pas et une erreur sera consignée dans le journal.

Il est important de comprendre dans quels cas 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 le paramètre --tls-connect)

Connexions entrantes

C’est un peu plus compliqué avec les connexions entrantes, car les règles sont spécifiques aux composants et à la configuration.

Pour l’agent Zabbix :

Pour le serveur et le proxy Zabbix :

Un certain schéma peut être observé 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 des 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, le proxy si la bibliothèque cryptographique prend en charge PSK), agent configuré pour accepter à la fois des connexions entrantes basées sur des certificats et sur PSK
• dans les autres cas, TLSCipherCert* et/ou TLSCipherPSK* suffisent

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

¹ Les valeurs par défaut sont différentes pour les anciennes versions 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 :

• Tester les chaînes de chiffrement et n’autoriser que les suites de chiffrement PFS
• Passer de AES128 à AES256

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

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

Il peut être nécessaire de faire quelques essais avec les paramètres TLSCipher* avant d’obtenir les suites cryptographiques souhaitées. Il est peu pratique de redémarrer plusieurs fois le serveur, le proxy ou l’agent Zabbix uniquement pour ajuster les paramètres TLSCipher*. Des options plus pratiques consistent à utiliser zabbix_sender ou la commande openssl. Montrons 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. Ajustez les chemins et les noms des fichiers de certificat et de PSK en fonction de 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 cryptographiques 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 cryptographiques 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 avec des versions plus anciennes d’OpenSSL (à partir de 1.0.1).

Avec des systèmes plus récents, vous pouvez choisir de renforcer la sécurité en n’autorisant qu’un petit nombre de suites cryptographiques, par exemple uniquement des suites cryptographiques avec PFS (Perfect Forward Secrecy). Essayons d’autoriser uniquement des suites cryptographiques avec PFS à l’aide des paramètres TLSCipher*.

Ajoutez deux lignes au fichier de configuration test.conf :

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

et 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 que des suites cryptographiques TLS 1.3 et des suites cryptographiques 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 des suites cryptographiques PFS, vous devrez peut-être ajouter jusqu’à trois paramètres

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

à zabbix_agentd.conf, zabbix_proxy.conf et zabbix_server_conf si chacun d’eux a un certificat configuré et si l’agent a également une PSK.

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

  TLSCipherPSK=kECDHEPSK+AES128

Maintenant que vous comprenez comment cela fonctionne, vous pouvez tester la sélection des suites cryptographiques même en dehors de Zabbix, avec la commande openssl. Testons les trois valeurs de paramètre 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

Passer de AES128 à AES256

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

Ceci peut être réalisé en ajoutant les paramètres respectifs suivants 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

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