Sophos Firewall v22 MR2: Update oder neues Risiko?

Sophos Firewall v22 MR2 ist da. Build 546 wurde am 14. Juli 2026 veröffentlicht und bringt eine überschaubare, aber durchaus sinnvolle Mischung aus Sicherheitsfunktionen, Authentifizierungsänderungen, Zertifikatsanpassungen und mehr als 50 Fehlerbehebungen.

Auf dem Papier ist das ein klassisches Maintenance Release. In der Praxis steckt aber genau jene Mischung darin, bei der ich bei Sophos inzwischen zweimal hinschaue: neue Erkennungslogik im IPS, verändertes Verhalten bei der Benutzerzuordnung, neue Zertifikatsketten und gleichzeitig eine lange Liste mit Kernel-Crashes, HA-Problemen, Failsafe-Zuständen, VPN-Fehlern und Reporting-Aussetzern.

Das ist nicht nur positiv. Wenn ein Maintenance Release mehr als 50 Fehler behebt, zeigt das einerseits, dass Sophos aufräumt. Andererseits zeigt es auch, wie viele ernsthafte Probleme in GA und MR1 noch vorhanden waren. Genau diese Firmware-Qualität habe ich bereits in Sophos Firewall: Keine CVEs, aber Bugs (v21.5 bis v22) kritisiert.

Ich werde MR2 gleich auf einer meiner Sophos Firewalls installieren. Nicht weil ich dem Release am ersten Tag blind vertraue, sondern weil ich sehen will, ob Build 546 die v22-Linie endlich beruhigt oder ob wieder mehr neue Bugs entstehen, als mit dem Update behoben werden. Besonders interessieren mich HA, Logging, IPsec, WebAdmin-Reaktionszeit, STAS und die Stabilität nach Pattern-Updates.

Gleichzeitig schafft Sophos mit diesem Release einen merkwürdigen Kontrast. In den offiziellen Firewall-Updates nimmt Config Studio 2.6 inzwischen viel Raum ein. Das externe Browser-Werkzeug bekommt Template-Merges, bessere Suche, Multi-File-Diffs, Migrationsanalysen und Hardware-Kompatibilitätsdaten. In der eigentlichen Firewall-Oberfläche passiert bei der täglichen Bedienung dagegen wieder praktisch nichts Sichtbares.

Ich finde MR2 deshalb technisch wichtig, strategisch aber ernüchternd. Die Security-Engine bekommt neue Funktionen, während moderne Admin-Workflows erneut in Config Studio ausgelagert werden.

Das Wichtigste in Kürze

SFOS 22.0 MR2 trägt die Build-Nummer 546 und folgt auf MR1 Build 490. Sophos nennt im Release im Kern sieben Bereiche:

• Erkennung und Kontrolle von Post-Quantum-Kryptografie
• bessere Kategorisierung generativer KI-Anwendungen
• eine neue Chromebook-User-ID-Erweiterung mit Manifest V3
• ein geändertes Standardverhalten bei STAS
• die frühe Abkündigung von Novell eDirectory für SFOS 23.0
• neue Let’s-Encrypt-Vertrauensketten und bessere E-Mail-Benachrichtigungen
• Config Studio 2.6 mit mehreren neuen Analyse-, Migrations- und Vergleichsfunktionen

Dazu kommen mehr als 50 behobene Probleme. Gerade diese Fixes sind aus Betriebssicht teilweise wichtiger als die neuen Funktionen, denn darunter befinden sich Kernel-Abstürze, HA-Probleme, Failsafe-Zustände, VPN-Fehler und Performance-Probleme im Reporting.

Meine kurze Einordnung:

• Wer bereits auf v22 GA oder MR1 läuft und von einem der gelisteten Fehler betroffen ist, hat einen konkreten Grund für MR2.
• Wer eine stabile 21.5-Installation betreibt, sollte nicht nur wegen PQC oder Config Studio hektisch aktualisieren.
• PQC-Signaturen gehören zuerst in einen reinen Beobachtungsmodus, nicht sofort auf Drop.
• STAS-Umgebungen müssen nach dem Upgrade prüfen, wie nicht authentifizierter Traffic während der Identity Probe behandelt wird.
• HA-, IPsec-, WAF-, Mail- und Reporting-Installationen brauchen echte Funktionstests statt eines kurzen Blicks auf grüne Statusanzeigen.
• Config Studio 2.6 ist technisch nützlich, aber kein Beweis für eine modernere SFOS-WebAdmin-Oberfläche. Eher im Gegenteil.

Wichtig bleibt die Hardwaregrenze: SFOS 22.0 unterstützt keine XG- und SG-Hardware-Appliances mehr. Das Release ist für XGS, virtuelle, Software- und unterstützte Cloud-Installationen gedacht. Wer noch XG-Hardware betreibt, kann MR2 nicht als normalen nächsten Firmware-Schritt einplanen.

Post-Quantum-Kryptografie erkennen und kontrollieren

Die technisch interessanteste Neuerung ist die Kontrolle von Post-Quantum-Kryptografie, kurz PQC. Dabei geht es nicht darum, dass die Sophos Firewall plötzlich Quantencomputer abwehrt. Die Funktion betrifft moderne kryptografische Schlüsselaustauschverfahren, die gegen zukünftige Angriffe mit leistungsfähigen Quantencomputern robuster sein sollen.

MR2 konzentriert sich auf ML-KEM. Das Verfahren wurde 2024 als FIPS 203 standardisiert und basiert auf der angenommenen Schwierigkeit des Module-Learning-with-Errors-Problems. NIST definiert drei Parameterstufen:

• ML-KEM-512 mit der kleinsten Schlüssel- und Datenmenge,
• ML-KEM-768 als mittlere und heute besonders häufig eingesetzte Variante,
• ML-KEM-1024 mit höherer Sicherheitsstufe, aber auch mehr Rechen- und Übertragungsaufwand.

Sophos schreibt in den MR2-Unterlagen nur allgemein von reinen und hybriden, auf ML-KEM basierenden Key-Exchange-Algorithmen. Welche konkreten Parameterstufen, TLS-Gruppen oder Signatur-IDs abgedeckt werden, wird dort nicht offengelegt. Man sollte deshalb nicht automatisch annehmen, dass jede denkbare ML-KEM-Variante erkannt wird.

Was ein KEM technisch überhaupt macht

ML-KEM verschlüsselt nicht direkt den gesamten Datenstrom. Ein Key Encapsulation Mechanism besteht vereinfacht aus drei Operationen:

1. KeyGen erzeugt einen Encapsulation Key und den dazugehörigen Decapsulation Key.
2. Encaps erzeugt mit dem öffentlichen Encapsulation Key ein Ciphertext-Objekt und ein gemeinsames Geheimnis.
3. Decaps gewinnt auf der Gegenseite mit dem privaten Decapsulation Key dasselbe Geheimnis zurück.

Aus diesem gemeinsamen Geheimnis leitet das Protokoll anschließend symmetrische Sitzungsschlüssel ab. Die eigentlichen Nutzdaten werden weiterhin mit schnellen symmetrischen Verfahren wie AES oder ChaCha20 geschützt. ML-KEM ersetzt also den gefährdeten asymmetrischen Teil der Schlüsselaushandlung, nicht die komplette TLS-Datenverschlüsselung.

Der praktische Hintergrund ist Harvest now, decrypt later: Ein Angreifer kann heute verschlüsselten Traffic aufzeichnen und darauf hoffen, ihn in einigen Jahren mit einem kryptografisch relevanten Quantencomputer zu entschlüsseln. Für kurzlebige Daten ist das weniger dramatisch. Für Gesundheitsdaten, staatliche Kommunikation, geistiges Eigentum oder langfristig vertrauliche Unternehmensdaten kann die Schutzdauer aber deutlich länger sein als die Zeit bis zu einer möglichen neuen Angriffsklasse.

Rein und hybrid sind nicht dasselbe

Bei einem reinen PQC-Schlüsselaustausch basiert die Sicherheit der Aushandlung nur auf dem neuen post-quanten-sicheren Verfahren. Ein hybrider Austausch kombiniert dagegen einen klassischen Mechanismus mit ML-KEM. Ein in der Praxis verbreitetes Beispiel ist X25519MLKEM768: Der klassische X25519-Anteil und ML-KEM-768 tragen gemeinsam zum resultierenden Geheimnis bei.

