So überwachen Sie Server mit kaputtem TLS in Checkmk 2.3

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.

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

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.

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.