Sophos Firewall WAF: Webserver sicher veröffentlichen

Mit Web Server Protection beziehungsweise Web Application Firewall (WAF) veröffentlicht man interne oder cloudbasierte Webanwendungen über die Sophos Firewall. Die Firewall arbeitet dabei als Reverse Proxy: Clients verbinden sich mit der öffentlichen Adresse der Firewall, die Firewall prüft HTTP- oder HTTPS-Traffic und leitet die Anfrage an den geschützten Webserver weiter.

Für den übergeordneten Hardening-Kontext passt der Hub Sophos Firewall Hardening: Best Practices für eine sichere Konfiguration.

Eine WAF-Regel ersetzt nicht automatisch sichere Applikationsentwicklung, Patching, starke Authentifizierung oder Server-Hardening. Gegenüber einer einfachen Portweiterleitung reduziert sie aber die Angriffsfläche deutlich, weil HTTP(S)-Traffic gezielter geprüft, eingeschränkt und geloggt werden kann.

WAF ist trotzdem nicht automatisch die richtige Antwort für jede Veröffentlichung. Entscheidend ist, ob die Anwendung tatsächlich über HTTP oder HTTPS sauber funktioniert, ob die Firewall Hostnamen und Pfade auswerten soll und ob die zusätzliche Reverse-Proxy-Schicht zur Anwendung passt.

Entscheidung vor der Veröffentlichung

Bevor man eine WAF-Regel erstellt, sollte klar sein, ob WAF, DNAT, VPN oder ZTNA zur Anwendung passt. Diese Entscheidung ist wichtiger als die eigentliche Maske in der Firewall, weil sie Angriffsfläche, Betrieb und Troubleshooting bestimmt.

Wann WAF statt DNAT sinnvoll ist

Für einfache TCP- oder UDP-Dienste verwendet man weiterhin NAT und Firewall Regeln. Für Webanwendungen ist WAF oft die bessere Wahl.

DNAT passt für Nicht-HTTP-Dienste, einfache Portweiterleitungen und Spezialprotokolle. Die Firewall übersetzt und erlaubt dann primär den Traffic.
WAF / Web Server Protection passt für HTTP- und HTTPS-Anwendungen, wenn Hostname, Zertifikat, Pfade, Schutzprofile, Authentifizierung oder Länderregeln relevant sind.
Reverse Proxy oder ZTNA passt für komplexe Webplattformen, Identitätsintegration und private Anwendungen, wenn Zugriff stark kontrolliert oder gar nicht öffentlich sein soll.

Wenn nur ein interner Webserver schnell per Portweiterleitung erreichbar gemacht werden soll, hilft die Anleitung Server per DNAT auf Sophos Firewall veröffentlichen. Wenn es um öffentliche Webanwendungen geht, sollte man WAF zuerst prüfen.

⚠️ WebDAV wird von Sophos WAF nicht unterstützt. Anwendungen wie Nextcloud sollte man deshalb nicht blind über WAF veröffentlichen, sondern über passende Firewall- und NAT-Regeln oder eine andere Veröffentlichungsarchitektur planen.

Entscheidung: WAF, DNAT oder privater Zugriff

Die wichtigste Frage lautet nicht, wie schnell eine Veröffentlichung gebaut ist, sondern ob sie später sicher betrieben, getestet und zurückgebaut werden kann. Diese Einordnung hilft vor der technischen Umsetzung:

Öffentliche Website oder einfache HTTPS-Anwendung: WAF ist meist der passende Startpunkt. DNS, Zertifikat, Hostname, Schutzprofil, Logging und Backend-Erreichbarkeit müssen getestet werden.
Kundenportal, Partnerportal oder Admin-Oberfläche: WAF mit Quellbegrenzung und optional MFA kann sinnvoll sein. Vorher sollte geklärt werden, ob WAF-MFA, Länderregeln oder feste Quellnetze möglich sind.
Reiner TCP- oder UDP-Dienst: DNAT ist meistens passender. Firewall-Regel, NAT-Regel, Zielserver, Rückroute und Logging müssen gemeinsam geprüft werden.
Webanwendung mit WebDAV oder Spezialprotokoll: Nicht automatisch WAF verwenden. Unterstützte Funktionen, Clientverhalten und alternative Veröffentlichung testen.
Anwendung nur für interne Benutzer: VPN, ZTNA oder stark eingeschränkte WAF prüfen. Öffentliche Erreichbarkeit sollte kritisch hinterfragt werden.

Für private Anwendungen ist eine weltweit erreichbare WAF-Regel oft zu viel Angriffsfläche. Wenn nur wenige Personen zugreifen müssen, sind feste Quellnetze, VPN, ZTNA oder eine andere private Zugriffsarchitektur häufig sauberer als eine öffentliche Webveröffentlichung.

Planung und Voraussetzungen

Eine stabile WAF-Veröffentlichung braucht DNS, Zertifikat, Backend-Erreichbarkeit, Logging und einen Rollback-Plan. Diese Punkte sollten vor der Konfiguration feststehen.

Voraussetzungen

Vor der ersten WAF-Regel sollte man diese Punkte klären:

Öffentlicher DNS-Name, zum Beispiel portal.example.com
Öffentliche IP-Adresse oder Alias auf der WAN-Schnittstelle
Zertifikat für den veröffentlichten Hostnamen
Interne IP-Adresse oder FQDN des Webservers
Interner Zielport des Webservers
Entscheidung, ob HTTP auf HTTPS umgeleitet wird
Erlaubte Quellnetze, Länder oder Benutzergruppen
Passendes Schutzprofil und optionale IPS-Policy
Aktiviertes Logging für spätere Analyse
Externer Testzugang ausserhalb des eigenen LAN

Der öffentliche DNS-Name muss auf die Adresse zeigen, die in der WAF-Regel als Hosted address verwendet wird. Bei HTTPS muss das Zertifikat zum veröffentlichten Hostnamen passen.

Zusätzlich braucht die Firewall ein Webserver-Objekt unter Web server > Web servers. Dort wird der interne oder externe Zielserver mit Host, Protokoll und Port beschrieben. Der Host ist ein IP- oder FQDN-Host-Objekt. Für Backends ist HTTP oder HTTPS möglich; Standardports sind 80 und 443. Wenn der Backend-Webserver lange Antworten liefert oder Keep-alive benötigt, sollten Keep alive und Timeout bewusst geprüft statt zufällig übernommen werden.

Der Backend-Timeout kann zwischen 1 und 65,535 Sekunden liegen; Standard sind 300 Sekunden. Läuft er ab, sendet die WAF dem Client 502. Disable backend connection pooling erzwingt für jeden Zugriff eine neue Backend-Verbindung und kann die Performance reduzieren. Diese Option gehört deshalb nur in eine gezielte Fehlereingrenzung und wird danach wieder auf den dokumentierten Vorzustand gesetzt.

Ausserdem sollte man die Grenzen der Web Server Protection früh berücksichtigen. Sophos nennt unter anderem ein Limit von 60 WAF-Regeln pro Firewall. Das reicht für viele Umgebungen, kann bei vielen Kundenportalen, Mandanten, Testsystemen oder getrennten Hostnamen aber schneller relevant werden als erwartet. Dann sollte man nicht blind weitere Einzelregeln bauen, sondern Namenskonzept, Pfade, virtuelle Webserver und alternative Veröffentlichungswege prüfen.

SFOS 22 unterstützt WAF-Regeln nicht über IPv6. Eine Anwendung darf deshalb nicht mit dieser Funktion als IPv6-Veröffentlichung geplant werden; der Überblick Sophos Firewall IPv6 Support und Grenzen in SFOS 22 grenzt WAF von den unterstützten IPv6-Regel- und Schutzfunktionen ab. Auch die Exchange-Vorlagen sind kein Freipass für moderne Exchange-Umgebungen: Sophos dokumentiert, dass WAF-Regeln aktuell keine Exchange-Versionen nach 2013 unterstützen.

Die vorkonfigurierten Vorlagen stammen aus einer älteren Microsoft-Anwendungswelt: Exchange Autodiscover, Outlook Anywhere und Exchange General enden an dieser Exchange-2013-Grenze; die weiteren Sophos-Anleitungen nennen Microsoft Lync, Remote Desktop Gateway beziehungsweise RD Web 2008/R2 sowie SharePoint 2010/2013. Sie sind deshalb keine aktuelle Baseline für Microsoft 365, moderne Exchange-Versionen, Teams oder heutige RDS-Deployments. Vor dem Einsatz werden die tatsächlich benötigten Pfade, Authentifizierungsverfahren und Schutzprofile gegen die aktuelle Microsoft-Architektur geprüft; bei einer modernen Anwendung bleibt Preconfigured template im Zweifel auf None.

Backend-Objekt mit einem nachvollziehbaren Beispiel anlegen

Öffentlicher Name und Backend-Name erfüllen verschiedene Aufgaben. Im folgenden Beispiel öffnen Benutzer portal.example.com; die Firewall erreicht den Server über backend.example.com. Beide Namen sind Platzhalter und müssen durch die eigenen DNS-Namen ersetzt werden. Der Backend-Name muss aus Sicht der Firewall zum tatsächlichen Server auflösen, nicht wieder zur eigenen öffentlichen WAF-Adresse: Sonst entsteht kein sinnvoller Weg zum Backend.

Unter Hosts and services > FQDN host > Add ein Objekt namens WAF_Backend_Portal mit FQDN backend.example.com anlegen und speichern. Alternativ ein IP-Host-Objekt für einen festen Backend-Server verwenden. FQDN-Hosts bieten laut Produktdokumentation eine breitere Serverkompatibilität; DNS-Auflösung und Zielserver müssen trotzdem geprüft werden.
Unter Web server > Web servers > Add ein Webserver-Objekt WAF_Portal_Server erstellen und unter Host das Backend-Objekt auswählen.
Type und Port nach dem tatsächlichen Backend-Listener setzen: im HTTPS-Beispiel HTTPS und 443, bei einem HTTP-Backend HTTP und beispielsweise 80. Der externe Listening Port wird erst in der WAF-Regel festgelegt und muss nicht mit dem Backend-Port identisch sein. Für ein HTTP-Backend das unverschlüsselte Segment bewusst absichern; ein HTTPS-Frontend allein verschlüsselt dieses Segment nicht.
Keep alive nur aktivieren, wenn der Webserver wiederverwendete Verbindungen unterstützt. Timeout zunächst mit dem Standard 300 Sekunden bewerten. Gemeint ist die Wartezeit auf Daten zum oder vom Backend, nicht eine pauschale maximale Gesamtdauer jeder Anfrage: Solange rechtzeitig Daten eintreffen, kann eine Antwort länger dauern. Bei 502 daher Backend-Logs und Datenpausen prüfen, statt den Wert sofort zu erhöhen.
Disable backend connection pooling im normalen Betrieb nicht als Performance-Optimierung aktivieren. Objekt speichern, Zuordnung zur WAF-Regel beziehungsweise zum SFOS-23-Protect-Pfad kontrollieren und einen repräsentativen Backend-Zugriff prüfen.

WAF-Freigabe vor der Konfiguration planen

Eine WAF-Regel sollte nicht erst in der Maske geplant werden. Vorher muss klar sein, ob die Sophos Firewall nur veröffentlichen soll oder ob sie zusätzlich Authentifizierung, Schutzprofile, Länderregeln und Logging übernehmen soll.

Diese Fragen sind vor einer produktiven Veröffentlichung wichtig:

Ist es wirklich eine HTTP- oder HTTPS-Anwendung? Für andere Protokolle ist DNAT meist passender.
Muss die Anwendung öffentlich erreichbar sein? Private Admin-Portale passen oft besser zu VPN, ZTNA oder eingeschränkten Quellnetzen.
Welcher Hostname und welches Zertifikat werden verwendet? DNS, SNI, Zertifikat und WAF-Domains müssen zusammenpassen.
Wie viele Veröffentlichungen sind geplant? Das WAF-Regellimit und die spätere Bedienbarkeit beeinflussen das Design.
Soll die Firewall Benutzer authentifizieren? Für Portale kann WAF-MFA sinnvoll sein.
Welche Schutzprofile sind aktiv? Zu breite Ausnahmen schwächen die WAF, zu harte Profile können Anwendungen brechen.
Wie wird geloggt und getestet? Log Viewer, reverseproxy.log und Backend-Logs müssen vor dem Go-live bekannt sein.