Der hybride Ansatz ist momentan vernünftig. Wenn sich später ein Implementierungsfehler oder eine mathematische Schwäche in ML-KEM zeigt, bleibt die klassische Komponente. Sollte umgekehrt ein ausreichend starker Quantencomputer die klassische elliptische Kurve brechen können, bleibt der ML-KEM-Anteil. Hybrid ist damit eine Migrationsbrücke und keine unnötige doppelte Verschlüsselung.

Wichtig ist aber: X25519MLKEM768 ist hier ein reales technisches Beispiel aus aktuellen TLS-Implementierungen. Sophos nennt in den MR2-Unterlagen nicht ausdrücklich, dass genau diese Gruppe die einzige oder primäre erkannte Variante ist.

Was IPS dabei macht

Das Intrusion Prevention System erhält neue Signaturen, mit denen reine und hybride ML-KEM-Schlüsselaustauschverfahren erkannt werden können. Admins können dafür eigene IPS-Regeln erstellen und Aktionen wie Allow, Drop oder Reset festlegen.

Technisch kann eine Firewall den angebotenen und ausgewählten Schlüsselaustausch im TLS-Handshake erkennen, weil der Client seine unterstützten Gruppen und Key Shares im ClientHello anbietet und der Server seine Auswahl im ServerHello bestätigt. Diese Phase findet statt, bevor der verschlüsselte Applikationsdatenstrom beginnt. Damit ist grundsätzlich Erkennung möglich, ohne den späteren HTTPS-Inhalt zu lesen.

Sophos dokumentiert allerdings nicht, an welcher Stelle Snort beziehungsweise die SFOS-IPS-Pipeline diese Merkmale auswertet, welche TLS-Versionen erfasst werden und ob sich die Erkennung bei Proxy-, DPI- und nicht entschlüsseltem FastPath-Traffic unterscheidet. Die Release Notes bestätigen die Fähigkeit, aber nicht die interne Datenpfad-Implementierung. Für eine produktive Policy ist deshalb ein eigener Test mit Firewall- und IPS-Logs nötig.

Die Aktionen haben unterschiedliche Auswirkungen:

• Allow lässt die Verbindung weiterlaufen und eignet sich zusammen mit Logging für eine Bestandsaufnahme.
• Drop verwirft passende Pakete still. Der Client sieht typischerweise einen Timeout oder einen abgebrochenen Handshake.
• Reset beendet die TCP-Verbindung aktiv. Der Fehler erscheint schneller, kann für Benutzer und Applikationslogs aber anders aussehen als ein stiller Drop.

Die neuen Signaturen sind standardmäßig deaktiviert. Das ist die richtige Entscheidung. PQC ist nicht mehr nur Labortechnik. Große Browser, Cloud-Dienste und Webplattformen testen oder verwenden hybride Verfahren bereits. Würde Sophos solche Verbindungen pauschal blockieren, könnten legitime Webseiten und Anwendungen ausfallen.

Die sinnvolle Einführung sieht deshalb so aus:

1. Signaturen zunächst aktivieren und den Verkehr nur erlauben und protokollieren.
2. Über mehrere Tage oder Wochen auswerten, welche Anwendungen und Ziele ML-KEM verwenden.
3. Prüfen, ob interne Kryptografie-Richtlinien bestimmte Verfahren verbieten oder ausdrücklich verlangen.
4. Erst danach gezielt mit Drop oder Reset durchsetzen.

In der ersten Community-Diskussion meldete ein Admin direkt nach dem Upgrade, dass er mit Suchbegriffen wie PQC, KEM oder quantum noch keine entsprechenden IPS-Signaturen finden konnte. Das kann an einer noch nicht eingetroffenen Pattern-Aktualisierung oder an der Benennung liegen. Wenige Stunden nach Veröffentlichung ist daraus noch kein belastbarer Produktfehler abzuleiten. Es zeigt aber ein Dokumentationsproblem: Eine Funktion ist nur dann administrierbar, wenn Signaturname, SID, Kategorie und Log-Merkmale auffindbar sind.

Vor einer Policy-Änderung würde ich deshalb konkret prüfen:

• Ist IPS aktiv und die Network-Protection-Subscription gültig?
• Welcher IPS-Pattern-Stand ist installiert?
• Unter welchem Namen und welcher SID erscheinen die neuen Signaturen?
• Tauchen Treffer im IPS-Log und im zentralen Reporting auf?
• Bleibt die Erkennung bei DPI-Ausnahmen, TLS-Inspection und FastPath gleich?
• Welche Browser, Betriebssysteme, Cloud-Dienste und internen Anwendungen erzeugen Treffer?

Was Web Protection dabei macht

Zusätzlich verhindert Web Protection laut Sophos, dass Web-Sessions nicht unterstützte PQC-Algorithmen aushandeln. Das ist eine andere Aufgabe als eine IPS-Signatur. IPS erkennt bestimmte Muster und kann darauf reagieren. Web Protection greift in den kontrollierten TLS- und Web-Workflow ein und soll verhindern, dass eine Verbindung ein Verfahren verwendet, das die Firewall nicht verarbeiten oder gemäß Richtlinie nicht zulassen kann.

Praktisch relevant wird das vor allem bei TLS-Inspection. Bei einer entschlüsselten Verbindung terminiert die Firewall die TLS-Session des Clients und baut selbst eine zweite TLS-Session zum Zielserver auf. Es existieren damit zwei getrennte Handshakes und zwei getrennte Sätze Sitzungsschlüssel. Ein Browser und ein Webserver könnten PQC beherrschen, während die dazwischenliegende Inspection-Komponente eine angebotene Gruppe nicht korrekt verarbeiten kann.

Ohne kontrolliertes Verhalten entstehen schwer verständliche Fehler: Der Client bietet eine neue Gruppe an, die Firewall kann den Handshake nicht vollständig vermitteln, der Server wählt eine unerwartete Variante oder ein Fallback verhält sich anders als geplant. MR2 soll verhindern, dass Web-Sessions nicht unterstützte PQC-Algorithmen aushandeln.

Was Sophos nicht präzise beschreibt, ist ebenso wichtig: Die Unterlagen nennen keine eigene PQC-Policy-Matrix für Web Protection, keine Liste unterstützter Gruppen und keine genaue Aussage dazu, ob ein nicht unterstütztes Angebot entfernt, abgelehnt oder durch klassischen Fallback ersetzt wird. Das sollte man nicht mit der frei konfigurierbaren IPS-Aktion gleichsetzen.

Die Funktion ist sinnvoll, aber sie ersetzt keine Krypto-Strategie. Unternehmen müssen weiterhin wissen, welche TLS-Verbindungen entschlüsselt werden, wo Ausnahmen bestehen und ob PQC nur beobachtet oder tatsächlich erzwungen werden soll.

Generative KI wird als Anwendung besser sichtbar

Die zweite neue Sicherheitsfunktion betrifft generative KI-Anwendungen. Sophos verbessert deren Kategorisierung über Synchronized Application Control.

Das Prinzip dahinter ist nicht neu: Sophos Endpoint sieht, welcher lokale Prozess eine Verbindung aufbaut, und teilt die Anwendungskontextdaten über Security Heartbeat mit der Firewall. Die Firewall kann dadurch eine Session einem Programm zuordnen, selbst wenn Port, Ziel-IP und verschlüsselter Traffic allein keine eindeutige Identifikation erlauben.

Der technische Datenpfad sieht vereinfacht so aus:

1. Eine Anwendung auf einem geschützten Endpoint öffnet eine Netzwerkverbindung.
2. Sophos Endpoint kennt Prozessname, Pfad und den lokalen Anwendungskontext.
3. Security Heartbeat verbindet Endpoint- und Firewall-Sicht.
4. SFOS ordnet die ansonsten unbekannte oder nur grob erkannte Session einer Anwendung zu.
5. Die Anwendung erscheint unter Synchronized Application Control und kann kategorisiert werden.
6. Eine Application-Filter-Policy erlaubt, blockiert oder formt den dazugehörigen Traffic.

