A reader recently told me about a problem with the Sophos UTM web application firewall.
Due to the Corona crisis, many of the employees have switched to the home office and have since been using more connections to the Exchange server, which are protected by the WAF of the Sophos UTM. Since there was a higher load on the UTM during the day due to the many home office users, connections that ran via the WAF became very slow. During the day, loading times of over 60 seconds occurred. However, the CPU and RAM utilization of the UTM did not show any bottlenecks.
The reader then opened a ticket with Sophos Support, who were able to determine that the WAF has too few free worker processes and therefore timeouts and long loading times occur when accessing the services via WAF.
In this case, the following message was found in the reverse proxy log of the UTM (/var/log/reverseproxy.log):
2020:03:31-17:24:14 vpn2-1 httpd[8532]: [mpm_worker:error] [pid 8532:tid 4147619520] AH00288: scoreboard is full, not at MaxRequestWorkers
According to Sophos Support, the WAF of the UTM has 800 worker processes available; if all worker processes are busy, the problem described above occurs.
The problem was finally solved by increasing the number of worker processes (see end of article). However, this was not the reason why I received a nice mail from the reader. Here is an excerpt from the email:
I came across this article while searching Sophos:
https://community.sophos.com/kb/en-us/123512
There is a status page for the WAF, but it can only be accessed via an SSH tunnel.
I am currently tinkering with Powershell and trying to parse the page to output it to PRTG, but I haven't found anything yet on how to build an SSH tunnel from the script.
WAF, PRTG and PowerShell then aroused my interest and together we built a sensor for PRTG (many thanks at this point!), which displays the performance data of the UTM in PRTG.
The WAF overview page looks like this, for example:
A small PowerShell sensor, which establishes an SSH tunnel to the UTM and reads the data from the status page, now displays the values in PRTG:
The screenshot shows a first attempt for the sensor, the current version of the sensor can now display the following values:
- Busy Workers
- Idle Workers
- Requests per Second
- Bytes per second
- Duration per request
- Cache Index Usage
- Cache Usage
If someone would also like to display the performance data of the WAF in PRTG, the sensor can be downloaded here:
The sensor requires the PowerShell module Posh-SSH. If there are problems with the PowerShell module in connection with Windows Server 2019, please here look. Lines 2 to 4 in the script must be adjusted accordingly.
Note: The number of worker processes of the UTM can be increased in the file "/var/storage/chroot-reverseproxy/usr/apache/conf/mpm.conf":
In this case, however, you should keep an eye on the CPU and RAM utilization of the UTM.
Guter Artikel, das Script für PRTH läuft bei uns einwandfrei. Danke dafür!
Du schreibst, dass man die Werte in der Datei /var/storage/chroot-reverseproxy/usr/apache/conf/mpm.conf anpassen kann. Das funktioniert bei uns nur eingeschränkt. Wenn ich die Werte anpasse, setzen sie sich nach einer Zeit wieder auf die Ausgangswerte zurück. Hast du eine Ahnung woran das liegen kann?
Wir haben bei uns leider das gleiche Problem. Die Werte setzen sich auch ohne Neustart irgendwann zurück.
Konntet ihr das lösen?
Das hier hat bei uns geholfen, um die Werte dauerhaft zu setzen:
https://community.sophos.com/utm-firewall/f/general-discussion/120550/connection-refused-response-under-load
Das hier ist auch gut zum besseren Verständnis:
https://ewen.mcneill.gen.nz/blog/entry/2016-01-21-sophos-utm-reverseproxy-connections-per-second/
## Konfiguration ändern ##
cc set reverse_proxy ‚max_processes‘ 32
cc set reverse_proxy ‚max_threads_per_process‘ 200
cc set reverse_proxy ‚max_spare_threads‘ 600
## Cronjob, der die EInstellungen bei Neustart erneut durchführt – falls ein neues Update was ändert ##
vi /etc/crontab-static
@reboot root /usr/local/bin/confd-client.plx set reverse_proxy ‚max_processes‘ 32
@reboot root /usr/local/bin/confd-client.plx set reverse_proxy ‚max_threads_per_process‘ 200
@reboot root /usr/local/bin/confd-client.plx set reverse_proxy ‚max_spare_threads‘ 600
## Up2Date einmal auf Manuell > Apply > auf 1 Tag > Apply
## Eintrag Kontrollieren ##
cat /etc/crontab
## Reverse Proxy neu starten
/var/mdw/scripts/reverseproxy stop
## kurz warten ##
/var/mdw/scripts/reverseproxy start
## Auf Slave wechseln und wiederholen
ha_utils ssh
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.
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.
PSx64 wird bei mir unter Server 2019 nicht benötigt. Es muss nur wie oben schon beschrieben der Parameter -UseBasicParsing angehängt werden. Ansonsten funktioniert bei mir das ursprüngliche Script.
Wie sieht es mit Sophos XG aus?
– Status Page?
– Fehlermeldung in reverseproxy.log?
….
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
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