Für Zertifikate sollte man früh klären, ob ein bestehendes Zertifikat mit Private Key und CA-Kette importiert wird, ob die Firewall selbst ein Let’s-Encrypt-Zertifikat erstellen und erneuern soll oder ob ein extern erzeugtes Zertifikat benötigt wird. Für Wildcard-Zertifikate gibt es eine separate Anleitung: Let’s Encrypt Wildcard Zertifikat erstellen.

WAF-Regel konfigurieren

Die eigentliche WAF-Regel besteht aus öffentlicher Adresse, Hostnamen, Zertifikat, Zielserver, erlaubten Quellen und Schutzprofil. Diese Felder sollten zusammen betrachtet werden, nicht als isolierte Einzeloptionen.

Grundaufbau einer WAF-Regel

Eine WAF-Veröffentlichung besteht aus mehreren Bausteinen:

Hosted address: Öffentliche IP-Adresse oder Alias, auf der Clients die Anwendung erreichen.
Listening port: Öffentlicher Port, meistens 80 oder 443.
Domains: Hostnamen, die zur WAF-Regel passen sollen.
HTTPS certificate: Zertifikat für den veröffentlichten Hostnamen.
Web server: Vorher angelegtes Webserver-Objekt mit Host, Protokoll, Port und Verbindungseinstellungen.
Allowed client networks: Quellnetze, die zugreifen dürfen.
Blocked client networks / countries: Quellen oder Länder, die blockiert werden.
Protection policy: WAF-Schutz gegen typische Webangriffe.
Authentication: Optionale vorgelagerte Anmeldung über die Firewall.

Sophos erstellt WAF-Regeln im Bereich der Firewall Regeln. Die Aktion heisst Protect with web server protection.

Wichtig: Eine WAF-Regel ist keine normale Firewall-Regel mit NAT dahinter. Dabei entsteht eine Reverse-Proxy-Veröffentlichung. Deshalb müssen Hosted address, Listening port, Domains, Zertifikat, Protected server und Allowed client networks zusammenpassen. Wenn eines dieser Felder nicht passt, sieht der Fehler oft wie ein Zertifikats-, DNS- oder Backendproblem aus.

WAF-Regel erstellen

Der Menüpfad lautet:

Rules and policies > Firewall

Vorgehen:

Neue Regeln sind standardmässig eingeschaltet. Für eine vorbereitete, noch nicht freigegebene Veröffentlichung den Regelzustand deshalb ausdrücklich prüfen und die Regel bis zum geplanten Go-live ausgeschaltet lassen. Rule position bietet Top oder Bottom; Rule group ordnet die Regel einer bestehenden oder über Create new erstellten Gruppe zu. Automatic verwendet die erste passende Gruppe nach Regeltyp und Quell-/Zielzonen. Gruppierung ist eine Verwaltungshilfe, kein Ersatz für die Zugriffsprüfung.

Das folgende nummerierte Vorgehen mit Protected servers gilt nur für SFOS 22 und bleibt für diese Version unverändert. WAF-Regeln unterstützen nur IPv4. Die äussere Regelaktion Protect with web server protection ist nicht mit der pfadbezogenen Action > Protect unter Traffic routing in SFOS 23 gleichzusetzen; für SFOS 23 gilt die separate Anleitung direkt nach diesem Vorgehen.

IPv4 auswählen.
Add firewall rule öffnen.
New firewall rule auswählen.
Einen sprechenden Regelnamen vergeben.
Rule position bewusst setzen, besonders wenn bereits allgemeinere WAF-Regeln oder alte Veröffentlichungen existieren.
Bei Action die Option Protect with web server protection wählen.
Falls keine spezielle Vorlage benötigt wird, Preconfigured template auf None lassen.
Unter Hosted server details die öffentliche Adresse, den Listening Port, HTTPS, Zertifikat und Domains definieren.
Unter Protected servers das passende Webserver-Objekt auswählen oder vorher unter Web server > Web servers anlegen.
Allowed client networks bewusst setzen. Für öffentliche Websites kann Any IPv4 nötig sein, für Portale ist eine Einschränkung meist besser.
Bei Bedarf Blocked client networks oder Blocked countries setzen.
Unter den erweiterten Policies Protection, Intrusion prevention und Traffic shaping bewusst prüfen.
Regel speichern und extern testen.

SFOS 23: Pfade unter Traffic routing veröffentlichen

Unter Rules and policies > Firewall eine IPv4-Regel erstellen oder bearbeiten. Als äussere Action weiterhin Protect with web server protection wählen und öffentliche Adresse, Port, HTTPS-Zertifikat und Domains passend konfigurieren. Eine neue Regel enthält standardmässig / mit Block: Ohne weitere Routing-Konfiguration werden Anfragen abgewiesen, nicht veröffentlicht.
Unter Traffic routing mit Edit oder Add new path den konkret vorgesehenen Pfad bearbeiten oder ergänzen. Bei Action ausdrücklich Protect wählen und die benötigten Backend-Objekte aus Web server > Web servers zuweisen. Eine Vorlage erzeugt zwar Pfade mit Protect, benötigt aber weiterhin die Backend-Zuweisung.
Für jeden geschützten Pfad die vorgesehene Authentication Policy im Feld Authentication zuweisen und Allowed client networks bewusst setzen, nicht leer lassen. Blocked client networks, Blocked countries und Block IP addresses of unknown country-origin gezielt prüfen; bei unbekannter Länderherkunft auch das eigene Lockout-Risiko berücksichtigen.
Wenn nur bestimmte Pfade veröffentlicht werden sollen, / bewusst mit Block als Auffangroute behalten. / nur dann auf Protect setzen, wenn die gesamte Anwendung veröffentlicht werden soll; Backend, Authentifizierung, Zugriffsbeschränkungen und dadurch erreichbare Anwendungsteile ausdrücklich prüfen. Längere, spezifischere Pfade werden zuerst ausgewertet, nicht die Tabellenreihenfolge.
Die Aktionen unterscheiden: Block weist Anfragen für den gewählten Pfad ab und leitet sie nicht zum Backend weiter. Protect wendet die Schutzpolicy der Regel sowie die konfigurierten Authentifizierungs- und Zugriffseinstellungen an. Redirect sendet dem Client eine Weiterleitung zum konfigurierten Ziel, statt ein Backend zu veröffentlichen. Passthrough erstellt einen Tunnel zum Backend ohne WAF-Inspektion und ohne Anwendung der Schutzpolicy. Protection gilt nur für Pfade mit Protect.
Nach dem Speichern extern einen vorgesehenen erlaubten Pfad, einen absichtlich blockierten Pfad und einen Pfad ohne spezifische Übereinstimmung testen. Falls eingesetzt, auch Redirect und Passthrough separat prüfen. Client-Ergebnis, Log Viewer, reverseproxy.log und Backend-Logs anhand derselben Anfrage und desselben Zeitpunkts korrelieren.

Der Default-Pfad kann bearbeitet, geklont oder gelöscht werden. Ein Klon übernimmt keine fachliche Freigabe: Aktion, Backend, Authentifizierung und Quellen für die neue Zuordnung erneut prüfen. / nicht versehentlich entfernen, wenn es die bewusst blockierende Auffangroute bildet.

Bestehende Regeln nach dem Upgrade: Laut Sophos-Dokumentation werden bestehende WAF-Regeln beim Upgrade auf SFOS 23 automatisch auf Protect umgestellt; bestehende pfadspezifische Routen bleiben erhalten. Das unterscheidet sich vom /-Block-Standard neuer Regeln und von der älteren SFOS-18-Migration der ModSecurity Protection Policies. Nach dem Upgrade trotzdem für jeden Pfad Aktion, Backend, Authentifizierung, Zugriffsbeschränkungen und tatsächliche Route prüfen und extern abnehmen; die automatische Migration ersetzt keine Abnahme.

Einordnung des Tutorials: Das Sophos-Tutorial zum Schutz eines Webservers gegen Angriffe verwendet weiterhin das Verfahren mit Protected servers und nennt IPv4 or IPv6, obwohl die WAF-Regelreferenz WAF auf IPv4 begrenzt. Das Tutorial ist deshalb keine vollständige SFOS-23-Routing-Anleitung. Für die aktuelle Konfiguration gelten IPv4 und die expliziten Pfadaktionen oben.

Wenn die Regel gespeichert wird, startet Sophos die Web Server Protection Regeln neu. Bestehende Live-Verbindungen über diese Regeln können dadurch unterbrochen werden. Änderungen an produktiven WAF-Regeln sollte man deshalb in einem Wartungsfenster oder zumindest bewusst durchführen.

Wenn Allowed client networks leer bleibt, funktioniert die WAF-Regel nicht korrekt; der Browser kann dann einen 400 Bad Request erhalten. Für eine öffentliche Anwendung ist Any IPv4 zwar möglich, aber nicht automatisch richtig. Für Admin-Portale, Partnerportale oder interne Werkzeuge sollte man zuerst feste Quellnetze, Länderbegrenzung, WAF-MFA, VPN oder ZTNA prüfen.

Portkonflikte sollten vor dem Speichern geklärt sein. WebAdmin und User Portal benötigen jeweils einen eindeutigen Port. WAF und VPN Portal verwenden beide TCP; bei gleichem Port müssen ihre Hosted address beziehungsweise WAN-IP-Adressen deshalb verschieden sein. Gegenüber SSL VPN kann sich WAF über WAN-IP, Port oder Protokoll unterscheiden, weil SSL VPN TCP oder UDP unterstützt. Ein anderer FQDN oder SNI-Name allein genügt für diese Listener-Trennung nicht. Wenn auf einer öffentlichen IP bereits ein anderer Dienst oder eine alte DNAT-Veröffentlichung lauscht, muss die Zuordnung vor dem Go-live pro IP, Port und Protokoll getestet werden.

Der Standardport des User Portal ist 4443; Portal-Listener und ihre Grenzen sind im Portalüberblick eingeordnet.

SFOS 23: Block- und Redirect-Antworten konkret festlegen

Eine Routing-Aktion kann mehrere Einträge unter Paths zusammenfassen, wenn alle dieselbe Behandlung benötigen. Unter Traffic routing > Add new path die Pfade und die Aktion auswählen, die aktionsabhängigen Felder ausfüllen und den Pfadeintrag speichern. Bei unterschiedlichen Backends, Zugriffsregeln oder Weiterleitungszielen getrennte Einträge verwenden.

Für Block bestimmt Response code die Antwort. Ein Beispiel ist /admin/ mit Forbidden (403), während / als Auffangroute auf Block bleibt. Die dokumentierte Auswahl umfasst 400 bis 417 sowie 422, 423, 424 und 426. Den Code nach der beabsichtigten Aussage wählen: 403 steht für verweigerten Zugriff, 404 für nicht gefundene Inhalte. Ein gewählter 401-Code richtet keine Authentication Policy ein; der Statuscode allein ist kein Anmeldeschutz. Bei der Abnahme den konfigurierten Status und das Ausbleiben einer entsprechenden Backend-Anfrage prüfen.

Für Redirect gehören neben Paths und Action die Felder Response code, Protocol, Host, Path und Port zur Konfiguration. Beispiel: /old-portal/ mit Temporary Redirection (307), Protocol HTTPS, einem FQDN-Host für portal.example.com, Path /portal/ und Port 443. Namen und Pfade durch die eigene Zielanwendung ersetzen. 307 bezeichnet eine temporäre Weiterleitung unter Beibehaltung der Request-Methode; das eignet sich für einen kontrollierten Pilot, wenn das Ziel dieselbe Methode verarbeitet. Browser und API-Client trotzdem getrennt testen, insbesondere POST-Anfragen. Das Ziel /portal/ muss selbst erreichbar und geschützt sein, beispielsweise über einen passenden Protect-Pfad; eine Weiterleitung allein erzeugt dort keine Backend- oder Zugriffskonfiguration.