In der Connection List kann SFOS für nicht identifizierte Verbindungen über Resolve application info Informationen vom Endpoint anfordern. Die Application-Liste lässt sich nach Name, Pfad, Kategorie oder Endpoints durchsuchen. Sophos nennt eine Obergrenze von 15.000 über Synchronized Application Control verwalteten Anwendungen. Pro Anwendung und Endpoint behält die Firewall aus Speichergründen nur die fünf jüngsten Vorkommnisse.

MR2 verbessert nun speziell die Zuordnung generativer KI-Anwendungen. Sophos Endpoint soll diese Anwendungen genauer erkennen und die Information an die Firewall liefern. Die Kategorie Generative AI existiert in der SFOS-Anwendungsliste und kann damit in Application Filters und Reports verwendet werden.

Für Admins sind drei Dinge relevant:

• Sichtbarkeit: Im Reporting soll klarer werden, welche generativen KI-Anwendungen im Unternehmen verwendet werden.
• Regeln: Erkannte Anwendungen können gezielter erlaubt, eingeschränkt oder blockiert werden.
• Inventar: Security- und Datenschutzteams erhalten eine bessere Grundlage, um genehmigte und nicht genehmigte KI-Dienste zu unterscheiden.

Das ist nützlich, aber die Formulierung “generative KI erkennen” darf nicht größer gemacht werden, als sie ist.

Synchronized Application Control beantwortet primär die Frage: Welche Anwendung hat die Verbindung erzeugt? Es beantwortet nicht automatisch:

• welchen Prompt ein Benutzer eingegeben hat,
• welche Datei hochgeladen wurde,
• ob personenbezogene oder vertrauliche Daten enthalten waren,
• ob eine Browser-Session private oder geschäftliche KI-Nutzung darstellt,
• ob ein erlaubter KI-Dienst innerhalb des Browsers über eine eingebettete Funktion verwendet wurde.

Ein Desktop-Client mit eindeutigem Prozesspfad ist leichter zuzuordnen als zehn KI-Webdienste, die alle im selben Browserprozess laufen. URL-Kategorisierung, TLS-Inspection und Cloud-App-Erkennung können zusätzliche Informationen liefern, sind aber technisch andere Erkennungsebenen.

Ebenso hängt der Mehrwert von Sophos Endpoint, aktivem Security Heartbeat und eingeschaltetem Synchronized Application Control ab. Die erstmalige Aktivierung erfolgt über Sophos Central. Wer nur SFOS ohne Sophos Endpoint betreibt oder Endpoints außerhalb des Heartbeat-Pfads hat, bekommt nicht automatisch dieselbe Erkennungstiefe.

Die richtige Erwartung ist deshalb: MR2 verbessert die Zuordnung von Anwendungen und damit die Policy-Grundlage. Es löst nicht allein die organisatorische Frage, welche KI-Dienste erlaubt sind und welche Daten dort verarbeitet werden dürfen.

Ich würde nach dem Upgrade nicht sofort die komplette Kategorie Generative AI blockieren. Zuerst gehört ins Reporting, welche Treffer über Endpoint-Kontext, Firewall-Signatur oder Web-Kategorisierung entstanden sind. Sonst blockiert man möglicherweise produktive Funktionen in Microsoft 365, Entwicklungswerkzeugen, Browsern oder Support-Plattformen, ohne die tatsächliche Nutzung zu verstehen.

Änderungen bei Authentifizierung und Benutzerzuordnung

MR2 bringt drei voneinander unabhängige Authentifizierungsthemen. Zwei davon erfordern konkrete Vorbereitung, das dritte ist eine frühe Migrationswarnung.

Chromebook User ID mit Manifest V3

Die Sophos Chromebook User ID Extension wurde auf Manifest V3 umgestellt. Das ist die aktuelle Erweiterungsplattform von Chrome und ersetzt die ältere technische Basis.

Der entscheidende Punkt: Sophos verlangt, dass die bisherige Erweiterung deinstalliert und die neue Version installiert wird. Ein einfaches stilles Update der alten Extension reicht also nicht. Schulen und Unternehmen mit zentral verwalteten Chromebooks sollten den Wechsel über ihre Google-Admin-Richtlinien vorbereiten, mit einer Testgruppe prüfen und danach breit ausrollen.

Technisch ist die Extension nur ein Teil des SSO-Pfads. Für Chromebook SSO erwartet Sophos unter anderem:

• einen AD-, LDAP- oder Google-Secure-LDAP-Server auf der Firewall,
• Chromebooks im durch SFOS geschützten Netz,
• Benutzeradressen aus der registrierten Google-Workspace-Domain,
• ein Zertifikat für die verschlüsselte Kommunikation,
• einen zum Zertifikat passenden CN,
• standardmäßig den Sophos-Kommunikationsport 65123,
• eine aus SFOS exportierte und in Google Workspace hinterlegte JSON-Konfiguration,
• Zugriff auf accounts.google.com, Google API Hosts und den Chrome Web Store.

In Google Workspace wird die neue Erweiterung unter Devices > Chrome > Apps and extensions > Users and browsers verteilt. Für produktive Umgebungen ist Force install sinnvoll, damit Benutzer die für die Identitätszuordnung benötigte Extension nicht entfernen können. Zusätzlich muss die Sophos User ID App unter den API Controls als vertrauenswürdig freigegeben werden, sonst kann OAuth scheitern.

Nach dem Wechsel würde ich nicht nur prüfen, ob die Extension installiert ist. Entscheidend ist die komplette Kette:

1. Benutzer meldet sich am Chromebook an.
2. Die Extension erreicht die Firewall über das vorgesehene Netz und Zertifikat.
3. Der Benutzer erscheint unter Live users.
4. Eine benutzerbasierte Regel matcht wirklich auf Benutzer oder Gruppe.
5. Nach Abmeldung oder Gerätewechsel verschwindet die Zuordnung wieder korrekt.

Ohne die neue Erweiterung können zukünftige Updates ausbleiben. Je nach Authentifizierungsdesign kann das die Benutzerzuordnung und damit benutzerbasierte Firewall- oder Web-Regeln beeinträchtigen. In einer Schule kann daraus sehr schnell ein Filterproblem werden, obwohl Firewall, Internetzugang und Chromebook auf den ersten Blick alle “online” sind.

STAS blockiert während der Identitätsprüfung nicht mehr standardmäßig

Bei der Sophos Transparent Authentication Suite ändert MR2 den Standardwert von Restrict client traffic during identity probe auf No.

STAS ordnet IP-Adressen den am Windows-Domain-Controller erkannten Benutzern zu. Der Ablauf ist älter, aber technisch durchaus interessant:

1. Der Benutzer meldet sich an der Windows-Domain an.
2. Der Domain Controller schreibt ein Security-Audit-Event, bei neueren Windows-Versionen typischerweise Event ID 4768.
3. Der STAS Agent liest Benutzername und IP-Adresse aus diesem Ereignis.
4. Der Agent sendet die Information standardmäßig über TCP 5566 an den Collector.
5. Der Collector meldet erfolgreiche Zuordnungen über UDP 6060 an die Firewall.
6. Wenn SFOS Traffic von einer unbekannten IP sieht, kann es den Collector über Port 6677 abfragen.
7. Die Firewall ergänzt die Gruppenzugehörigkeit über den konfigurierten AD-Server und wendet benutzerbasierte Regeln an.

Wenn die Firewall für eine IP noch keine Zuordnung hat, landet diese im Learning Mode. Bisher wurde der Traffic während dieser Probe standardmäßig angehalten beziehungsweise verworfen. Der dokumentierte Standardzeitraum beträgt 120 Sekunden. Antwortet der Collector nicht, kann die IP anschließend für eine Stunde als unauthentifiziert gelten; dann greifen die Regeln für unauthentifizierten Traffic.

Genau dort lag unter MR1 ein reales Betriebsproblem. Sophos dokumentiert NC-181885: Mit Restrict client traffic during identity probe = Yes konnten wiederholte Identity Probes zu intermittierenden Unterbrechungen führen oder das MR1-Upgrade blockieren. MR2 ist als Fix-Version genannt und ändert gleichzeitig den Standard auf No.

