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.

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.

WAF-Regeln sind ausserdem auf IPv4-Veröffentlichungen ausgerichtet. Wenn eine Anwendung zwingend über IPv6 veröffentlicht werden soll, muss das Design separat geprüft werden. 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.

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 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 rules

Vorgehen:

1. IPv4 auswählen.
2. Add firewall rule öffnen.
3. New firewall rule auswählen.
4. Einen sprechenden Regelnamen vergeben.
5. Rule position bewusst setzen, besonders wenn bereits allgemeinere WAF-Regeln oder alte Veröffentlichungen existieren.
6. Bei Action die Option Protect with web server protection wählen.
7. Falls keine spezielle Vorlage benötigt wird, Preconfigured template auf None lassen.
8. Log firewall traffic aktivieren, wenn die Regel im Log Viewer und in Reports nachvollziehbar sein soll.
9. Unter Hosted server details die öffentliche Adresse, den Listening Port, HTTPS, Zertifikat und Domains definieren.
10. Unter Protected servers das passende Webserver-Objekt auswählen oder vorher unter Web server > Web servers anlegen.
11. Allowed client networks bewusst setzen. Für öffentliche Websites kann Any IPv4 nötig sein, für Portale ist eine Einschränkung meist besser.
12. Bei Bedarf Blocked client networks oder Blocked countries setzen.
13. Schutzprofil, IPS und erweiterte Optionen prüfen.
14. Regel speichern und extern testen.

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. WAF kann je nach Hosted address denselben Port wie SSL VPN verwenden, aber nicht denselben Port wie das User Portal. Wenn auf einer öffentlichen IP bereits WebAdmin, VPN Portal, User Portal oder eine alte DNAT-Veröffentlichung lauscht, muss die Zuordnung eindeutig sein. Sonst sieht der Fehler später wie ein WAF-Problem aus, obwohl eine andere Funktion antwortet.

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

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.

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.

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.

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.

Dabei sollte man beachten, dass die Firewall Pfade nicht einfach nach Tabellenreihenfolge bewertet. Sophos priorisiert längere und damit spezifischere Pfade. Spezifische Pfade müssen deshalb sauber geplant und getestet werden. Wenn WebSocket benötigt wird, kann WebSocket passthrough aktiviert werden. WebSocket-Traffic wird dann ohne dieselbe WAF-Prüfung durchgereicht, weil das Protokoll nicht gleich geprüft werden kann wie normaler HTTP-Traffic.

Der Default-Pfad / sollte bewusst gesetzt bleiben. Wenn er entfernt wird, werden nicht passende Pfade nicht an einen Standardserver weitergeleitet, sondern mit 404 Not Found abgewiesen. Das kann gewollt sein, wirkt im Fehlerfall aber schnell wie ein Backendproblem.

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.

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.

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.
• 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:

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

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