Sophos Firewall v23: Überblick und alle neuen Features

Sophos Firewall v23 greift viele Aufgaben auf, die im Firewall-Alltag Zeit kosten: Regeln durchsuchen, Benutzer richtig zuordnen, Updates planen und herausfinden, warum ein Cluster umgeschaltet hat. Die neue Hauptversion bringt dafür eine REST API, einen KI-Assistenten sowie Erweiterungen für WAF, DNS und DHCP.

Hinweis zum Release-Stand: Wie in den vergangenen Jahren startet die nächste Hauptversion mit einer Early-Access-Phase von Sophos Firewall v23 rund um den Oktober, dieses Jahr bereits am 28. September 2026. Dieser Beitrag basiert auf dem EAP1-Stand. Bis zur finalen Version können sich einzelne Funktionen und Details noch ändern. Für den Testpfad ist eine aktuelle Grenze wichtig: Von SFOS 22.0 MR3 Build 576 ist ein Upgrade auf 23.0 EAP1 nicht möglich. Vor einem v23-Piloten muss deshalb der genaue Ausgangs- und Zielbuild geprüft werden. Den Versionspfad und die übrigen Blocker erklärt der SFOS-22-Upgrade-Check.

Ein Teil der Neuerungen ist direkt auf der Firewall verfügbar, andere Funktionen benötigen Sophos Fusion oder zusätzliche Software. Besonders wichtig für die Planung: Die neue Benutzererkennung über Synchronized Security setzt Sophos Endpoint auf den betreffenden Geräten und eine passende Endpoint-Lizenz voraus. Wer bisher nur Microsoft Defender oder einen anderen Endgeräteschutz einsetzt, erhält diese Funktion also nicht allein durch das Firewall-Update, sondern müsste Sophos Endpoint zusätzlich einführen und lizenzieren. Bei bereits vorhandenen Sophos-Lizenzen hängt der zusätzliche Aufwand vom bestehenden Vertrag ab. Die Voraussetzungen der übrigen Funktionen erklären wir in den jeweiligen Abschnitten.

KI und Automatisierung

REST API: Firewall-Konfiguration automatisieren

Mit der neuen REST API können Skripte und Verwaltungswerkzeuge die Konfiguration direkt auf der Firewall lesen und bearbeiten. Die Anmeldung erfolgt über API-Schlüssel. Eine Beschreibung im OpenAPI-3.0-Format dokumentiert die verfügbaren Aufrufe und Datenfelder, sodass sich die Schnittstelle leichter in bestehende Werkzeuge integrieren lässt. Der Zugriff erfolgt auf die Firewall selbst und ist unabhängig von der Sophos Central API für Konfigurationsexporte und -importe.

Gemeinsame Einstellungen über mehrere Firewalls zu verteilen, war bereits eine zentrale Idee von Sophos Central Firewall Management. Über Firewall-Gruppen und übergeordnete Richtlinien sollen sich solche Änderungen zentral verwalten lassen. In unserer Praxis funktioniert das allerdings nur teilweise so, wie wir es für einen verlässlichen Betrieb benötigen. Bei wiederkehrenden Änderungen verlassen wir uns deshalb lieber auf eigene Skripte und Prozesse, deren Ablauf und Ergebnis wir selbst kontrollieren können. Genau dafür ist die neue REST API eine hilfreiche Ergänzung.

Ein Beispiel sind Netzwerkobjekte für einen neuen Server, die auf mehreren Standort-Firewalls benötigt werden. Ein Skript kann zuerst prüfen, ob das Objekt bereits existiert, nur die nötige Änderung ausführen und danach den gespeicherten Wert nochmals auslesen. Im Protokoll bleibt nachvollziehbar, welche Firewall erfolgreich aktualisiert wurde und wo nachgearbeitet werden muss. Das ist besonders dann hilfreich, wenn ein Standort während der Änderung nicht erreichbar ist und später gezielt nachgezogen werden soll.

API-Schlüssel verwaltet man unter Administration > API access. Sie erben die Berechtigungen des zugehörigen Administrators. Für Automationen empfiehlt sich deshalb ein eigenes Konto mit einem passenden Berechtigungsprofil. Auch die erlaubten Quelladressen und der Managementzugriff müssen stimmen. Der Zugriff sollte auf die Systeme beschränkt bleiben, die ihn für ihre Verwaltungsaufgaben tatsächlich benötigen.

Allowed IP hosts: Auch in v23 lassen sich hier nur IP-Adressen oder Netzwerke freigeben. Ein FQDN, also ein vollständiger DNS-Name, ist weiterhin nicht möglich. Für einen Automationsserver mit fester Ausgangs-IP ist das unproblematisch. Läuft das Skript aber hinter einem Anschluss mit wechselnder öffentlicher IP-Adresse, kann man dessen DNS-Namen nicht einfach als erlaubte Quelle hinterlegen. Dann braucht es beispielsweise einen festen Ausgangspunkt oder einen kontrollierten VPN-Zugang. Gerade für eine Schnittstelle, die Automatisierung erleichtern soll, hätten wir uns hier mehr Flexibilität gewünscht.

Den REST API guide öffnet man in der WebAdmin-Oberfläche unter Administration > API access. Der Link steht rechts oberhalb der Liste mit den API-Schlüsseln, direkt neben OpenAPI.yaml. Die öffentliche Sophos Firewall API Reference beschreibt die Endpunkte, Datenfelder und den Einstieg in die Authentisierung. Für die konkrete Implementierung ist die OpenAPI-Datei des installierten Firewall-Builds massgebend. Vor dem Ablösen bestehender XML-Automationen sollte man prüfen, ob die benötigten Funktionen vollständig abgedeckt sind. Fehlerbehandlung, Protokollierung und ein getesteter Rückweg gehören auch bei einer modernen API dazu.

KI-Assistent für Firewall-Regeln

Der neue Assistent in Sophos Fusion beantwortet Fragen zu Firewall-Regeln. Regelentwürfe legt er deaktiviert am Tabellenende an; die Freigabe bleibt beim Administrator.