Mit No darf der Client-Verkehr während der Prüfung weiterlaufen. Das reduziert Störungen, verändert aber die Abwägung:

• Der Benutzer erlebt weniger Unterbrechungen.
• Die Firewall hat während der laufenden Prüfung möglicherweise noch keine bestätigte Identität.
• Benutzerbasierte Regeln und Protokollierung müssen deshalb in dieser Übergangsphase genau geprüft werden.

Das ist ein klassischer Trade-off zwischen Verfügbarkeit und strikter Identitätsdurchsetzung. Mit Yes kann eine gestörte Collector-Kommunikation den Client blockieren. Mit No kann während der Probe Traffic fließen, bevor die Benutzeridentität bestätigt ist. Ob dieser Traffic eine allgemeine Netzwerkregel, eine unauthentifizierte Regel oder später eine Benutzerregel trifft, muss im eigenen Regelwerk getestet werden.

Die Release Notes sagen, dass der Standardwert auf No wechselt. Sie sagen nicht eindeutig, dass MR2 jede bestehende, bewusst gesetzte Konfiguration automatisch überschreibt. Bestehende Installationen sollten daher nach dem Upgrade kontrollieren, welcher Wert tatsächlich gesetzt ist.

Zusätzlich würde ich folgende Punkte prüfen:

• Sind UDP 6060 und 6677 zwischen Firewall und Collector offen?
• Läuft der STAS Service und ist er an die richtige NIC gebunden?
• Sind mehrere Collector in Gruppen für Fault Tolerance konfiguriert?
• Greifen Clientless-User-Objekte für Drucker, IoT und andere Nicht-Domain-Geräte?
• Erscheinen Benutzer nach Sleep, Roaming, DHCP-Wechsel und Abmeldung korrekt?
• Matchen Regeln während Learning Mode und unauthentifiziertem Zustand so, wie das Security-Design es vorsieht?

Besonders wichtig ist das in Umgebungen, in denen Benutzeridentität nicht nur fürs Reporting, sondern als echte Zugriffsbedingung verwendet wird.

Novell eDirectory endet mit SFOS 23.0

MR2 zeigt erstmals frühzeitig an, dass Sophos die Unterstützung für Novell-eDirectory-Authentifizierungsserver mit SFOS 23.0 beendet.

In MR2 funktioniert eDirectory weiterhin. Die Meldung ist eine Vorwarnung, kein sofortiger Funktionsverlust. Wer eDirectory noch produktiv verwendet, sollte die verbleibende Zeit aber ernst nehmen und auf einen unterstützten Authentifizierungstyp migrieren, bevor SFOS 23.0 eingespielt wird.

Eine solche Migration betrifft mehr als den Servereintrag. Gruppen, Firewall-Regeln, Web-Policies, VPN-Zugriffe, Benutzerportale und Reporting können an der bisherigen Identitätsquelle hängen. Auch unterschiedliche Distinguished Names, Gruppenverschachtelungen, Suchpfade und Benutzernamenformate können dafür sorgen, dass ein technisch erfolgreicher LDAP-Test noch lange keine funktionierende Policy-Migration bedeutet.

Hinzu kommt eine schon länger bestehende Grenze: STAS unterstützt für eDirectory kein LDAP über SSL/TLS. Dass Sophos eDirectory mit SFOS 23.0 ganz entfernt, ist deshalb nicht völlig überraschend. Trotzdem muss die Ersatzarchitektur rechtzeitig stehen. Das sollte als eigenes Projekt mit Testkonten, parallel nachgebildeten Gruppen, dokumentierten Regelreferenzen und einem Rückfallplan behandelt werden.

Let’s Encrypt: neue Ketten und bessere Zuordnung

Let’s Encrypt stellt seine Zertifikatsinfrastruktur schrittweise auf neue Root- und Intermediate-Zertifikate um. MR2 ergänzt die Unterstützung für YE Root, YE1, YE2, YR Root, YR1 und YR2.

Das ist die sogenannte Generation-Y-Hierarchie. Sie besteht aus zwei neuen Root CAs mit unterschiedlichen Schlüsseltypen:

• ISRG Root YE verwendet ECDSA P-384 und ist der Nachfolgerpfad für die bisherige ECDSA-Hierarchie.
• ISRG Root YR verwendet RSA 4096 und ist der neue RSA-Root-Pfad.
• YE1 und YE2 sind ECDSA-P-384-Intermediates.
• YR1 und YR2 sind RSA-2048-Intermediates.

Die Roots sind von den bisherigen ISRG-Roots kreuzsigniert. Dadurch können neue Zertifikatsketten auf ältere, bereits verbreitete Trust Anchors zurückgeführt werden, während Browser- und Betriebssystemhersteller die neuen Roots in ihre Trust Stores aufnehmen. Die Intermediates YE1, YE2, YR1 und YR2 wurden 2026 für aktive Ausstellung relevant.

Für SFOS ist das vor allem eine Kompatibilitätsänderung. Die Firewall muss neue Aussteller und Ketten korrekt kennen, damit automatische Ausstellung, Erneuerung, WAF-Verwendung und Validierung auch mit der nächsten Generation der Let’s-Encrypt-Infrastruktur funktionieren. Ohne aktualisierte Vertrauenskette könnten ansonsten Zertifikatsoperationen scheitern, obwohl Domain, Port 80 und HTTP-01-Validierung korrekt eingerichtet sind.

Das ist im Betrieb besonders unangenehm, weil ein ACME-Fehler leicht falsch eingeordnet wird. Man sucht dann bei DNS, DNAT, Port 80, WAF-Regel oder Terms of Service, obwohl die eigentliche Ursache eine neue CA-Kette sein kann.

SFOS verwendet für Let’s-Encrypt-Anfragen weiterhin HTTP-01. Die Domain muss als FQDN auf die ausgewählte öffentliche WAN-Adresse zeigen. Port 80 muss die Firewall erreichen, und eine konkurrierende DNAT-Regel auf derselben Adresse und Port 80 kann die Validierung verhindern. MR2 ändert dieses Grundprinzip nicht; es erweitert die unterstützte CA-Hierarchie.

Zusätzlich enthalten Let’s-Encrypt-E-Mail-Benachrichtigungen jetzt Hostname und Seriennummer der Firewall. Das klingt klein, ist für MSPs und größere Umgebungen aber sehr nützlich. Wer Dutzende Firewalls verwaltet, kann eine Warnung endlich schneller dem richtigen Gerät zuordnen, ohne erst anhand einer generischen Nachricht suchen zu müssen.

Das ist eine klassische Quality-of-Life-Verbesserung: technisch unspektakulär, im Alltag sinnvoll. Eigentlich sollte jede systemgenerierte Meldung einer zentral verwalteten Firewall mindestens Hostname, Seriennummer, Modell und Firmware enthalten. Bei Backup-E-Mails hat Sophos diese Richtung bereits eingeschlagen; Let’s Encrypt zieht mit MR2 nach.

Config Studio 2.6: jede neue Funktion erklärt

Sophos führt Config Studio 2.6 offiziell als Teil der MR2-Ankündigung auf, obwohl es weiterhin ein separates browserbasiertes Werkzeug ist und nicht als neue Oberfläche direkt in SFOS läuft. Wer das Grundprinzip noch nicht kennt, findet im früheren Beitrag Sophos Firewall Config Studio V2: Mehr als ein Viewer den kompletten Workflow mit Export, Entities.xml, Vergleich und Editor.

Wichtig für die technische und datenschutzrechtliche Einordnung: Sophos gibt an, dass Parsing, Analyse und Report-Erzeugung lokal im Browser auf dem Endpoint stattfinden. Die hochgeladene Konfiguration soll nicht an Sophos oder einen anderen Server übertragen werden. Das ist bei einer vollständigen Firewall-Konfiguration entscheidend, denn Entities.xml kann interne Netze, Objekte, Regelwerke, VPN-Definitionen, Zertifikatsreferenzen und organisatorische Namen enthalten.

