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:
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:
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:
In diesem Fall sollte aber die CPU und RAM Auslastung der UTM im Auge behalten werden.
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