Das ist ein sinnvoller Ansatz für die Zusammenarbeit mit KI. Eine Anfrage wie «Erstelle einen Entwurf für HTTPS-Zugriff vom Mitarbeiternetz auf den internen Webserver» kann Vorarbeit leisten. Vor dem Aktivieren muss trotzdem klar sein, welche konkreten Objekte gemeint sind, ob Benutzer eingeschränkt werden sollen und welche Sicherheitsprüfungen dazugehören.

Besonders wichtig ist die Regelposition. Eine fachlich korrekte Freigabe kann wirkungslos bleiben, wenn vorher bereits eine andere Regel greift. Umgekehrt kann eine zu weit oben platzierte Regel mehr Verkehr erlauben als vorgesehen. Der Assistent nimmt einem die Sicherheitsentscheidung daher nicht ab. Sein Wert liegt darin, die Arbeit am Regelwerk vorzubereiten und die Suche nach Zusammenhängen zu erleichtern.

KI-Dienste gezielt erlauben oder sperren

Zur Kontrolle von KI-Nutzung kommen die Webkategorie Generative AI und Anwendungsfilter im Umfeld von Sophos AI Defense hinzu.

Sophos AI Defense ist seit 13. Oktober 2026 allgemein verfügbar, aber ein separates kostenpflichtiges Add-on für qualifizierende EDR-, XDR- und MDR-Kunden. Ein Firewall-Update auf v23 oder eine sichtbare Generative-AI-Kategorie allein schaltet diesen Anspruch nicht frei. Das dokumentierte Setup setzt ein auf Security Operations aktualisiertes Fusion-Konto und Sophos EDR Endpoint Protection voraus. Für die Einbindung einer Firewall kommen Gruppenverwaltung und Web-Policy-Logging hinzu; eine ausgewählte Datenquelle beweist noch keine wirksame Durchsetzung. Berechtigung, Sensoranforderungen und Pilotprüfung erklärt unsere Anleitung zu Sophos AI Defense.

Unter Diagnostics > URL category lookup lässt sich die Einstufung einer Domain nachschlagen. Bei openai.com zeigt die Firewall die Kategorie Generative AI an. Das hilft bei der Fehlersuche: Wird ein KI-Dienst unerwartet gesperrt, kann man zuerst seine Kategorie prüfen und danach die zutreffende Webrichtlinie kontrollieren.

Für Unternehmen beginnt die sinnvolle Konfiguration mit einer einfachen Entscheidung: Welche KI-Dienste sind für welche Arbeit zugelassen? Eine Entwicklungsabteilung benötigt möglicherweise andere Werkzeuge als die Buchhaltung. Erst daraus lässt sich eine brauchbare Netzwerk-Richtlinie ableiten.

Eine erlaubte Domain sagt allerdings noch nichts darüber aus, welche Informationen dort eingegeben werden dürfen. Zugangskontrolle und Datenschutz sind unterschiedliche Aufgaben. Auch bei einem freigegebenen Dienst braucht es Regeln für Kundendaten, Quellcode und vertrauliche Dokumente. Netzwerkfilter können diese organisatorischen Vorgaben unterstützen, ersetzen aber keine inhaltliche Prüfung jedes Prompts.

Regelverwaltung und Bedienung

Neue Tabelle für Firewall-Regeln

Die Ansicht unter Rules and policies > Firewall rules wurde grundlegend überarbeitet. Statt aufklappbarer Ordner zeigt Sophos die Regeln jetzt in einer durchgehenden Tabelle. Die Gruppierung bleibt erhalten, wird aber in der Spalte Group dargestellt. Dazu kommen Freitextsuche, Filter und eine anpassbare Spaltenansicht.

Das löst einen Ärger aus der bisherigen Oberfläche: Nach dem Bearbeiten und Speichern einer Firewall-Regel klappte die Gruppe wieder zu. Wollte man direkt die nächste Regel derselben Gruppe bearbeiten, musste man den Ordner erneut öffnen. Bei mehreren Anpassungen hintereinander war das unnötig mühsam. Mit der Gruppenzugehörigkeit als Spalte entfällt dieses ständige Aufklappen.

Spalten auswählen und anordnen

Über das Zahnrad rechts oberhalb der Tabelle lässt sich festlegen, welche Spalten angezeigt werden. Man kann nicht benötigte Angaben ausblenden, zusätzliche Details einblenden und die Reihenfolge der Spalten ändern. Ausserdem lassen sich Spalten fixieren. So bleibt beispielsweise der Regelname im Blick, während man eine breite Tabelle durchgeht.

Besonders erfreulich: In unserem Test blieb die gewählte Ansicht auch nach dem Logout und erneutem Login gespeichert. Man muss sich die passende Übersicht also nicht bei jeder Anmeldung neu zusammenstellen.

Für einen schnellen Überblick reichen oft Name, Gruppe, Aktion, Status und Traffic. Bei einer Fehlersuche sind dagegen Quell- und Zielnetze, Dienste und Logging interessant. Soll beispielsweise der Zugriff auf einen alten Applikationsserver entfernt werden, möchte man die Ziele der betroffenen Regeln direkt nebeneinander sehen. Dafür nicht jede Regel einzeln öffnen zu müssen, spart Zeit und erleichtert den Vergleich.

Folgende Spalten stehen zur Auswahl. Die Bezeichnungen entsprechen der englischen Oberfläche; zur besseren Übersicht sind sie hier thematisch zusammengefasst:

• Regel und Übersicht: Name, Type, Group, ID, Features, Traffic (In/Out), Status, Action, Schedule, Description.
• Netze und Dienste: Src networks, Src zones, Dst zones, Dst networks, Services.
• Benutzer und Protokollierung: Users, Exclude users from accounting, Web authentication for unknown users, Log.
• Schutzfunktionen und Policies: Email, Web policy, IPS policy, Application policy.
• Bandbreite und Priorisierung: Traffic shaping policy, Traffic shaping (applications), Traffic shaping (web category), DSCP marking.
• Security Heartbeat: Source HB, Block client with no source HB, Destination HB, Block client with no destination HB.
• Ausnahmen: Excluded source address, Excluded destination address, Excluded source zone, Excluded destination zone, Excluded service.

Alte Ansicht bleibt vorerst wählbar

Über den Schalter New design kann man noch zur bisherigen Ansicht zurückkehren. Wer mit der neuen Tabelle nicht zurechtkommt, hat damit vorerst eine Ausweichmöglichkeit. Wie lange Sophos beide Ansichten parallel anbieten wird, bleibt offen.