Die Auswahl bietet 300, 301, 302, 303, 304, 305, 307 und 308. Nicht jeder angebotene Code ist eine gewöhnliche Weiterleitung zu einer neuen Seite: 304 beschreibt Cache-Validierung. 305 ist wegen Sicherheitsbedenken veraltet und keine Empfehlung für öffentliche Anwendungen. 301 beziehungsweise 308 erst bei beabsichtigter dauerhafter Umstellung verwenden und das Client-/Cache-Verhalten im Rückweg berücksichtigen. Die Standardports des Ziels sind 80 für HTTP und 443 für HTTPS. Redirect führt keine WAF-Inspektion durch und sendet den Request nicht an ein Backend dieser Route; deshalb am Client Status und Weiterleitungsziel sowie anschliessend den Schutz der Zielanwendung prüfen.

Host Header, HTML und Kompression gezielt anpassen

Die Advanced settings einer WAF-Regel helfen bei konkreten Reverse-Proxy-Problemen. Sie sind keine Optionen, die pauschal alle aktiviert werden sollten:

Pass host header reicht den vom Client angeforderten Host Header an das Backend weiter. Bei mehreren Websites auf einem Server kann dadurch der richtige virtuelle Host gewählt werden. Den Backend-vHost passend zum veröffentlichten Namen konfigurieren und im Access-Log prüfen, dass keine andere Website antwortet.
Rewrite HTML passt Links in zurückgegebenen Seiten an. Zeigt beispielsweise ein absoluter Link auf http://backend.example.com/, während die Anwendung über den öffentlichen Namen veröffentlicht wird, kann eine Umschreibung nötig sein. Bei bereits passenden öffentlichen Hostnamen oder durchgehend relativen Links ist sie normalerweise nicht erforderlich. Die Verarbeitung betrifft Content-Types text/* und *xml*; binäre Downloads müssen mit korrektem Content-Type ausgeliefert werden, sonst droht Beschädigung. Öffentliche Links, Downloads und Anwendungsfunktionen danach getrennt testen.
Rewrite cookies schreibt Cookies in den zurückgegebenen Seiten um. Bei Session-Problemen die tatsächlich gesetzten Cookies sowie Login und Logout untersuchen, statt Cookie-Umschreibung mit Cookie signing zu verwechseln: Umschreibung und Manipulationsschutz erfüllen unterschiedliche Aufgaben.
Disable compression support ist eine gezielte Hilfe bei fehlerhaft dargestellten Seiten oder Content-Encoding-Fehlern. Die Firewall fordert dann unkomprimierte Daten beim Backend an und liefert sie unabhängig vom angeforderten Encoding unkomprimiert aus. Vorzustand dokumentieren, denselben Seitenaufruf wiederholen und die Option zurücknehmen, wenn sie den Fehler nicht behebt.

Einige Ports sind für Systemdienste reserviert, auch wenn der jeweilige Dienst nicht verwendet wird. Ein freier Listener allein macht einen solchen Port nicht für WAF verfügbar; die Übersicht Reservierte Ports der Sophos Firewall hilft bei der Planung. Traffic shaping weist der Veröffentlichung Bandbreite und zeitabhängige Priorisierung zu. Das ist eine Betriebsentscheidung, kein zusätzlicher Anwendungsschutz; Uploads und Downloads bei aktivierter Policy auch unter repräsentativer Last prüfen.

Go-live und Abnahme

Nach dem Speichern der Regel ist die Veröffentlichung noch nicht fertig. Erst externe Tests, passende Logs und ein klarer Rollback machen die Änderung produktionsreif.

Go-live und Rollback planen

Eine WAF-Veröffentlichung sollte nicht direkt mit dem Speichern der Regel als abgeschlossen gelten. Entscheidend ist, ob DNS, Zertifikat, Hosted address, Backend, Schutzprofil und Logging zusammen funktionieren. Besonders bei bestehenden Portweiterleitungen sollte man den Wechsel wie eine kleine Veröffentlichung behandeln.

Vor dem Go-live prüfen:

Aktuelle Firewall-Konfiguration oder mindestens die betroffenen Regel- und Zertifikatseinstellungen dokumentieren.
Bisherige DNAT- oder Firewall-Regeln identifizieren, die denselben Port, dieselbe öffentliche IP oder denselben Hostnamen betreffen.
Alte DNAT-Regeln deaktivieren oder eindeutig dokumentieren, warum sie nicht mit der WAF-Regel konkurrieren.
DNS-TTL vor einer Umstellung reduzieren, wenn der öffentliche Hostname von einer alten Veröffentlichung auf die WAF wechselt.
Externen Testzugang bereitstellen, nicht nur aus dem internen LAN testen.
Testfälle definieren: Startseite, Login, Upload, Download, API-Pfad, WebSocket, Logout und Fehlermeldung.
Erwartete Logstellen festlegen: Log Viewer, reverseproxy.log, Backend-Access-Log und Backend-Error-Log.
Rollback-Kriterium festlegen, zum Beispiel Login nicht möglich, Backend nicht erreichbar, falsches Zertifikat, starke Fehlerrate oder kritische Anwendungsteile defekt.

Beim Wechsel sollte jeweils nur eine Veröffentlichung aktiv sein. Wenn eine alte DNAT-Regel und eine neue WAF-Regel dieselbe öffentliche IP und denselben Port verwenden, ist das Verhalten schwer nachvollziehbar. Vor dem produktiven Umschalten sollte klar sein, welche Regel den Traffic tatsächlich verarbeitet.

Ein einfacher Rollback besteht häufig darin, die neue WAF-Regel zu deaktivieren und die vorherige Veröffentlichung wieder zu aktivieren. Wenn zusätzlich DNS geändert wurde, muss die DNS-TTL berücksichtigt werden. Bei Zertifikats- oder Hostnamenproblemen ist ein Rollback über DNS allein oft zu langsam; in solchen Fällen sollte die alte Regel auf derselben Hosted address wieder aktivierbar sein oder ein alternativer Zugang bereitstehen.

Nach dem Go-live sollten die ersten Zugriffe aktiv beobachtet werden. Wichtig sind nicht nur erfolgreiche HTTP-Statuscodes, sondern auch WAF-Blocks, Backend-Fehler, unerwartete Weiterleitungen, Session-Probleme und fehlende Client-IP-Informationen in den Backend-Logs.

Abnahmetest nach dem Go-live

Ein WAF-Test ist erst vollständig, wenn dieselbe Anfrage aus drei Blickwinkeln nachvollziehbar ist: Client, Firewall und Backend. Dadurch erkennt man schneller, ob ein Problem bei DNS, Zertifikat, WAF-Matching, Schutzprofil oder Anwendung liegt.

Externer Client: DNS-Auflösung, Zertifikat, HTTP-Status, Login und wichtige Pfade prüfen. Die Anwendung sollte über den öffentlichen Hostnamen ohne Zertifikatswarnung öffnen.
Sophos Firewall: Log Viewer, WAF-Regel, reverseproxy.log und blockierte Signaturen prüfen. Die richtige WAF-Regel sollte den Zugriff verarbeiten und Logs sollten erlaubte oder begründet blockierte Requests zeigen.
Backend-Webserver: Access-Log, Error-Log, Anwendungssession und X-Forwarded-For prüfen. Der Request sollte den richtigen vHost oder Pfad erreichen, und die Client-IP-Logik muss verstanden sein.

Für produktive Anwendungen sollte man mindestens diese Fälle testen:

Aufruf über den richtigen Hostnamen und über eine nicht passende Domain.
Login mit gültigem und ungültigem Benutzer, falls die Anwendung oder WAF authentifiziert.
Upload, Download, API- oder WebSocket-Funktion, wenn die Anwendung solche Funktionen nutzt.
Zugriff aus erlaubter Quelle und, wenn möglich, aus einer bewusst nicht erlaubten Quelle.
Verhalten einer bekannten harmlosen WAF-Testanfrage, damit Logging und Blockpfad sichtbar sind.

Wenn die Anwendung nach dem Go-live scheinbar funktioniert, aber keine passenden Logs sichtbar sind, ist der Test noch nicht abgeschlossen. Dann kann es sein, dass eine andere Veröffentlichung matched, Logging fehlt oder der Zugriff nicht über den erwarteten Pfad läuft.

Schutz und Zugriff absichern

Bei öffentlichen Webanwendungen ist die WAF nur eine Schutzschicht. Zertifikate, Quellbegrenzung, Threat Feeds, Schutzprofile und Backend-Logging müssen gemeinsam geplant werden.

Zertifikate und Hostnamen

Für HTTPS muss die WAF-Regel ein Zertifikat verwenden, das zum öffentlichen Hostnamen passt. Das Zertifikat wird unter Certificates > Certificates importiert oder erstellt und anschliessend in der WAF-Regel ausgewählt.

Wichtige Punkte:

Der DNS-Name muss zum Zertifikat passen.
Das ausgewählte HTTPS-Zertifikat kann die Domain-Liste in der WAF-Regel automatisch füllen oder bestehende Domain-Einträge überschreiben.
Bei mehreren Hostnamen auf derselben IP nutzt die Firewall SNI.
Wildcard-Zertifikate sind möglich, sollten aber sauber dokumentiert werden.
Wildcard-Domains werden erst nach spezifischeren Domain-Regeln verwendet. *. ist nur am Anfang zulässig, beispielsweise *.example.com; mehrere Wildcard-Domains in einer Regel sind möglich.
Unterstriche im linken Domain-Label sind kein sauberer DNS-Name und sollten für WAF-Domains vermieden werden.
Das Backend kann einen anderen internen Namen verwenden, wenn Host Header und Anwendung damit umgehen können.
Bei Problemen mit absoluten Links kann Rewrite HTML relevant werden.

Wenn mehrere virtuelle Webserver über dieselbe IP und denselben Port laufen, entscheidet die Firewall bei HTTPS anhand von SNI und Hostname, welche WAF-Regel passt.

Die Domains in der WAF-Regel sollten deshalb exakt zu DNS und Zertifikat passen. Wildcards können hilfreich sein, sollten aber nicht als Ersatz für ein sauberes Veröffentlichungskonzept dienen. Wenn mehrere Anwendungen unter ähnlichen Hostnamen laufen, braucht es eine klare Regel- und Zertifikatsdokumentation, sonst wird später schwer nachvollziehbar, welche WAF-Regel tatsächlich matched. Ein Test mit einer absichtlich nicht passenden Subdomain ist sinnvoll: Dann erkennt man, ob die spezifische Regel, eine Wildcard-Regel oder kein passender virtueller Webserver antwortet.

Der Name des Zertifikatobjekts darf nur alphanumerische Zeichen des US-ASCII-Zeichensatzes enthalten; das ist nicht mit dem DNS-Namen im Zertifikat gleichzusetzen. Nach der Auswahl die automatisch übernommenen Domains kontrollieren und bei Bedarf bearbeiten, ergänzen oder löschen. HTTPS macht den Listener über HTTPS erreichbar, nicht zusätzlich über HTTP. Redirect HTTP leitet separat Zugriffe von Port 80 auf Port 443 um; diese Listener und mögliche Portkonflikte deshalb ebenfalls planen.

Bei einem nicht passenden Subdomain-Namen muss keine grafische Blockseite erscheinen. Die Dokumentation zeigt beispielsweise 403 für einen anderen Subdomain-Aufruf. Deshalb den HTTP-Status und reverseproxy.log prüfen, nicht nur das Aussehen der Browserseite.

Client-IP und Backend-Logs planen

