PRTG and Sophos UTM Webserver Protection (WAF)

In the last article I had already announced that I would also like to use PRTG to monitor the web server protection of the Sophos UTM. Unfortunately, PRTG only offers generic sensors for the UTM, which makes monitoring a little more difficult. I made some progress with the Sophos RESTful API, but unfortunately the RESTful API can only check whether the front-end and back-end servers are activated. The exact status (reachable or down) cannot be determined directly via the API. Therefore, I still have to think of a better way to monitor the status.

But here is the first version of the sensor, which at least checks the "activated/deactivated" status:

PRTG and Sophos UTM Webserver Protection (WAF)

Enable Sophos UTM RESTful API

For the sensor to work, the RESTful API of the UTM must be activated. All you need to do is create a ReadOnly user for PRTG. The API can then be activated in the "WebAdmin settings" and a token created for the PRTG user:

PRTG and Sophos UTM Webserver Protection (WAF)

The WebAdmin interface must be accessible from the PRTG server:

PRTG and Sophos UTM Webserver Protection (WAF)

Add sensor to PRTG

The PowerShell Sensor for UTM Webserver Protection can be downloaded here:

The file "Sophos_UTM_WAF.PS1 must now be copied to the PRTG sensor directory. Normally, the directory is located under the following path:

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

PRTG and Sophos UTM Webserver Protection (WAF)

A new sensor of the type "Program/Script (Advanced)" can now be created in PRTG:

PRTG and Sophos UTM Webserver Protection (WAF)

The sensor can now be given a name. The previously copied script can be selected under "Program/Script". The API token and address of the Sophos UTM must be specified as parameters:

-UTMApiToken "UTMAPITOKEN" -UTMAdress "IPorHostnameofUTM"

PRTG and Sophos UTM Webserver Protection (WAF)

As already mentioned, the sensor does not check the actual status, but only whether the front end (FE, virtual web server) and back end (BE, real web server) are activated:

PRTG and Sophos UTM Webserver Protection (WAF)

I think in the next version I'll add simple port checks to the sensor, so it's at least a bit easier to check the function.

8 thoughts on “PRTG und Sophos UTM Webserver Protection (WAF)”

  1. Habe versucht das Script zum Laufen zu bringen mit Version 9.6 der UTM.
    Bekomme jedoch für FE und BE nur die Meldung „API Query Failed: Der Remoteserver hat einen Fehler zurückgegeben: 403 unzulässig.

    Hat sich in der Zwischenzeit etwas geändert?

    Reply
  2. 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

    Reply
  3. 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

    Reply
    • 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

      Reply
  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

    Reply
  5. 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)

    Reply
  6. 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?

    Reply
    • 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

      Reply

Leave a Comment