NAT-Regeln: weiterhin keine Gruppierung und kein Klonen

Leider hat Sophos die neue Ansicht nicht auf die NAT-Regeln übertragen. Diese werden auch in v23 weiterhin anders behandelt: NAT-Regeln lassen sich weder gruppieren noch klonen. Bei Firewall-Regeln ist das Klonen möglich, bei NAT-Regeln fehlt diese Funktion nach wie vor.

Gerade beim Veröffentlichen mehrerer ähnlicher Dienste wäre das hilfreich. Wenn für einen weiteren Webserver fast dieselbe Weiterleitung benötigt wird, möchte man eine vorhandene NAT-Regel kopieren und anschliessend Ziel und Dienst anpassen. Stattdessen muss man die Regel erneut anlegen. Das kostet Zeit und erhöht die Gefahr, bei einer der übrigen Einstellungen abzuweichen.

Wir hatten diese Wünsche bereits im Beitrag zu Sophos Firewall v22 angesprochen. Die neue Firewall-Regelansicht ist ein erfreulicher Fortschritt. Umso bedauerlicher ist es, dass die NAT-Verwaltung bei solchen grundlegenden Bedienfunktionen weiterhin zurückbleibt.

WebAdmin, Seriennummer und Clusterstatus

Die WebAdmin-Oberfläche nutzt HTTP/2, um die Übertragung der Seitenelemente zu beschleunigen. Ausserdem bleiben die Seriennummer und der Zustand des HA-Clusters beim Wechsel zwischen den Einstellungsseiten sichtbar.

HTTP/2 kann beim Laden vieler Seitenelemente helfen, insbesondere über Verbindungen mit höherer Latenz. Ob sich dadurch eine konkrete Ansicht schneller anfühlt, hängt aber auch von der Verarbeitung auf der Firewall ab. Eine langsame Datenbankabfrage oder das Speichern einer komplexen Konfiguration wird durch ein anderes Transportprotokoll allein nicht schnell. In meinem ersten Test fiel der Geschwindigkeitsgewinn jedenfalls gering aus: Das Speichern einer Firewall-Regel dauerte weiterhin mehrere Sekunden.

Die sichtbare Geräteidentität hat einen unmittelbar verständlichen Nutzen: Bei mehreren offenen Firewall-Sitzungen lässt sich leichter kontrollieren, auf welchem System man gerade arbeitet. Vor Änderungen an einem HA-Cluster lohnt zusätzlich ein Blick auf Rolle und Zustand der beteiligten Geräte.

Wer im Support mehrere nahezu identische Kundenumgebungen offen hat, kennt die kurze Unsicherheit vor dem Speichern einer Änderung. Eine stets sichtbare Seriennummer erleichtert den Abgleich mit dem Ticket, ohne erst die aktuelle Einstellungsseite verlassen zu müssen. Das ist eine kleine Änderung mit einem sehr konkreten Nutzen.

Hochverfügbarkeit: schneller erkennen, gezielter umschalten

Hardwarezustand als Auslöser

Der HA-Cluster überwacht neben Verbindungen und Diensten nun auch den Zustand bestimmter Hardwarekomponenten. Dazu gehört die SSD. Verschlechtert sich deren Zustand, kann der Cluster auf die andere Firewall umschalten.

Ein HA-Cluster kann nur dann sinnvoll reagieren, wenn er einen Fehler auch erkennt. Ein Gerät kann über seine Netzwerkschnittstellen noch erreichbar sein, obwohl es intern bereits Probleme hat. Die zusätzliche Hardwareperspektive ist deshalb für den Betrieb relevant.

Eine fehlerhafte SSD kann beispielsweise Schreibzugriffe beeinträchtigen, während der HA-Link weiterhin funktioniert. Eine reine Verbindungsüberwachung würde den Zustand des Datenträgers nicht erkennen. Hier setzt die zusätzliche Hardwareüberwachung an, bevor aus einem angeschlagenen Knoten ein vollständiger Ausfall wird.

Nach einer solchen Umschaltung sollte die Ursache trotzdem untersucht werden. Der zweite Knoten erhält den Dienstbetrieb, repariert aber keine defekte SSD. Zum Betriebsablauf gehören deshalb die Prüfung des betroffenen Geräts, die Bewertung der verbleibenden Redundanz und gegebenenfalls ein Hardwareaustausch.

Kürzeres Erkennungsfenster

Die detaillierte HA-Einrichtung für SFOS 23 dokumentiert 100 ms Keepalive-Intervall und drei Versuche, also 300 ms Heartbeat-Timeout statt bisher vier Sekunden. Dieser Setup-Default gilt nicht für jede HA-Link-Topologie: Bei einem LAG oder VLAN über LAG als Dedicated HA link muss der Timeout mindestens 2500 ms betragen. Das betrifft auch den redundanten LAG, den QuickHA bei mehreren ausgewählten ungebundenen physischen Ports erzeugt.

Vor der Upgradeplanung deshalb die tatsächliche HA-Link-Topologie und die konfigurierten Werte beider Nodes prüfen, nicht einen bestehenden Cluster pauschal auf 300 ms umstellen. Die Voraussetzungen und den Prüfweg erklärt Sophos Firewall High Availability einrichten.

Die 300 ms beziehen sich auf die Zeit, bis die Firewall den Ausfall des anderen Geräts im Cluster erkennt. Bis eine Anwendung wieder normal arbeitet, können weitere Schritte nötig sein: Die verbleibende Firewall muss den Betrieb übernehmen, benachbarte Netzwerkgeräte müssen den Verkehr über den richtigen Weg zustellen und bestehende Verbindungen müssen weiterlaufen oder neu aufgebaut werden.

Für einen aussagekräftigen Test sollte man daher mehr als einen Ping beobachten. Eine laufende Telefonverbindung, ein Dateitransfer und ein VPN-Zugriff zeigen unterschiedliche Auswirkungen. Erst solche Messungen beantworten die Frage, ob die Umschaltung für die eigenen Geschäftsprozesse schnell genug ist.

Weniger Fehlumschaltungen bei hoher Last

