PRTG Remote Probe

PRTG kann aber nicht nur vom PRTG-Server selbst aus Tests gegen andere System fahren, sondern Sie können auch reine Probe-Systeme auf anderen Windows Systemen installieren und zentral konfigurieren und ausführen lassen. So lassen sich auch Niederlassungen einfach lokal abprüfen. für den Einsatz mit Lync ist die RemoteProbe noch aus einem anderen Grund interessant. Sie kann als Sender und Empfänger für QoS-Tests dienen oder vor Ort per Paketsniffer die Datenverteilung aufnehmen.

Hinweis:
Die Überwachung ist wie bei allen Sensoren immer nur eine "Momentaufnahme", d.h. der Sensor sendet z.B. alle 5 Minuten eben 1000 Pakete. Es ist aber kein Dauertest.

Achtung
Viele Sensoren basieren auf .NET 2.0, welches in NET 4.0 aber nicht enthalten ist. Auf Windows 2012 Servern kann es passieren, dass die Sensoren nicht laufen, wenn Sie nicht explizit .NET 3.5 installieren.

Einrichtung

Für die Einrichtung einer Remote Probe sind folgende Schritte erforderlich:

  • Listen-IP auf PRTG-Server einrichten
    per Default erlaubt der PRTG-Server nur "localhost" als Probe. Die Einstellung erfolgt nicht über die Enterprise Console oder das Webfrontend, sondern über den PRTG Server Manager
  • Dann müssen Sie sich noch den Access Key der PRTG Serverinstallation besorgen und die IP-Adresse der geplanten Remote Probe zulassen. Das können Sie in der System Administration über die Webverwaltung oder Enterprise Konsole machen.
  • Installation der Probe
    Dann gehen Sie am besten auf das Probensystem und laden sich doch der Browser die Installation vom PRTG-Server herunter:
    "http://<prtgserver>:<webport>/downloads.htm?gototab=3#tab3"
  • Konfiguration der Probe
    Nach der Installation der Probe muss natürlich noch die Probe konfiguriert werden. Auch das erledigt eine Windows-GUI auf dem Probe-System
  • Kontrolle der Probe
    Wenn die Probe dann korrekt gestartet wurde, meldet sich sie beim PRTG-Server und trägt sich dort auch direkt selbst ein.

    Als Administrator müssen Sie hier dann nur noch ein "Approve new Probe" machen.

Nun können Sie in der zentralen Konsole wie gewohnt die Konfiguration von Sensoren vornehmen.

Kommunikation

Die Verbindung von der Probe erfolgt immer nur unidirektional zum Server. Sie müssen also den PRTG-Core über den Port 23560 (Default, kann geändert werden) erreichbar machen. Die Probe baut die Verbindung auf und so ist es auch kein Problem, wenn die Probe sich z.B. hinter einen NAT-Router befindet. Eine Firewall muss einfach nur 23560/TCP ausgehend auf die eine bekannte IP-Adresse des PRTG-CORE zulassen.

Natürlich können Sie auch andere Ports verwenden um möglichen Angreifern etwas den Zugang zu erschweren: Mit NetMon lässt sich gut sehen, wie die Probe dann mit dem PRTG-Server spricht und dass sie weitere Tests durchführt:

Wenn die Probes über das Internet mit dem Core sprechen wollen, dann muss der Core natürlich entweder selbst eine öffentliche IP haben oder hinter einer Firewall mit Reverse-NAT zumindest über den Port 23560 erreichbar sein. Es ist technisch kein Problem diese Ports abweichend einzustellen, so dass mögliche Angreifer oder "Portscanner" nicht allzu leichtes Spiel haben. Sogar ein Portwechsel bei NAT ist möglich, also dass die Firewall extern z.B. TCP-Verbindungen auf einem anderen Port (z.B. 12345) annimmt und nach innen auf 23560 weiter gibt. Dann können sie intern im sicheren Netzwerk die Standardwerte weiter verwenden. Nur bei der Installation "draußen" muss dann natürlich der richtige Hostname/IP-Adresse samt Port angegeben werden.