Bei WAF-Veröffentlichungen sieht der interne Webserver häufig nicht die echte Client-IP als direkte Quelladresse. Die Sophos Firewall arbeitet als Reverse Proxy und baut die Verbindung zum Backend selbst auf. Für die Anwendung und die Webserver-Logs kann deshalb zuerst die Firewall-Adresse sichtbar sein.

Wenn die Anwendung oder das Backend die ursprüngliche Client-IP braucht, sollte man früh prüfen, ob X-Forwarded-For oder ein vergleichbarer Header ausgewertet wird. Das ist wichtig für:

Anwendung-Logs und Security-Auswertung
Rate Limits oder Login-Schutz auf Applikationsebene
Fehleranalyse mit Benutzer- oder Quell-IP-Bezug
SIEM- oder Monitoring-Korrelation
forensische Auswertung nach einem Vorfall

Wichtig ist die Vertrauensgrenze: Ein Backend sollte solche Header nur dann als vertrauenswürdig behandeln, wenn die Anfrage wirklich von der Sophos Firewall oder einem definierten Reverse Proxy kommt. Öffentliche Clients dürfen X-Forwarded-For nicht direkt als Sicherheitsnachweis setzen können. In der Praxis sollte der Webserver deshalb nur der Firewall-IP vertrauen und Header aus anderen Quellen ignorieren oder überschreiben.

Für Troubleshooting bedeutet das: Log Viewer, reverseproxy.log und Backend-Log müssen denselben Testzeitpunkt abdecken. Wenn im Backend nur die Firewall-IP sichtbar ist, ist das nicht automatisch ein WAF-Fehler, sondern oft normales Reverse-Proxy-Verhalten.

Client-Zugriff einschränken

Nicht jede Webanwendung muss weltweit erreichbar sein. Schon in der WAF-Regel kann man den Zugriff begrenzen.

Sinnvolle Einschränkungen:

Nur bekannte Quell-IP-Adressen oder Partnernetze erlauben.
Nicht benötigte Länder blockieren.
IP-Adressen unbekannter Länderherkunft nur blockieren, wenn das Risiko eines eigenen Lockouts geprüft wurde.
Für Portale zusätzlich WAF-MFA oder vorgelagerte Authentifizierung verwenden.
Bekannte bösartige Quellen über Threat Feeds blockieren.

Für Länder- und Bad-IP-Blocking hilft Sophos Firewall: Länder und bösartige IPs blockieren. Für dynamische Bedrohungslisten ist Sophos Firewall Threat Feeds relevant.

Threat Feeds und Active Threat Response einplanen

Bei öffentlich erreichbaren Webanwendungen sollte man nicht nur die WAF-Regel selbst betrachten. Seit SFOS 22 werden Threat Feeds auch für eingehenden, weitergeleiteten Traffic wie WAF- und DNAT-Veröffentlichungen relevanter. Die Firewall kann solche Treffer mit MDR Threat Feeds, NDR Essentials und Third-Party Threat Feeds abgleichen.

Für Administratoren heisst das: WAF ist die Veröffentlichungsschicht, Threat Feeds und Active Threat Response können zusätzliche bekannte bösartige Quellen blockieren oder sichtbar machen. Das ersetzt aber kein Patch-Management, keine saubere Authentifizierung und keine Anwendungshärtung.

Praktisch sollte man prüfen:

Ist Active Threat Response in der Umgebung sinnvoll konfiguriert?
Werden relevante Threat Feeds eingesetzt und regelmässig geprüft?
Sind WAF-Events, Active-Threat-Response-Logs und Backend-Logs im Betrieb sichtbar?
Gibt es einen Prozess für False Positives, Allowlisting und Notfallfreigaben?
Ist klar, wer auf Treffer reagiert und ob nur geloggt oder aktiv blockiert wird?

Gerade bei Kundenportalen, Admin-Oberflächen oder Partnerzugängen sollte diese Prüfung vor dem Go-live passieren. Wenn ein Feed später produktiven Traffic blockiert, muss der Betrieb wissen, wo man den Treffer sieht und wie man sauber entscheidet: echter Angriff, Fehlalarm oder falsch veröffentlichte Anwendung.

Schutzprofile und Ausnahmen

Eine WAF-Regel sollte nicht nur veröffentlichen, sondern auch schützen. Dafür verwendet man Protection Policies, optionale IPS-Policies und Ausnahmen.

Typische Schutzbereiche:

Cookie Manipulation
URL Hardening
Form Hardening
Cross-Site Scripting
Application Attacks
Antivirus-Prüfung
Bad-Reputation-Clients

Unter Web server > General settings liegen zusätzliche globale Einstellungen für Web Server Protection, unter anderem TLS-Versionssteuerung und Schutz gegen langsame HTTP-DoS-Muster. Diese Einstellungen gelten nicht nur für eine einzelne Regel. Änderungen sollten deshalb bewusst geplant und mit bestehenden WAF-Veröffentlichungen abgestimmt werden.

SFOS 23: Worker-Profil gezielt anpassen

Unter Web server > General settings > Worker customization berechnet die Firewall die Standardwerte anhand der verfügbaren CPU- und RAM-Ressourcen; sie passen für die meisten Installationen. Höhere Werte können WAF-Performance und Systemressourcen negativ beeinflussen. Use custom worker profile deshalb nur nach geprüftem Bedarf und einer Bewertung der Auswirkungen aktivieren. Vorher die bisherigen Werte und den berechneten oder benutzerdefinierten Zustand dokumentieren, ein Konfigurationsbackup erstellen und ein Wartungsfenster sowie den Rollback auf genau diesen vorherigen Zustand planen. Diese Anpassung ist keine Änderung von Maximum sessions.

Start servers: Anzahl der beim Start des Webservers gestarteten Worker-Prozesse.
Server limit: Maximale Anzahl gleichzeitig ausführbarer Worker-Prozesse.
Minimum spare threads: Mindestanzahl verfügbar gehaltener inaktiver Threads für neue Anfragen.
Maximum spare threads: Höchstanzahl inaktiver Threads, bevor überschüssige Threads entfernt werden.
Threads per child: Maximale Anzahl Worker-Threads pro Worker-Prozess.
Asynchronous request worker factor: Steuert die Skalierung der Worker-Prozesse für asynchrone Verbindungen und Anfragen.

Bei formbasierter Reverse-Proxy-Authentifizierung begrenzt das globale Feld Maximum sessions die gleichzeitigen Benutzersitzungen aller WAF-Regeln, die diese Authentifizierung verwenden. Der Standardwert beträgt 25,000, der zulässige Bereich 100 bis 100,000. Beim Erreichen des Limits schliesst die Firewall alte oder abgelaufene Sitzungen, um neue zuzulassen. Der Wert ist deshalb keine Kapazität pro Regel; man dimensioniert ihn nach den gleichzeitigen Anmeldungen der betroffenen Anwendungen und kontrolliert nach einer Änderung Login, Logout und Sitzungswechsel.

Bei Slow HTTP protection ist Soft limit das zunächst gewährte Zeitfenster für den Empfang des Request-Headers. Hard limit setzt die absolute Obergrenze. Über Extension rate wird festgelegt, nach wie vielen zusätzlich empfangenen Bytes das Soft limit um eine Sekunde verlängert wird. Diese drei Werte sollten gemeinsam und mit realen langsamen Clients getestet werden; ein einzelner grosszügiger Wert kann den Schutz unnötig abschwächen.

Bei Slow HTTP protection sollten Ausnahmen auf die kleinste nötige IP-Adresse oder das kleinste nötige Netz begrenzt werden. Sophos unterstützt an dieser Stelle IP- und Network-Host-Objekte, aber keine IP-Bereiche oder Host-Listen. Die Minimum TLS version gilt ebenfalls global; vor einer Verschärfung müssen ältere Clients und alle veröffentlichten Anwendungen mit einem echten externen Test geprüft werden.

Als globale TLS-Vorgabe bietet SFOS unter anderem TLS v1.2 (wide compatibility), TLS v1.2 (strict) und TLS v1.3. Custom protocol configuration und Custom cipher configuration sollten nur mit dokumentierten, getesteten OpenSSL-Werten verändert werden; Cipher Suites für TLS 1.3 werden dabei separat gepflegt. Ungültige Werte können verhindern, dass der von SFOS verwaltete Apache-Dienst und damit Web Server Protection startet. Vorherige Werte, Konfigurationsbackup, Wartungsfenster und alternativer Admin-Zugang gehören deshalb zum Änderungsplan. Danach müssen alle WAF-Veröffentlichungen und reverseproxy.log geprüft werden; startet der Dienst nicht, werden die letzten benutzerdefinierten Werte zurückgenommen statt weitere Varianten im Produktivbetrieb auszuprobieren.

Bei Protection Policies ist der Modus wichtig. Reject blockiert und erzeugt sichtbare Log-Viewer-Ereignisse für WAF-Regeln. Monitor protokolliert nur, zeigt diese WAF-Meldungen aber nicht zwingend im Log Viewer; dann muss man reverseproxy.log prüfen. Für einen Pilotbetrieb kann Monitor sinnvoll sein, für produktiven Schutz sollte klar sein, ob Angriffe nur beobachtet oder wirklich abgewiesen werden.

Der Common threat filter arbeitet mit vier Filtering Strengths. Level 1 ist am tolerantesten und wird nicht geloggt; ab Level 2 stehen Treffer in /log/reverseproxy.log, gleichzeitig steigt das False-Positive-Risiko. Einzelne Regeln werden nur anhand der im Log belegten Rule ID unter Skip filter rules ausgenommen. Eine ganze Kategorie oder ein höheres Level pauschal abzuschalten, ist kein sauberer Ersatz für diese Analyse.

Static URL hardening ist case-sensitive, akzeptiert keine Wildcards und hilft nicht bei dynamisch durch JavaScript erzeugten URLs. Form hardening vergleicht die Formularstruktur und unterstützt Formulare bis 8,000 Bytes. Werden binäre Inhalte fälschlich als HTML oder XML ausgeliefert, können beide Funktionen diese Inhalte beschädigen; zuerst wird daher der Content-Type des Backends korrigiert statt die Schutzfunktion breit auszuschalten.

Beim Antivirus-Scan bezieht sich ein Grössenlimit auf das gesamte Upload-Volumen eines Requests, nicht auf jede einzelne Datei. Der zusätzliche Request size limit für den HTTP-Body reicht von 1 bis 1,024 MB und steht standardmässig auf 10 MB. HTTP Strict Transport Security fügt den HSTS-Header nur hinzu, wenn die WAF-Regel Redirect HTTP verwendet; MIME-type sniffing protection setzt X-Content-Type-Options: nosniff. Upload, Download und Header müssen deshalb mit der echten Anwendung geprüft werden.

IPS in einer WAF-Regel sollte man separat bewerten. Sophos setzt IPS für WAF nur ein, wenn die Kommunikation zwischen Firewall und Webserver über HTTP läuft. Wenn das Backend per HTTPS angebunden ist, darf man also nicht automatisch erwarten, dass eine ausgewählte IPS-Policy denselben Effekt hat.

Ausnahmen sollten eng gesetzt werden. Wenn eine Anwendung wegen eines einzelnen Pfads oder einer bestimmten Quelle nicht funktioniert, sollte man nicht das gesamte Schutzprofil abschalten. Besser ist eine gezielte Ausnahme mit Pfad, Quelle und klarer Begründung.

⚠️ Jede Ausnahme reduziert die Schutzwirkung. Pfad, Quelle, Grund, Datum und Review-Termin sollten dokumentiert werden, damit temporäre Workarounds nicht dauerhaft bestehen bleiben.

Protection Policy erstellen und die Schutzwirkung verstehen

Unter Web server > Protection policies > Add einen sprechenden Namen vergeben, beispielsweise WAF_Portal_Protection, die benötigten Schutzfunktionen konfigurieren und Save wählen. Danach die Policy im Feld Protection der WAF-Regel auswählen; unter SFOS 23 wirkt sie nur auf Protect-Pfade. Eine vorhandene Standardpolicy, etwa für Exchange Autodiscover, sollte nur für den dazu passenden Anwendungsfall verwendet werden.