Die beiden Firewalls tauschen regelmässig kurze Statusmeldungen aus, die sogenannten HA-Heartbeats. Diese Meldungen werden nun bevorzugt und getrennt vom normalen Datenverkehr verarbeitet.

Damit wird ein Problem bei hoher Auslastung angegangen: Wenn ein System stark ausgelastet ist, kann eine verspätete Antwort wie ein Ausfall aussehen. Eine daraufhin ausgelöste Umschaltung bringt zusätzliche Unruhe in eine bereits belastete Umgebung.

Für die Abnahme sind daher beide Situationen interessant: Erkennt der Cluster einen echten Ausfall, und bleibt er bei hoher Last ohne tatsächlichen Geräteausfall stabil? Ein reiner Funktionstest im Leerlauf beantwortet nur die erste Hälfte dieser Frage.

DNS-Sicherheit, Hotfixes und Firmware

DNS over HTTPS und DNSSEC

Die Firewall kann DNS-Anfragen nun über HTTPS verschlüsselt an einen Resolver senden und DNS-Antworten mit DNSSEC überprüfen. Auch Sophos DNS Protection lässt sich einfacher aktivieren.

Die beiden DNS-Techniken lösen unterschiedliche Probleme. DNS over HTTPS, kurz DoH, verschlüsselt den Transport zum Resolver. DNSSEC dient der Prüfung signierter DNS-Daten. Eine verschlüsselte Verbindung allein bestätigt noch nicht die Echtheit einer DNS-Antwort, und eine gültige Signatur verbirgt die Anfrage nicht vor Beobachtern des Transportwegs.

Für die Einführung sollte man zunächst den bestehenden DNS-Weg verstehen. Fragt der Client die Firewall, einen internen Windows-DNS-Server oder direkt einen öffentlichen Resolver? Interne Namensräume müssen weiterhin am richtigen Ort aufgelöst werden. Dafür bleiben beispielsweise DNS Request Routes relevant.

Auch Browser mit eigenen DoH-Einstellungen verdienen Aufmerksamkeit. Wenn ein Client einen anderen Resolver verwendet, entspricht sein tatsächlicher DNS-Weg möglicherweise nicht der zentral vorgesehenen Konfiguration. Ein Funktionstest sollte deshalb sowohl interne Namen als auch externe Auflösung und gewünschte Filterentscheidungen abdecken.

Sichtbare Hotfix- und Sicherheitsupdates

Beim Durchsehen der Oberfläche ist uns noch eine Änderung aufgefallen: Unter Backup & firmware gibt es wieder einen eigenen Bereich für Hotfixes. Die Registerkarte heisst Hotfix: Security updates. Früher befand sich die Hotfix-Einstellung im Bereich Firmware. Dort konnte man über einen Haken festlegen, ob wichtige Hotfixes automatisch installiert werden sollen. Nachdem diese Einstellung aus der Oberfläche verschwunden war, bekommen Hotfixes nun wieder einen sichtbaren Platz.

Dabei geht es in der neuen Ansicht um den Status der Sicherheitsupdates. Der frühere Ein-/Ausschalter ist im gezeigten Bildschirm nicht zu sehen. Auch bedeutet das zwischenzeitliche Fehlen der Einstellung nicht, dass die Firewall keine Hotfixes mehr erhalten hat: Die automatische Installation besteht als Funktion weiterhin.

Wozu Hotfixes dienen

Hotfixes sind gezielte Korrekturen für dringende Probleme, insbesondere Sicherheitslücken. Sie können ausserhalb der regulären Firmware-Veröffentlichungen verteilt werden. Dadurch muss eine wichtige Korrektur nicht warten, bis das nächste Maintenance Release erscheint und im Unternehmen ein vollständiges Firmware-Update eingeplant ist.

Wird beispielsweise eine Schwachstelle in einem Verwaltungsdienst bekannt, kann ein passender Hotfix die betroffene Komponente korrigieren. Die automatische Installation verkürzt dabei die Zeit zwischen der Bereitstellung der Korrektur und ihrer Anwendung auf der Firewall. Sie ist standardmässig aktiviert und sollte im normalen Betrieb eingeschaltet bleiben. Hotfixes ersetzen allerdings keine regulären Firmware-Updates: Diese bringen zusätzlich weitere Fehlerkorrekturen, Änderungen an Komponenten und neue Funktionen mit.

Patchstand direkt nachsehen

Die Oberfläche zeigt nun an, welche Sicherheitslücken durch installierte Hotfixes behoben wurden. Zu jedem Eintrag gehören die CVE-Kennung, der Schweregrad, das Installationsdatum und ein Link zum zugehörigen Sicherheitshinweis. Diese Informationen stehen auch im Reporting zur Verfügung.

Das hilft bei einer häufigen Betriebsfrage: Ist eine konkrete Schwachstelle auf genau dieser Firewall bereits behandelt? Eine Firmware-Versionsnummer ist dafür nicht immer die ganze Antwort, wenn zusätzlich Hotfixes verteilt werden.

Fragt ein Kunde nach einem neuen Security Advisory, lässt sich der lokale Stand damit gezielter belegen. Statt allein aus der Firmware-Version auf den Schutzstatus zu schliessen, kann man die betreffende CVE und das Installationsdatum des Hotfixes nachsehen und im Ticket dokumentieren.

Für die Dokumentation sollte man den angezeigten Patchstand zusammen mit dem zugehörigen Advisory bewerten. Ein installierter Fix beantwortet die Frage nach der betreffenden Korrektur. Er beweist weder, dass das gesamte System sicher konfiguriert ist, noch dass ein früherer Angriff ausgeschlossen werden kann. Dafür bleiben Konfigurationsprüfung, Logauswertung und gegebenenfalls eine Untersuchung nötig.

Wiederkehrende Firmware-Updates

In Sophos Fusion lassen sich wiederkehrende Wartungszeiten festlegen, zu denen Firewalls neue Firmware-Versionen automatisch installieren. Die Geräte müssen dabei nicht alle gleichzeitig aktualisiert werden. Man kann zuerst ausgewählte Firewalls aktualisieren und die übrigen später folgen lassen. Für einzelne Geräte sind abweichende Einstellungen möglich, etwa wenn ein Standort ein eigenes Wartungsfenster benötigt.

