Mit Checkmk 2.3.0 haben wir die OpenSSL-Version von 1.1 auf 3.0 aktualisiert. Das bedeutet, dass die Standardeinstellungen für Verschlüsselungsalgorithmen, Handshake und Neuaushandlung viel strenger sind. Es kann daher vorkommen, dass aktive Checks für alle möglichen Arten von Diensten fehlschlagen, einschließlich (aber nicht beschränkt auf) check_http, check_smtp und anderen. In diesem Artikel erfahren Sie, wie Sie mögliche Probleme umgehen können.

Seit den bescheidenen Anfängen von Checkmk war OMD der bevorzugte Weg, alle Komponenten eines Monitoring-Systems gemeinsam zu verpacken. Dies umfasste nicht nur den Monitoring-Kern, das Web-Interface und die Datenbankkomponente. Es bedeutete auch, Bibliotheken wie OpenSSL oder den Python-Interpreter in bestimmten Versionen zu bündeln, die für alle unterstützten Betriebssysteme identisch sind. Diese Komponentenkonsistenz ist notwendig, um ein konsistentes Verhalten über eine breite Spanne an Betriebssystemen zu garantieren. Schließlich unterstützt Checkmk 2.3.0 auf der einen Seite recht alte wie RHEL 8 ebenso wie das bald veröffentlichte Ubuntu 24.04.

Ein größeres Update, welches den Versionssprung auf Checkmk 2.3.0 begleitet, ist der Wechsel von OpenSSL 1.1 zu 3.0. Die Entwickler von OpenSSL haben hart daran gearbeitet, veraltete Algorithmen, Protokolle und Erweiterungen zu entfernen und zu moderneren (lies: sichereren) Standardeinstellungen zu wechseln. Dass diese Änderungen die Kompatibilität zu älterer Soft- oder Hardware beeinflussen, ist unvermeidbar. Das Resultat sind fehlgeschlagene aktive Checks in Checkmk.

Grundsätzlich sollten diese fehlgeschlagenen Checks als Indikator dafür betrachtet werden, dass der betroffene Host im Monitoring auf modernere TLS-Bibliotheken oder wenigstens sicherere TLS spezifische Standardeinstellungen aktualisiert werden sollten. Bei internen Tests mit Checkmk 2.3.0 Beta genügte das bereits in den meisten Fällen.

Dennoch mag es nicht in allen Fällen möglich sein, TLS-Einstellungen zu ändern. Gründe, wie eine breite Kompatibilität zu anderen alten Systemen sicherzustellen, können valide sein. Für Systeme, bei denen weder Updates noch Konfigurationsänderungen möglich sind, werden sie das Verhalten von OpenSSL 3.x so ändern wollen, dass die Kommunikation mit diesen Systemen möglich ist. Dies erledigen Sie, indem Sie die Standardeinstellungen von OpenSSL mit einer freizügigeren Konfiguration überschreiben, die nur bei betroffenen Hosts angewandt wird.

Simulation des Verhaltens

Betrachten Sie dies als optionalen Schritt, der empfehlenswert ist, wenn Sie keinen dauerhaften Zugriff auf betroffene Systeme haben. Dies können Hosts sein, die in anderen Netzwerken verortet sind und auf die nur von Remote-Instanzen zugegriffen werden kann. Oder Sie sind Checkmk Partner und versuchen Lösungen für Probleme Ihrer Kunden zu finden. Hierfür ist das BadSSL-Projekt, welches unter https://badssl.com/ erreichbar ist, sehr praktisch. Es stellt Ihnen alle möglichen veralteten oder „fehlkonfigurierten“ SSL-Endpunkte für Tests zur Verfügung. Erstellen Sie eine Regel (im Beispiel für einen aktiven Check für einen HTTP Service), bei dem die Details des Fehlers dem Fehler entsprechen, der bei dem Host in Ihrem Monitoring auftritt.

“Setup > HTTP, TCP, Email, … > Check HTTP service”

Check HTTP service

Die Ausgabe des Checks sollte nun lauten: “CRIT - Cannot make SSL connection”:

Cannot make SSL connection

Erstellung des Workarounds

Erster Schritt: Anlegen der eigenen OpenSSL Konfigurationsdatei

Erstellen Sie eine Konfigurationsdatei im Verzeichnis etc/ folder des Instanznutzenden. Unser Beispiel verwendet einfach den Dateinamen unsafe_openssl.cnf. In größeren Umgebungen können Sie am Ende durchaus mehrere verschiedene Dateien haben, die verschiedene Probleme adressieren:

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

Zweiter Schritt: Kopieren Sie die Kommandozeile des fehlschlagenden Checks

Service check command

Jetzt müssen Sie herausfinden, welches Plugin benutzt wird. Wechseln Sie in die Details des Checks und suchen Sie das “Service check command”. Der Name des Plugins ist die Zeichenkette zwischen ‘check_mk_active-’ und dem Ausrufezeichen ‘!’. Zudem benötigen Sie die Parameter, die nach dem ersten (und in der Regel einzigen) Ausrufezeichen stehen:

In diesem Fall kopieren Sie das folgende:

Plugin: http

Arguments: -C 0,0 --sni -p 1010 -I tls-v1-0.badssl.com -H tls-v1-0.badssl.com

Dritter Schritt: Nagios Plugins integrieren

Der Workaround besteht im Wesentlichen darin, das Check-Plugin mit einer anderen Environment aufzurufen, welche zur Folge hat, dass die freizügigere Konfiguration benutzt wird, die im ersten Schritt erstellt wurde. Navigieren Sie zu