Lokal verarbeitet heißt trotzdem nicht automatisch risikofrei. Der Browser lädt die Anwendung weiterhin aus dem Internet. Für hochsensible Umgebungen bleiben deshalb Fragen nach Code-Version, Browser-Cache, Offline-Nutzung, Endpoint-Härtung und der sicheren Ablage der Exporte. Eine Entities.xml gehört nicht unkontrolliert in Downloads, Tickets oder normale Cloud-Synchronisation.

Config Studio 2.6 deckt inzwischen fünf Arbeitsbereiche ab:

• Configuration Report mit Policy Test, Analyse und globaler Suche
• Vergleich von zwei oder mehr Konfigurationen
• visueller Editor mit Bulk Editing und XML-, API- oder curl-Ausgabe
• Migration von Sophos UTM, SonicWall, FortiGate und Palo Alto Networks
• Backup-Restore-, Flexi-Port-, Transceiver- und Modellkompatibilität

Version 2.6 erweitert diese Bereiche an mehreren Stellen.

Templates zusammenführen

Mit Merge Templates lassen sich Baseline-Konfigurationen mit branchenspezifischen Vorlagen kombinieren. Ein MSP könnte beispielsweise eine technische Grundkonfiguration für Logging, DNS, Admin-Zugriffe und Standardobjekte mit einer Vorlage für Arztpraxen, Schulen oder Filialstandorte verbinden.

Der Vorteil liegt in der Wiederverwendung. Man beginnt nicht bei jeder Firewall wieder bei null. Eine Baseline kann beispielsweise Admin-Zugänge, NTP, DNS, Syslog, Standard-Services und Logging-Konventionen enthalten. Ein zweites Template ergänzt branchenspezifische Regeln und Objekte.

Der kritische Punkt bleibt die Konfliktbehandlung:

• Was passiert bei identischen Objektnamen mit unterschiedlichen Werten?
• Werden UUIDs, Referenzen und Regelreihenfolgen konsistent aufgelöst?
• Welche Interface- und Zonenreferenzen passen nicht zum Zielmodell?
• Entstehen durch den Merge doppelte oder überlappende Regeln?
• Wird ein bestehendes restriktives Objekt durch einen breiteren Template-Wert ersetzt?

Nach dem Merge gehören deshalb Duplicate Analysis, Shadow Rule Analysis, Usage References und ein vollständiger Policy Test zum Pflichtprogramm. Ein technisch erfolgreicher Merge ist kein Beweis, dass die resultierende Policy sicher ist.

Verbesserte globale Suche

Die globale Suche kann Konfigurationsobjekte schneller finden und direkt zu ihnen navigieren. Das ist bei großen Regelwerken wichtiger, als es klingt. Ein Hostobjekt kann in Firewall-, NAT-, TLS-, Web- oder VPN-Konfigurationen referenziert sein. Wenn ein Treffer mit einem Klick zur relevanten Stelle führt, spart das viel manuelles Öffnen und Zurückspringen.

Config Studio kann nicht nur nach dem sichtbaren Objektnamen suchen. Je nach Datentyp sind auch Werte, Pfade und referenzierte Elemente relevant. Der direkte Sprung zum Treffer ist besonders bei generischen Namen wie Server, LAN_Network oder historisch gewachsenen Hostgruppen wertvoll.

Die Suche ist aber nicht dasselbe wie Usage Reference. Search beantwortet: “Wo finde ich dieses Objekt oder diesen Wert?” Usage Reference beantwortet: “Welche anderen Konfigurationselemente hängen davon ab?” Für eine sichere Änderung braucht man beide Perspektiven.

Gerade diese Funktion wäre allerdings auch direkt in der Firewall-Oberfläche dringend nötig.

Aussagekräftigere Konfigurationsreports

Reports zeigen bei Firewall-, NAT- und TLS-Regeln nun nicht nur Referenznamen, sondern auch die Werte und Details der verwendeten Objekte. Statt beispielsweise nur Webserver-Gruppe zu sehen, kann der Reviewer direkt erkennen, welche Hosts oder Netze dahinter liegen.

Für Audits, Übergaben und Vier-Augen-Reviews ist das ein großer Fortschritt. Eine Regel lässt sich nur sinnvoll beurteilen, wenn Quelle, Ziel, Dienste und verknüpfte Objekte ohne zusätzliche Klickstrecke sichtbar sind. Ein Objektname kann sauber klingen und trotzdem Any, ein zu breites Netz oder längst vergessene Einträge enthalten.

Der Report unterstützt außerdem Policy Test und Analyse. Policy Test prüft, welche Regel beziehungsweise Route auf definierte Quell- und Zielwerte passt. Die Analyse sucht unter anderem nach Shadowing und Duplikaten. Da SFOS Firewall-Regeln von oben nach unten auswertet und beim ersten Treffer stoppt, ist die Reihenfolge Teil der Security-Logik und nicht nur Darstellung.

Config Studio 2.6: Migration, Vergleich und Export

Migrationsanalysen mit Erfolgsquote

Config Studio zeigt Migrations- und Konvertierungsinformationen einschließlich des Anteils, der erfolgreich übernommen wurde. Eine Prozentzahl ist dabei ein schneller Indikator, aber kein Abnahmeprotokoll.

Sophos unterscheidet bei Drittanbieter-Migrationen mehrere Zustände:

• Supported: automatisch und ohne inhaltliche Änderung migriert
• Partial: mit Lücken migriert; fehlende Teile müssen ergänzt werden
• Manual: muss auf der Sophos Firewall manuell neu erstellt werden
• Not supported: wird nicht migriert
• Action required: erfordert vor dem Export eine konkrete Entscheidung

Wenn 95 Prozent einer Konfiguration konvertiert wurden, können die fehlenden fünf Prozent ausgerechnet Zertifikate, Kennwörter, VPNs, NAT oder Sonderrouting enthalten. Der praktische Nutzen liegt deshalb nicht im grünen Prozentwert allein, sondern in der Liste der nicht, teilweise oder automatisch aufgelösten Elemente.

Die Unterschiede zwischen Herstellerlogiken sind real. FortiGate-Regeln können stärker interfacebezogen sein, während SFOS mit Zonen arbeitet. Bei Palo Alto kommen andere Objekt-, Zone- und Policy-Modelle hinzu. Config Studio kann Syntax und viele Strukturen konvertieren, aber es kann nicht automatisch beweisen, dass das Sicherheitsmodell semantisch identisch geblieben ist.

Multi-File Configuration Diff

Bisher war der klassische Vergleich vor allem ein Vorher-gegen-Nachher-Modell. Mit Multi-File Diff können zwei oder mehr Konfigurationsstände hochgeladen und über verschiedene Zeitpunkte hinweg verglichen werden. Config Studio ordnet die Dateien nach ihrem Änderungsdatum und kann Änderungen auf Feldebene als hinzugefügt, entfernt oder verändert darstellen.

Für die Darstellung stehen Side-by-Side-, Unified- und Semantic-Ansichten zur Verfügung. Der semantische Vergleich ist besonders interessant, weil ein reiner Text-Diff bei XML schnell durch Reihenfolge, IDs oder Formatierung verrauscht. Ein Entity- und Field-Level-Diff versucht stattdessen, die tatsächliche Konfigurationsänderung sichtbar zu machen.

Das ist nützlich für Change-Rekonstruktion und Fehlersuche. Wenn ein Problem nicht direkt nach einem einzelnen Wartungsfenster auffällt, kann man mehrere Exporte vergleichen und prüfen, wann eine Regel, ein Objekt oder eine Einstellung tatsächlich verändert wurde.

Der Haken bleibt: Dafür braucht man regelmäßig gespeicherte Konfigurationsstände, korrekte Zeitstempel und einen sauberen Umgang mit sensiblen Exportdaten. Das Änderungsdatum einer heruntergeladenen oder kopierten Datei muss nicht zwingend dem Zeitpunkt der Firewall-Änderung entsprechen. Für eine belastbare Historie sollten Dateiname, Exportzeit, Firewall-Hostname, Seriennummer, Firmware und zugehöriges Change-Ticket gemeinsam dokumentiert werden.