Das ist eine Funktion von Sophos Fusion und kein allein durch v23 erfülltes Upgradeversprechen. Die Firewall muss für das Management registriert und online erreichbar sein; Support-/Updateberechtigung und unterstützter Upgradepfad müssen zum Ziel passen. Über Fusion lassen sich nur Zielversionen in der Phase Available to all installieren. Den wiederkehrenden Plan muss man ausdrücklich aktivieren; die Termine richten sich nach der Zeitzone der jeweiligen Firewall. Staging hilft bei der Reihenfolge, ersetzt aber keine Anwendungsabnahme. Der automatische Staging-Ablauf wartet nicht auf eine manuelle Anwendungsabnahme; dafür muss ein geeignetes separates Freigabeverfahren geplant werden. Den konkreten Ablauf und die Ausnahmen beschreibt die Planung wiederkehrender Firmware-Updates.

Das ist besonders bei mehreren Niederlassungen hilfreich. Beispielsweise erhält zunächst die Firewall eines kleinen Büros das Update. Danach prüft man dort VPN-Verbindungen, Benutzeranmeldungen und veröffentlichte Dienste. Erst wenn diese Kontrollen erfolgreich waren, folgen die weiteren Standorte. So muss man nicht jede Installation einzeln anstossen und behält trotzdem die Kontrolle über die Reihenfolge.

Vorher muss feststehen, wer die Ergebnisse prüft und bei Problemen die weiteren Updates stoppt. Eine automatische Installation ersetzt weder das Backup noch einen vorbereiteten Rückweg. Die nötigen Schritte beschreiben unsere Anleitungen zu Firmware-Updates und Backup und Wiederherstellung.

Identität und Anmeldung

Entra ID mit Synchronized User ID

Die Firewall kann über Synchronized Security jetzt auch Benutzer erkennen, die mit Entra ID arbeiten. Damit lassen sich Geräte mit lokaler AD-Anbindung und Geräte mit Cloud-Identität gemeinsam betreiben. Für den Entra-Pfad braucht es Sophos Endpoint 2025.1 oder neuer, eine passende Endpoint-Lizenz und eine bereits eingerichtete Entra-ID-Authentifizierung auf der Firewall. Endpoint muss den User Principal Name (UPN) des angemeldeten Benutzers per Security Heartbeat übertragen; ältere Endpoint-Versionen senden dieses Attribut nicht. Ein grüner Heartbeat allein bestätigt deshalb noch keine Entra-Benutzerzuordnung.

Die praktische Frage dahinter lautet: Woher kennt die Firewall den Benutzer hinter einer Verbindung? Eine IP-Adresse allein reicht nicht immer für eine sinnvolle benutzerbezogene Regel. Beim Wechsel von einer lokalen Domäne zu einer Cloud-Identität muss auch diese Zuordnung weiterhin zuverlässig funktionieren.

Ein typischer Fall ist ein Unternehmen, das neue Notebooks nur noch mit Entra ID verbindet, während ältere Geräte weiterhin zur lokalen AD-Domäne gehören. Für die Webrichtlinie der Buchhaltung sollte diese technische Übergangsphase keinen Unterschied machen: Massgebend ist die Benutzergruppe. Genau diese Kontinuität ist bei einer schrittweisen Cloud-Migration wichtig.

Für die Planung ist die Abgrenzung zur bereits bekannten Entra-ID-Anmeldung am Captive Portal wichtig. Hier geht es um das Zusammenspiel mit Sophos Endpoint. Aus einer vorhandenen Entra-ID-Umgebung allein folgt deshalb noch keine passende Benutzererkennung durch die Firewall. Im Pilot sollte man prüfen, welcher Benutzer tatsächlich erscheint und welche Gruppenregel anschliessend greift. Den vollständigen Ablauf mit Identitätsvoraussetzungen, Grenzen und negativem Berechtigungstest beschreibt Synchronized User ID einrichten.

Google Workspace als Identity Provider

Benutzer können sich mit ihrem Google-Workspace-Konto am Captive Portal, VPN Portal, Sophos Connect und an der WebAdmin-Oberfläche anmelden. Google Workspace übernimmt dabei die Rolle des Identity Providers und kann bei der Anmeldung auch die Mehrfaktor-Authentisierung verlangen.

Für Organisationen mit Google als zentralem Benutzerverzeichnis ist das eine wichtige Ergänzung. Konten und Anmeldevorgaben sollten möglichst dort gepflegt werden, wo auch die übrigen Unternehmenszugänge verwaltet werden.

Eine Schule mit Google Workspace muss beispielsweise für den VPN-Zugang der Lehrpersonen nicht zusätzlich einen unabhängigen Passwortbestand auf der Firewall pflegen. Das reduziert doppelte Administration und erleichtert es, die Anmeldung über den zentralen Identity Provider abzusichern.

Trotzdem ist eine erfolgreiche Anmeldung nur ein Teil der Integration. Danach muss die richtige Berechtigung folgen. Ein normaler Mitarbeiter darf durch eine funktionierende SSO-Anmeldung keinen Verwaltungszugriff erhalten. Beim Test gehören deshalb Benutzerattribute, Gruppenzuordnung, erlaubte Dienste und der Entzug von Zugriffsrechten zusammen.

MFA-Einrichtung per E-Mail

Für die Einrichtung der Mehrfaktor-Authentisierung kann die Firewall den benötigten QR-Code per E-Mail zustellen. Wird die Registrierung nicht innerhalb von 24 Stunden abgeschlossen, verfällt der unbenutzte Code. Bei bestehenden Installationen bleibt zunächst die bisherige Einrichtung über das Portal erhalten.

Das verändert den Einrichtungsprozess für neue Benutzer. Vor dem Rollout sollten E-Mail-Adressen und Mailzustellung geprüft werden. Sonst endet die erste VPN-Anmeldung in einem Supportfall, obwohl die eigentliche Authentisierung korrekt eingerichtet ist.

Ein QR-Code zur Registrierung enthält sicherheitsrelevante Informationen. Das empfangende Postfach muss daher ebenfalls geschützt sein. Für den Helpdesk braucht es ausserdem einen klaren Ablauf für abgelaufene Registrierungen und falsch hinterlegte Adressen. Ein erneuter Versand darf nicht dazu führen, dass die Identität des Anfragenden ungeprüft bleibt.