Für einen Pilot der eigenen Anwendung zunächst klar zwischen Monitor und Reject entscheiden. Monitor blockiert nicht und zeigt die betreffenden WAF-Meldungen nicht im Log Viewer; dafür ist reverseproxy.log nötig. Die stärkere Sichtbarkeit von Reject darf nicht mit einer bereits getesteten Anwendungskompatibilität verwechselt werden. Pass Outlook anywhere erlaubt externen Outlook-Clients, den Webserver-Schutz für den Exchange-Zugriff zu umgehen. Die Option ist keine allgemeine Kompatibilitätslösung für moderne Portale und bleibt ohne begründeten Legacy-Anwendungsfall ausgeschaltet.

Cookie signing ergänzt ein vom Server gesetztes Cookie um ein zweites Cookie mit einem Hash aus Name, Wert und einem nur der Firewall bekannten Geheimnis. Liefert der Client das passende Paar nicht, wird das Cookie verworfen. Das schützt vor Manipulation, ersetzt aber weder sichere Anwendungssessions noch die korrekte Cookie-Konfiguration des Backends. Login, Warenkorb oder andere Cookie-abhängige Abläufe nach Aktivierung testen.

Bei Static URL hardening signiert die Firewall statische Links und bewertet aus der Serverantwort, welche Folge-Links zulässig sind. Entry URLs definiert Einstiegs-URLs, die ohne Hardening-Signatur erreichbar sein dürfen; für eine einfache Website kann / der Einstieg sein. Diese Liste ist keine allgemeine Routing-Liste. Gross-/Kleinschreibung beachten und keine Wildcards eintragen. Anwendungen mit JavaScript-generierten URLs oder legitimen Deep Links benötigen eine gesonderte Prüfung. Form hardening signiert die ursprüngliche Formularstruktur und weist manipulierte Formulare zurück. Bestehende Grenzen von 8,000 Bytes und korrektes HTML-/XML-Content-Type bleiben entscheidend.

Das dokumentierte einfache Angriffsschutz-Beispiel verwendet Reject, Static URL hardening mit Einstieg /, Form hardening, Antivirus, Block clients with bad reputation und Common threat filter. Cookie signing, Pass Outlook anywhere und Skip remote lookups for clients with bad reputation sind dort ausgeschaltet. Das ist ein Testprofil für diesen konkreten Ablauf, keine universelle Empfehlung und kein Beleg für passende Defaults jeder Anwendung. Für ein modernes Portal jeden dieser Schalter anhand des echten Anwendungsverkehrs bewerten. Auch das dort genannte Basic with passthrough ist keine MFA-Empfehlung; Client-Modus, Weitergabe von Anmeldedaten und Vorlagen werden im verlinkten WAF-Authentifizierungs- und MFA-Artikel erklärt.

Antivirus und Reputation bewusst konfigurieren

Bei Antivirus bestimmt Mode, ob ein oder zwei Scan-Engines verwendet werden; bei Single-Scan die Engine auswählen. Direction legt Upload, Download oder beide Richtungen fest. Block unscannable content blockiert beispielsweise verschlüsselte oder beschädigte Dateien, die nicht geprüft werden können. Das erhöht die Durchsetzung, kann aber legitime verschlüsselte Dokumente betreffen; deshalb zulässige Geschäftsabläufe und den Supportweg vorher festlegen.

Limit scan size begrenzt das zu scannende Volumen; 0 oder ein leeres Feld bedeutet keine Grössenbegrenzung für den Scan. Beispiel: Bei 50 MB Scanlimit und Dateien von 45, 5 und 10 MB in einem Upload wird die letzte Datei nicht gescannt. Ein erfolgreicher Upload beweist daher nicht, dass jede enthaltene Datei geprüft wurde. Dieses Scanlimit ist vom Request size limit für den gesamten HTTP-Body zu unterscheiden: Ein grösseres Bodylimit macht nicht automatisch mehr Inhalt scanbar. Limits nach den tatsächlich benötigten Uploads, Ressourcen und Sicherheitsanforderungen wählen und Mehrdatei-Uploads sowie nicht scannbare Inhalte in einer freigegebenen Testumgebung prüfen.

Block clients with bad reputation verwendet RBL- und GeoIP-Informationen: Sophos SXL für RBLs und MaxMind für GeoIP. Dokumentiert sind auch Sperren für die Klassifikationen A1 (anonyme Proxys beziehungsweise VPN-Dienste) und A2 (Satelliten-ISP). Das kann legitime Partnerzugänge betreffen. Skip remote lookups for clients with bad reputation kann Performance verbessern, verändert aber die Bewertung über entfernte Abfragen; nicht unbemerkt aktivieren und nicht mit einer Quellen-Allowlist gleichsetzen.

Common threat filter nach Kategorien und Stärke bewerten

Die Kategorien beantworten unterschiedliche Fragen und werden für die Anwendung bewusst gewählt:

Application attacks: Erkennt unter anderem unzulässige Pfadzugriffe und typische Befehlsausführungsversuche, auch nach einem möglichen Einbruch.
SQL injection attacks: Prüft Request-Argumente auf eingebettete SQL-Befehle und Escape-Zeichen.
XSS attacks: Prüft Eingaben auf eingebettete Skript-Tags und Code.
Protocol enforcement: Prüft Protokollkonformität, typische Header wie Host und User-Agent, Argumentgrenzen und erlaubte HTTP-Nutzung. Ein ungewöhnlicher legitimer Client kann daher ebenfalls auffallen.
Scanner detection: Erkennt typische Bot-, Crawler- und Scan-Muster; gewünschte Suchmaschinen- oder Monitoring-Zugriffe müssen trotzdem getestet werden.
Data leakage: Verhindert, dass sensible Informationen etwa über Serverfehlermeldungen zum Client gelangen. Bei aktivem Application attacks oder SQL injection attacks sollte diese Kategorie ebenfalls geprüft werden, weil sich die Erkennungsbereiche überschneiden.

Filter strength steht standardmässig auf Level 1 und erzeugt die wenigsten False Positives. Level 2 ergänzt beispielsweise reguläre Ausdrücke für SQL-/XSS-Injection und weitere Code-Injection-Schlüsselwörter; Level 3 ergänzt Regeln, Schlüsselwortlisten und Sonderzeichenlimits; Level 4 schränkt Sonderzeichen noch stärker ein und benötigt besonders gründliche False-Positive-Tests vor dem Go-live. Die vorher beschriebenen Loggrenzen bleiben bestehen: Level 1 wird nicht geloggt, Level 2 und höher erscheinen in /log/reverseproxy.log. Keine höhere Stärke allein deshalb als sicher abgenommen betrachten, weil eine Startseite öffnet.

HSTS und MIME-Schutz vor dem Einschalten prüfen

Bei HTTP Strict Transport Security und aktiviertem Redirect HTTP fügt die Firewall diesen Header hinzu:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

31536000 entspricht einem Jahr. Das betrifft nicht nur den getesteten Einstieg: includeSubDomains bezieht Subdomains ein, und Browser können die Vorgabe speichern. Vor der Aktivierung müssen HTTPS, Zertifikate und alle betroffenen Subdomains dauerhaft funktionieren; das spätere Abschalten der Checkbox ist kein sofortiger Rückweg für bereits gespeicherte Browser-Vorgaben. preload im Header allein beweist keine Aufnahme in eine Browser-Preload-Liste. MIME-type sniffing protection ergänzt X-Content-Type-Options: nosniff; fehlerhafte MIME-Typen deshalb am Backend korrigieren, statt den Header pauschal zu entfernen. Beide Header am externen Client prüfen.

Ausnahmen so eng wie nötig anlegen

