Sophos UTM: Sehr langsame Verbindung via WAF / Sensor für PRTG

Ein Leser berichtete mir kürzlich von einem Problem mit der Web Application Firewall der Sophos UTM.

Aufgrund der Corona Krise sind viele der Mitarbeiter ins HomeOffice gewechselt und nutzen seitdem verstärkt Verbindungen zum Exchange Server, welche durch die WAF der Sophos UTM geschützt werden. Nachdem es also tagsüber zu einer höheren Last auf der UTM aufgrund der vielen HomeOffice User kam, wurden Verbindungen welche über die WAF liefen sehr langsam. Tagsüber kam es zu Ladezeiten von über 60 Sekunden. Die CPU und RAM Auslastung der UTM zeigte allerdings keine Engpässe an.

Der Leser hat daraufhin ein Ticket beim Sophos Support geöffnet, der Support konnte feststellen, dass die WAF zu wenige freie Worker Prozesse hat und es daher zu Timeouts und langen Ladezeiten kommt, wenn via WAF auf die Services zugegriffen wird.

Im ReverseProxy Log der UTM (/var/log/reverseproxy.log) fand sich in diesem Fall die folgende Meldung:

2020:03:31-17:24:14 vpn2-1 httpd[8532]: [mpm_worker:error] [pid 8532:tid 4147619520] AH00288: scoreboard is full, not at MaxRequestWorkers

Laut Sophos Support hat die WAF der UTM 800 Worker Prozesse zur Verfügung, sind alle Worker Prozesse ausgelastet, kommt es zu dem oben beschriebenen Problem.

Das Problem konnte schließlich gelöst werden, indem die Anzahl der Worker Prozesse erhöht wurde (siehe Ende des Artikels). Dies war allerdings nicht der Grund, warum ich eine nette Mail des Lesers erhalten habe. Hier mal ein Auszug aus besagter Mail:

Ich bin beim Suchen bei Sophos auf diesen Artikel gestoßen:
https://community.sophos.com/kb/en-us/123512
Es gibt eine Statusseite für die WAF, die jedoch nur über einen SSH-Tunnel aufrufbar ist.
Ich bastel gerade mit Powershell und versuch die Seite zu parsen um das ins PRTG auszugeben, jedoch hab ich noch nichts gefunden, wie ich aus dem Script ein SSH Tunnel aufbauen kann.

WAF, PRTG und PowerShell haben dann mein Interesse geweckt und wir haben gemeinsam (Vielen Dank an dieser Stelle!) einen Sensor für PRTG gebastelt, welche die Leistungsdaten der UTM in PRTG darstellt.

Die Übersichtsseite der WAF sieht beispielsweise so aus:

Sophos UTM: Sehr langsame Verbindung via WAF / Sensor für PRTG

Ein kleiner PowerShell Sensor, welcher einen SSH Tunnel zur UTM aufbaut und die Daten aus der Statuspage liest, stellt nun die Werte in PRTG dar:

Sophos UTM: Sehr langsame Verbindung via WAF / Sensor für PRTG

Der Screenshot zeigt einen ersten Versuch für den Sensor, die aktuelle Version des Sensors kann nun die folgenden Werte darstellen:

  • Busy Workers
  • Idle Workers
  • Requests per Second
  • Bytes per Second
  • Duration per Request
  • Cache Index Usage
  • Cache Usage

Falls jemand ebenfalls die Leistungsdaten der WAF in PRTG darstellen möchte, kann der Sensor hier runtergeladen werden:

Der Sensor benötigt das PowerShell Moduls Posh-SSH. Falls es bei dem PowerShell Modul zu Problemen in Verbindung mit Windows Server 2019 kommt, bitte hier schauen. Die Zeilen 2 bis 4 müssen im Script müssen entsprechend angepasst werden.

Hinweis: Die Anzahl der Worker Prozesse der UTM lässt sich in der Datei /var/storage/chroot-reverseproxy/usr/apache/conf/mpm.conf” erhöhen:

Sophos UTM: Sehr langsame Verbindung via WAF / Sensor für PRTG

In diesem Fall sollte aber die CPU und RAM Auslastung der UTM im Auge behalten werden.

5 Gedanken zu „Sophos UTM: Sehr langsame Verbindung via WAF / Sensor für PRTG“

  1. Guten Morgen,
    wäre vielleicht zu erwähnen das es damit das Powershell Script läuft (bei mir tat es das nämlich nicht)
    die PSx64 Exe von Prtgtoolsfamily benötigt (http://prtgtoolsfamily.com/downloads/sensors)
    Aufruf dann im Sensor Auswahl von PSx64.exe mit dem Parameter: „-f=Sophos_UTM_WAF_Worker.ps1“

    Danach gab es erstmal:
    SSH Session to UTM failed: Der Antwortinhalt kann nicht analysiert werden, da das Internet Explorer-Modul nicht verf gbar ist, oder die Konfiguration beim ersten Start von Internet Explorer ist nicht abgeschlossen. Geben Sie den UseBasicParsing-Parameter an, und wiederholen Sie den Vorgang.

    Da reichte es aber GPO zu setzen:
    Computerkonfiguration => Richtlinien => Administrative Vorlagen => Windows-Komponenten => Internet Explorer
    Eintrag: Ausführen des Anpassungs-Assistenten verhindern
    Aktivieren und Wert auf „Direkt zur Startseite wechseln“

    All das gemacht und der Sensor läuft.

    Danke Frank

    Antworten
    • Ich hatte das gleiche IE-Problem, konnte es dank Google aber durch hinzufügen von einem „-UseBasicParsing“ lösen. Die Zeile lautet im Script lautet nun:

      $UTMWAFStatus = Invoke-WebRequest „http://localhost:10000/status?auto“ -UseBasicParsing

      Antworten
  2. Moin Moin,

    die Erhöhung der Anzahl der Worker muss wahrscheinlich nach einem Update der UTM neu gesetzt werden oder? Hat das schonmal jemand getestet?

    Ansonsten danke für den Sensor. Auf unserem Server 2012R2 PRTG habe ich ihn leider wegen Problemen mit dem PoshSSH noch nicht zum laufen bekommen, aber inzwischen ist der Server auf 2019 upgegraded und ich werde nochmal mein Glück versuchen.

    Antworten
    • Das Powershell Skript ansich funktioniert jetzt und liefert auch gültige Werte zurück. Nur PSx64 scheint unter Server 2019 nicht (mehr) zu laufen. Beim Aufruf von ‚PSx64.exe -f=“Sophos_UTM_WAF_Worker.ps1″‚ aus der Shell passiert einfach nichts. Die Shell bleibt mit blinkendem Cursor stehen. Auch im PRTG kommen dann keine Werte für den Sensor an.

      Antworten

Schreibe einen Kommentar