PRTG und Sophos UTM Webserver Protection (WAF)

Im letzten Artikel hatte ich ja bereits angekündigt, das ich mit PRTG auch die Webserver Protection der Sophos UTM überwachen möchte. Leider bietet PRTG für die UTM nur generische Sensoren an, sodass es mit dem Monitoring etwas schwieriger wird. Mit der Sophos RESTful API bin ich etwas weiter gekommen, aber leider lässt sich via RESTful API nur prüfen, ob FrontEnd und BackEnd Server aktiviert sind. Der genaue Status (erreichbar oder ausgefallen) lässt sich nicht direkt via API feststellen. Daher muss ich mir hier noch eine bessere Möglichkeit überlegen um den Zustand zu überwachen.

Hier aber erst einmal die erste Version des Sensors, welche zumindest den Status Aktiviert/Deaktiviert” prüft:

PRTG und Sophos UTM Webserver Protection (WAF)

Sophos UTM RESTful API aktivieren

Damit der Sensor funktioniert, muss die RESTful API der UTM aktiviert werden. Dazu reicht es einen ReadOnly Benutzer für PRTG erstellen. In den “WebAdmin Einstellungen” lässt sich dann die API aktivieren und ein Token für den PRTG Benutzer erstellen:

PRTG und Sophos UTM Webserver Protection (WAF)

Die WebAdmin Schnittstelle muss vom PRTG Server aus erreichbar sein:

PRTG und Sophos UTM Webserver Protection (WAF)

Sensor zu PRTG hinzufügen

Der PowerShell Sensor für die UTM Webserver Protection lässt sich hier runterladen:

Die Datei “Sophos_UTM_WAF.PS1 muss jetzt in das PRTG Sensor Verzeichnis kopiert werden. Im Normalfall befindet sich das Verzeichnis unter folgendem Pfad:

C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML

PRTG und Sophos UTM Webserver Protection (WAF)

In PRTG lässt sich nun ein neuer Sensor vom Typ “Programm/Script (Erweitert)” anlegen:

PRTG und Sophos UTM Webserver Protection (WAF)

Dem Sensor kann jetzt ein Name gegeben werden. Unter dem Punkt “Programm/Script” kann das zuvor kopierte Script ausgewählt werden. Als Parameter müssen API Token und Adresse der Sophos UTM angegeben werden:

–UTMApiToken „UTMAPITOKEN“ –UTMAdress “IPoderHostnamederUTM”

PRTG und Sophos UTM Webserver Protection (WAF)

Wie zuvor schon erwähnt prüft der Sensor nicht den tatsächlichen Status, sondern nur ob Frontend (FE, Virtuelle Webserver ) und Backend (BE, Echte Webserver) aktiviert sind:

PRTG und Sophos UTM Webserver Protection (WAF)

Ich denke in der nächsten Version erweitere ich den Sensor noch um simple Portchecks, so lässt sich zumindest etwas besser die Funktion prüfen.

7 Replies to “PRTG und Sophos UTM Webserver Protection (WAF)”

  1. Mich würde mal interessieren, auf welcher Hardware / VM dein PRTG läuft.
    Hast du eine dezidierte VM oder läuft das nebenher auf einem Server? Wie ist denn so die Auslastung durch PRTG?

    Wollte PRTG auch einführen, aber ich schätze das ich mit der Free Lizenz nicht so weit komme. Würde meine UTM, Server, NAS und vor allem Kameras monitoren wollen.
    Wie viele Sensoren hast du denn so in Betrieb?

  2. Hallo,
    also bei mir ist es aktuell noch ein Windows 10 als VM mit 4GB Speicher
    Auslastung hält sich in Grenzen.
    CPU Last ist hier recht wenig, Arbeitsspeicher schon einiges mehr. (immer um die 60%)
    Nutze es um meine Server Infrastruktur zu überwachen, und mit Remote Probes auch die von Kunden.
    Alles in einem PRTG Cluster (zweite Maschine hat ähnliche Hardware Werte)

  3. Hi,
    ich betreibe PRTG auf einer VM mit 3GB RAM und 2 CPU Kernen, die kostenfreie Version ist auf 100 Sensoren beschränkt, daher muss man sich schon ein paar Gedanken machen, wie man Sensoren zusammen fassen kann. Mit nur wenigen Geräten komme ich schon auf 100 Sensoren, aber das ist eine Frage wie man diese organisiert. Man könnte zum Beispiel jeden Port eines 48-Port Switches mit einem Sensor überwachen, dann sind 48 Sensoren weg. Alternativ legt man einen Sensor mit 48 Kanälen kann, dann wird nur ein Sensor belegt. :-)
    Gruß, Frank

  4. Hi Frank,

    ich muss dein kurzes Feedback zum organisieren in PRTG aufgreifen.
    Am bsp. des Switches.
    Je Port ein Sensor ist blöd – keine Frage, du erwähnst, dass du dies mit einem Sensor mit 48 Kanälen möglich sei.
    Welcher Sensor soll dies sein?

    Danke und dir einen schönen Abend noch
    Gruß Peter

  5. Oh drei Franks.
    Das Beispiel von FrankZ ist nur ein „Beispiel“ um zu erklären, was man vielleicht konsolidieren kann. Ein Sensor pro Port zeigt die natürlich dann pro Port in den Channels Details wie In/Out/error etc. Wenn man das nicht braucht wäre ein Sensor mit 48 Channels eine Option. Den gibt es so aber nicht. Man müsste schon selbst das Skript dazu bauen, der 48 Ports abfragt. Wer aber einen 48 Port Switch hat, ist doch schon wirklich „Gewerbe“ oder ? Die Free Version i8st genial für Evals, Showcase und Homeoffice, IoT Bastler. In der Firma habe ich auch eine kommerzielle Version gekauft. Zuhause reicht mir die 100er

  6. Hallo Frank, Hallo Frank,

    langsam wird es unübersichtlich :-)
    Wie FrankC schon sagte, entweder den entsprechenden Sensor selbst erstellen, alternativ könnte man auch den Sensor „SNMP (Benutzerdef. erweitert)“ benutzen, dieser kann 10 OIDs prüfen. 200 Sensoren für HomeUse wären jetzt nicht soooo schlecht…

    Gruß, FrankZ

  7. Hallo,
    also PRTG hat das Limit von 50 Channels per Sensor, offiziell.

    „PRTG does not support more than 50 sensor channels officially. Depending on the data used with this sensor type, you might exceed the maximum number of supported sensor channels. In this case, PRTG will try to display all sensor channels. However, please be aware that you will experience limited usability and performance.“

    Müsste also dann aufgeteilt werden, wenn man seinen 48er Port Switch prüfen will.
    Ich selbst habe im Büro auch nur bei meinen 2 x 24ern die wichtigsten Ports, VMServer und ISCSI Interfaces.
    Gruß FrankF

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.