Windows überwachen

Checkmk bietet Ihnen für die Installation des Windows-Agenten verschiedene Wege — von der manuellen Installation der Einzelteile bis hin zum vollautomatischen Deployment. Manche davon stehen nur in den Checkmk Enterprise Editions zur Verfügung:

Unabhängig davon, ob Sie die MSI-Pakete über die Agentenbäckerei erstellen lassen, oder auf jedem Host manuell konfigurieren: Sie benötigen zuerst die Installationsdatei. In der Checkmk Raw Edition gelangen Sie über Setup > Agents > Windows zu den Packaged Agents. Dort finden die benötigte Datei check_mk_agent.msi.

In den Enterprise Editions finden Sie die gebackenen Pakete über Setup > Agents > Windows, Linux, Solaris, AIX. Klicken Sie zum Download einfach auf das Icon in der Spalte Windows.

Laden Sie diese MSI-Datei auf den Host und starten Sie die Installation. Prinzipiell müssen Sie nur dem Menü folgen und die Lizenzbedingungen der GNU GENERAL PUBLIC LICENSE lesen und diesen zustimmen.

Nach der Installation wird der Agent sofort als Windows-Dienst gestartet und ist für die Überwachung des Systems bereit.

Die Checkmk Enterprise Editions verfügen auch für den Agenten unter Windows über die Möglichkeit, diesen über die Agentenbäckerei individuell über das Setup-Menü zu konfigurieren. Eine ausführliche Beschreibung finden Sie im allgemeinen Kapitel über die Agenten. Die Installation des gebackenen MSI-Pakets geschieht dann wieder genau wie oben beschrieben.

Wenn Sie die Agentenbäckerei verwenden, können Sie automatische Updates des Agenten einrichten. Diese werden in einem eigenen Artikel beschrieben.

Der Agent gliedert sich in zwei Bereiche des Dateisystems auf:

Für die Konfiguration des Agenten liest dieser nacheinander und hierarchisch drei Dateien ein:

Wie Sie vielleicht schon an der Dateiendung der Konfigurationsdateien erkannt haben, wird als Konfigurationsformat YAML verwendet. Wir haben uns entschieden, ab Version 1.6.0 dieses Format zu verwenden, da es damit einfacher möglich ist, strukturierte Daten zu konfigurieren, als mit dem klassischen INI-Format.

Für das manuelle Arbeiten mit dem Agenten ist also lediglich die letzte Konfigurationsdatei (check_mk.user.yaml) relevant, weil sie als letzte eingelesen wird und damit das letzte Wort hat. Wenn die Agentenbäckerei nicht genutzt wird, ist sie sogar die einzige Datei, in der Anpassungen an der Konfiguration des Agenten vorgenommen werden dürfen.

In früheren Versionen von Checkmk hatte der Agent eine andere Architektur. Diese hat sehr lange gut funktioniert und wurde erst ab 1.6.0 durch eine neue abgelöst, um alte Enden abzuschneiden, die Konfiguration zu vereinfachen und letztendlich auch, um bessere Werkzeuge an der Hand zu haben, um zum Beispiel Konfigurationsfehlern besser auf die Spur zu kommen.

Der alte Agent ist aus Kompatibilitätsgründen in Checkmk noch enthalten, da nur dieser alte Plattformen wie Windows XP und Windows 2003 zuverlässig überwachen kann. Diese beiden Systeme werden von dem neuen Agenten nicht mehr unterstützt. Zusätzlich soll der alte Agent die Migration zu dem aktuellen komfortabler gestalten. Dieser ist nach wie vor mit Checkmk kompatibel, sodass ein Update Ihres Checkmk-Servers auf Version 1.6.0 nicht automatisch auch ein Update der Agenten erfordert.

Der alte Windows-Agent hat folgende Unterschiede:

Die Migration von einem bereits installierten Agenten auf den aktuellen Agenten ist sehr einfach. Rufen Sie schlicht das Installationspaket des neuen Agenten (check_mk_agent.msi) auf und folgen Sie wie gewohnt den Anweisungen. Bei der Installation werden Sie immer gefragt, wie mit alten Konfigurationsdateien umgegangen werden soll:

Der alte Agent wird dann lediglich gestoppt und deaktiviert. Unabhängig davon wird die Konfiguration des alten Agenten als Teil des Installationsprozess in das neue Format übertragen und als Benutzerkonfiguration (check_mk.user.yml) abgespeichert. Das gibt Ihnen die Möglichkeit, die Konvertierung anhand der Originaldatei zu prüfen. Sobald Sie sicher sind, dass die Konvertierung erfolgreich war, können Sie den alten Agenten deinstallieren.

