Indirektes Remote-Monitoring von Servern

Adacor Kunden haben oftmals komplexe Anforderungen an Sicherheit und Datenschutz unserer Server. Daher kann es vorkommen, dass wir Systeme oder Verbindungen kontrollieren müssen, die nicht direkt von der Monitoring-Plattform zu erreichen sind. Unser Beitrag beschreibt, wie das indirekte Remote-Monitoring von Servern funktioniert.

Adacor setzt generell für das Monitoring, der von ihr betriebenen Systeme eine Plattform ein, die auf Nagios basiert und als Frontend zur erleichterten Konfiguration Centreon benutzt.

Die Monitoring-Plattform arbeitet mit verteilten Pollern, welche grundsätzlich Server mit installiertem Nagios sind. Von denen werden Service-Checks auf die betriebenen Systeme abgesetzt. Im Normalfall wird hier geprüft, ob ein bestimmter Port auf einem System die definierte, erwartete Antwort schickt oder über snmp verschiedene andere Werte abgefragt. Wie wir den reibungslosen Betrieb sämtlicher Systeme unserer IT-Infrastruktur überwachen, haben wir in einem anderen Blogpost beschrieben.

Anwendungsfälle für Remote-Monitoring

Ein mögliches Szenario für ein Remote-Monitoring wäre beispielsweise ein Kundenhost, der über eine initiierte VPN-Verbindung Daten mit einem Rechenzentrum des Kunden austauscht. In diesem Beispiel wird der Monitoring-Server als Server A, der überwachte Server als Server B und das entfernte VPN-System als Server C bezeichnet.

Server B kann über sein Routing und seine VPN-Verbindung Systeme erreichen, die aus dem internen Netz und dem Server A von Adacor nicht geroutet sind. Da Adacor diese Endpunkte (Server C) aufgrund von Sicherheitsaspekten nicht einfach in ihr Netzwerk integrieren kann, weiß die Monitoring-Plattform nicht wie sie diese erreichen soll.

Lautet die Anforderung des Kunden, auf dem entfernten Server C zu prüfen, ob ein bestimmter Port geöffnet ist, gibt es in der Nagios-Welt verschiedene Ansätze in der Nagios-Welt zum Monitoring von nicht direkt erreichbaren Systemen.

SNMP-Trap

Sie bilden das einfachste Beispiel: Der am Tunnel teilnehmende, bei Adacor gehostete Server B führt lokal die erforderlichen Checks aus und sendet sein Ergebnis per snmp-Trap an den Server A, welcher damit das Ergebnis in das Monitoring hebt.

Nagios Remote Plugin Executor (NRPE)

NRPE bietet ein andere Möglichkeit des indirekten Remote-Monitorings.
Hierzu dokumentieren wir aus der Doku des Monitoring Wiki:

• Mit nrpe (Nagios Remote Plugin Executor) ist es möglich, Plugins auf entfernten Rechnern auszuführen.
• Soll zum Beispiel der verfügbare Speicherplatz auf einem entfernten Rechner überprüft werden, wird das Plugin check_nrpe (Client) auf dem Nagios-Rechner ausgeführt. check_nrpe sendet nun einen String an den zu überwachenden Rechner. Der dort (auf Port 5666) hörende NRPE-Dienst (Server) vergleicht den ankommenden String mit den in seiner Konfigurationsdatei hinterlegten. Jedem dieser Strings ist ein Kommando zugeordnet. Findet er den vom Nagios Gesendeten in seiner Konfiguration, führt er das zugehörige Kommando aus und schickt das Ergebnis (Exitcode und Ausgabe) an check_nrpe der Nagiosmaschine zurück. check_nrpe wiederum reicht das Ergebnis an Nagios weiter, wo es, wie die Ergebnisse anderer Plugins auch dargestellt wird.

Via NRPE lassen sich nicht nur Checks ausführen, sondern jegliches Kommando. Aus diesem Grund besteht die Möglichkeit, die komplette Kommunikation (check_nrp ←→ NRPE-Dienst) verschlüsselt ablaufen zu lassen. Weiterhin können nur die in der Konfigurationsdatei des NRPE-Dienstes festgelegten Kommandos ausgeführt werden. Diese Datei wird beim Starten des NRPE-Dienstes eingelesen, weswegen Änderungen in dieser Datei logischerweise einen Neustart des Dienstes nach sich ziehen.

Systemcheck via ssh

Die dritte hier vorgestellte Variante ist es einen Systemcheck via ssh auszuführen. Adacor setzt hierfür ein Skript ein, welches auf einem der Poller (Server A) liegt und per Argumenten mitgeteilt bekommt, an welchen Host (Server B) es sich verbinden soll. Welchen Key es zur Authentifizierung benutzen soll und welches Kommando auf dem entfernten Host (Server B) ausgeführt werden soll. Hierdurch kann das Problem der „Nicht-Erreichbarkeit“ des zu prüfenden Systems umgangen werden.

Der Poller (Server A) von Adacor logt sich also per ssh-key-authentifizierung auf dem bei Adacor betriebenen Host (Server B) ein und führt auf diesem dann unter dem Kontext eines Users mit beschränkten Rechten ein Nagios-Konformes Check-Plugin aus, welches Dienste auf Server C überprüft. Das Ergebnis des lokal ausgeführten Plugins wird an den Poller (Server A) zurück übertragen und die ssh-Verbindung wird wieder geschlossen.

Das Monitoring kann somit mit dem per VPN verbundenen Server B kommunizieren und sich unter Zuhilfenahme seiner Ressourcen ein Bild von der zu prüfenden Umgebung hinter dem Tunnel machen, ohne selber in der Lage sein zu müssen, auf diesen Tunnel zuzugreifen. Die hierdurch erfolgten Zugriffe sind somit sauber logbar.