Eine "Remote Probe" hat durchaus auch den Charme, dass man als Dienstleister beim Kunden eine solche Probe installieren kann und übe reinen Kanal zu einer zentralen PRTG-Instanz (z.B. in der Cloud) die Überwachung durchführen kann. Dazu muss natürlich die Firewall beim Kunden etwas geöffnet werden, womit sich die Diskussion um das Thema Sicherheit eröffnet.

Die Verbindung wird dazu immer nur von der Probe zum PRTG-Server aufgebaut. Eine Adressumsetzung (NAT) ist problemlos, solange der Port „offen“ und keine weitere Authentifizierung erforderlich ist. Es ist daher eine Firewall-Regel zu öffnen, ähnlich wie sie bei HBCI und anderen Diensten erforderlich ist.

Source:IP: RemoteProbe-Server
Source-Port: Highport
DestinationIP: PRTG-Server (meist Public IP eines Dienstleisters wie Net at Work)
DestinationPort: 23560 (Default, kann von Dienstleister abweichend eingestellt sein)
Protokoll: TCP 

Sie können die Funktion testen, indem sie von dem Remote-Probe-Server per „TELNET <prtgservername> <prtgport>“ eine Verbindung starten. Sie sollte aufgebaut werden. Wir stehen immer wieder in der Diskussion, ob dies denn sicher sei und warum die Kommunikation nicht per HTTPS erfolgt.

  • Eigener Port statt 443
    Die Nutzung eines eigenen Ports ist nicht unsicherer oder sicherer als 443. Es ist nur ein anderer Port. Die Nutzung eines eigenen Ports hat aber mehrere Vorteile:
    • Sie können den PRTG-Verkehr einfacher erkennen und müssen
      Als eigener Port können sie mit NetFlow o.ä. die Verbindungen einfach aufschlüsseln und ggfls. per QoS priorisieren.
    • Sie können per Default PRTG nicht nutzen, wenn der Port nicht in der Firewall freigeschaltet ist
      Würde PRTG einfach 443 nutzen, würden Sie als Firewall Admin das vermutlich gar nicht merken
  • PRTG-Port ist auch verschlüsselt
    Nur weil nicht der Port 443 zum Einsatz kommt, ist die Verbindung nicht automatisch als unsicher anzusehen.
    Viele Protokolle nutzen anderen Ports und sind dennoch per SSL verschlüsselt, z.B. 993/995 (POP3S/IMAP4S), 5061 (SIPS).
    Auch die Verbindung mit PRTG ist gesichert
  • http-Proxy
    Der Verzicht auf HTTPS verhindert leider auch die Nutzung eines HTTPS-Proxy. Auch das würde ich nicht als Nachteil sehen. für die Verbindung der PRTG-Remote Probe zum PRTG-Server gibt es eigentlich keinen Vorteil, einen HTTP-Proxy zu nutzen, außer dass er schon da wäre.
    • Proxy Authentifizierung
      Die meisten Proxies erwarten eine Authentifizierung. Sicher könnte eine PRTG-Probe auch ein Dienstkonto angeben aber das macht die Anwendung schon wieder komplexer. Kennworte können ablaufen, abgefischt werden o.ä und bei PRTG sind ja Quelle und Ziel bekannt und nicht variabel. Anders als beim klassischen "Surfen"
    • Proxy Inspektion und Filterung
      Es ist durchaus möglich., auch HTTPS-Verkehre zu öffnen und zu inspizieren. Das hat das Risiko, dass die Authentifizierungsdaten sichtbar werden als auch dass der Inhalt verändert wird. Das hat durchaus seinen Sinn beim Zugriff auf das „Internet“ mit all den Schadanteilen um Download zu scannen, URLs zu blockieren etc. Beim Einsatz mit PRTG muss diese Funktion aber zusätzlich die Daten bediene, obwohl sie weder etwas filtern, verändern noch blockieren darf.
    • NAT und Port-Firewall ist einfacher als HTTP Proxy
      Durch die Umgehung eines HTTPS-Proxy spart PRTG auch eine Station ein, die gerade im Fehlerfall von Komponenten auch die eigentliche Überwachung stören könnte. Wenn z.B. Probleme bei der Authentifizierung vorliegen, könnte die Remote Probe dies zwar erkennen aber gar nicht mehr melden. Daher ist die Nutzung einer TCP-Verbindung über eine einzelne Firewall/NAT-Regel zuverlässiger.
  • Bekannte Ziel-IP
    Bei all dem darf man nicht vergessen, das die Verbindung zu einer bekannten IP-Adresse eines Partners mit einem Vertragsverhältnis erfolgt.
    Die Firewall-Regel muss und sollte gar nicht mehr zu lassen, als „nur“ die Verbindung zu dieser IP-Adresse und Port.

