PRTG Securitycheck

Überwachungsprodukte wie PRTG, Nagios, CheckMK u.a. benötigen natürlich Berechtigungen, um ihre Aktionen auszuüben. Das gilt umso mehr, wenn die Prüfungen aus der Ferne über das Netzwerk erfolgen. Anmeldungen erfolgen je nach Protokoll vielleicht nicht immer "sicher". Als sollten sie ihrer Überwachungslösung auch einmal auf die Finger schauen.

Ich denke ich kenne PRTG relativ gut und habe daher mir dessen Funktionen und möglich Schwächen einmal genauer angeschaut.

Diese ist schon deswegen wichtig, weil ein PRTG-Dienstkonto, welches viele Server aus der Ferne überwacht, damit ganz viele Berechtigungen auf sich vereint. Leider wird LAPS - Local Admin Password Solution noch nicht von PRTG unterstützt

Meine Analyse erhebt keinen Anspruch auf Vollständigkeit und kann nicht immer den aktuellen Stand wiedergeben. Es ist auch keine "Deep Inspection", d.h. ich habe nicht versucht aktiv Lücken zu finden oder das System anzugreifen.

Dennoch kann diese Seite einem PRTG-Admin schon helfen, die Schwachstellen zu umgehen und das System besser kennen zu lernen.

Funktionsweise

Auf der Seite PRTG Plattform habe ich die verschiedenen Komponenten erläutert und überall kann Code ausgeführt oder Kennworte verwendet und übertragen werden.

Die Stellen führe ich in eigenen Kapiteln weiter aus.

1. Client und Client-Kommunikation

PRTG überwacht nicht nur, sondern natürlich gibt es auch einen Zugang zur Anzeige der Statusmeldungen. Die verschiedenen Nutzer können über verschiedene Clients auf den Server zugreifen. PRTG unterstützt nicht nur eine Verbindung per HTTPS sondern auch die Verwendung eines "Passhash" anstelle eines Kennworts. Allerdings gilt für beide Komponenten, das diese nicht zwingend sind, sondern Sie als Administrator sich aktiv darum kümmern müssen, diese Sicherheit zu nutzen.

Gerade der Zugriff aus die Weboberfläche kann aus den Internet z.B. über den AzureAD WebProxy noch sicherer gestaltet werden. Er funktioniert natürlich nur für Browser und Kunden mit AzureAD-P1-Lizenzen, aber dann ist eine Pre-Authentication gegen AzureAD und sogar Conditional Access möglich.

Nebenbei kann ich so PRTG auch hinter DSLite-Anschlüssen ohne statische IPv4-Adresse nutzen.

2. Core und Cluster Kommunikation

Das Herzstück von PRTG ist der CORE-Server, welcher als Mittelpunkt ganz viele Aufgaben hat. Diese sind zugleich auch die Angriffspunkte:

  • Konfiguration
    Die komplette Information über Sensoren und insbesondere Zugangsdaten liegen in Datenbanken der Core-Rolle. Das System bzw. der Server ist daher besonders schützenswert, damit nicht ein unberechtigter Administrator über den Weg sich Zugangsdaten organisieren kann. Die Daten sind technisch begründet in der Datenbank zumindest reversibel und teilweise in Klartext gespeichert, da später zumindest die Probe bei einem Check auch die Credentials verwenden kann. Hier ein Auszug aus der "PRTG Configuratio.dat"

    Die Datei enthält die Sensoren samt Parametern aber auch Benutzerdaten und zumindest Hashwerte

    Der Server sollte auf jeden Fall entsprechend gegen unberechtigte Zugriffe gesichert sein. Auch Bitlocker oder EFS sind durchaus Möglichkeiten den zugriff besser abzusichern.
  • Benutzerdatenbank
    Die Core verwaltet auch alle PRTG-Benutzer und wenn es einem Angreifer gelänge, hier die Zugangsdaten eines Administrators zu entwenden oder einen eigenen Admin zu addieren, könnte er wieder die Konfiguration einsehen oder auch eigene Probes und Sensoren einrichten. Hinter den Sensoren stehen Skripte die eventuell höhere Rechte haben.
  • Cluster-Kommunikation
    Bei der hochverfügbaren Konfiguration als Cluster gibt es ein Protokoll zwischen den Knoten, die auch die Konfiguration austauscht. Damit gehen auch Kennworte über die Leitung. Soweit sich gesehen habe, ist die Kommunikation verschlüsselt.

