Linux überwachen im Legacy-Modus

Eine umfangreiche Beschreibung der Installation aus deb- oder rpm-Paketen zeigen wir im Artikel Linux überwachen. Daher erklären wir hier nur die Vorgehensweise im Schnelldurchlauf.

In der Checkmk Raw Edition finden Sie die Linux-Pakete des Agenten über Setup > Agents > Linux. In den kommerziellen Editionen gelangen Sie im Setup-Menü über Agents > Windows, Linux, Solaris, AIX zunächst in die Agentenbäckerei, wo Sie die gebackenen Pakete finden. Von dort aus kommen Sie mit dem Menüeintrag Related > Linux, Solaris, AIX files zur Liste der Agentendateien

Sie können diese über den Browser herunterladen oder direkt auf dem Host im Monitoring wget oder curl zum Download nutzen:

Auf RHEL, SLES und verwandten Distributionen erfolgt die Installation des RPM-Pakets unter root mit dem Befehl rpm -U:

Die Option -U steht übrigens für „Update“, kann aber auch eine Erstinstallation korrekt durchführen.

Die Installation des DEB-Pakets auf Debian, Ubuntu oder verwandten Distributionen erfolgt unter root mit dem Befehl dpkg -i:

Für die komfortable distributionsunabhängige Installation benötigen Sie den Linux-Agenten im TGZ-Archivformat ("Tarball"), den Sie in den kommerziellen Editionen im Setup-Menü über Agents > Windows, Linux, Solaris, AIX herunterladen können. Das TGZ-Archiv enthält die komplette Verzeichnisstruktur des Linux-Agenten zum Entpacken im Wurzelverzeichnis des überwachten Hosts.

Damit alle Pfade stimmen, ist der Parameter -C ("change directory") beim Entpacken unerlässlich. Wir verwenden zudem --no-overwrite-dir, damit Berechtigungen von bereits vorhandenen Verzeichnissen nicht verändert werden:

Wenn Sie alles richtig gemacht haben, muss das Agentenskript jetzt einfach als Befehl ausführbar sein und seine typische Ausgabe erzeugen. Das | head schneidet hier alles ab der 11. Zeile weg:

Wird hier eine Versionsnummer kleiner als 2.2.0 ausgegeben, haben Sie vermutlich noch eine ältere Version des Agentenskripts als /usr/local/bin/check_mk_agent installiert. Verschieben Sie dieses alte Skript, oder benennen Sie es um, beispielsweise indem Sie .bak an den Dateinamen anhängen.

Die manuelle Installation des Agentenskripts ist zwar selten nötig, aber auch nicht sehr schwierig. Bei dieser Installationsart wird zunächst nur das Agentenskript installiert, aber noch keine Konfiguration des Zugriffs vorgenommen. Sie benötigen aus der Seite der Agentendateien dazu den Kasten Agents. Dort finden Sie die Datei check_mk_agent.linux:

Laden Sie diese Datei auf das Zielsystem und kopieren Sie sie in ein Verzeichnis, das für root ausführbar ist. Gut eignet sich /usr/local/bin/, da es sich im Suchpfad befindet und für eigene Erweiterungen gedacht ist. Alternativ können Sie /usr/bin oder ein Unterverzeichnis von /opt verwenden. Wir verwenden /usr/bin, damit alle Tests den anderen Installationsmethoden entsprechen. Die Installation können Sie auch direkt mit wget durchführen, sofern vorhanden:

Vergessen Sie nicht die letzten beiden Befehle: Damit entfernen Sie die Endung .linux und machen die Datei ausführbar. Jetzt muss der Agent als Befehl ausführbar sein und seine typische Ausgabe erzeugen. Das | head schneidet hier alles ab der 11. Zeile weg:

Falls Sie den Agenten konfigurieren oder erweitern möchten, müssen Sie die dafür notwendigen Verzeichnisse selbst anlegen. Der Ort für die drei notwendigen Verzeichnisse ist im Agenten hart kodiert in Variablen, die mit MK_ beginnen und über das Environment auch den Plugins bereitgestellt werden:

Diese drei Verzeichnisse sollten Sie anlegen (mit den Standardrechten 755 und root als Eigentümer):

Falls Sie die Pfade ändern möchten, so editieren Sie einfach /usr/bin/check_mk_agent.

Für die Konfiguration eines bereits vorhandenen xinetd, der das Verzeichnis /etc/xinetd.d/ zur Konfiguration verwendet, bringen sowohl das TGZ-Archiv als auch die DEB- und RPM-Pakete ein Skript bei, welches in zwei Schritten zuerst die Konfiguration installiert und dann den xinetd die geänderten Einstellungen einlesen lässt. Das Skript müssen Sie mit vollem Pfad aufrufen:

Bei manueller Installation des Agentenskriptes legen Sie die Konfigurationsdatei /etc/xinetd.d/check-mk-agent mit dem Editor an. Als Inhalt genügt:

Hier haben wir eine (auskommentierte) Zeile ergänzt, in welcher der Zugriff auf zwei Checkmk-Server eingeschränkt wird. Weitere Konfigurationsmöglichkeiten zeigt ein Blick in die Datei ~/share/check_mk/agents/scripts/super-server/1_xinetd/check-mk-agent auf Ihrem Checkmk-Server.

Falls Ihr xinetd das alte Konfigurationsschema mit lediglich einer großen /etc/xinetd.conf nutzt, übertragen Sie die Beispielkonfiguration aus /etc/check_mk/xinetd-service-template.cfg in die /etc/xinetd.conf.

Ist die Konfiguration des xinetd abgeschlossen, starten Sie ihn neu:

Sie sind nun bereit für den Verbindungstest.

Prüfen Sie zunächst, ob Ihre /etc/services bereits einen Eintrag für Port 6556 enthält:

Ist dies nicht der Fall, muss Checkmk als Dienst bekannt gemacht werden. Fügen Sie dafür folgende Zeile hinzu. Die Schreibweise entspricht dabei exakt der in der IANA-Tabelle hinterlegten mit nur einem Bindestrich:

Das Format der Konfigurationsdatei /etc/inetd.conf unterscheidet sich zwischen den verschiedenen Varianten. Entnehmen Sie den Kommentaren in der Konfigurationsdatei und der Manual Page (man 5 inetd.conf) das zu Ihrem inetd passende Format. Es folgt die Konfiguration passend zum openbsd-inetd mit zwei Zeilen für IPv4- und IPv6-Unterstützung. Auch hier gilt es, die korrekte Schreibweise zu beachten:

Nach Änderung der Konfigurationsdatei starten Sie den inetd neu, bspw. mit:

Je nach verwendetem init-System und installiertem Superserver kann dieses Kommando abweichen.

Prüfen Sie zunächst, ob der xinetd oder inetd (neu) gestartet werden konnte:

Nun können Sie sich mit telnet oder nc (netcat) auf TCP Port 6556 verbinden – zunächst vom Host selbst, später vom Checkmk-Server aus:

Erfolgt trotz aktivem (x)inetd ein Hinweis auf eine verweigerte Verbindung, prüfen Sie Ihre Firewall-Einstellungen.

SSH arbeitet mit „Public-Key-Authentifizierung“. Dazu erzeugt man zunächst ein Paar von aufeinander abgestimmten Schlüsseln, bei denen einer öffentlich (public) ist und einer geheim (private). Bei der Wahl der Algorithmen können Sie wählen zwischen rsa, ecdsa oder ed25519. In dem nachfolgenden Beispiel nutzen Sie den Befehl ssh-keygen -t ed25519 als Instanzbenutzer:

Lassen Sie den Dateinamen leer, um den vorgeschlagenen Dateinamen zu verwenden. Selbstverständlich können Sie einen anderen Pfad angeben, beispielsweise wenn Sie mit verschiedenen Schlüsseln für verschiedene Hosts arbeiten wollen.

Wichtig: Geben Sie keine Passphrase an! Es nützt Ihnen nichts, die Datei mit dem geheimen Schlüssel zu verschlüsseln. Denn Sie möchten ja sicher nicht jedes Mal beim Start des Checkmk-Servers die Passphrase eingeben müssen…​