Ohne Versionsdisziplin kann auch ein Multi-File-Diff keine Historie herbeizaubern. Und genau deshalb wäre diese Funktion direkt in Central mit unveränderbarer Audit-Historie wesentlich stärker als ein manueller Datei-Upload.

Backup-Restore-, Flexi-Port- und Geschwindigkeitsreferenz

Config Studio kann die Backup-Restore-Kompatibilität und Portlayouts verschiedener Sophos-Firewall-Modelle prüfen. Zusätzlich zeigt es Informationen zu Flexi-Port-Modulen sowie unterstützten Portgeschwindigkeiten und Standards bis hin zu 25, 40 oder 100 Gbit/s.

Diese Funktion hilft bei Hardwaremigrationen. Vor dem Wechsel von einem Modell auf ein anderes lässt sich besser abschätzen:

• ob ein Backup grundsätzlich wiederhergestellt werden kann,
• wie viele physische Ports zur Verfügung stehen,
• ob bestehende Flexi-Port-Module kompatibel sind,
• welche Schnittstellenstandards und Geschwindigkeiten unterstützt werden.

Sie ersetzt trotzdem kein Migrationsdesign. LAGs, VLANs, Bridges, HA, Portnamen, Zonen und die konkrete Interface-Zuordnung müssen weiterhin geplant und nach dem Restore geprüft werden.

Die breitere Backup-Restore-Kompatibilität gilt für Ziele ab SFOS 20.0 MR2. Je nach Quellversion und Zielplattform erscheint der Backup-Restore Assistant für die Interface-Zuordnung. Physische Ports können neu gemappt werden, während VLANs und Aliases ihrer Parent-Schnittstelle folgen und LAGs oder Bridges aus den zugeordneten Ports neu aufgebaut werden.

Gerade bei Flexi Ports reicht die Frage “passt das Modul mechanisch?” nicht. Modellgeneration, Formfaktor, Transceiver, unterstützter Standard, Portgeschwindigkeit, Breakout-Verhalten und verfügbare SFOS-Version gehören zusammen geprüft. Config Studio macht die Referenz schneller, ersetzt aber keinen Link- und Failover-Test nach der Migration.

Dark Mode

Die eigentlichen Release Notes nennen zusätzlich einen Dark Mode. Das ist eine kleine Bedienverbesserung und keine Firewall-Funktion. Trotzdem ist es fast symbolisch: Selbst der Dark Mode landet zuerst im externen Config Studio, während die lokale WebAdmin-Konsole visuell und ergonomisch seit Jahren nur sehr langsam vorankommt.

Was der Editor technisch ausgeben kann

Der Editor kann Konfigurationen importieren oder neu anlegen, Bulk Changes durchführen und das Resultat vor dem Export als Import XML, API Request oder curl anzeigen. Alternativ lässt sich XML oder ein TAR-Archiv herunterladen und über Backup & firmware > Import export wieder in SFOS einspielen.

Das ist mächtig, vergrößert aber auch die Verantwortung des Admins. Ein generierter API-Request ist nicht automatisch idempotent. Ein erfolgreicher Import bestätigt nicht, dass Rule Order, Objektverwendung, NAT, VPN und Security Policies funktional richtig sind. Vor produktiver Übernahme gehören die Ausgabe in ein Change-Ticket, der Diff in ein Review und die resultierende Firewall in einen echten Datenpfad-Test.

Mehr als 50 Fixes sind der eigentliche Grund für MR2

Sophos nennt mehr als 50 behobene Zuverlässigkeits-, Stabilitäts- und Sicherheitsprobleme. Nicht jeder Fix betrifft jede Installation, aber mehrere Einträge sind operativ ernst.

Besonders relevant sind aus meiner Sicht diese Gruppen:

HA und Failsafe sind keine Randthemen

Mehrere Fixes betreffen nicht nur eine einzelne Funktion, sondern die Betriebsfähigkeit der Appliance:

• NC-181331: Eine volle Konfigurationspartition konnte die Firewall in den Failsafe Mode bringen.
• NC-180110: Auf dem Primary konnte der Logging Daemon nicht starten, worauf das HA-Gerät in Failsafe ging.
• NC-177441: Nach einem Upgrade auf v22 GA konnte das ursprüngliche Primary-Gerät durch ein Postgres-Problem in Failsafe landen.
• NC-178906: Der RED Server Service konnte nicht starten und dadurch einen Failsafe-Zustand auslösen.
• NC-177467: Das Auxiliary-Gerät startete bei sehr vielen parallelen unauthentifizierten SSH-Verbindungsversuchen nicht korrekt.

Das sind unterschiedliche Fehlerursachen, aber derselbe operative Effekt: Die Firewall verliert Dienste, geht in einen Schutzmodus oder der HA-Partner steht nicht so zur Verfügung, wie es das grüne Clusterbild vorher suggeriert hat. Genau deshalb reicht nach dem Upgrade ein Blick auf HA status: Active-Passive nicht. Man muss Synchronisation, Dienststatus, Failover und echten Traffic testen.

IPsec-Fixes greifen tief in den Datenpfad

Auch die VPN-Fixes sind technisch nicht kosmetisch:

• NC-180433: Multicast-Traffic durch einen VPN-Tunnel konnte wiederholte Firewall-Crashes auslösen.
• NC-171719: ESP-Traffic traf in einer SD-WAN-Konstellation auf falsches Routing.
• NC-180520: Bei aktiviertem IPsec Acceleration blieb ein XFRM-Gateway nach dem Upgrade unverfügbar, wenn ein Tunnel an eine Alias-IP gebunden war und ESP über einen anderen WAN-Port eintraf.
• NC-176855: IPv6-Durchsatz über route-based IPsec war beeinträchtigt.
• NC-178121: Drag-and-drop konnte Site-to-Site-IPsec-Verbindungen innerhalb einer Failover Group an falsche Positionen verschieben.

Ein Tunnelstatus Active beweist bei diesen Fehlerbildern gar nichts. Für route-based VPNs gehören XFRM-Interface, Routing Table, SD-WAN-Entscheidung, ESP-Pfad, MTU, IPv4 und IPv6 getrennt getestet. Bei Failover Groups muss zusätzlich geprüft werden, ob Reihenfolge und Umschaltung nach dem Upgrade noch der dokumentierten Priorität entsprechen.

Logging und Reporting konnten selbst Ausfälle erzeugen

NC-155252 ist ein besonders unangenehmer Fix: Hohe Disk-I/O-Last im Reporting verursachte CPU-Spitzen und intermittierende Internetausfälle von bis zu einer Minute. Das ist genau die Sorte Fehler, bei der ein Analyse-Subsystem den produktiven Datenpfad beeinträchtigt.

NC-178745 beschreibt einen automatischen Neustart eines HA-Geräts wegen Out-of-Memory im Logging Framework. NC-181520 verbessert die Performance des Log Viewers. Zusammengenommen zeigt das, dass Logging in SFOS nicht als harmlose Nebenfunktion betrachtet werden darf. Storage, Datenbank, Garner, Log Viewer und Central Reporting hängen operativ enger am System, als die Oberfläche vermuten lässt.

Nach MR2 würde ich deshalb nicht nur prüfen, ob neue Logzeilen erscheinen. Relevant sind:

• Kommen Firewall-, IPS-, WAF-, Authentication- und VPN-Events vollständig an?
• Bleibt die Zeitachse ohne Lücken?
• Erhält der externe Syslog-Collector weiterhin Daten?
• Bleiben CPU, RAM und Disk I/O unter normaler Last stabil?
• Werden Reports erzeugt, ohne den Datenpfad zu beeinträchtigen?

Central-Fixes zeigen die Grenze des “Single Pane of Glass”

Mit NC-181175 konnten Gruppen-Policies aus Sophos Central im Status Pending hängen bleiben. NC-180513 betraf den Konfigurationsimport aus der Central View nach dem Upgrade auf MR1. NC-181904 verhinderte die Freigabe von Quarantäne-Mails über Central.