Chromebook-SSO

Mit einer neuen Erweiterung für Chromebooks lässt sich die Benutzeranmeldung an die Firewall übermitteln, ohne dass sich der Benutzer nochmals am Captive Portal anmelden muss. Die Erweiterung unterstützt alle weiterhin unterstützten SFOS-Versionen.

Gerade in Schulen sind wiederholte Portalanmeldungen störend. Entscheidend ist dort aber nicht nur die erste erfolgreiche Anmeldung, sondern auch der Wechsel zwischen Benutzern und Geräten. Ein Test mit gemeinsam genutzten Chromebooks sollte zeigen, dass nach einem Benutzerwechsel keine alte Zuordnung weiterverwendet wird.

Da die Erweiterung versionsübergreifend gedacht ist, sollte ihre Einführung separat vom v23-Upgrade geplant werden. Eine neue Client-Komponente und eine neue Firewall-Firmware gleichzeitig auszurollen, erschwert die Eingrenzung möglicher Fehler.

Terminalserver: Benutzerzuordnung mit XDR Sensor

Für Sophos Authentication for Thin Client, kurz SATC, lässt sich ein schlanker XDR Sensor einsetzen. Er hilft der Firewall dabei, den Netzwerkverkehr auf einem gemeinsam genutzten Server den einzelnen Benutzern zuzuordnen, und kann neben einer bestehenden Endpoint-Schutzlösung betrieben werden.

Auf einem Terminalserver teilen sich viele Sitzungen dieselbe Server-IP. Eine IP-basierte Freigabe unterscheidet deshalb nicht zwischen der Buchhaltung und einem externen Mitarbeiter auf demselben Host. Für benutzerbezogene Web- oder Firewall-Regeln braucht es eine zusätzliche Zuordnung.

Die Möglichkeit, einen Sensor neben einem vorhandenen Schutzprodukt einzusetzen, ist für gemischte Umgebungen interessant. Daraus folgt aber keine pauschale Kompatibilitätszusage für jede Kombination. Lizenz, Betriebssystem und unterstütztes Zusammenspiel gehören vorab geprüft. Beim Funktionstest sollten mindestens zwei gleichzeitig angemeldete Benutzer unterschiedliche Regeln erhalten. Die Auswirkungen auf den Terminalserver selbst sind getrennt von den Entscheidungen der Firewall zu beurteilen.

WAF: mehr Kontrolle über veröffentlichte Anwendungen

Unterschiedliche Aktionen je URL-Pfad

Die Web Application Firewall erhält Aktionen pro Pfad: Protect, Block, Redirect und Passthrough. Letzteres dient WebSockets ohne WAF-Inspektion.

Mit Protect bleibt ein Pfad unter WAF-Prüfung. Block weist den Zugriff mit HTTP 403 zurück. Redirect schickt den Browser an eine andere Adresse. Passthrough ist damit die bewusst gewählte Ausnahme für den entsprechenden WebSocket-Verkehr, keine zusätzliche Prüfstufe.

Damit lässt sich die Behandlung einer Anwendung genauer an deren Aufbau ausrichten. Nach einem Portalwechsel könnte etwa /altes-portal auf /kundenportal weiterleiten, während ein stillgelegter Bereich unter /legacy mit HTTP 403 gesperrt wird. Der eigentliche Anwendungsbereich bleibt unter WAF-Prüfung. Solche Entscheidungen direkt am vorgeschalteten Zugangspunkt zu verwalten, kann Änderungen am Backend reduzieren.

Bei Weiterleitungen muss das Ziel präzise stimmen. Ein falscher Pfad kann Anmeldeabläufe oder gespeicherte Links beschädigen; eine unbedachte Weiterleitung kann Schleifen erzeugen. Für eine Ausnahme ohne WAF-Prüfung muss wiederum klar sein, welcher Schutz auf der Anwendung selbst verbleibt. Eine funktionierende Verbindung ist noch kein Nachweis einer gleichwertigen Sicherheitsprüfung.

Mehr Pfade und Regeln

Pro Pfadeintrag sind bis zu 128 Pfade vorgesehen. Das WAF-Regellimit liegt standardmässig bei 100 und lässt sich auf 200 erhöhen.

Für die Planung sollte man Regellimit und Leistungsfähigkeit getrennt betrachten. Mehr konfigurierbare Regeln bedeuten nicht automatisch, dass eine Appliance beliebig viele aktive Anwendungen mit derselben Antwortzeit bedienen kann. TLS-Verarbeitung, Inspektion, Uploads und die Geschwindigkeit der Backend-Server bestimmen den Ressourcenbedarf mit.

Eine sinnvolle Abnahme verwendet deshalb typische Anfragen der tatsächlichen Anwendungen. Eine statische Testseite allein bildet beispielsweise ein Portal mit grossen Datei-Uploads nur schlecht ab.

Neue Verarbeitung mit Apache Event MPM

Die WAF wechselt auf Apache Event MPM, um gleichzeitige Anfragen besser zu verarbeiten.

Vereinfacht geht es darum, Arbeitskapazität besser zu nutzen, während einzelne Verbindungen auf weitere Verarbeitung warten. Bei vielen gleichzeitigen Zugriffen ist diese Verteilung entscheidend: Nicht jede offene Verbindung soll unnötig Ressourcen blockieren, die für andere Anfragen gebraucht werden. Die Kapazität des Backends bleibt dabei eine eigene Grenze.

Der entscheidende Betriebswert ist das Verhalten unter Last. Eine Anwendung kann technisch erreichbar bleiben und trotzdem so langsam antworten, dass Benutzer ihre Arbeit abbrechen. Bei Lasttests sollten daher nicht nur erfolgreiche Verbindungen, sondern auch Antwortzeiten und Fehlerquoten ausgewertet werden.

Für einen brauchbaren Vorher-nachher-Vergleich müssen Hardware, Sicherheitsprofil, Backend und Testverkehr gleich bleiben. Erst dann lässt sich beurteilen, welchen Unterschied die neue Verarbeitung im eigenen Einsatz macht. Aus dem Architekturwechsel allein lässt sich kein allgemeiner Durchsatzwert ableiten.

DHCP, Routing und Netzwerkdienste

DHCP auf der neuen Control Plane