Das Ergebnis sind zwei Dateien im Verzeichnis .ssh:

Der private Schlüssel heißt id_ed25519 und ist nur für den Instanzbenutzer lesbar (-rw-------) — und das ist auch gut so! Der öffentliche Schlüssel id_ed25519.pub sieht etwa so aus:

Der nächste Schritt muss jetzt auf (je-)dem per SSH überwachten Linux-Hosts stattfinden. Loggen Sie sich dort als root ein und legen Sie in dessen Home-Verzeichnis (/root) das Unterverzeichnis .ssh an, falls es das nicht bereits gibt. Mit dem folgenden Befehl werden die Zugriffsrechte gleich korrekt auf 700 gesetzt:

Öffnen Sie jetzt die Datei authorized_keys mit einem Texteditor Ihrer Wahl. Falls die Datei nicht existiert, wird sie der Editor automatisch anlegen:

Kopieren Sie den Inhalt der öffentlichen Schlüssel in diese Datei. Das geht z.B. mit der Maus und Copy & Paste. Seien Sie genau! Jedes Leerzeichen zählt. Achten Sie auch darauf, dass nirgendwo zwei Leerzeichen hintereinander stehen. Und: Das ganze ist eine Zeile! Wenn die Datei schon existiert, dann hängen Sie einfach unten eine neue Zeile an.

Was jetzt kommt, ist sehr wichtig! Der SSH-Schlüssel soll ausschließlich zur Ausführung des Agenten dienen. SSH bietet so etwas unter dem Namen Command restriction an. Dazu setzen Sie den Text command="/usr/bin/check_mk_agent" an den Anfang der Zeile, die Sie gerade erzeugt haben — mit einem Leerzeichen vom Rest getrennt. Das sieht dann etwa so aus:

Speichern Sie die Datei und kontrollieren Sie die Rechte. Nur der Eigentümer darf Schreibrechte auf dieser Datei haben.

Testen Sie jetzt den Zugriff auf den Agenten mit dem Befehl ssh:

Beim ersten Mal müssen Sie den Fingerprint des Schlüssels mit der Eingabe von yes bestätigen. Alle weiteren Zugriffe können dann ohne Nutzerinteraktion erfolgen, so auch die minütliche automatische Abfrage des Agentenskripts durch den Checkmk-Server.

Wenn es nicht klappt, überprüfen Sie bitte:

Bei sehr alten Zielsystemen kann es zudem vorkommen, dass Schlüssel mit elliptischen Kurven (ed25519 und ecdsa) nicht bekannt sind. Erzeugen Sie in diesem Fall zusätzlich einen RSA-Schlüssel und tragen Sie auch diesen in die authorized_keys ein. SSH wird für die Verbindung dann automatisch den stärksten bekannten Schlüssel verwenden.

Das Zielsystem ist vorbereitet. Jetzt fehlt nur noch die Konfiguration von Checkmk selbst. Das geschieht über den Regelsatz Setup > Agents > Other integrations> Custom integrations > Individual program call instead of agent access. Erstellen Sie hier für die betroffenen Hosts eine Regel und tragen Sie als Befehl ssh -T root@$HOSTNAME$ oder ssh -C -T root@$HOSTNAME$ (für zusätzliche Komprimierung der Agentendaten) ein:

Sie können in der GUI unter Setup > Hosts > Properties of host > Test connection to host mit dem Button Run tests den Verbindungstest durchführen. Schlägt dieser mit Timeout oder verweigertem Zugriff fehl, überprüfen Sie, ob Sie zum Verbindungstest den Hostnamen in exakt der Schreibweise verwendet haben, die im Monitoring hinterlegt ist — OpenSSH unterscheidet mittlerweile zwischen Hostnamen ohne Domainpart, FQDN und IP-Adresse. Alternativ können Sie auch über die IP-Adresse zugreifen, müssen dann aber das Macro $HOSTADDRESS$ verwenden, welches durch die von Checkmk zwischengespeicherte IP-Adresse ersetzt wird.