Eine solche händische Prüfung werden Sie wahrscheinlich nur für einzelne Hosts einer Gruppe machen wollen. Wenn Sie sich sicher sind, dass die Konvertierung korrekt funktioniert, können Sie den alten Agenten entsprechend automatisch deinstallieren lassen. Sie sparen sich dann die manuelle Deinstallation und tauschen lediglich den alten Agenten durch den neuen aus.

Wichtig: Nachdem Sie den alten Agenten entfernt haben, kann es sein, dass das Verzeichnis nicht vollständig gelöscht wurde. Das ist kein Fehler, sondern reguläres Verhalten, wenn sich in dem zu löschenden Verzeichnis Dateien befinden, die nicht über die Installationsroutine auf das System gekommen sind. Das können zum Beispiel Plugins oder eigene Konfigurationsdateien sein, die händisch von einem Benutzer angelegt wurden. Löschen Sie in solchen Fällen schlicht das Installationsverzeichnis des alten Agenten nach der Deinstallation, nachdem Sie sichergestellt haben, dass sich dort keine wichtigen Dateien mehr befinden.

Um zu prüfen, ob die Konfiguration so eingelesen wurde, wie Sie das erwarten, rufen Sie den Agenten mit der Option showconfig auf. Mit dieser Option bekommen Sie nicht nur die Konfiguration ausgegeben, wie sie derzeit vom Agenten benutzt wird. Zusätzlich werden auch immer die benutzten Umgebungsvariablen sowie die verwendeten Konfigurationsdateien angezeigt.

Ist nur ein bestimmter Teil der Konfiguration interessant, schränken Sie die Ausgabe auf einen bestimmten Teil ein. Hier wird zum Beispiel geprüft, ob die Optionen der Sektion ps korrekt gesetzt sind:

Über diesen Weg bekommen Sie einen schnellen Überblick, wie die drei verschiedenen Konfigurationsdateien von dem Agenten zusammengeführt und benutzt werden. Fehler werden somit sofort sichtbar.

Es gibt unter Windows verschiedene Möglichkeiten, den Agenten auf seine Funktion zu testen. Mit der Option help bekommen Sie eine Übersicht, welche Diagnosemöglichkeiten der Agent im Einzelnen bietet. Die wichtigsten sollen hier vorgestellt werden.

Der Agent bietet über die bereits beschriebenen Optionen noch weitere Möglichkeiten viele Details über das konkrete Verhalten des Agenten herauszufinden. Mit der Option help bekommen Sie unter anderem eine ausführliche und vollständige Liste an Möglichkeiten, die Ihnen über die hier beschriebenen hinaus zur Verfügung stehen.

Unter Windows können Sie weiterhin ihre Nagios-basierten Plugins auf einem Host ausführen, falls es dazu noch kein Pendant in Checkmk geben sollte. Der Mechanismus dafür ist recht simpel: Sie nutzen dafür das MRPE-Feature von Checkmk, welches sich analog zu dem NRPE von Nagios verhält.

Standardmäßig ist die Berücksichtigung von MRPE-Plugins aktiviert. Falls Sie diese Funktion nicht nutzen wollen, können Sie sie in der Konfigurationsdatei deaktivieren, indem Sie die folgende Definition hinzufügen:

Um dem Agenten mitzuteilen, wo sich die auszuführende Datei befindet und wie diese aufzurufen ist, fügen Sie einen Eintrag in der Konfiguration des MRPE hinzu:

Die Datei ebenfalls in dem Verzeichnis des Agenten abzulegen ist keine Voraussetzung, auch wenn es sich anbietet, um alle an einem gemeinsamen Ort abzulegen. In dieser Beispielkonfiguration sehen Sie nun folgende Elemente der relevanten Zeile:

Nachdem Sie das MRPE-Plugin eingerichtet haben, ist es direkt und ohne Neustart des Agenten aktiv und wird der Ausgabe hinzugefügt. In der Service-Erkennung werden Sie nun Ihren neuen Service automatisch finden:

Alternativ zu der Konfiguration direkt auf einem Host in der benutzerspezifischen Konfigurationsdatei können Sie Ihre MRPE-Plugins auch direkt im Setup-Menü definieren. Benutzen Sie dazu den Regelsatz Setup > Agents > Windows, Linux, Solaris, AIX > Agent > Agent rules > Execute MRPE checks. Der notwendige Eintrag wird dann automatisch in der Konfigurationsdatei der Agentenbäckerei erzeugt.

Der Standardagent enthält eine ganze Reihe von Sektionen, welche Überwachungsdaten für diverse Check-Plugins liefern und dann von der Service-Erkennung automatisch gefunden und als Services ausgegeben werden. Dazu gehören vor allem die wichtigen Überwachungen des Betriebssystems.