Der DHCP-Dienst läuft nun auf der neuen Control Plane und kann grössere Adressbereiche sowie mehr Reservierungen verarbeiten. Ausserdem wird der DHCP-Verkehr bereits vor dem Dienst durch die Firewall geprüft, um die Auswirkungen einer Flut von Anfragen zu begrenzen. Einstellungen, für die bisher die Kommandozeile nötig war, sind nun in der Oberfläche erreichbar.

Das betrifft eine grundlegende Abhängigkeit des Netzwerks. Wenn Clients keine Adresse erhalten, wirken viele andere Dienste ebenfalls gestört. Beim Upgrade sollte der DHCP-Server deshalb genauso bewusst geprüft werden wie VPN oder Internetzugang.

Relevant wird die Skalierung etwa in einer Schule, wenn morgens viele Geräte fast gleichzeitig ins WLAN kommen und eine Adresse anfordern. Für die Benutzer sieht eine stockende Adressvergabe schnell wie ein WLAN-Problem aus. Eine zügige Lease-Verarbeitung hilft an einer Stelle, die bei der Fehlersuche leicht übersehen wird.

Zum Test gehören neue Leases, Verlängerungen bestehender Leases und reservierte Adressen. Auch übermittelte Werte wie Gateway, DNS-Server und individuelle DHCP-Optionen müssen stimmen. Gerade selten verwendete Einstellungen fallen oft erst auf, wenn ein spezielles Gerät neu startet.

Auch das Abfragen vergebener Adressen wurde überarbeitet. DHCP-Optionen werden einheitlicher entsprechend den zugrunde liegenden Standards verarbeitet. Bestehende Sonderkonfigurationen verdienen deshalb einen gezielten Vergleich vor und nach dem Upgrade.

Zu den in die Oberfläche übernommenen Einstellungen gehören negative Bestätigungen und die Begrenzung auf eine Lease pro Client. Eine negative Bestätigung signalisiert einem Client, dass er eine angeforderte Adresse nicht verwenden darf und seine Adresskonfiguration neu aushandeln muss. Solche Einstellungen sollte man anhand des eigenen Netzdesigns bewerten, insbesondere wenn mehrere DHCP-Dienste beteiligt sind.

mDNS-Reflector für Bonjour und Geräteerkennung

Mit dem mDNS-Reflector können Geräte auch Dienste in anderen ausgewählten Netzen entdecken. Das funktioniert sowohl mit IPv4 als auch mit IPv6. Für die anschliessende Verbindung zum gefundenen Gerät braucht es weiterhin eine passende Firewall-Regel.

Das ist beispielsweise relevant, wenn Drucker und Mitarbeiter in unterschiedlichen VLANs liegen. Der Drucker kann korrekt adressiert und grundsätzlich erreichbar sein, erscheint aber möglicherweise nicht in der automatischen Gerätesuche. Diensterkennung und anschliessende Datenverbindung sind zwei getrennte Schritte.

Für die Konfiguration sollte man nur die benötigten Netzpaare und Dienste freigeben. Ein Gästenetz muss nicht sämtliche Geräte der internen Infrastruktur entdecken können. Nach der Einrichtung sollte man sowohl das gewünschte Verhalten als auch die Grenze testen: Der vorgesehene Drucker wird gefunden und ist nutzbar, andere interne Dienste bleiben unzugänglich.

Routing-Engine und experimentelles BFD

Die Firewall verwendet eine aktualisierte Version der Routing-Software FRR. Über eine gemeinsame Konsole lassen sich die verschiedenen Routing-Protokolle verwalten. Hinzu kommt eine experimentelle BFD-Unterstützung für BGP und statische Routen auf einzeln betriebenen Firewalls.

BFD, ausgeschrieben Bidirectional Forwarding Detection, dient der schnellen Erkennung einer ausgefallenen Verbindung zwischen Routing-Nachbarn. Das ist eine andere Aufgabe als der Rollenwechsel eines Firewall-HA-Clusters. Schnellere Fehlererkennung kann helfen, Verkehr früher auf einen alternativen Pfad zu lenken.

Sehr kurze Überwachungsintervalle sind aber kein Selbstzweck. Wenn die Gegenstelle oder der Transportweg unter Last nicht zuverlässig antwortet, kann eine aggressive Einstellung unnötige Zustandswechsel verursachen. Den experimentellen Status sollte man deshalb ernst nehmen und BFD zunächst in einer passenden Testumgebung bewerten.

Interessant ist das beispielsweise bei zwei gerouteten Standortverbindungen: Bleibt das lokale Interface aktiv, obwohl der Nachbar über den bevorzugten Weg nicht mehr erreichbar ist, reicht der Linkstatus allein nicht zur Fehlererkennung. Eine passende BFD-Anbindung kann in einer solchen Architektur helfen, den Ausfall früher festzustellen.

IPv6 IPoE und 4in6

Die Firewall unterstützt weitere Anschlussvarianten mit IPv6 IPoE und 4in6-Tunneln. Dazu gehört auch der japanische Internetdienst Xpass.

Bei 4in6 wird IPv4-Verkehr durch eine IPv6-Verbindung transportiert. Solche Funktionen sind vor allem dann relevant, wenn der Internetprovider genau dieses Anschlussmodell verlangt. Für einen klassischen Anschluss ergibt sich daraus allein kein Anlass, die WAN-Konfiguration umzubauen.

Die Erweiterungen betreffen auch dynamische Adressen, Tunnelendpunkte und MTU/MSS. Für die Fehlersuche ist das Zusammenspiel wichtig: Ein erfolgreicher Tunnelaufbau garantiert noch nicht, dass grosse Pakete oder alle Anwendungen sauber funktionieren. Providerparameter, Namensauflösung und Paketgrössen sollten daher gemeinsam geprüft werden.

Bereitstellung auf IONOS Cloud

Sophos Firewall lässt sich nun auch auf IONOS Cloud mit dem offiziellen SFOS-Image betreiben. Die Installation erfolgt manuell über ein eigenes Image und nicht über einen fertigen Marketplace-Eintrag.

Für die Architekturplanung bleibt damit zu klären, wie öffentliche und interne Netze angebunden werden, wie der Managementzugang geschützt wird und wer den Lebenszyklus der virtuellen Maschine betreut. Ein unterstützter Installationsort beantwortet noch nicht die Fragen nach Redundanz, Wiederherstellung und Überwachung.

