Come monitorare i server con TLS interrotto in Checkmk 2.3

Con Checkmk 2.3.0 la versione di OpenSSL è passata da 1.1 a 3.0. Ciò significa impostazioni predefinite molto più rigide per quanto riguarda i cifrari di sicurezza, le impostazioni di handshake e di rinegoziazione. Potreste riscontrare il fallimento dei check attivi per tutti i tipi di servizi, inclusi, ma non solo, check_http, check_smtp e molti altri. Ecco come risolvere i potenziali problemi.

Sin dagli inizi di Checkmk, OMD è stato un modo per impacchettare tutti i componenti di un sistema di monitoraggio. Questo non comprendeva solo il nucleo di monitoraggio, l'interfaccia web e i componenti del database. Si trattava anche di impacchettare librerie come OpenSSL o l'interprete Python in versioni specifiche, coerenti per tutti i sistemi operativi supportati. Questa coerenza dei componenti è necessaria per garantire un comportamento coerente su sistemi piuttosto vecchi come RHEL 8, ancora supportato, e allo stesso tempo supportare nuovi sistemi come Ubuntu 24.04, di prossima uscita.

Un importante aggiornamento che ha accompagnato l'aggiornamento 2.3.0 di Checkmk è il passaggio da OpenSSL 1.1 a 3.0. Gli sviluppatori di OpenSSL hanno lavorato duramente per garantire la coerenza dei componenti e per rimuovere i vecchi cifrari, i protocolli legacy e le estensioni, e passare a impostazioni predefinite più moderne (leggi: più sicure). Questo inevitabilmente rompe la compatibilità con il software o l'hardware più vecchio, dando luogo a check attivi falliti in Checkmk.

In generale, questi controlli falliti dovrebbero essere utilizzati come indicatore del fatto che l'host monitorato deve essere aggiornato con librerie TLS più moderne o che almeno le impostazioni specifiche di TLS devono essere regolate su valori predefiniti più sicuri. Durante i test interni con Checkmk 2.3.0 beta, questo ha già funzionato nella maggior parte dei casi.

Tuttavia, modificare le impostazioni TLS potrebbe non essere sempre possibile. Motivi come la necessità di mantenere una compatibilità più ampia con altri sistemi più vecchi possono essere validi. Per i sistemi in cui non è possibile né aggiornare né modificare la configurazione, si potrebbe voler cambiare il comportamento di OpenSSL 3.x per poter comunicare con questi sistemi. Questo si ottiene sovrascrivendo la configurazione predefinita di OpenSSL con una configurazione personalizzata più permissiva, che verrà applicata solo agli host interessati.

OMD[heute]:~$ cat << EOF > etc/unsafe_openssl.cnf 
# DISCLAIMER:
# This configuration is _very_ insecure.
# Please reconsider if it is possible to upgrade the monitored system instead.
# Proceed at your own risk.

# Tell openssl which section to check
openssl_conf = openssl_init

[openssl_init]
# Which section to use for tls/ssl related options
ssl_conf = ssl_configuration

[ssl_configuration]
# system_default will be applied during any creation of the SSL_CTX structure
system_default = policy

[policy]
# To read up on these options go to:
# https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html

MinProtocol = TLSv1
Options = UnsafeLegacyRenegotiation

# The Ciphers and the seclevel are explained here:
# https://www.openssl.org/docs/man1.1.1/man1/ciphers.html
# https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_security_level.html
CipherString = DEFAULT:@SECLEVEL=0
EOF

L'esempio fornito dovrebbe funzionare nella maggior parte dei casi. Se non dovesse funzionare, si consiglia di trovare una soluzione che funzioni con i check standard che utilizzano OpenSSL 3.0. Questo potrebbe comportare ulteriori modifiche al file di configurazione e quindi portare ai già citati file di configurazione multipli per problemi diversi. Vi saremmo grati se pubblicaste le vostre soluzioni nel forum di Checkmk. Non dimenticate di specificare la versione del software o del dispositivo a cui si rivolge la configurazione.

Come avete appreso, il check attivo significa semplicemente eseguire un programma che aderisce alle specifiche del progetto Monitoring Plug-ins. Se non si riesce a modificare la configurazione di OpenSSL 3 per il servizio che si desidera controllare, si può provare a installare un pacchetto di plug-in di monitoraggio da altre fonti diverse da Checkmk. Questi non interferiranno con quelli forniti da Checkmk.

Prima di fare ciò, si prega di considerare che:

1. Potreste avere problemi di sicurezza nascosti che devono essere affrontati con urgenza.

2. Un approccio "pigro" potrebbe impedirci di creare un archivio adeguato dei file di configurazione di OpenSSL 3 per i software e i dispositivi più diffusi.

Siete stati avvertiti ma volete comunque continuare? L'impegno necessario può variare notevolmente: L'installazione può essere semplice come l'utilizzo di un pacchetto fornito dalla distribuzione. Per esempio, Ubuntu 20.04 fornisce i plug-in di monitoraggio 2.2 come pacchetto binario collegato a OpenSSL 1.1. Testare questa combinazione non richiede praticamente alcuno sforzo, quindi vale la pena di provare. Sulle distribuzioni più recenti, può essere necessario compilare sia OpenSSL 1.1 che i plug-in di monitoraggio, il che potrebbe richiedere molte modifiche al compilatore, patch dei sorgenti e quindi noiosi tentativi ed errori.

Anche se a volte potrebbe essere necessario rompere la compatibilità per alcuni sistemi interessati per ottenere una maggiore sicurezza per la maggior parte dei sistemi, l'approccio aperto di Checkmk, con la sua adesione agli standard comunemente utilizzati, consente di creare soluzioni facili e mirate.