17. Chiffrement

Aperçu

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 de chiffrement). Le chiffrement basé sur des certificats et basé sur des clés pré-partagées est pris en charge.

Le chiffrement peut être configuré pour les connexions :

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

Le chiffrement est facultatif et configurable pour les composants individuels :

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

Les démons Zabbix utilisent un port d'écoute pour les connexions entrantes chiffrées et non chiffrées. L'ajout d'un cryptage ne nécessite pas l'ouverture de nouveaux ports sur les pare-feux.

Limitations

• Les clés privées sont stockées en texte brut dans des fichiers lisibles par les composants Zabbix lors du démarrage
• Les clés pré-partagées sont saisies dans l'interface Zabbix et stockées dans la base de données Zabbix en texte brut
• Le cryptage intégré ne protège pas les communications :
  • Entre le serveur Web exécutant l'interface Zabbix et le navigateur Web de l'utilisateur
  • Entre l'interface Zabbix et le serveur Zabbix
• Actuellement, chaque connexion cryptée s'ouvre avec une vérification TLS complète, aucune mise en cache de session et les tickets ne sont implémentés
• L'ajout du chiffrement augmente le temps de vérification et d'action des éléments, en fonction de la latence du réseau :
  • Par exemple, si le délai de paquet est de 100 ms, l'ouverture d'une connexion TCP et l'envoi d'une requête non chiffrée prend environ 200 ms. Avec le cryptage, environ 1000 ms sont ajoutées pour établir la connexion TLS ;
  • Il peut être nécessaire d'augmenter les timeouts, sinon certains éléments et actions exécutant des scripts distants sur des agents peuvent fonctionner avec des connexions non chiffrées, mais échouer avec un délai d'expiration chiffré.
• Le chiffrement n'est pas pris en charge par la découverte du réseau. Les vérifications de l'agent Zabbix effectuées par la découverte du réseau ne seront pas chiffrées et si l'agent Zabbix est configuré pour rejeter les connexions non chiffrées, ces vérifications échoueront.

Compiler Zabbix avec prise en charge du chiffrement

Pour prendre en charge le chiffrement, Zabbix doit être compilé et lié à l'une des bibliothèques de chiffrement 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. Notez que 3.0.x est pris en charge depuis Zabbix 6.0.4.
• 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 en tant que remplacement compatible d'OpenSSL ; les nouvelles fonctions 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 peuvent être utilisés.

La bibliothèque est sélectionnée en spécifiant l'option respective pour "configurer" le script :

• --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 de chiffrement (par exemple, un serveur avec OpenSSL, un agent avec GnuTLS).

Gestion du chiffrement des connexions

Les connexions dans Zabbix peuvent utiliser :

• pas de cryptage (par défaut)
• Cryptage basé sur un certificat RSA
• Cryptage basé sur PSK

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

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

TLSConnect est utilisé dans les fichiers de configuration pour le proxy Zabbix (en mode actif, spécifie uniquement les connexions au serveur) et l'agent Zabbix (pour les vérifications actives). Dans l'interface Zabbix, l'équivalent TLSConnect est le champ Connexions à l'hôte dans l'onglet Configuration → Hôtes → <un hôte> → Chiffrement et le champ Connexions au proxy dans l'onglet Administration → Proxies → <un proxy> → 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 pour le proxy Zabbix (en mode passif, spécifie uniquement les connexions depuis le serveur) et l'agent Zabbix (pour les vérifications passives). Dans l'interface Zabbix, l'équivalent TLSAccept est le champ Connexions depuis l'hôte dans l'onglet Configuration → Hôtes → <un hôte> → Chiffrement et le champ Connexions depuis le proxy dans l'onglet Administration → Proxies → <un proxy> → Chiffrement .

Normalement, vous ne configurez qu'un seul type de chiffrement pour les chiffrements entrants. Mais vous voudrez peut-être changer le type de cryptage, par exemple de non crypté à basé sur certificat avec un temps d'arrêt minimum et une possibilité de restauration. 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 à l'agent à l'aide du certificat. Si cela fonctionne, vous pouvez reconfigurer le chiffrement pour cet agent dans l'interface Zabbix dans l'onglet Configuration → Hôtes → <un hôte> → Chiffrement en définissant Connexions à l'hôte sur "Certificat".
• 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 proxy), les connexions à cet agent seront crypté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 basées sur des certificats chiffrés. Les connexions non chiffrées et 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 "Certificat", seules les connexions chiffrées basées sur un certificat seront acceptées par l'agent (vérifications actives) et zabbix_sender (éléments de trappeur).

