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.

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.

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.

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:

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.

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.

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:

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.

Grundaufbau einer WAF-Regel

Eine WAF-Veröffentlichung besteht aus mehreren Bausteinen:

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

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. Bei Action die Option Protect with web server protection wählen.
6. Falls keine spezielle Vorlage benötigt wird, Preconfigured template auf None lassen.
7. Unter Hosted server details die öffentliche Adresse, den Listening Port, HTTPS, Zertifikat und Domains definieren.
8. Unter Protected servers den internen Webserver auswählen oder neu erstellen.
9. Allowed client networks bewusst setzen. Für öffentliche Websites kann Any IPv4 nötig sein, für Portale ist eine Einschränkung meist besser.
10. Bei Bedarf Blocked client networks oder Blocked countries setzen.
11. Schutzprofil, IPS und erweiterte Optionen prüfen.
12. 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.

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.

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.

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.
• Bei mehreren Hostnamen auf derselben IP nutzt die Firewall SNI.
• Wildcard-Zertifikate sind möglich, sollten aber sauber dokumentiert 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.

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

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. Spezifische Pfade müssen 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.

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.

Typische Fehler

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. Gibt es eine allgemeinere WAF-Regel, die vorher matched?
8. Wird der Zugriff im Log Viewer als erlaubt, blockiert oder verworfen angezeigt?
9. Gibt es Hinweise in /log/reverseproxy.log?

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