“Setup > [show more] > Other services > Integrate Nagios plugins”

Nun müssen Sie den neuen Befehlsaufruf zusammenbauen. Das Voranstellen der Umgebungsvariable OPENSSL_CONF weist OpenSSL an, die Konfigurationsdatei unsafe_openssl.cnf zu verwenden, die Sie im ersten Schritt erstellt haben:

OPENSSL_CONF="$HOME/etc/unsafe_openssl.cnf"

Nun geben Sie an, welches Programm aufgerufen wird. Dies ist der Plugin-Name aus dem zweiten Schritt, dem check_ vorangestellt wird. Plugins liegen gewöhnlich im Instanz spezifischen Verzeichnis lib/nagios/plugins/ – als Aufruf ergibt dies:

$HOME/lib/nagios/plugins/check_http

Zuletzt werden die Parameter benötigt, die Sie auch im zweiten Schritt notiert haben:

-C 0,0 --sni -p 1010 -I tls-v1-0.badssl.com -H tls-v1-0.badssl.com

Der folgende schnelle Hack konvertiert den gesamten kopierten Befehl in einen, der die angepasste Konfigurationsdatei verwendet. Benutzung auf eigene Gefahr! Prüfen Sie das Resultat immer vor Verwendung:

echo '<<<COPIED COMMANDLINE>>>' | python -c 'import sys; cmdline = sys.stdin.read().strip(); cmd, args = cmdline.split("!", maxsplit=1); cmd = cmd.removeprefix("check_mk_active-"); print(f"OPENSSL_CONF=\"$HOME/etc/unsafe_openssl.cnf\" $HOME/lib/nagios/plugins/check_{cmd} {args}")'

An diesem Punkt können Sie das gesamte Kommando in eine Shell des Instanznutzers kopieren, um es einmal auszuprobieren. Prüfen Sie danach sowohl die Ausgabe als auch den Rückgabewert (in der Variablen $? enthalten).

Zu guter Letzt fügen Sie den gesamten Befehl in das Eingabefeld, welches mit Command line betitelt ist und speichern die Regel:

Command line

Das HTTPS-BadSSL-Beispiel 2 mit der benutzerdefinierten Konfiguration funktioniert jetzt und Beispiel 1 kann entfernt werden – in einer realen Situation hätten Sie wahrscheinlich zuerst Beispiel 1 entfernt und dem benutzerdefinierten Check denselben Namen gegeben wie dem zuvor fehlgeschlagenen.

HTTPS BadSSL example 1 and 2

Weiterführende Gedanken

Das angegebene Beispiel sollte in den meisten Fällen funktionieren. Ist dies nicht der Fall, empfehlen wir Ihnen, eine Lösung auszuarbeiten, die mit den Standard-Check-Plugins und OpenSSL 3.0 funktioniert. Dies kann weitere Änderungen an der Konfigurationsdatei bedeuten und am Ende dazu führen, dass Sie (wie eingangs erwähnt) am Ende mehrere Konfigurationsdateien für verschiedene Probleme haben. Wir würden uns freuen, wenn Sie Ihre Lösungen im Checkmk Forum bereitstellen würden. Bitte geben Sie dabei an, auf welche Software- oder Geräteversion Ihre Konfiguration abzielt.

Wie Sie nun wissen, bedeutet ein aktiver Check nur die Ausführung eines Programms, das den Spezifikationen des Monitoring Plugins Projekt entspricht. Wenn Sie keinen Erfolg mit der Änderung der Konfiguration für OpenSSL 3 haben, steht es Ihnen frei, ein Monitoring-Plugins-Paket aus einer anderen Quelle als Checkmk zu installieren. Die so bereitgestellten Checks kommen den von Checkmk mitgelieferten Checks nicht in die Quere.

Bevor Sie dies tun, beachten Sie jedoch bitte:

  1. Es kann sein, dass Sie so Sicherheitsprobleme verstecken, die dringend angegangen werden sollten.
  2. Der faule Ansatz kann zur Folge haben, dass es uns nicht gelingt, ein umfangreiches Archiv an Konfigurationsdateien für OpenSSL für gebräuchliche Hard- und Software aufzubauen.

Sie wurden gewarnt – und wollen dennoch weitermachen? Der erforderliche Aufwand kann gewaltig variieren: Die Installation ist möglicherweise so einfach wie das Paket des Distributors zu verwenden. Ubuntu 20.04 bietet beispielsweise die Monitoring-Plugins 2.2 als gegen OpenSSL 1.1 gelinktes Binärpaket. Diese Kombination zu testen, bereitet praktisch keine Arbeit und ist deshalb einen Versuch wert. Auf neueren Distributionen kann es dagegen notwendig sein, sowohl OpenSSL 1.1 als auch die Monitoring-Plugins aus Quellcodes zu bauen, was Herumdrehen an Compiler-Einstellungen und Patchen der Quellcodes bedeuten kann – und damit letztlich einiges an nervigem Trial-and-Error.

Fazit

Während es manchmal notwendig sein kann, die Kompatibilität für eine kleine Anzahl betroffener Systeme zu brechen, um eine bessere Sicherheit für die Mehrheit der Systeme zu erreichen, ermöglicht dennoch der offene Ansatz von Checkmk dank der Einhaltung gebräuchlicher offener Standards die Schaffung einfacher und zielführender Umgehungsmöglichkeiten.