Unter Add new exception die Paths, Sources, Operation und konkret zu überspringenden Prüfungen festlegen. Ausnahme-Pfade sind case-sensitive und erlauben Wildcards, beispielsweise /products/*/images/*. Das unterscheidet sie von den wildcardfreien Entry URLs der Static URL Hardening Policy. Bei Operation ist die boolesche Verknüpfung entscheidend: Ein Pfad und eine Quelle gemeinsam treffen enger zu als ein Pfad oder eine Quelle. Die gewünschte Schnittmenge vor dem Speichern kontrollieren, damit eine Partnerquelle nicht versehentlich für alle Pfade vom Schutz ausgenommen wird.

Für Sources einer Ausnahme sind IP-Adressen, Bereiche, Listen und Netze dokumentiert. Das darf nicht auf andere Felder übertragen werden: Bei SFOS-22-Path-specific routing sowie bei den SFOS-23-Passthrough-Feldern Allowed client networks und Blocked client networks sind nur Hosttypen IP und Network dokumentiert, keine IP ranges oder IP lists. Für eine vorhersehbare Zugriffsbeschränkung dort einzelne IP- oder Netzwerkobjekte verwenden.

Die Schalter einer Ausnahme überspringen unter anderem Cookie signing, Static URL hardening, Form hardening, Antivirus, Block clients with bad reputation und ausgewählte Common-Threat-Kategorien. Zwei Optionen benötigen zusätzliche Vorsicht:

Never change HTML during static URL hardening or form hardening verhindert das Umschreiben der HTML-Seite, etwa wenn die Anwendung auf unveränderte Links angewiesen ist. Daraus folgt nicht automatisch, dass die nicht signierten Links akzeptiert werden; dazu kann eine gezielte Hardening-Ausnahme nötig sein.
Accept unhardened form data akzeptiert Formulardaten ohne Hardening-Signatur. Eine Form hardening-Ausnahme allein tut das nicht. Diese zusätzliche Freigabe entfernt eine weitere Prüfung und ist nur für einen genau eingegrenzten, begründeten Ablauf geeignet.

Vorher den fehlerhaften legitimen Request, Zeitpunkt und die belegte Rule ID sichern. Nachher denselben Request wiederholen und eine nicht ausgenommene Quelle beziehungsweise einen nicht ausgenommenen Pfad gegenprüfen. Die Ausnahme ist erst sinnvoll eingegrenzt, wenn der notwendige Ablauf funktioniert und der übrige Schutz erhalten bleibt; im Zweifel eine einzelne belegte Rule ID unter Skip filter rules statt eines ganzen Schutzbereichs ausnehmen.

Migrierte Protection Policies neu abnehmen

Seit SFOS 18 verwendet Web Server Protection das OWASP ModSecurity Core Rule Set 3.0. Bei der Migration älterer Protection Policies wurden frühere Kategorien zusammengeführt, Regel-IDs neu zugeordnet und Filtering Strengths eingeführt. War eine der zusammengeführten Kategorien vorher aktiv, kann deshalb auch die neue gemeinsame Kategorie aktiv sein, selbst wenn ein anderer Teilbereich zuvor ausgeschaltet war.

Nach einem solchen Upgrade genügt es nicht, nur den Namen der Policy zu vergleichen. Die aktivierten Kategorien, Ausnahmen und Filtering Strengths müssen gegen die alte Dokumentation geprüft werden. Danach folgen kontrollierte Positiv- und Negativtests mit echtem Anwendungstraffic sowie die Kontrolle von Log Viewer und reverseproxy.log. Erst wenn legitime Requests weiterhin funktionieren und erwartete Testangriffe erkannt werden, ist die migrierte Policy abgenommen.

Für die alte SFOS-18-Migration sind folgende Zuordnungen wichtig: Protocol violations, Protocol anomalies, Request limits und HTTP policy wurden zu Protocol enforcement; Generic attacks und Tight security zu Application attacks; Bad robots zu Scanner detection; Outbound zu Data leakage. Rigid filtering migriert zu Level 1 und muss bewusst neu bewertet werden. Die Kategorie Trojans entfiel; Antivirus übernimmt den entsprechenden Schutz. Bereits ausgenommene Regeln mit einer zugeordneten neuen Rule ID bleiben ausgenommen, während nicht zugeordnete, entfernte oder in eine neue Regel zusammengeführte IDs aus der Skip-Liste entfernt werden. Deshalb die alte Ausnahme-Liste nicht ungeprüft kopieren, sondern gegen die aktuelle Policy und aktuelle Logs vergleichen.

Path-specific routing, WebSocket und Load Balancing

WAF kann Anfragen je nach Pfad an unterschiedliche Backend-Server weiterleiten. Das ist nützlich, wenn eine Anwendung mehrere Komponenten hat oder ein einzelner Hostname auf mehrere interne Dienste verteilt werden soll.

Beispiele:

/api/ geht an einen API-Server.
/shop/ geht an ein Shop-System.
/ geht an den Standard-Webserver.

Die Firewall bewertet Pfade nicht nach Tabellenreihenfolge, sondern priorisiert längere und damit spezifischere Pfade vor der Auffangroute. Diese Zuordnung muss gezielt getestet werden. Nur für SFOS 22: Für den benötigten Website-Pfad kann die Checkbox WebSocket passthrough aktiviert werden; WebSocket-Traffic wird dabei ohne WAF-Schutz durchgereicht, da sich die WebSocket-Daten nicht wie normaler HTTP-Traffic prüfen lassen. Für SFOS 23: Unter Traffic routing ausschliesslich den erforderlichen WebSocket-Pfad mit Action > Passthrough und dem vorgesehenen Backend konfigurieren. Dieser Tunnel arbeitet ohne WAF-Inspektion und ohne Schutzpolicy; die übrigen Anwendungspfade bleiben auf Protect. Niemals das gesamte Portal als Workaround auf Passthrough umstellen. Verbindungs-Upgrade, Datenübertragung und Wiederverbindung separat testen. Daraus lässt sich keine Aussage zur MFA-Durchsetzung von Passthrough ableiten; bei erforderlicher Authentifizierung die Zuständigkeit mit dem Authentifizierungsverantwortlichen klären.

Nur für SFOS 22: Beim Verfahren mit Protected servers leitet der Default-Pfad / Anfragen ohne spezifischere Übereinstimmung an den zugewiesenen Standardserver weiter. Wird diese Default-Route entfernt, weist die Firewall solche Anfragen mit 404 Not Found ab. Für SFOS 23: Anfragen ohne spezifischere Übereinstimmung verwenden die Aktion von /; bei neuen Regeln ist das standardmässig Block. Diese Auffangroute bewusst beibehalten, wenn nur einzelne Pfade veröffentlicht werden sollen. Protect für / ist nur bei beabsichtigter Veröffentlichung der gesamten Anwendung sinnvoll und erfordert eine Prüfung der zusätzlichen Erreichbarkeit. Für SFOS 23 ist kein fester 404-Status zugesichert: Die Antwort von Block wird über Response code konfiguriert.

Bei mehreren Backend-Servern sind Sticky Sessions oder Hot-standby möglich. Das hilft bei einfachen Hochverfügbarkeits- oder Lastverteilungsfällen, ersetzt aber kein vollständiges Applikations-Load-Balancing-Konzept.

Ohne zusätzliche Bindung werden Requests bei mehreren ausgewählten Webservern verteilt. Sticky session cookie bindet den Browser an einen Backend-Server; fällt dieser aus, wird das Cookie aktualisiert und die Sitzung auf einen anderen Server umgestellt. Das garantiert keine Übertragung des Anwendungszustands: Ein Warenkorb kann beispielsweise einen gemeinsamen Session-Speicher benötigen.

Hot-standby mode sendet zunächst alle Anfragen an den ersten ausgewählten Server und nutzt die übrigen als Backup. Nach Rückkehr des Hauptservers wechseln Sitzungen grundsätzlich zurück; mit aktiviertem Sticky session cookie bleibt die bestehende Sitzung auf dem Backup. Primärserver, Backup-Reihenfolge, Ausfall, Rückkehr und einen tatsächlich zustandsbehafteten Login- oder Warenkorbvorgang deshalb getrennt abnehmen.

Das Feld Authentication ist auch in der SFOS-23-Tabelle für Passthrough aufgeführt, während die Funktionsübersicht Authentifizierung Protect zuordnet. Diese Dokumentationsspannung wird nicht durch Vermutung aufgelöst. Wenn WAF-MFA erforderlich ist, den geschützten Teil auf Protect und eine explizite Policy stützen; die Abgrenzung und Tests stehen unter WAF-Authentifizierung mit MFA.

Remote WAF-Backends über SD-WAN erreichen

Wenn der geschützte Webserver nicht im lokalen Netz der Firewall steht, sollte man Routing und SD-WAN besonders bewusst prüfen. Für Backends über Standortleitungen, MPLS oder route-based IPsec kann eine passende SD-WAN Route nötig sein, damit die Firewall den Protected Server zuverlässig erreicht und der Rückweg stimmt. Bei route-based IPsec ist zusätzlich wichtig: WAF über route-based IPsec mit Traffic Selectors für Subnetze wird von Sophos nicht unterstützt; Any-to-Any-Verbindungen sind der dokumentierte Ausweg.

Der von Sophos dokumentierte Aufbau beginnt mit einer funktionierenden WAF-Regel und dem erreichbaren route-based Tunnel. Unter Routing > Gateways wird für den entfernten Pfad ein Gateway-Objekt mit der IP der Gegenstelle, dem adressierten XFRM-Interface und einem belastbaren Monitoring-Host hinter der Gegenstelle angelegt. Erst danach entsteht unter Routing > SD-WAN routes die gezielte Route für den WAF-Proxyverkehr:

Unter Routing > Gateways > IPv4 gateway > Add das Gateway anlegen und speichern. Im Beispiel heisst es gw6, verwendet Gateway IP 10.12.13.2 und Interface xfrm1-10.12.13.1. Unter Monitoring condition einen zuverlässig antwortenden Host hinter dem Gateway verwenden; das dokumentierte Beispiel nutzt 10.12.13.2. Diese privaten Adressen und das Interface durch die tatsächliche Tunneladressierung und einen passenden Monitoring-Host ersetzen.
Unter Routing > SD-WAN routes IPv4 und Add wählen, beispielsweise mit Namen SD-WAN_WAF_Portal. Bei Destination networks Any entfernen und die öffentliche WAN-Schnittstelle beziehungsweise Hosted address wählen, über die der Client die WAF-Regel erreicht; im Beispiel #Port1. Das ist bei dieser dokumentierten WAF-Route nicht einfach die private Backend-IP.
Bei Services Any entfernen und den externen Listening Port der WAF-Regel auswählen, im Beispiel TCP 8080. Unterscheidet er sich vom internen Backend-Port, gehört hier ausdrücklich der externe Port hinein. Der nicht standardmässige Port muss auch beim externen Testaufruf berücksichtigt werden.
Unter Link selection settings Primary and Backup gateways auswählen und bei Primary gateway das zuvor angelegte XFRM-Gateway gw6 setzen. Route speichern. Verwenden mehrere Veröffentlichungen dasselbe Gateway, kann dieselbe SD-WAN Route mehrere öffentliche WAN-Adressen und Listening Ports aufnehmen. Für verschiedene Gateways werden getrennte Routen benötigt.

Der SD-WAN-Ablauf verweist auf eine Anleitung zu route-based VPN mit Traffic Selectors; die WAF-Regelreferenz schliesst subnetzbasierte Traffic Selectors jedoch ausdrücklich aus. Für diesen WAF-Anwendungsfall deshalb eine Any-to-Any-Verbindung planen und die Verweisüberschrift nicht als Freigabe für Subnetz-Selector-Konfigurationen verstehen.

Die Abnahme trennt anschliessend die Ebenen: Extern muss die erwartete WAF-Regel treffen; im Log Viewer werden WAF-Regel, Reverse-Proxy-Fehler und Zeitpunkt korreliert; auf der Firewall müssen XFRM-Interface, Gateway-Monitor und SD-WAN Route aktiv sein; der Backend-Server muss die Anfrage empfangen und über den vorgesehenen Pfad antworten. Ein grüner Tunnel allein beweist weder das SD-WAN-Matching noch die Erreichbarkeit des Backends.

WAF-Objekte über die XML API einordnen

Für Automationen gehören Veröffentlichung, Backend und Schutzpolicy zusammen, bleiben aber unterschiedliche Objekte. FirewallRule mit PolicyType HTTPBased enthält HTTPBasedPolicy; RealServers beschreibt den Backend-Webserver und ProtocolSecurity die Protection Policy. Die WAF-Regel referenziert diese Objekte, sie ersetzt ihre Konfiguration nicht. Zugriff, TLS-Prüfung, Secrets, explizite Schreiboperationen und Auswertung des XML-Status erklärt XML API Zugriff sicher begrenzen.

Die folgenden Zuordnungen erklären die SFOS-22-/23-Referenzen, sind aber keine ausführbaren Request-Vorlagen. Vor jedem Schreiben die API help des installierten Builds mit dem vorhandenen Objekt abgleichen, Backup und Rückweg vorbereiten und zuerst eine ungefährliche Leseabfrage prüfen. Bei ungeklärter Syntax, Einheit oder Aktionszuordnung nicht schreiben, sondern die Klärung mit Support veranlassen. Das gilt besonders nach einem Versionswechsel.

Veröffentlichung und Zugriffspfade nicht verwechseln

Name identifiziert die FirewallRule; die Referenz erlaubt höchstens 60 Zeichen, keine Kommas und UTF-8. Position ist Pflicht und nennt Bottom, Top, After oder Before; für die letzten beiden Varianten gehört die benannte Bezugsregel dazu. Für Status nennt die Tabelle Default ON und die Schreibwerte Disable und Enable: Weglassen ist keine sichere Vorbereitung einer ausgeschalteten Veröffentlichung. LogTraffic steht laut Tabelle standardmässig auf Disable; Logging ausdrücklich prüfen. IPFamily bietet im gemeinsamen FirewallRule-Vertrag auch IPv6, doch HTTPBasedPolicy ist ausdrücklich auf IPv4 begrenzt. Netzwerk- und Benutzerregeln werden unter Firewall-Regeln behandelt, nicht als WAF-Payload übernommen.

Im WAF-Teil entsprechen HostedAddress, ListenPort, HTTPS, HTTPSCertificate und Domains/Domain dem öffentlichen Listener. Die Tabelle führt HostedAddress, ListenPort, HTTPS und Domains als Pflichtfelder. ListenPort ist ein Integer von 1 bis 65535; dokumentiert sind 80 bei ausgeschaltetem HTTPS und 443 bei eingeschaltetem HTTPS. Das ist nicht der Backend-Port. RedirectHTTP ist die separate HTTP-Weiterleitung. Den öffentlichen Namen, das Zertifikat und den Listener nach jeder Änderung zusammen prüfen.

Pfadzuordnungen liegen unter HTTPBasedPolicy/AccessPaths/AccessPath. Darin referenziert backend die Webserver-Objekte; allowed_networks, denied_networks, blocked_countries und block_unknown_country beschreiben den Client-Zugriff. stickysession_status und hot_standby gehören zur Sitzungsbindung und Backend-Auswahl. Eine referenzierte Authentication Policy wird im WAF-Authentifizierungsartikel eingeordnet; aus einem vorhandenen Feld folgt keine getestete MFA-Durchsetzung für jede Aktion.

Versionsunterschied: Die SFOS-22-Tabelle beschreibt path als einzelnen String und backend als Pflicht-Array. In SFOS 23 ist path ein Array mit mehreren Werten, während backend als optional geführt wird. Die Pfadwerte sind laut Tabelle auf 63 Zeichen begrenzt und dürfen keine Kommas enthalten. Optional bedeutet hier nicht, dass ein Protect- oder Passthrough-Pfad ohne zugewiesenes Backend sinnvoll veröffentlicht: Die aktuelle UI verlangt für diese Aktionen die Backend-Auswahl, während Block und Redirect kein Backend veröffentlichen.

SFOS 23 ergänzt das kleingeschriebene action mit den erlaubten Werten 0, 1, 2, 3, ausserdem response_code, redirect_protocol, redirect_host, redirect_port und redirect_path. Die Referenz ordnet die vier Zahlen nicht den UI-Aktionen zu. Keine Zuordnung aus Reihenfolge oder Vermutung bauen; die bestätigte Zuordnung für den installierten Build ist Voraussetzung für jede automatisierte Änderung. Das grossgeschriebene Action mit Accept, Drop, Reject steht im Beispiel unter UserPolicy beziehungsweise NetworkPolicy, nicht im WAF-Block. Es ersetzt weder die äussere UI-WAF-Aktion noch AccessPath/action. Für redirect_protocol stehen wörtlich http und https, für redirect_port 1 bis 65535 und für redirect_path höchstens 8192 Zeichen in der Tabelle. response_code ist dort lediglich als Integer beschrieben; die UI-Auswahl oben bleibt für die konkrete Konfiguration massgebend.

Auch das Beispiel ist kein Schema-Beweis: Es mischt path und Path, enthält leere Referenzen und Platzhalter und zeigt HTTPSCertificate sowie LogTraffic nicht vollständig im WAF-Block. SFOS 22 zeigt noch websocket_passthrough; SFOS 23 verwendet das Aktionsmodell. Schreibweise, Verschachtelung, benötigte Felder und Logging deshalb im build-spezifischen Vertrag bestätigen, nicht das Beispiel mechanisch vervollständigen. ProtocolSecurity im WAF-Block referenziert die Schutzpolicy. Die erweiterten Schalter PassHostHeader, RewriteHTML, RewriteCookies und CompressionSupport gehören zu den oben erklärten Reverse-Proxy-Anpassungen; widersprüchliche Beispiel-/Tabellenwerte nicht zu eigenen Enums vereinheitlichen.

Das Beispiel zeigt ausserdem SourceNetworks/Network und ExceptionNetworks/Network, während sein Kommentar alternativ Authentication, AllowFrom, BlockFrom oder AccessPaths nennt. Daraus keine Aliasgleichheit, zulässige Kombination oder Vorrangregel ableiten. Bei Bestandsobjekten mit dieser Zugriffsdarstellung die Struktur und Wirkung im installierten Build klären; bleibt sie ungeklärt, nicht automatisiert schreiben.

Für Ausnahmen liegt ein eigener Block Exceptions/Exception vor. Dort verbinden path, source und op die Bedingungen; die Tabelle nennt für op wörtlich and, or, AND, OR. skipcookie, skipurl, skipform, skipav und skipbadclients überspringen die jeweiligen Prüfungen. Dagegen verhindert skiphtmlrewrite die Änderung passender Inhalte, und skipform_missingtoken erlaubt Formulardaten ohne Hardening-Signatur zusätzlich zur Form-Ausnahme. Die entsprechende Tabellenzeile vertauscht Beschreibung und Default; daraus keinen verlässlichen Default ableiten. Die oben beschriebenen Sicherheitsfolgen beider Optionen bleiben entscheidend. skip_threats_filter_categories verwendet andere Tokens als die Schutzpolicy, beispielsweise application_attacks und data_leakages. Diese Ausnahme-Tokens nicht mit den Anzeigenamen der Policy vertauschen. Der veraltete Beschreibungstext zu früheren Kategorien ist ebenfalls keine Freigabe für alte Tokens. Nach einer Änderung erlaubten Pfad, blockierten Pfad, Auffangroute und eine nicht ausgenommene Anfrage getrennt prüfen.

Die Tabelle beschreibt path für Site-Path-Routen; das Ausnahme-Beispiel zeigt dagegen mehrere path-Elemente innerhalb einer Exception, ohne einen eindeutigen eigenen Tabellenvertrag. Kardinalität und Grenzen von Routing-Pfaden deshalb nicht auf Ausnahmen übertragen. Vor automatisierten Ausnahmeänderungen Struktur, Anzahl und zulässige Werte im installierten Build bestätigen; bei ungeklärtem Vertrag nicht schreiben.

Backend-Vertrag und Timeout sicher prüfen

Bei RealServers sind Name, Host, Port und TimeOut als Pflichtfelder dokumentiert. Name erlaubt höchstens 60 UTF-8-Zeichen ohne Komma. Host ist die Referenz auf ein IP- oder FQDN-Host-Objekt, kein frei austauschbarer öffentlicher WAF-Name. Port reicht von 1 bis 65535, mit API-Default 80; Type nennt wörtlich Plaintext (HTTP) oder Encrypted (HTTPS). Für ein HTTPS-Backend deshalb den tatsächlichen Listener und Port ausdrücklich abgleichen, statt den API-Portdefault zu übernehmen.

Die API beschreibt TimeOut mit Default 300, Bereich 1 bis 65535 und dem Hinweis, dass es nur bei aktiviertem Keep alive gilt. Die GUI erklärt Timeout dagegen als Wartezeit auf Daten zum oder vom Backend und nennt nach Ablauf einen HTTP-502. Das ist eine unterschiedliche Beschreibung, kein Nachweis identischen Verhaltens bei ausgeschaltetem Keep-alive. Für UI-Konfigurationen den oben beschriebenen Datenpausen-Test verwenden; vor einer Automation Abhängigkeit und gespeicherten Wert im installierten Build klären. Keine globale Timeout-Erhöhung daraus ableiten.

Bei KeepAlive zeigt das Beispiel Enable/Disable, die Tabelle aber nur 0 und Enable sowie Default ON. Diese Abweichung nicht still durch ein vermutetes Disable reparieren. DisableReuse nennt Disable und Enable und entspricht Disable backend connection pooling. Vorzustand sichern, geändertes Objekt zurücklesen und erst danach repräsentative Datenübertragung sowie Backend-Logs prüfen. Eine API-Antwort allein belegt weder Backend-Erreichbarkeit noch passende Verbindungseinstellungen.

Schutzpolicy und abhängige Optionen

ProtocolSecurity benötigt laut Tabelle Name, Mode und RequestSizeLimit. Für Name gelten höchstens 60 UTF-8-Zeichen ohne Komma; Mode nennt Monitor und Reject. Die Schalter CookieSigning, StaticUrlHardening und FormHardening entsprechen dem Cookie-, URL- und Form-Schutz oben. PassOutlookAnywhere ist laut Tabelle standardmässig OFF: Die API beschreibt den Exchange-Zugriff nur knapp, während die GUI ausdrücklich den Bypass von Web Server Protection nennt. Ohne begründeten Legacy-Anwendungsfall deshalb ausgeschaltet lassen, nicht als gewöhnlichen Kompatibilitätsschalter behandeln. Bei aktiviertem StaticUrlHardening beschreibt die Referenz EntryURLType mit Manual, SitemapFile, SitemapURL; für den manuellen Fall zeigt das Beispiel EntryURLList/EntryURL, mit mehreren Entry URLs von jeweils höchstens 255 Zeichen. Nicht daraus ableiten, dass die GUI alle API-Varianten identisch anbietet.

Die API-Tabelle führt CookieSigning, StaticUrlHardening, FormHardening, AntiVirus, BlockClientsWithBadReputation und ThreatsFilter jeweils mit Default OFF, ParanoiaLevel mit Default 1. Eine neue oder referenzierte Policy belegt deshalb noch keine aktivierten Schutzprüfungen. Bei Neuanlage die beabsichtigten Schalter ausdrücklich festlegen und zurücklesen. Bei Edit ohne bestätigten Update-Vertrag weder Erhaltung ausgelassener Felder noch Zurücksetzen auf Defaults unterstellen.

Bei aktiviertem AntiVirus werden AVMode (Avira, Sophos, DualScan), Direction (Uploads, Downloads, UploadsAndDownloads), BlockUnscannableContent und LimitScanSize relevant. Der Integer Megabytes hängt zusätzlich von aktiviertem LimitScanSize ab. Das bleibt vom Bodylimit getrennt. SkipRemoteLookups hängt von BlockClientsWithBadReputation ab; die Wirkung der Reputationsprüfung nicht allein aus der knappen API-Beschreibung ableiten.

ThreatsFilter aktiviert den Common threat filter. Dazu gehören ThreatFilters/Filter, ParanoiaLevel mit 1 bis 4 und SkipFilterRules/FilterRules als Liste ganzzahliger Rule IDs. Die zulässigen Filter-Tokens lauten wörtlich Application attacks, SQL injection attacks, XSS attacks, Protocol enforcement, Scanner detection, Data leakages. Der letzte Token unterscheidet sich vom GUI-Namen Data leakage. Nur belegte Fehlalarme gezielt ausnehmen und danach den übrigen Schutz gegenprüfen; Level, Kategorie und Ausnahme sind unterschiedliche Entscheidungen.

RequestSizeLimit bleibt ein Quellenkonflikt: Die API-Tabelle nennt Pflicht, Default 10, die Beschreibung «Megabytes» und einen Integerbereich von 1 bis 1073741824. Die aktuelle GUI dokumentiert dagegen 1 bis 1024 MB, Default 10 MB. Im API-Beispiel fehlt RequestSizeLimit vollständig. Daraus weder eine Byte-/MB-Umrechnung noch einen erweiterten produktiven Grenzwert oder sichere Optionalität ableiten. Für die GUI den dokumentierten MB-Bereich verwenden; einen API-Schreibwert erst nach Bestätigung von Einheit, Bereich und Pflichtfeldverhalten im installierten Build verwenden. Gleiches gilt für den Tabellenbezeichner HSTS Enforcement, der im Beispiel fehlt: keinen XML-Tag aus dem Namen erfinden. XContentTypeOptions beschreibt den MIME-Schutz; gespeicherte Policy-Zuordnung und tatsächliche Header extern kontrollieren.

XML-Antworten nach Operation unterscheiden

Die folgenden Zahlen sind XML-Objektstatus, nicht HTTP-Statuscodes. Message.* bezeichnet hier einen unaufgelösten Symbolnamen aus der Referenz, keine übersetzte Fehlermeldung und keinen Beweis für eine genaue Ursache. Antwort, Operation und gespeicherten Objektzustand zusammen prüfen; bei Fehlern, Warnungen oder möglicher Teiländerung niemals blind erneut schreiben. Die zentrale API-Sicherheitsanleitung erklärt den sicheren Prüf- und Eskalationsweg.

Für die WAF-relevanten Antworten von FirewallRule sind insbesondere diese Unterschiede wichtig:

Add firewall rule: 200 → Message.FWRuleAddSuccess, 500 → Message.FWRuleAddFail, 502 → Message.FWRuleRecordExists. Edit firewall rule: 200 → Message.FWRuleEditSuccess, 202 → Message.FirewallRuleUpdateWithRename, 500 → Message.FWRuleEditFail, 502 → Message.FWRuleUpdateRecordExist. Bei 202 auch Objektname und Referenzen nachlesen, nicht nur den alten Namen erneut verwenden.
Add firewall rule 541 → Message.VHIPRangeConflict. Edit firewall rule 541 hat dagegen Message.FWRuleFailMaxUser; derselbe Code darf nicht dieselbe Diagnose auslösen.
Add firewall rule 543 und Edit firewall rule 544 → Message.CannotSetupRedirectionFromHTTP. Add firewall rule 544 und Edit firewall rule 543 → Message.CannotUseDefaultPort. Die Zuordnung ist zwischen Add und Edit vertauscht: Listener, Port und Weiterleitung prüfen, nicht allein nach der Zahl klassifizieren.
Bei Add firewall rule und Edit firewall rule: 542 → Message.CannotUseTypeHTTP, 545 → Message.PortAlreadyExists, 546 → Message.CannotConfigureDomainWithAddrTypePort, 550 → Message.PortUsedInUserPortal, 553 → Message.CannotConfigureDomainWithHTTPSRedirection. Die vorhandene Listener-/Domain-Konfiguration abgleichen; Portfreigaben nicht auf Verdacht ändern.
Bei beiden Operationen: 547 → Message.warn_update_business_policy; 548 und 549 verwenden beide Message.MaxIPv4ForAppServerAllowed. Die doppelte Symbolzuordnung belegt keine unterschiedlichen erfundenen Limits. Warnung und tatsächlich gespeicherten WAF-Zustand prüfen.
Add firewall rule 554 → Message.CannotUseFQDNWildCardAsProtectedServer; Edit firewall rule 554 → Message.CannotUpdateFQDNWildCardAsProtectedServer. Öffentliche Wildcard-Domains nicht mit einem geeigneten Backend-Host verwechseln. Edit firewall rule 552 → Message.CannotImportDiffPolicytypeWithSameName: Name und Policy-Typ prüfen, nicht ein fremdes Objekt überschreiben.
Bei Add, Edit und Delete firewall rule: 596 → Message.CMLOCALOperationrestriction. Für Delete stehen ausserdem 200 → Message.FWDelSuccess und 500 → Message.FWRuleDeleteFail. Verwaltungszuständigkeit und Referenzen vor einem erneuten Versuch klären. Die Delete-Seite bezeichnet Name als optional und verwendet einen unpassenden Beschreibungstext zu Before/After; das ist keine sichere Löschvorlage. Das genaue Ziel und den build-spezifischen Remove-Vertrag bestätigen, sonst nicht löschen.

Auch Backend und Schutzpolicy haben eigene Antwortreihen: Add Web Server 200/500/502 stehen für Message.RealServerAddSuccess/Message.RealServerAddFail/Message.RealServerRecodExist; Update Web Server 200/500 für Message.RealServerUpdateSuccess/Message.RealServerUpdateFail. Add Protection Policy 200/500/502 stehen für Message.ProtocolSecurityAddSuccess/Message.ProtocolSecurityAddFail/Message.ProtocolSecurityRecodExist; Edit Protection Policy 200/500 für Message.ProtocolSecurityUpdateSuccess/Message.ProtocolSecurityUpdateFail. Die Schreibweisen RecodExist sind wörtlich erhalten, nicht korrigierte Symbolnamen. Bei Namenskollisionen zuerst das vorhandene Objekt lesen; ein Delete-and-recreate ist kein sicherer Standard-Retry.

Für das globale Objekt WAFSlowHTTP entsprechen RequestHeaderTimeoutEnabled, RequestHeaderTimeoutSoftLimit, RequestHeaderTimeoutHardLimit und RequestHeaderTimeoutExtensionRate dem Schalter und den oben erklärten drei Limits. Alle vier sind als Pflichtfelder dokumentiert; der Schalter nennt Disable und Enable, die übrigen Werte sind Integer ohne angegebenen Bereich. NetworkExceptions/Host ist eine optionale Liste von Hostreferenzen. Die Beispielwerte 10, 30, 5000 sind keine nachgewiesenen Defaults. SlowHTTP Protection nennt 200 mit Operation Successful. und 500 mit Operation Fail.. Änderungen bleiben global: gespeicherte Werte und enge Ausnahmen prüfen und alle betroffenen Veröffentlichungen mit langsamen legitimen Clients abnehmen.

Betrieb und Troubleshooting

Im Betrieb zählt, ob die Veröffentlichung nachvollziehbar bleibt: welche Regel matched, welche Logs relevant sind, welche Ausnahmen existieren und wie man bei Störungen vorgeht.

Typische Fehler

Öffentlicher DNS-Name zeigt auf die falsche IP: Die WAF-Regel wird nie erreicht.
Zertifikat passt nicht zum Hostnamen: Browser zeigen Zertifikatsfehler oder SNI-Matching passt nicht.
Falsche Hosted address gewählt: Die Firewall matched eine andere Regel oder keinen WAF-Traffic.
Allowed client networks leer: Die Regel funktioniert nicht wie erwartet.
WAF-Regellimit nicht beachtet: Weitere Veröffentlichungen lassen sich nicht mehr sauber abbilden.
Exchange-Version nach 2013 mit WAF-Template geplant: Die Vorlage passt nicht zur unterstützten WAF-Grenze.
Portkonflikt mit User Portal, VPN Portal oder anderem Dienst: Die Anwendung ist nicht erreichbar oder ein Firewall-Dienst reagiert.
Backend ist intern nicht erreichbar: Externe Clients erhalten Fehler, obwohl DNS und Zertifikat stimmen.
Backend-Timeout falsch gesetzt: Lange Antworten enden mit Fehlern, obwohl die Anwendung grundsätzlich erreichbar ist.
Backend liegt über VPN oder SD-WAN ohne passende Route: Die WAF-Regel matched, aber der Protected Server wird nicht zuverlässig erreicht.
Route-based IPsec mit Traffic Selectors zum Backend: WAF über diesen Pfad ist nicht unterstützt.
WAF-Ausnahme zu breit gesetzt: Die Schutzwirkung sinkt unnötig.
WebDAV-Anwendung über WAF veröffentlicht: Die Anwendung funktioniert nicht zuverlässig oder wird nicht unterstützt.
URL-Pfad enthält %2F: Die WAF antwortet mit 404 Not Found, obwohl die Ressource direkt auf dem Backend erreichbar ist. %2F ist die URL-codierte Schreibweise für einen Slash / und muss von einem normalen Backend-404 unterschieden werden.
Regeländerung ohne Wartungsfenster: Bestehende Verbindungen können beim Neustart der WAF-Regeln abbrechen.
Alte DNAT-Regel und neue WAF-Regel konkurrieren: Es ist unklar, welche Veröffentlichung den Traffic verarbeitet.

Troubleshooting

Wenn eine WAF-Veröffentlichung nicht funktioniert, sollte man systematisch prüfen:

Zeigt der öffentliche DNS-Name auf die richtige öffentliche IP?
Ist die richtige Hosted address in der WAF-Regel ausgewählt?
Ist der Listening Port frei und nicht durch WebAdmin, User Portal, VPN Portal oder eine andere Veröffentlichung belegt?
Passt das Zertifikat zum aufgerufenen Hostnamen?
Ist der interne Webserver von der Firewall aus erreichbar?
Sind Allowed client networks, Blocked client networks und Blocked countries korrekt gesetzt?
Liegt der Protected Server über eine Route, SD-WAN Route oder VPN-Verbindung, die aus Sicht der Firewall wirklich passt?
Gibt es eine allgemeinere WAF-Regel, die vorher matched?
Wird der Zugriff im Log Viewer als erlaubt, blockiert oder verworfen angezeigt?
Gibt es Hinweise in /log/reverseproxy.log?
Ist die Protection Policy auf Monitor oder Reject gesetzt?
Passt der Timeout des Webserver-Objekts zur Anwendung?

Für die erste Analyse ist der Log Viewer sinnvoll. Für tieferes Troubleshooting helfen die Web Server Protection Logs auf der Firewall. Eine Übersicht zu Logdateien und Diensten steht in Sophos Firewall Troubleshooting: Services und Logs.

WAF antwortet bei `%2F` im Pfad mit 404

Ein spezielles Fehlerbild betrifft URLs mit einem codierten Slash. Ein Aufruf wie https://portal.example.com/api/files/project%2Freport.pdf kann über die Sophos WAF 404 Not Found liefern, obwohl die Ressource direkt auf dem Backend existiert. Sophos führt dieses Verhalten unter NC-159041 und nennt derzeit weder eine bestimmte betroffene oder behobene SFOS-Version noch einen unterstützten Workaround.

Für die Eingrenzung sollte derselbe Aufruf kontrolliert über die WAF und direkt am Backend verglichen werden. Dabei sind die exakte URL und der Testzeitpunkt wichtig:

Prüfen, ob der Pfad tatsächlich %2F enthält. Ein normaler Slash / oder ein fehlender Default-Pfad ist ein anderes Fehlerbild.
Den Zeitpunkt im Log Viewer, in /log/reverseproxy.log und im Access-Log des Webservers vergleichen.
Erscheint zur Anfrage kein passender Eintrag am Backend, wurde sie wahrscheinlich bereits vor dem Webserver abgewiesen. Mit einem direkten Backend-Test lässt sich gleichzeitig ausschliessen, dass die Ressource selbst fehlt.

Eine breite WAF-Ausnahme hilft hier nicht gezielt und würde den Schutz unnötig reduzieren. Auch die von SFOS verwaltete Apache-Konfiguration sollte nicht verändert werden: Die restriktive Behandlung codierter Slashes schützt davor, dass Pfad- oder Zugriffskontrollen umgangen werden.

Am saubersten ist es, wenn die Anwendung oder der Hersteller URLs ohne codierte Slashes erzeugt. Ist das nicht möglich, muss eine andere Veröffentlichungsart wie DNAT, ein dafür geeigneter Reverse Proxy oder privater Zugriff bewusst gegen den wegfallenden WAF-Schutz abgewogen werden. Für unveränderbare Anwendungen sollte Sophos Support den konkreten SFOS-Build und den Anwendungsfall prüfen. Die Schreibweisen project%2Freport.pdf und project/report.pdf sind dabei nur ein Erkennungsmuster und nicht automatisch funktional gleich.

Checkliste für produktive WAF-Regeln

Regelname beschreibt Anwendung, Hostname und Umgebung.
Verantwortliche Person oder Systemowner ist dokumentiert.
DNS, Zertifikat und Hosted address sind geprüft.
Backend-Erreichbarkeit wurde von der Firewall aus getestet.
Vorherige Veröffentlichung und Rollback sind dokumentiert.
Alte DNAT- oder Firewall-Regeln konkurrieren nicht mit der WAF-Regel.
Externe Go-live-Tests sind definiert.
Zugriff ist auf notwendige Quellen oder Länder beschränkt.
Threat Feeds und Active Threat Response wurden für öffentliche Anwendungen bewertet.
Logging ist aktiv.
Schutzprofil ist nicht unnötig deaktiviert.
Ausnahmen sind eng, begründet und befristet.
Änderung wurde extern getestet.
Ablaufdatum oder Review-Termin ist dokumentiert.

Häufige Fragen

Ersetzt WAF das Patchen des Webservers?

Nein. WAF kann Angriffe erkennen oder blockieren, aber keine unsichere Anwendung dauerhaft kompensieren. Betriebssystem, Webserver, Frameworks, Plugins und Anwendungscode müssen weiterhin gepflegt werden.

Braucht man zusätzlich DNAT?

Für dieselbe Webveröffentlichung normalerweise nicht. Die WAF-Regel übernimmt die Veröffentlichung über die Hosted address und leitet an den geschützten Webserver weiter. DNAT bleibt für andere Protokolle oder nicht unterstützte Webanwendungen relevant.

Warum sieht der Webserver nicht die echte Client-IP?

Die Firewall arbeitet als Reverse Proxy. Der Webserver sieht deshalb häufig die Firewall als Quelladresse. Die ursprüngliche Client-IP steht im Header X-Forwarded-For, sofern die Anwendung oder der Webserver diesen Header auswertet.

Kann man mehrere Websites über dieselbe öffentliche IP veröffentlichen?

Ja, bei HTTPS verwendet die Firewall SNI und den Hostnamen, um die passende WAF-Regel beziehungsweise den passenden virtuellen Webserver zu wählen. DNS, Zertifikat und Domains in der WAF-Regel müssen dafür sauber zusammenpassen.

Sollte man WAF für Nextcloud verwenden?

Nicht ohne sorgfältige Prüfung. WebDAV ist als nicht unterstützter WAF-Fall dokumentiert. Da Nextcloud WebDAV intensiv nutzt, ist eine Veröffentlichung über WAF in vielen Umgebungen nicht passend.

Schützen Threat Feeds auch WAF-Regeln?

Unter SFOS 22 können Threat Feeds auch für eingehenden, weitergeleiteten Traffic wie WAF- und DNAT-Veröffentlichungen relevant sein. Damit daraus echter Schutz entsteht, müssen Feeds, Logging, Alarme, Zuständigkeit und False-Positive-Prozess aber sauber betrieben werden.