Darüber hinaus gibt es die Möglichkeit den Agenten um Agentenplugins zu erweitern. Das sind kleine Skripte oder Programme, die vom Agenten aufgerufen werden und diesen um weitere Sektionen mit zusätzlichen Monitoring-Daten erweitern. Das Checkmk-Projekt liefert hier bereits eine ganze Reihe solcher Plugins mit aus, welche — wenn sie korrekt installiert und konfiguriert sind — in der Service-Erkennung ebenfalls automatisch in neue Services münden.

Warum sind diese Plugins nicht einfach in den Standardagenten fest integriert? Für jedes der Plugins gibt es einen der folgenden Gründe:

Checkmk liefert wie bereits erwähnt eine ganze Reihe an Plugins für Windows mit. Sie finden diese auf dem überwachten Host in dem Installationsverzeichnis des Agenten. Dort werden alle verfügbaren Plugins immer direkt mit dem Agenten abgelegt, damit Sie auch direkt zur Verfügung stehen: C:\Program Files (x86)\checkmk\service\plugins. Alternativ finden Sie die Plugins auch auf dem Checkmk-Server selbst unter local/share/check_mk/agents/windows/plugins. Auch über Setup > Agents > Windows, Linux, Solaris, AIX > Related > Windows files sind diese im Kasten Plugins verfügbar. Hier ein Auszug:

Zu allen von uns mitgelieferten Agentenplugins gibt es auch passende Check-Plugins, welche die erhobenen Daten auswerten und Services erzeugen können. Sie müssen also nichts zusätzlich auf dem Checkmk-Server installieren.

Wichtig: Werfen sie einen Blick in ein Agentenplugin, bevor Sie es auf einem Host installieren. Oft finden Sie dort wichtige Hinweise zu der korrekten Verwendung.

Die eigentliche Installation ist dann einfach. Kopieren Sie das gewünschte Plugin entweder vom Checkmk-Server oder aus dem Installationsverzeichnis nach C:\ProgramData\checkmk\agent\plugins. Wenn das Plugin in diesem Verzeichnis liegt, wird es vom Agenten automatisch aufgerufen und es entsteht eine neue Sektion in der Agentenausgabe. Diese trägt üblicherweise den gleichen Namen wie das Plugin. Komplexe Plugins (z.B. mk_oracle.ps1) erzeugen sogar eine ganze Reihe an neuen Sektionen.

Manche Plugins benötigen eine Konfigurationsdatei in C:\ProgramData\checkmk\agent\config, damit sie funktionieren können. Bei anderen ist eine Konfiguration optional (z.B. mssql.vbs) und ermöglicht besondere Features oder Anpassungen. Wieder andere funktionieren ohne weitere Schritte. Sie haben verschiedene Quellen, um an Informationen zu kommen:

Auch bei speziellen (Skript)-Sprachen kann es notwendig sein, diese erst in der Konfiguration des Agenten freizuschalten. So werden beispielsweise Python-Skripte nicht ausgeführt, wenn sie nicht explizit freigegeben wurden. Sie können hier schlicht in der check_mk.user.yml in der Sektion global die Dateiendungen erweitern, wie in dem folgenden Ausschnitt zu sehen:

Wichtig: Der Einsatz solcher Plugins setzt natürlich voraus, dass die Dateien auch in einer regulären Kommandozeile ohne spezielle Pfade aufgerufen werden können. Im Fall von Python muss dieses entsprechend korrekt installiert und der Pfad zu dem Interpreter in den Umgebungsvariablen vorhanden sein. Anleitungen, wie Sie Python korrekt einrichten, finden Sie direkt auf den Seiten der Python Software Foundation.

Jedes Plugin kann in unterschiedlichen Modi ausgeführt werden. Dabei stehen die folgenden Optionen zur Verfügung. Der jeweils fett gedruckte Wert ist der Standardwert:

Eine Konfiguration für das Veeam-Plugin sieht dann zum Beispiel so aus (der Auszug ist gekürzt und enthält nur den relevanten Teil für das Beispiel):

Das Plugin wird nach der Definition oben Asynchron alle fünf Minuten (300 Sekunden) ausgeführt und darf dabei maximal zwei Minuten (120 Sekunden) laufen. Falls das Plugin in diesen Timeout läuft, wird ein zweites Mal versucht ein Ergebnis zu bekommen.

Die von Checkmk mitgelieferten Plugins können über die Agentenbäckerei konfiguriert werden. Diese sorgt sowohl für die Installation des Plugins selbst, als auch für die korrekte Erstellung der Konfigurationsdatei, falls eine notwendig sein sollte.