Insbesondere darf das eigene Betriebsmodell nicht stillschweigend Funktionen eines vollständig verwalteten Cloud-Dienstes voraussetzen. Auch eine virtuelle Firewall benötigt geplante Wartung und überprüfbare Backups.

Bedrohungsmeldungen und kleinere Änderungen

NDR-Meldungen ohne automatische Isolation

Erkennungen durch NDR Essentials und NDR Active Threat Intelligence können eine Meldung auslösen, ohne das betroffene Endgerät automatisch vom Netzwerk zu isolieren.

Damit werden Erkennen und Reagieren deutlicher getrennt. Das kann beim Einführen neuer Erkennungsquellen helfen: Man beurteilt zunächst die Qualität der Meldungen und legt danach fest, welche Ereignisse eine Sperre auslösen sollen. Die Unterschiede der Verfahren erläutert unser Beitrag zu NDR Active Threat Intelligence.

Eine reine Meldung hat allerdings nur dann einen Nutzen, wenn sie bearbeitet wird. Zuständigkeit, Reaktionszeit und Eskalationsweg müssen feststehen. Ebenso sollte man separat kontrollieren, welche Blockieraktionen in Active Threat Response weiterhin konfiguriert sind. Aus einer Änderung der Alarmierung darf man nicht auf die Abschaltung aller Schutzaktionen schliessen.

E-Mail-Inhaltslisten und Webkategorien

Weitere Änderungen betreffen ID-basierte Referenzen für E-Mail-Inhaltslisten und die Versionierung von Webkategorien.

Bei den E-Mail-Inhaltslisten, den Content Control Lists, wird die Referenz damit vom sichtbaren Namen getrennt. Ein Name dient Menschen zur Orientierung, eine stabile ID der eindeutigen Zuordnung. Die Webkategorie-Versionierung betrifft dagegen die Abstimmung der verwendeten Kategoriedefinitionen mit Sophos im Hintergrund.

Diese Punkte sind weniger sichtbar als eine neue Oberfläche, gehören aber in einen vollständigen Release-Überblick. Bei Konfigurationsänderungen und Wiederherstellungen kommt es darauf an, dass eine Richtlinie weiterhin das beabsichtigte Objekt verwendet. Für Webfilter wiederum sollten bekannte erlaubte und gesperrte Testseiten nach einem Upgrade noch die erwartete Entscheidung ergeben.

eDirectory wird nicht mehr unterstützt

Sophos Firewall v23 unterstützt den nativen eDirectory-Servertyp nicht mehr. Eine noch vorhandene eDirectory-Anbindung verhindert deshalb das Upgrade. Als Alternativen kommen Entra ID SSO, Active Directory, RADIUS oder eine LDAP-Anbindung an den bisherigen eDirectory-Server infrage.

Wichtig ist dabei die Unterscheidung zwischen Anmeldung und automatischer Benutzererkennung: LDAP kann Benutzer gegen das bestehende Verzeichnis authentisieren, ersetzt aber nicht das native eDirectory-SSO. Auch beim Wiederherstellen eines Backups oder beim Import einer Konfiguration wird die bisherige eDirectory-Anbindung nicht übernommen.

Den Wechsel und seine Auswirkungen auf Benutzer, Gruppen und Dienste beschreiben wir in unserer Anleitung Sophos Firewall: eDirectory vor SFOS 23 migrieren.

Fazit

Die REST API ist für mich eine der sinnvollsten Neuerungen in Sophos Firewall v23. Sie erleichtert wiederkehrende Änderungen und schafft eine gute Grundlage, um Konfigurationen mit eigenen Werkzeugen auszuwerten. Auch für die Analyse mit KI sind APIs hilfreich: Regeln und Objekte lassen sich strukturiert auslesen, vergleichen und auf Auffälligkeiten untersuchen. Welche Änderungen daraus folgen, muss weiterhin ein Administrator entscheiden. Aber schon beim Zusammentragen und Aufbereiten der Informationen lässt sich viel Handarbeit sparen.

Die neue Übersicht der Firewall-Regeln gefällt mir ebenfalls. Die Gruppenzugehörigkeit als Spalte, die frei wählbaren Details und die dauerhaft gespeicherte Ansicht machen die Arbeit angenehmer. Schade ist, dass diese Überarbeitung nicht auch bei den NAT-Regeln angekommen ist. Gerade dort fehlen das Gruppieren und Klonen weiterhin, obwohl man diese Funktionen beim Aufbau und bei der Pflege grösserer Konfigurationen gut gebrauchen könnte.

Aus Sophos Firewall Config Studio hätte ich mir zudem mehr Funktionen direkt in der Firewall gewünscht: den Vergleich mehrerer Konfigurationsstände, das Zusammenführen von Konfigurationsvorlagen und Berichte, die bei Firewall-, NAT- und TLS-Regeln auch die Werte der referenzierten Objekte anzeigen. Solche Werkzeuge helfen dabei, Änderungen zu verstehen und vorzubereiten. In dieser Form bleiben sie weiterhin dem separaten Config Studio vorbehalten.

Bei der Geschwindigkeit konnte ich in meinem ersten Test dagegen keine wesentliche Verbesserung feststellen. Bis eine Firewall-Regel gespeichert ist, vergehen weiterhin mehrere Sekunden. Bei einer einzelnen Änderung fällt das wenig ins Gewicht. Wenn man aber ein Regelwerk aufräumt und viele Regeln nacheinander bearbeitet, summieren sich die Wartezeiten und unterbrechen ständig den Arbeitsfluss. Die Verbesserungen an der Oberfläche sind willkommen. Für den täglichen Betrieb wünsche ich mir vor allem, dass häufige Aufgaben schneller erledigt werden können und sich Firewall- und NAT-Regeln einheitlicher verwalten lassen.

FAQ

Quellen

• Sophos Firewall v23: Release-Ankündigung, Ankündigung vom 28. September 2026.
• Sophos Firewall OS v23: Key New Features, technischer Funktionsleitfaden, Stand 28. September 2026.
• Sophos Firewall v23: Feedback und Erfahrungen, laufende Community-Rückmeldungen.