Das Gemeinsame: Die zentrale Oberfläche kann einen Auftrag annehmen oder anzeigen, ohne dass die gewünschte Änderung auf der Firewall tatsächlich ausgeführt wurde. Nach einem Gruppen-Policy-Push muss daher auf dem Zielgerät geprüft werden, ob Objekt, Regel, Reihenfolge und Zeitstempel wirklich angekommen sind. Ein erfolgreich geschlossener Dialog in Central ist kein technischer Commit-Nachweis.

Diese Liste zeigt auch, warum ich Maintenance Releases nicht nur nach der Länge der Feature-Liste bewerte. Wenn eine Firewall wegen Logging, Postgres, SD-WAN oder Multicast in Failsafe geht oder neu startet, ist ein Fix dafür wertvoller als eine neue Dashboard-Kachel.

Gleichzeitig ist die Menge der Fixes kein automatisches Qualitätsprädikat. Sie zeigt, dass Probleme behoben wurden, aber auch, wie viele ernsthafte Fehler in früheren Builds vorhanden waren. Wer eine kritische HA-, VPN- oder WAF-Umgebung betreibt, sollte deshalb weder aus Angst ewig auf einem alten Build bleiben noch MR2 am ersten Tag ungeprüft überall verteilen.

Was Admins vor dem Upgrade prüfen sollten

Sophos empfiehlt, MR2 wegen der Sicherheits-, Stabilitäts- und Performance-Fixes zeitnah einzuspielen. Das ist grundsätzlich nachvollziehbar. Zeitnah heißt in produktiven Umgebungen aber nicht blind.

Legacy-VLAN-Tagging auf Bridges blockiert MR2

Neu für MR2 ist eine harte Upgrade-Sperre bei altem CLI-basiertem VLAN-Tagging auf Bridge-Interfaces. Wenn die Konfiguration noch das Legacy-Verfahren system vlan-tag verwendet, kann die Firewall nicht auf SFOS 22.0 MR2 oder neuer aktualisiert werden.

Solche Konfigurationen müssen vor dem Upgrade bereinigt oder migriert werden. Außerdem lassen sich Backups mit dieser Legacy-Konfiguration nicht auf SFOS 22.0 GA oder neuer wiederherstellen. Das ist besonders wichtig bei lange gewachsenen Installationen, die irgendwann über die CLI angepasst wurden.

Die bisherigen v22-Hürden gelten weiter

Zusätzlich bleiben die bekannten Voraussetzungen aus GA und MR1 bestehen:

• Legacy Remote Access IPsec muss vor MR1 oder MR2 entfernt beziehungsweise migriert sein.
• SFOS 22 benötigt mehr Speicherplatz; einzelne Desktop-, virtuelle oder Software-Appliances brauchen vorab eine Anpassung.
• Das Verhalten policy-basierter IPsec-VPNs hat sich seit GA geändert und muss bei entsprechenden Tunneln geprüft werden.
• XG- und SG-Hardware wird von SFOS 22 nicht unterstützt.
• Alte RED 15, RED 15w und RED 50 werden seit v21.5 nicht mehr unterstützt.

Mein Upgrade-Ablauf

Für produktive Firewalls würde ich mindestens so vorgehen:

1. Aktuelles Backup erstellen und extern sichern.
2. Support- und Lizenzstatus sowie den freigegebenen Upgrade-Pfad prüfen.
3. Legacy Remote Access IPsec und CLI-VLAN-Tagging auf Bridges ausschließen.
4. Disk-Space-Warnungen im Control Center kontrollieren.
5. Bei HA den Zustand beider Knoten, Synchronisation und verfügbare Firmware prüfen.
6. Kritische VPNs, WAF-Publikationen, Mail-Flows, SD-WAN-Regeln und Authentifizierung dokumentieren.
7. MR2 zuerst auf einer repräsentativen Test- oder weniger kritischen Appliance installieren.
8. Nach dem Upgrade Logs, Pattern-Stand, HA, Routing, DNS, VPN, WebAdmin, Reporting und zentrale Policy-Pushes testen.

Bei einem Release mit vielen Fixes ist ein sauberer Vorher-/Nachher-Test besonders wertvoll. Sonst weiß man nachher zwar, dass die Firmware neu ist, aber nicht, ob die eigenen kritischen Datenpfade noch exakt so funktionieren wie geplant.

SFOS besitzt seit Version 20 einen automatischen Firmware-Rollback, wenn die Konfigurationsmigration während des Upgrades scheitert. Das reduziert das Risiko, mit Factory Configuration statt der produktiven Konfiguration zu starten. Dieser Schutz greift aber nicht in jedem Szenario, beispielsweise nicht bei einem nicht unterstützten Upgrade-Pfad oder bestimmten Setup-Assistant-Abläufen. Nach einem automatischen Rollback gehören migration.log und migrationhash.log in die Analyse.

Und ein automatischer Rollback ist kein Ersatz für ein extern gesichertes Backup, den Secure Storage Master Key und einen erreichbaren Konsolenzugang. Er schützt primär vor einer fehlgeschlagenen Konfigurationsmigration. Er beweist nicht, dass WAF, VPN, HA oder Reporting nach einem technisch erfolgreichen Upgrade funktional korrekt sind.

Bei meinem direkten MR2-Test werde ich deshalb vor und nach dem Upgrade dieselben Punkte messen beziehungsweise provozieren:

• Neustart und vollständiger Dienstestart
• WebAdmin-Login und Reaktionszeit großer Regellisten
• lokaler und externer Logfluss
• IPsec-Datenverkehr, Rekey und Failover
• Central Policy Push mit Kontrolle auf der Firewall
• Pattern-Update für IPS und Application Control
• STAS-Neuanmeldung und Verhalten einer noch unbekannten Client-IP
• HA-Synchronisation und kontrollierter Rollenwechsel, sofern das Testsystem ein Cluster ist

Erst danach kann ich sagen, ob MR2 in meiner Umgebung wirklich besser ist. Eine erfolgreiche Installation und eine grüne Control-Center-Seite sind dafür zu wenig.

Was die ersten Community-Rückmeldungen aussagen

Der Feedback-Thread wurde am selben Tag wie MR2 eröffnet. Zum Zeitpunkt dieser Einordnung ist er erst wenige Stunden alt. Daraus kann man weder ableiten, dass MR2 stabil ist, noch dass es problematisch ist.

Zwei Diskussionen sind trotzdem erwähnenswert:

• Ein Betreiber einer XGS 5500 im Active-Passive-HA fragt ausdrücklich nach der Testtiefe, weil ihn NC-177467 unter MR1 über Monate beschäftigt habe. Sophos listet diesen Fehler in MR2 als behoben. Der Fix betrifft ein Auxiliary-Gerät, das wegen sehr vieler gleichzeitiger nicht authentifizierter SSH-Verbindungsversuche nicht startete.
• Bei den PQC-Signaturen weist ein Sophos-Mitarbeiter darauf hin, dass diese bewusst deaktiviert sind. Weil PQC-TLS in Browsern und Anwendungen zunimmt, könne eine sofortige Aktivierung zu sehr vielen Meldungen führen. Die empfohlene Richtung ist zunächst Allow mit Logging und erst später, falls wirklich nötig, eine blockierende Aktion.

Das ist eine vernünftige Frühphase für ein neues Release: konkrete Tests, Case-IDs und nachvollziehbare Rückmeldungen statt pauschalem “läuft” oder “ist kaputt”. Ich würde den Thread in den ersten Tagen und Wochen weiter beobachten, insbesondere für HA, IPsec, WAF, STAS und Reporting.

Config Studio wird zum Ersatzteillager für eine alte Oberfläche

Jetzt zum unangenehmen Teil.

Config Studio 2.6 ist ein gutes Werkzeug. Templates mergen, Objekte suchen, Referenzen im Report auflösen, mehrere Konfigurationsstände vergleichen und Hardwaremigrationen vorbereiten sind echte Admin-Funktionen. Ich kritisiere nicht, dass Sophos diese Funktionen baut. Ich kritisiere, wo sie gebaut werden.

Sophos nennt Config Studio inzwischen direkt in den Firewall-Release-Notes und in der offiziellen MR2-Ankündigung. Dadurch wirkt es zunehmend wie die strategische Antwort auf Probleme, die eigentlich in WebAdmin oder Sophos Central gelöst werden müssten.