Vous configurerez très probablement les connexions entrantes et sortantes pour utiliser le même type de cryptage ou aucun cryptage du tout. Mais techniquement, il est possible de le configurer de manière asymétrique, par ex. 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 Configuration → Hôtes dans la colonne Chiffrement de l'agent. Par exemple:

Exemple	Connexions à l'hôte	Connexions autorisées depuis l'hôte	Connexions rejetées depuis l'hôte
	Non crypté	Non crypté	Crypté, certificat et cryptage basé sur PSK
	Crypté, basé sur un certificat	Crypté, basé sur un certificat	Non crypté et crypté par PSK
	Crypté, basé sur PSK	Crypté, basé sur PSK	Crypté non crypté et crypté sur certificat
	Crypté, basé sur PSK	Non crypté et crypté PSK	Crypté basé sur certificat
	Crypté, basé sur certificat	Non crypté, PSK ou crypté basé sur certificat	-

zabbix_get et zabbix_sender avec chiffrement

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

Suite de chiffrement

Les suites de chiffrement par défaut sont configurées en interne lors du démarrage de Zabbix et, avant Zabbix 4.0.19, 4.4.7, ne sont pas configurables par l'utilisateur.

Depuis Zabbix 4.0.19, 4.4.7, les suites de chiffrement configurées par l'utilisateur sont également prises en charge pour GnuTLS et OpenSSL. Les utilisateurs peuvent configurer des suites de chiffrement en fonction de leurs politiques de sécurité. L'utilisation de cette fonctionnalité est facultative (les suites de chiffrement par défaut intégrées fonctionnent toujours).

Pour les bibliothèques de chiffrement compilées avec les paramètres par défaut, les règles intégrées de Zabbix entraînent généralement les suites de chiffrement suivantes (dans l'ordre de priorité la plus élevée à la plus faible) :

Suites de chiffrement configurées par l'utilisateur

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

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

Pour remplacer la sélection de la suite 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 par défaut interne 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 de chiffrement échoue, le serveur, le proxy ou l'agent ne démarre pas et une erreur est consignée.

Il est important de comprendre quand chaque paramètre est applicable.

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 et TLSCipherPSK
• Dans le cas des utilitaires zabbix_get et zabbix_sender, les paramètres de ligne de commande --tls-cipher13 et --tls-cipher peuvent être utilisés (le chiffrement est spécifié sans ambiguïté avec un 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 :

Certains modèles peuvent être observés 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 et basées sur PSK est utilisée. Il existe deux cas où cela se produit : serveur (proxy) avec un certificat configuré (les suites de chiffrement PSK sont toujours configurées sur le serveur, proxy si la bibliothèque de chiffrement prend en charge PSK), agent configuré pour accepter les connexions entrantes basées sur certificat et PSK
• dans les autres cas TLSCipherCert* et/ou TLSCipherPSK* sont suffisants

Les tableaux suivants montrent les valeurs par défaut intégrées de TLSCipher*. Ils pourraient être un bon point de départ pour 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 le support 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 autoriser uniquement les suites de chiffrement PFS
• Passer de AES128 à AES256

Tester les chaînes de chiffrement et autoriser uniquement les 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.

Certaines expérimentations avec les paramètres TLSCipher * peuvent être nécessaires avant d'obtenir les suites de chiffrement souhaitées. Il n'est pas pratique de redémarrer plusieurs fois le serveur, le proxy ou l'agent Zabbix juste pour modifier les paramètres TLSCipher *. Des options plus pratiques utilisent 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 d'agent valides et de PSK pour cet exemple. Ajustez les chemins et les noms des certificats et des fichiers PSK pour votre environnement.

Si vous n'utilisez pas de certificats, mais uniquement 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 vues 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 assurer l'interopérabilité avec les agents Zabbix exécutés sur des systèmes avec des versions OpenSSL plus anciennes (à partir de 1.0.1).

Avec les systèmes plus récents, vous pouvez choisir de renforcer la sécurité en n'autorisant que quelques suites de chiffrement, par exemple uniquement les suites de chiffrement avec PFS (Perfect Forward Secrecy). Essayons de n'autoriser que les suites de chiffrement avec PFS en utilisant les 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, ne contenant que les suites de chiffrement TLS 1.3 et les suites de chiffrement 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" indiquée dans l'exemple ci-dessus. Pour modifier TLSCipherAll et TLSCipherAll13, vous devez l'expérimenter avec l'agent, le proxy ou le serveur.

Ainsi, pour autoriser uniquement 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 que l'agent a également PSK.

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

  TLSCipherPSK=kECDHEPSK+AES128

Maintenant que vous comprenez comment cela fonctionne, vous pouvez tester la sélection de la suite de chiffrement 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