Es gibt auf der Core daher durchaus interessante und schützenswerte Daten. Der schwächste Punkt ist aber hier der Administrator und die Gruppe der Anwender mit Zugriff auf die Plattform. PRTG wird ja auch gerne genutzt, um Informationen über eine Teilmenge an Diensten an fachverantwortliche Personen bereitzustellen. Diese legitimen Zugänge sollten aber nicht mehr sehen dürfen und natürlich sind speziell Zugangsdaten gesondert zu betrachten.

3. Probe und Kommunikation zur Core

Der Probe-Dienst macht in der PRTG-Umgebung die eigentliche Arbeit. Dieser Dienst startet Skripte, überprüft andere Hosts und hat dazu entweder selbst die notwenigen Berechtigungen oder bekommt die Information aus der Konfiguration. Die Probe kommuniziert regelmäßig mit dem Core-System, um Konfigurationsupdates aber auch Software-Updates zu erhalten und einzuspielen. Damit haben wir mehrere Risiken:

  • Software Update
    Die Probe installiert automatisch die Updates, die durch die Core vorgegeben wird. Da der Code dann zur Ausführung kommt sollte die Core irgendwie sicherstellen, dass der Code nicht verändert wurde. Die Quellen von PRTG sind digital signiert aber ich habe noch nicht ermittelt, ob eine defekte oder fehlende Signatur die Installation verhindert. Bei dem Schritt werden auch die Sensor-Programme aktualisiert.
  • Konfigurationsdaten
    Die Probe nutzt den Port 23560/TCP zur Kommunikation, über den so auch die Zugangsdaten in der Konfiguration übertragen werden. Die Verbindung ist laut Paessler geschützt.
  • Sparsamkeit
    Eine Probe müsste nur die Konfiguration kennen, die sie für ihre Arbeit braucht. Ich habe noch nicht geprüft, ob die Probe nur diese oder alle Daten hat. Für die Funktion müsste sie nur ihre Daten haben.
  • Sensor-Skripte und Code
    Die Probe nutzt eingebundene Funktion aber auch sehr viel externe Skripte um Prüfungen durchzuführen. Der Aufruf der EXE, CMD, VBS, PS1-Dateien erfolgt durch die Probe.exe als Unterprozess. Damit müssen der Code dieser Sensoren natürlich "sicher" sein. Auch wenn das System sehr elegant für Updates sorgt, so werden gerade eigene "Custom-EXE"-Skripts gerade nicht aktualisiert. Auf der einen Seite ist das vielleicht sicherer aber auf der anderen Seite müssen Sie dann einen parallelen Weg implementieren, um ihre eigenen Skripte auf allen Probe-Systemen zu aktualisieren.
    Leider prüft die PRTG-Probe nicht, ob die Skripte in der Zwischenzeit verändert wurden. Ein böser Admin könnte mit entsprechenden Berechtigungen auf dem Server mit der PRTG-Probe den Code eines Sensor verändern und so die erweiterten Berechtigungen des Skripts für eigene Aktionen missbrauchen. Theoretisch könnte PRTG hier z.B. einen Hashwert für ein Skript machen und bei Veränderungen alarmieren und eine Bestätigung einfordern. Auf der anderen Seite könnte ein Admin natürlich auch "Code Signing" auf dem Server erzwingen und dann die eigenen und fremden nicht signierten Skripte selbst signieren.
  • Übergabe der Parameter
    Der Sensor-Code muss natürlich mit Parametern versehen werden. Wenn Sie sich hier die Arbeitsweise anschauen, dann gibt es schon Stellen, die vielleicht besser gelöst werden können. So kann auf dem Server über den Taskmanager die "Befehlszeile" eingebunden werden. Hier finden Sie dann auch die Parameter, was speziell bei Credentials unschön ist:

    Allerdings muss man dazu schon auf dem Server angemeldet und die Berechtigungen haben. Das gilt dann auch für Funktion, solche sensiblen Daten als Umgebungsvariable zu übergeben.

    Dennoch können Sie als Entwickler natürlich solch sensible Daten auch anders übertragen, z.B. in einer verschlüsselten Datei (Siehe auch PS Passwort / Kennwort). PRTG erlaubt natürlich auch die Verwaltung eigener Kennworte pro Sensor oder Server, so dass Sie die Angriffsfläche deutlich reduzieren können. Allerdings wird die Verwaltung dann aufwändiger. Wenn auf der Probe-Server das Protokoll SNMP installiert ist, können Sie sogar über das LAN die Prozessliste samt Parametern auslesen. Zu SNMP gibt es aber noch einen eigenen Abschnitt.