Die lokale Firewall-Oberfläche bleibt im Alltag alt und bei größeren Konfigurationen oft langsam. Bulk-Änderungen sind unzureichend. Objektverwendungen, echte globale Suche, saubere Diffs, NAT-Cloning, Regelkonflikte und ein moderner Change-Workflow fehlen direkt dort, wo Admins täglich arbeiten. Sophos Central schließt nur einen Teil dieser Lücke.

Das Problem ist nicht nur das Design. Eine moderne Firewall-Oberfläche braucht aus meiner Sicht einen belastbaren Change-Prozess:

• Candidate Configuration statt sofort verteilter Einzeländerungen
• vollständige Vorher-/Nachher-Diffs vor dem Commit
• Abhängigkeitsprüfung über Objekte, Regeln, NAT, VPN und TLS hinweg
• atomaren Commit oder klaren Transaktionsstatus
• validierten Rollback auf den letzten bekannten Zustand
• echte Benutzer-, Zeit- und Quellenzuordnung im Audit Trail
• Bulk Operations mit Vorschau und Konfliktprüfung
• konsistente API-Ausgabe für reproduzierbare Changes

Config Studio baut Teile davon außerhalb des Systems nach. Es analysiert einen Export, erzeugt XML beziehungsweise API-Requests und hilft bei Diffs. Aber zwischen dieser Offline-Sicht und dem aktiven Laufzeitstatus der Firewall bleibt eine Lücke. Sessions, dynamisches Routing, HA-Zustand, aktuelle Pattern, Zertifikatsstatus und die tatsächlich geladene Konfiguration sind nicht dasselbe wie eine lokal geöffnete Entities.xml.

Es wäre zu weitgehend, aus einer Release-Ankündigung als Tatsache abzuleiten, dass Sophos die SFOS-Oberfläche nie mehr grundlegend modernisieren wird. Dafür gibt es keine bestätigte Aussage. Das Signal ist trotzdem schlecht: Die sichtbarsten Fortschritte bei Bedienung, Suche, Vergleich und Konfigurationsarbeit landen wieder außerhalb der eigentlichen Management-Oberflächen.

Der Workflow bleibt dadurch fragmentiert:

1. Konfiguration aus der Firewall exportieren.
2. Archiv entpacken und Entities.xml suchen.
3. Datei in ein separates Browser-Werkzeug laden.
4. Dort analysieren, vergleichen oder bearbeiten.
5. Ergebnis wieder exportieren und über XML, API oder curl zurückbringen.

Für einen Audit ist das okay. Für moderne, sichere und nachvollziehbare Administration ist es ein Umweg. Besonders irritierend ist, dass Config Studio nicht einfach nur einen Spezialfall abdeckt. Es bekommt genau jene Low-Hanging-Fruits, auf die Sophos-Admins seit Jahren warten.

Und genau hier werde ich kritischer als bisher: Wenn Sophos Config Studio inzwischen in den normalen Firewall-Release-Notes als großes Thema aufführt, dann kann man das externe Tool nicht mehr als kleine Zusatzhilfe abtun. Sophos macht es sichtbar zum Teil der Admin-Strategie. Damit steigt auch der Druck, endlich zu erklären, welche Funktionen langfristig in WebAdmin oder Central integriert werden und welche dauerhaft im Browser-Werkzeug bleiben.

Ohne diese Roadmap entsteht der Eindruck, dass die alte, langsame und in größeren Konfigurationen zunehmend benutzerunfreundliche Oberfläche im Kern bleibt und Admins für moderne Arbeitsabläufe einfach Config Studio verwenden sollen. Das ist kein bestätigter Plan von Sophos. Es ist aber die Richtung, die das Produkt aktuell vermittelt.

Warum UniFi dadurch leichtes Spiel bekommt

UniFi ist kein vollständiger Ersatz für jede Sophos-Firewall. Sophos bietet je nach Lizenz und Architektur tiefere Security-Funktionen, IPS, Web Protection, WAF, Endpoint-Integration, MDR/XDR-Anbindung und klassische Enterprise-Features. Ein fairer Vergleich darf diese Unterschiede nicht wegwischen.

Aber bei der wahrgenommenen Produktqualität gewinnt Bedienung jeden Tag.

Ubiquiti investiert sichtbar in Design, mobile Apps, konsistente Navigation, Topologie, einfache Geräteeinbindung und eine Oberfläche, die auch ohne jahrelange Produkterfahrung verständlich wirkt. Nicht jede UniFi-Funktion ist technisch tiefer. Das Produkt fühlt sich aber moderner an, und das beeinflusst Kaufentscheidungen stärker, als klassische Firewall-Hersteller gern glauben.

Wenn ein kleineres IT-Team zwischen zwei Lösungen wählt, sieht es nicht nur IPS-Datenblätter. Es sieht auch:

• Wie schnell finde ich ein Gerät, eine Regel oder einen Client?
• Kann ich die Umgebung sinnvoll vom Smartphone aus prüfen?
• Verstehe ich Warnungen und Abhängigkeiten ohne Spezialwissen?
• Wie viele Klicks brauche ich für eine alltägliche Änderung?
• Wirkt das Produkt wie eine zusammenhängende Plattform oder wie mehrere Werkzeuge nebeneinander?

Genau hier macht Sophos es Herstellern wie Ubiquiti unnötig leicht. Die Sophos Firewall kann sicherheitstechnisch mehr und für viele KMU-Umgebungen weiterhin die vernünftigere Lösung sein. Wenn Admins für moderne Suche, Diffs, Templates und Massenänderungen aber ein separates Config Studio öffnen müssen, während die Kernoberfläche alt und träge bleibt, verliert Sophos Vertrauen auf der sichtbarsten Ebene.

Gute Security braucht nicht nur eine starke Engine. Sie braucht eine Oberfläche, in der Menschen Regeln verstehen, Fehler erkennen und Änderungen sicher durchführen können. Bedienbarkeit ist deshalb kein kosmetisches Extra, sondern Teil der Betriebssicherheit.

Fazit: MR2 installieren, aber das Produktproblem bleibt

SFOS 22.0 MR2 ist kein großer Feature-Release. Es ist ein wichtiges Maintenance Release mit sinnvollen Ergänzungen.

Die PQC-Kontrolle kommt zum richtigen Zeitpunkt, sollte aber zuerst beobachtend eingeführt werden. Die bessere Erkennung generativer KI-Anwendungen hilft bei Sichtbarkeit und Policy, ersetzt aber keine DLP- oder KI-Governance-Strategie. Chromebook-Admins müssen die neue Manifest-V3-Erweiterung aktiv ausrollen. STAS wird weniger störanfällig, verlangt aber eine bewusste Prüfung der Identitätsregeln. Let’s Encrypt wird für die nächsten Zertifikatsketten vorbereitet. Und die vielen Fixes adressieren mehrere Probleme, die in produktiven Umgebungen echte Ausfälle verursachen konnten.

Ich werde MR2 direkt nach Backup und Preflight installieren und anschließend genau diese Datenpfade testen. Gerade wer von den genannten HA-, VPN-, Reporting-, Central- oder Failsafe-Problemen betroffen ist, hat gute Gründe für das Update. Ob Build 546 am Ende wirklich ruhiger läuft oder wieder neue Regressionen mitbringt, lässt sich am Release-Tag noch nicht seriös beantworten.

Meine Kritik bleibt trotzdem deutlich: Config Studio 2.6 ist nützlich, aber seine prominente Rolle im Firewall-Release verstärkt den Eindruck, dass Sophos moderne Administration in ein Nebenwerkzeug verlagert. Das ist keine bestätigte Abkündigung einer neuen SFOS-Oberfläche. Es ist aber ein strategisches Warnsignal.

Sophos hat eine starke Firewall-Basis. Der Hersteller sollte Admins endlich eine Management-Erfahrung geben, die zu dieser technischen Basis passt. Sonst gewinnen modernere Plattformen nicht unbedingt wegen besserer Security, sondern weil sie den Menschen vor dem Bildschirm ernster nehmen.

Bis zum nächsten Mal,
Euer Joe

FAQ