Nach einem Speichern und einem Aktivieren der Änderungen ist der Host ins Monitoring aufgenommen. Im Monitoring wird nun der Dienst Check-MK Agent mit dem Hinweis Transport via SSH angezeigt. Zur weiteren Diagnose bieten sich die Befehle cmk -D und cmk -d an, die im Artikel über die Kommandozeile erklärt werden.

Sie können auch mit mehr als einem SSH-Schlüssel arbeiten. Legen Sie die Schlüssel in einem beliebigen Verzeichnis ab. In der Regel Individual program call instead of agent access müssen Sie den Pfad zum jeweiligen privaten Schlüssel dann mit der Option -i angeben. Verwenden Sie hier am besten $OMD_ROOT als Ersatz für den Pfad zum Instanzverzeichnis (/omd/sites/mysite). Der vollständige Befehl könnte dann ssh -i $OMD_ROOT/.ssh/my_key -T root@$HOSTADDRESS$ lauten und damit wäre die Konfiguration auch in einer Instanz mit einem anderen Namen lauffähig:

Sie können so für verschiedene Gruppen von Hosts verschiedene SSH-Schlüssel verwenden, indem Sie mehrere unterschiedliche Regeln verwenden.

Um potentielle Angreifer nicht trotz SSH-Tunnels mit Klartextdaten zu versorgen, müssen Sie auf dem Host im Monitoring den eventuell noch möglichen Zugriff auf Port 6556 deaktivieren. Falls der oben ausgeführte Befehl ss -tulpn | grep 6556 keinen Prozess gefunden hat, der an TCP Port 6556 lauscht, sind Sie mit der Einrichtung des SSH-Tunnels fertig. Wird eine Zeile ausgegeben, muss der gefundene Prozess dauerhaft deaktiviert werden.

Vergessen Sie auf keinen Fall einen abschließenden Test. Eine Verbindung auf Port 6556 darf jetzt nicht mehr möglich sein:

Das Aufsetzen der Verschlüsselung mit der Agentenbäckerei geht so: Mit dem ersten Schritt, dem Erstellen der Regel Symmetric encryption (Linux, Windows), sind Sie fast fertig. Sie brauchen nur noch neue Agenten zu backen und zu verteilen. Die Datei /etc/check_mk/encryption.cfg wird automatisch für Sie erzeugt und mit in die Agentenpakete eingebaut. Übrig bleibt dann nur der dritte Schritt, d.h. die Erstellung der Regel Enforce agent data encryption.

Auch wenn ein Angreifer keine Befehle ausführen kann: Die Monitoring-Daten des Agenten könnten für ihn bereits nützlich sein, denn sie enthalten unter anderem eine Liste von allen auf dem System laufenden Prozessen. Am besten ist es daher, wenn die Daten nicht jeder einfach abrufen kann.

Wenn Sie den Checkmk Agenten über den xinetd freigeben, ist es sehr einfach und effektiv, den Zugriff auf bestimmte IP-Adressen zu beschränken — und zwar natürlich auf die des Monitoring-Servers. Das ist über die Direktive only_from der Konfigurationsdatei Ihres xinetd schnell zu erreichen. Tragen Sie durch Leerzeichen getrennt IP-Adressen oder Adressbereiche (in der Form 12.34.56.78/29 oder 1234::/46) ein. Zulässig sind auch Host-Namen. In diesem Fall wird geprüft, ob der durch Rückwärtsauflösung der IP-Adresse des anfragenden Hosts ermittelte Host-Name mit dem eingetragenen übereinstimmt:

In den kommerziellen Editionen können Benutzer der Agentenbäckerei die erlaubten IP-Adressen über den Regelsatz Allowed agent access via IP address (Linux, Windows) konfigurieren. Diesen Regelsatz finden Sie über Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Generic Options.

Natürlich kann ein Angreifer sehr leicht seine IP-Adresse fälschen und so eine Verbindung zum Agenten bekommen. Aber dann ist es sehr wahrscheinlich, dass er die Antwort nicht bekommt — weil diese zum echten Monitoring-Server geht. Oder er bekommt sie tatsächlich, aber der Checkmk-Server bekommt keinerlei Daten und wird sehr bald einen Fehler melden.