In dem Zuge sollten Sie dann überlegen, ob die Probe-Server nicht besser eigenständige Instanzen sind und eine Probe nicht einfach mal auf einem bestehenden Server "mit installiert "wird.

4. Abfrage der Zielsysteme, SNMP und Co

Die Probe prüft Dienste der Zielsysteme über verschiedene Wege. Wenn der Check nicht durch eine lokale Probe erfolgt, haben wir die Netzwerkkommunikation zwischen der Probe und dem Device zu betrachten.

  • SNMP
    Quasi jedes Gerät kann auf die ein oder andere Weise per SNMP angesprochen werden. Selbst Windows Server können einen SNMP-Dienst bereitstellen und umfangreiche Daten liefern. Damit ist der Schutz dieses Agenten zu betrachten und wie eine Authentifizierung möglich ist. SNMP kennt in der Version V1 und V2 eigentlich nur unterschiedliche "Communities", die zugleich die Authentifizierung darstellen. Wer hier mit den Default "public" als ReadOnly  und "private" als ReadWrite agiert, handelt fahrlässig. Selbst andere Communities sind nicht als sicher anzusehen, wenn SNMP/UDP oder SNMP/TCP genutzt wird, da dann keine Verschlüsselung erfolgt.

ich würde bei SNMP auf allen Geräten die Erreichbarkeit auf die IP-Adresse der Managementstationen (Netzwerkmanagement PRTG-Probes etc.) beschränken und den Zugang zu diesen Systemen auf vertrauenswürdige Personen beschränken. Schreibzugriff per SNMP würde ich heute nur per SNMPv3 per TLS und Anmeldung erlauben. Einfache "Community"-Absicherungen sind maximal für "Lesen" von Systemen tauglich, die darüber aber keine kritischen Daten ausliefern. Windows Server können per SNMP sowieso nur partiell überwacht werden.

  • WMI/WinRM
    Für Windows Systeme ist "WMI" für die Überwachung vorzuziehen, da die Daten dabei per RPC oder HTTP übertragen werden und Microsoft mittlerweile per Default schon eine Absicherung (NTLMv2/Kerberos) vorsieht. Die zwingende Authentifizierung bedeutet natürlich auch, dass die Zugangsdaten der Probe oder dem Sensor-Skript bekannt sein müssen. Mit PRTG auf der Windows Plattform können sehr einfach WMI-Abfragen an andere Server ausgeführt werden.
  • HTTP
    Da immer mehr Dienste auf HTTP aufsetzen, werden auch immer mehr Dienste per HTTP durch eine PRTG-Probe abgerufen. Ohne Verschlüsselung durch HTTPS würde ich nicht viel mehr als ein "Is Live"-Check machen. Sobald die Probe sich aber abmeldete, um qualifizierte Daten zu erhalten, sollte Verschlüsselung vorgegeben sein. Das bedeutet aber auch, dass die Probe dann wieder Zugangsdaten kennen und das System diese verifizieren muss.
  • Telnet/SSH/Sudo
    Viele UNIX-Systeme liefert Daten nach dem Aufruf von lokalen Programmen. PRTG hat keine richtige "Probe" für Linux, wenn man von den MiniProbes absieht. Der Sensor auf der Probe muss sich dazu mit dem Zielsystem verbinden (Telnet/SSH) und dort dann direkt oder über SUDO die entsprechenden Codes startet und die Ergebnisse einsammelt. SSH, idealerweise er Zertifikat, ist natürlich TELNET vorzuziehen, damit alles verschlüsselt ist.