Insofern habe ich persönlich aktuell kein Problem damit, wenn für die Installation einer PRTG Remote Probe eine TCP-Verbindung zu dem PRTG-Server über eine direkte TCP-Verbindung aufgebaut wird, wobei Quell-IP, Ziel-IP und Ziel-Port bekannt sind und eine Umsetzung per NAT möglich ist.

Sicherheit

Damit nun nicht jeder einfach eine Probe installieren und mit einem PRTG-Core verbinden kann, ist auf der Probe ein Kennwort einzutragen (Siehe oben), welches auch auf dem Server hinterlegt werden muss. Mehrere Probes können das den gleichen Zugangsschlüssel verwenden.

Ohne gültigen Zugriffsschlüssel wird die Verbindung der Probe sofort abgelehnt und nur im Log protokolliert. Konnte sich die Probe verbinden, dann sehen Sie die im Log auf dem Core Server. Hier sehen Sie auch alle weiteren Verbindungen der Probe:

Aber auch dann muss die Probe erst noch "autorisiert" werden. Die Probe erscheint in der GUI aber ist hier noch durch einen Administrator "zuzulassen". Insofern ist es durchaus möglich, dass ein lokaler Administrator die Installationsquelle und Konfigurationsdaten bekommt aber damit nicht endlos viele Probes installieren kann.

Die Verbindung zwischen der Probe und dem Core-Server scheint per SSL verschlüsselt zu sein. Sicher kann ich es nicht sagen, aber als ich auf dem Core-Server das SSL-Zertifikat für die Webverwaltung getauscht habe und mit dabei ein Fehler unterlaufen ist, Waren auch alle Probes auf einmal "Disconnected".

Probe Health und Last

Wie viel Last letztlich die Probe auf einem System macht, ist natürlich direkt abhängig von der Anzahl der Tests, die sie auf dem Host selbst oder Remote gegen andere Systeme ausführt. Insofern gibt es keine allgemein gültigen Aussagen. Gerade das Suchen in Eventlogs oder Dateien (z.B. IISLogs) kann je nach Programmierung auch ineffektiv sind. Mit der Installation der Probe richtet PRTG aber gleich mehrere Sensoren ein, die zum einen Die Leistung des Systems und der Probe mit erfassen und auch Festplatten und Netzwerkkarten einschließen. Hier als Beispiel mein Heimserver, der als Probe an den Firmenserver gebunden ist und damit z.B. "externe" Tests ausführen kann.

Wir haben solche Probes durchaus auch auf virtuellen Servern in anderen Rechenzentren oder bei Kunden eingesetzt. Allerdings kann eine Probe immer nur mit genau einem Core sprechen. Es ist also nicht möglich, zwei Probes auf einem Server zu installieren um z.B. den PRTG Core des Kunden undden PRTG-Core eines Dienstleisters zu bedienen.

Weitere Links