Jedes Plugin wird über eine Agentenregel konfiguriert. Sie finden die passenden Regelsätze in Setup > Agents > Windows, Linux, Solaris, AIX > Agents > Agent rules:

Da Agentenplugins ausführbare Programme sind, können Sie diese zu Test- und Diagnosezwecken auch von Hand ausführen. Es gibt allerdings Plugins, welche bestimmte vom Agenten gesetzte Umgebungsvariablen brauchen, um z.B. ihre Konfigurationsdatei zu finden. Setzen Sie diese gegebenenfalls von Hand, wenn Sie in dem Skript oder Programm benötigt werden.

Wie auch bei dem Linux-Agent muss auch der Zugriff auf den Agent für Windows abgesichert werden. Immerhin handelt es sich um potentiell sensible Server, die vor Angriffen von außen geschützt werden müssen. Aus dem Grund gelten hier auch die gleichen Grundgedanken, wie unter Linux. Auch unter Windows liest der Agent keinerlei Daten vom Netzwerk, so dass ein Angreifer über den Überwachungsport 6556 niemals Befehle oder Skripte einschleusen kann.

Wird das überwachte System über eine unsichere (Internet-)Verbindung abgefragt, werden zusätzliche Maßnahmen notwendig. So verfügt der Agent über eine optionale eingebaute Verschlüsselung, um die übermittelten Daten vor Angriffen aus dem Netzwerk zu schützen. Auf neueren Windows-Versionen ist zusätzlich natives SSH möglich, so dass eine Verschlüsselung über die gesamte Verbindungsdauer gewährleistet werden kann, wie man das unter Linux bereits kennt.

Diese und andere Methoden der Absicherung werden im Folgenden näher beschrieben.

Die Einschränkung auf bestimmte IP-Adressen können Sie zwar auch über die Firewall konfigurieren. Zusätzlich bietet aber auch der Agent selbst die Möglichkeit, Anfragen von fremden IP-Adressen schlicht zu ignorieren. Fügen Sie der Konfigurationsdatei lediglich die folgende Einschränkung in den globalen Optionen hinzu. Beachten Sie, dass davor oder danach noch andere Parameter in der Konfigurationsdatei gesetzt sein können und dies nur ein Ausschnitt ist:

Wie in dem Beispiel gut zu sehen, können Sie prinzipiell beliebig viele Subnetze erlauben. Mit einem /32 geben Sie z.B. ein Subnetz der Größe 1 an, so dass nur diese eine Adresse erlaubt ist, während sie mit mit 192.168.42.0/24 alle Adressen zwischen 192.168.42.0 und 192.168.42.255 erlauben.

In der Agentenbäckerei können Sie die erlaubten IP-Adressen über folgenden Regelsatz konfigurieren: Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Allowed agent access via IP address (Linux, Windows)

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.

Neuere Versionen von Windows haben eine native Unterstützung für SSH. Aber auch bei älteren Versionen können Sie einen SSH-Server über Cygwin nachrüsten und damit eine identische Konfiguration nachstellen, wie Sie unter Linux möglich ist. Beachten Sie dabei die aktuellen Hilfestellungen seitens Cygwin oder Microsoft für die Einrichtung. Sobald ein SSH-Server gestartet und erreichbar ist, ist die weitere Einrichtung identisch zu der unter Linux: Sie richten die authorized_keys auf dem überwachten Host ein und beschränken den Zugriff auf die Ausführung des Agenten.

Der Eintrag in der Datei authorized_keys ist auf Windows Hosts allerdings etwas holprig, da hier viele Zeichen maskiert werden müssen. Orientieren Sie sich bitte an dem folgenden (gekürzten) Beispiel:

Beachten Sie, dass Sie den Windows-Dienst danach stoppen können und auch eine eventuell eingerichtete Firewall-Regel damit obsolet ist.

Der Windows-Agent (wie auch sein Linux-Pendant) kann seine Daten ohne Zusatzmittel selbst verschlüsseln. Dies ist streng genommen kein Ersatz für eine Zugangskontrolle. Da aber ein Angreifer ja keine Befehle senden und mit verschlüsselten Ausgabedaten nichts anfangen kann, kommt es einer solchen schon sehr nahe.

Der Aufwand für die Verwendung der Verschlüsselung und die nötige zusätzliche CPU-Last sind beide geringer, als bei der oben beschriebenen Methode mit SSH, welche wir aber nach wie vor bei der Übertragung über das Internet empfehlen.

Die Verschlüsselung braucht natürlich sowohl auf dem Agenten als auch auf dem Server eine passende Konfiguration. Diese kann entweder von Hand erstellt werden ( Checkmk Raw Edition) oder mit der Agentenbäckerei ( Checkmk Enterprise Editions).