Die Möglichkeiten in die Kommunikation zwischen Probe und Client zu kommen, sind vielfältig aber sie müssen schon schwache Protokolle nutzen oder die Gegenstelle auf dem zu überwachenden System ist schwach gesichert.

5. Sonderfall Push/Dezentrale Skripte

Die PRTG-Probe unterstützt noch eine weiter Schnittstelle, die hinsichtlich Security und Berechtigungen interessant ist. Die Probe selbst ist dabei nicht der aktive Part sondern sammelt nur die Daten ein, die Sensoren im Feld eigenverantwortlich sammeln und senden. Sie müssen also selbst Code in einer beliebigen Programmiersprache schreiben und ausführen. Der Code wird meist auf dem zu überwachenden System lokal gestartet. Weder die PRTG-Code noch die PRTG-Probe hat irgendwelche Parameter oder Credentials, die übergeben werden müssten. Einzig ein "Shared Secret" wird vereinbart, mit der sich der Code gegenüber der PRTG-Probe ausweisen muss.

Als Transport kommt ein HTTP-POST zum Einsatz, der natürlich am besten auch per HTTPS verschlüsselt ist. So kann ein Angreifer die Kommunikation nicht mitlauschen. Wenn er irgendwie in den Besitz des SharedSecret kommt, könnte er maximal "falsche Daten" einliefern, die dann die Messung stören und zu Fehlalarmen oder Alarmunterdrückung führen. Das könnte PRTG noch etwas verbessern, in dem ein Throttling oder ein Wechselcode optional mit eingebaut wird.

Zusammenfassung

Wie jedes Produkt, das sich mit anderen Servern verbindet, Werte ausliest und Aktionen ausführt, ist auch PRTG nicht 100% "sicher". Die meisten Risiken können aber durch eine geeignete Implementierung (HTTPS statt HTTP, eingeschränkte und separate Credentials", abgesicherte bzw. gehärtete Umgebungen) deutlich reduziert werden. PRTG selbst könnte natürlich selbst noch ein paar Funktionen ergänzen, z.B. die Verifizierung der Skripte auf Veränderungen oder alternative Übergabe von Credentials. Aber mehr Sicherheit bedeutet auch mehr Aufwand und Komplexität.

Sicherheit hat einen Preis: normale Aktionen brauchen länger und sind aufwändiger Trotzdem würde niemand auf das Schloss in der Haustür verzichten, auch wenn Sie mit Einkaufstaschen fluchend davor stehen. Es ist auch eine Abwägung, ob sie ihr Auto aus Bequemlichkeit per "KeylessGo" starten, obwohl die Systeme wohl einfach zu umgehen sind.

Ein Schutz gegen richtige "Fehler" im Code kann meine Bewertung aber nicht sein. Es gab in der Vergangenheit einige Meldungen zu Lücken in PRTG, die aber von Paessler geschlossen wurden.

Insofern ist es schon ein Vorteil, wenn ein kommerzieller Hersteller natürlich solche Fehler kurzfristig behebt und zügig verteilt. Ich kenne durchaus auch andere Produkte, die trotz bekannter Lücken und bereitstehenden Updates nicht zeitnah korrigiert wurden. Es reicht ja nicht nur in der Quelle den Fehler zu beheben, sondern auch die Verteilung an alle Installationspunkte muss gewährleistet sein. Und dann muss Administrator sich an das Update wagen. Da muss ich bei PRTG sagen, dass zumindest bei meinen Installation noch nie ein PRTG-Update richtig schief gegangen ist.

Weitere Links