Sophos Firewall: Keine CVEs, aber Bugs (v21.5 bis v22)

Wenn man sich aktuell im Firewall-Umfeld bewegt, hat man meistens mit einem von zwei großen Übeln zu kämpfen: Entweder man ist im Dauerstress wegen kritischer Sicherheitslücken (CVEs, wie aktuell bei Fortinet) und patcht sich die Nächte um die Ohren – oder die Systeme werfen einem im regulären Betrieb durch instabile Firmware und nervige Bugs (wie aktuell bei Sophos) so viele Steine in den Weg, dass man zu nichts anderem mehr kommt.

Bei meiner Arbeit in der Firma trifft gerade Letzteres voll zu – ein Stress, den ich teils natürlich auch mit nach Hause nehme. Unser aktueller Schmerzpunkt trägt den Namen: Sophos Firewall.

Während Mitbewerber wie Fortinet gefühlt im Wochentakt neue PSIRT-Advisories herausfeuern und Administratoren im Patch-Takt rotieren lassen, frisst bei uns Sophos massiv Zeit. Nicht wegen Schlagzeilen-trächtiger Lücken, sondern wegen ganz banaler, aber kritischer Bugs im Systemalltag.

Disclaimer, damit das nicht nach Äpfel-mit-Birnen klingt: Mir ist völlig klar, dass auch Fortinet mit massiven Bugs kämpft (Stichwort Conserve Mode und Memory Leaks in FortiOS 7.2/7.4/7.6) und dass auch Sophos in der Vergangenheit schon heftige CVEs hatte. In der aktuellen v21.5/v22-Phase drückt der Schuh bei uns aber genau in dieser speziellen Konstellation: Bei den einen ist es ständiges CVE-Patching, bei Sophos ist es unnötige Ops-Arbeit durch Stabilitätsprobleme.

Versionskontext (TL;DR)

Damit klar ist, dass ich nicht von einer verstaubten v19 schreibe, sondern von dem, was viele gerade als “aktuell” fahren:

• SFOS 21.5 GA (02.06.2025): Release Notes: SFOS 21.5
• SFOS 21.5 MR2 (Build 323, 18.02.2026): laut Release Notes die neueste 21.5 im Zeitraum.
• SFOS 22.0 GA (Dezember 2025) und v22 GA Re-Release (Build 411, 20.01.2026): Release Notes: SFOS 22.0

Das sind GA und Maintenance Releases, keine “random Nightlies”.

Damit der Vergleich nicht nur gefühlt ist, hier ein kurzer Realitätscheck.

Fortinet: FortiOS CVEs seit November 2025 (Stand 26.02.2026)

Zeitraum: 01.11.2025 bis 26.02.2026 (Published Date). Quelle: Fortinet PSIRT Advisories (PSIRT Übersicht).

Ich liste hier bewusst nicht “alles Fortinet”, sondern die FortiOS/FortiGate-relevanten Advisories im Zeitraum, weil das in der Praxis der Schmerz ist: Du musst patchen, planen, testen.

CVSS ist nicht alles, aber es macht den Operations-Kontrast sichtbar: Ein Medium mit 5.x ist oft planbar, ein 9.x ist schnell ein “drop everything and patch”.

Published 10. Februar 2026 (mehrere Advisories am selben Tag)

• FG-IR-25-667 (CVE-2025-55018, CVSSv3 5.2): Request smuggling in der FortiOS GUI. Unschön auch deshalb, weil es um “unlogged requests” geht.
• FG-IR-25-795 (CVE-2025-64157, CVSSv3 6.7): Format-String-Problem im CAPWAP Fast-Failover-Modus (Admin/Config als Trigger).
• FG-IR-25-1052 (CVE-2026-22153, CVSSv3 7.5): LDAP Authentication Bypass in Agentless VPN/FSSO (Workaround in der Praxis oft: unauthenticated bind auf dem LDAP-Server deaktivieren).
• FG-IR-25-934 (CVE-2025-68686, CVSSv3 5.3): SSL VPN Symlink Persistence Patch Bypass. Wichtig zur Einordnung: Laut Advisory braucht es zuerst eine Kompromittierung über eine andere Schwachstelle auf Filesystem-Level.
• FG-IR-25-384 (CVE-2025-62439, CVSSv3 3.8): Policy Bypass im FSSO Terminal Services Agent (Fix ist eine Kombi aus FortiOS-Version und Mindestversion des TS Agents).

Januar 2026

• FG-IR-26-060 (CVE-2026-24858, CVSSv3 9.4), published 27.01.2026: Administrative FortiCloud SSO Auth Bypass. Das Advisory beschreibt auch Exploitation in the wild und konkrete Gegenmaßnahmen.
• FG-IR-25-084 (CVE-2025-25249, CVSSv3 7.4), published 13.01.2026: Heap-based buffer overflow im cw_acd daemon (FortiOS/FortiSwitchManager).

Published 09. Dezember 2025

• FG-IR-25-647 (CVE-2025-59718, CVE-2025-59719, CVSSv3 9.1): FortiCloud SSO Login Auth Bypass via crafted SAML Message (Feature nicht zwingend Default, aber real im Feld).
• FG-IR-25-411 (CVE-2025-62631, CVSSv3 5.3): Insufficient Session Expiration in SSL VPN (Session-Lebensdauer/Password-Change Edge Case).
• FG-IR-24-268 (CVE-2024-47570, CVSSv3 6.3): Sensitive Information landet in REST API Logs (wenn REST-API-Logging aktiv ist).
• FG-IR-24-133 (CVE-2024-40593, CVSSv3 5.9): Private key kann von Admin gelesen werden (Key-Management-Fehler, fixbar über Patchlevel).

Published 18. November 2025

• FG-IR-25-358 (CVE-2025-53843, CVSSv3 6.9): CAPWAP daemon Stack buffer overflow.
• FG-IR-25-632 (CVE-2025-58413, CVSSv3 6.9): Noch ein CAPWAP daemon Stack buffer overflow.
• FG-IR-25-545 (CVE-2025-54821, CVSSv3 1.8): Trusted hosts Bypass via SSH (CLI Edge Case).

Ja: Das ist viel. Und ja: Das kann man mit Prozessen erschlagen (Patch-Window, Staging, Change-Management, Wartungsfenster).

Und dann kommt die andere Seite.

Sophos: keine Schlagzeilen, aber der Betrieb brennt

Bei Sophos reden wir natürlich auch über Security. Aber was uns gerade wirklich Zeit frisst, sind schlicht Bugs.

Wir haben aktuell in der Firma so viel unnötige Arbeit, weil die Firewall einfach Probleme macht. Und irgendwann erwischst du dich bei einer Frage, die eigentlich absurd ist:

Was ist mir lieber: eine Firewall mit einer Sicherheitslücke, die dafür stabil läuft, oder eine Firewall ohne große CVE-Schlagzeilen, die nach dem Boot nicht mehr hochkommt?

Das ist keine akademische Debatte. Das ist Operations. Eine theoretische Sicherheitslücke, die irgendwann vielleicht einmal ausgenutzt werden könnte, ist mir traurigerweise mittlerweile fast lieber als ein Kunde, dessen Netzwerk wegen eines banalen Bugs schon wieder für mehrere Stunden komplett down ist.

Unsere aktuellen Pain Points (ja, alle auf einmal)

Und um das klarzustellen: Das sind nur die Bugs, die wir in den letzten Monaten diverse Male und bei verschiedenen Systemen hatten. Es ist einfach nur zermürbend und frustrierend, wenn der Betrieb zum Projekt wird. Vor allem, wenn man dann mal wieder im Sophos Support-Karussell landet und dort gerne so getan wird, als wäre man “weltweit der erste und einzige Kunde mit genau diesem Problem”. Nein, sind wir nicht.

• Die Firewall kommt nach einem Boot manchmal nicht sauber hoch.
• Das HA-Cluster bricht auseinander oder verhält sich wie Split-Brain.
• Logging ist plötzlich unzuverlässig (oder komplett weg).
• Let’s Encrypt Zertifikate werden nicht erneuert und man darf nachts manuell nachfassen.
• Ein Interface fehlt oder ist in der GUI plötzlich nicht mehr sichtbar.
• SSDs verabschieden sich (kaputte Hardware).
• Der WebAdmin-Login streikt komplett – man kann sich nicht mehr anmelden, oft hilft nur ein Reboot.
• Interfaces fehlen plötzlich komplett in der Config.
• Die Log-Disk läuft voll, woraufhin Fehlermeldungen auftauchen oder betroffene Services direkt stoppen.

Was die Community dazu sagt (ihr seid nicht allein!)

Wenn man sich in der Sophos Community umschaut (Stand Anfang 2026), deckt sich das Bild der nachlassenden Qualität leider. Zu unseren Problemen gesellen sich in v21.5 / v22 bei anderen Usern noch weitere, heftige Showstopper:

• Kaputte SSL-VPN-Profile (v22.0 Build 411): Einige User berichten, dass nach dem Upgrade auf die aktuellste v22 das Erstellen von SSL-VPN-Profilen fehlschlägt. Sie mussten teilweise einen Rollback auf v21.5 durchführen, da die neue Version schlichtweg zu fehleranfällig ist.
• Defektes SNAT / Webserver-Zugriff (v22.0 Build 365): Es gibt Meldungen, dass nach dem Update der Zugriff auf interne Webserver von außen bricht. Oft streikt das Internet-Routing komplett, bis man SNAT manuell auf die Standard-MASQ-Option zurücksetzt.
• CLI Spam / “Invalid rule id”: In der Konsole tauchen massenhaft Warnungen wie “Invalid rule id or family for update” auf. (Das scheint “nur” ein Anzeigefehler zu sein, aber er flutet sinnlos die Logs).

Und das Bittere an all dem: Jede einzelne dieser Sachen ist nicht nur nervig, sondern ein massives Risiko. Wenn Logs fehlen, fliegst du blind. Wenn HA wackelt, verlierst du das Vertrauen ins Failover. Wenn Zertifikate nicht erneuert werden, bastelst du Workarounds. Und Workarounds sind nun mal der Nährboden für spätere Incidents.

Sophos Bugs (v21.5 bis v22): das, was direkt auf eure Symptome einzahlt

Ich nenne hier bewusst konkrete NC-IDs aus den offiziellen Release Notes oder offiziell dokumentierte Known Issues, damit du das als Admin auch sauber nachvollziehen kannst.

TL;DR: Symptom -> was dazu in den Notes steht

Eine genervte Story aus dem Betrieb

Wir sitzen morgens da und machen das, was man immer macht: Tickets abarbeiten, Changes planen, Monitoring lesen.

Und dann klopft die Firewall an die Tür, ohne anzuklopfen.

Nicht mit einer CVE, nicht mit einem “Critical Advisory”. Sondern mit Alltag.

Erster Kaffee, erster Restart und die Frage im Kopf: Kommt sie wieder hoch oder nicht?

Wenn es gut läuft, kommt sie hoch. Wenn es schlecht läuft, landet sie irgendwo zwischen “Failsafe” und “lebt, aber verarbeitet keinen Traffic”. Und während du noch darüber nachdenkst, ob du jetzt wirklich schon wieder eine Konsole brauchst, geht das nächste Kapitel auf.

HA. Dein Airbag. Und manchmal fühlt es sich an, als würde der Airbag beim Einparken auslösen.

Dann Logging. Wir wissen alle: Wenn du nicht siehst, was passiert, kannst du es nicht steuern. Und plötzlich fehlen Logs, Reports sind leer oder ein Dienst verabschiedet sich. Du stehst da und fragst dich, ob du gerade ein Security-Problem hast oder ein Datenqualitätsproblem oder beides.

Und dann kommt der Showstopper: WAF, Reverse Proxy, Let’s Encrypt.

Du willst nicht mal fancy sein. Du willst nur, dass Zertifikate erneuert werden und dass deine Websites nicht um 02:13 Uhr “connection refused” schreien.

Und als Bonus ist ein Interface “weg”. Nicht wirklich weg, nur weg in der UI. Traffic läuft vielleicht sogar, aber du siehst nicht, was du debuggen musst.

Irgendwann stellst du dir dann diese Frage, die eigentlich absurd ist:

Was ist mir lieber: eine Firewall mit einer Sicherheitslücke, die dafür stabil läuft, oder eine Firewall ohne große CVE-Schlagzeilen, die mir operativ jede Woche neue Löcher in den Boden frisst?

1) Boot, Reboot, Upgrade: “Sie lebt noch, aber arbeitet nicht”

Wenn eine Firewall nach einem Boot nicht sauber hochkommt, ist das nicht einfach “Uptime”. Das ist ein verlorener Tag plus Risiko, weil du in so einer Situation gern Dinge tust, die du sonst nie tun würdest.

Ein paar Beispiele aus SFOS 21.5 Release Notes:

• Failsafe beim Restart: NC-151715 (Firmware Management): Auxiliary device ging beim Neustart in Failsafe; Restart schlug fehl.
• Traffic stoppt nach Upgrade: NC-152641 (Firmware Management): Nach Upgrade (21.0 MR1 Build 237) wurde kein Traffic mehr verarbeitet (SWAP Memory Config Changes).
• Kernel Panic: NC-123910 (Firewall): Kernel panic issue.

Und ja: SFOS 22.0 bringt zusätzlich noch einen Upgrade-Faktor rein: Sophos weist in den Release Notes darauf hin, dass v22 architektonische Änderungen mitbringt und in seltenen Fällen zusätzliche manuelle Schritte nötig sein können. Genau das ist die Art Upgrade-Edge-Case, die im Betrieb weh tut.

2) HA: der Airbag, der beim Einparken auslöst

HA ist dein Sicherheitsnetz. Und genau deshalb tut es so weh, wenn ausgerechnet dort Edge Cases eskalieren.

Aus den SFOS 21.5 Release Notes (Auswahl):

• HA Event Tracking stoppt bei gleichzeitigen Restarts: NC-142962 (HA).
• Firmware Upload auf Passiv hängt: NC-132291 (HA).
• Failover führt zu Restart Loop: NC-147307 (HA) (in den Notes explizit z. B. XGS 2300).
• Sync failt nach Power Outage: NC-147739 (HA).
• HA Status flapped, Crash Dump bei Dedicated Link: NC-149039 (HA).

3) Logging und Reporting: wenn du blind fliegst

Das hier ist für mich der eigentliche Punkt, warum “Bugs” nicht einfach nur “Betrieb” sind. Wenn Logging/Reporting wackelt, ist das ein Security-Problem.

Aus den SFOS 21.5 Release Notes (Auswahl):

• Logging/Reporting stoppt sporadisch; Garner coredump häufig: NC-158526 (Logging Framework).
• Garner und fwcm-heartbeatd stoppen: NC-160962 (Logging Framework).
• Nach Upgrade: keine Reports mehr: NC-157663 (Logging Framework).
• Log Viewer verliert Events durch DB Corruption: NC-169237 (Logging Framework).
• Syslog fd corruption, Daten gehen an falschen FD: NC-135594 (Logging Framework).

Zusätzlich findest du in der Sophos Known Issues List (KIL) ein paar Punkte, die im Alltag genauso schmerzhaft sind:

• Log Viewer zeigt keine neuen Daten (active.db fehlt): NC-175936 (Logging Framework). Auf manchen 21.5.1-Systemen kann die active.db unter /tmp/eventlogs/ fehlen. Dann “friert” der Log Viewer ein, obwohl Traffic und Security-Funktionen weiterlaufen. Laut KIL ist das in v22 behoben und sollte in einem 21.5 MR2 Fix landen.
• False Positive “advanced threat detected” in HA: NC-170292 (Logging Framework). Sophos Central kann in HA Deployments einen Alert schicken, inklusive raw logs in der Beschreibung. Workaround laut KIL: Garner-Service neu starten. KBA: https://support.sophos.com/support/s/article/KBA-000043672
• ReportDB_v9 zeigt STOPPED (wirkt dramatisch, ist es aber nicht): NC-166381 (Reporting). Nach Upgrade auf v21.0 GA oder später taucht der Service nach einer sehr spezifischen Zeitspanne als STOPPED auf. Laut KIL ist das expected und hat keinen operativen Impact, weil es nur Legacy-Reporting vor v21 betrifft.

Und hier kommt der “Sophos Central Faktor”: Wenn du Central als Single Pane of Glass nutzt, tut ein Logging-Problem doppelt weh. Wenn die lokale Logging-Pipeline (Garner/DB) kippt, kann auch der Upload Richtung Central Firewall Reporting (CFR) aussetzen oder hängen. Und CFR ist ohnehin nicht immer “realtime”. Heißt: Im Worst Case fehlen dir nicht nur lokale Logs, sondern auch genau die zentrale Sicht, auf die du dich im Alltag eigentlich verlassen wolltest.

4) WAF und Let’s Encrypt: Public Service, aber bitte ohne Drama

Wenn Zertifikate nicht erneuert werden und der Reverse Proxy spinnt, ist das nicht “ein kleiner Bug”. Das ist direkt Customer Impact.

In den SFOS 21.5 Release Notes findest du eine ganze Familie an WAF/Let’s-Encrypt-Problemen:

• Let’s Encrypt cert creation scheitert: NC-148937 (WAF).
• LE Request klappt nicht, weil Auto-Firewall-Rule fehlt: NC-152022 (WAF).
• Invalid LE Config lässt Reverse Proxy dauernd restarten: NC-140663 (WAF).
• ACME stellt keine Zertifikate für IPs aus: NC-141062 (WAF).
• WAF Rule toggelt automatisch an/aus: NC-152540 (WAF).

Und dann gibt es noch “wirkt wie Bug, ist aber Security-Tradeoff”-Themen. Beispiel aus dem KIL:

• Encoded slashes (%2F) in URLs: WAF liefert 404: NC-159041 (WAF). Wenn deine App encoded slashes in der URL nutzt, blockt Apache das standardmäßig (Directive AllowEncodedSlashes steht default auf No) und du siehst 404, obwohl das Backend den Pfad “eigentlich” hat. Hintergrund: encoded slashes können Pfad-Restriktionen aushebeln (klassisches Beispiel: .../something%2F..%2Fadmin). Details: https://httpd.apache.org/docs/2.4/mod/core.html#allowencodedslashes

Und wenn du wissen willst, wie das im Feld aussieht: In diesem Community-Thread beschreibt jemand nach Upgrade auf 21.5.x, dass Auto-Renew-Zertifikate “weg” waren, WAF nicht startete und Websites mit ERR_CONNECTION_REFUSED starben. Die Lösung war am Ende: Cleanup der Web Protection Rules und das Löschen kaputter LE CSRs, danach lief es wieder. (Thread: WAF/Let’s Encrypt nach Upgrade, ERR_CONNECTION_REFUSED).

Und manchmal ist es nicht mal ein “Bug”, sondern Prozess: In der Sophos Community gab es auch Fälle, in denen die Let’s Encrypt Terms of Service im WebAdmin als abgelaufen markiert waren und erneut akzeptiert werden mussten. (Thread: Let’s Encrypt Terms of Service have expired).

Zusätzlicher “Upgrade-Fallen”-Klassiker aus der Known Issues List: Ein Upgrade kann scheitern, wenn bereits ein Onboard-Zertifikat denselben Namen trägt wie neu eingeführte Let’s-Encrypt-Zertifikate im CA Store (NC-146082).

5) “Ein Interface fehlt” (oder ist nur unsichtbar)

Das ist so ein Bug, der im Release Note trocken klingt, aber dich in der Praxis in den Blindflug zwingt.

Offiziell als Known Issue dokumentiert:

Wenn ein physisches oder logisches Interface in SFOS 21.5 GA und später eine Bezeichnung hat, die mit 10 oder mehr Zahlen endet (Beispiel in den Notes: VLAN_1234567890), dann sind im WebAdmin unter Network > Interfaces physische Interfaces nicht sichtbar oder logische Interfaces lassen sich nicht aufklappen. Wichtig: Laut Release Notes ist die Funktion nicht betroffen, nur die Darstellung in der WebAdmin Console.

Zwischenfazit (bis hierher): Boot/Upgrade, HA, Logging/Reporting, WAF/Let’s Encrypt und sogar die UI können dir gleichzeitig Beine stellen. Ab hier kommen die Themen, die erst wie “Netzwerk-Details” wirken, aber operativ genauso teuer sind: Entra SSO, VPN-Interop und scheinbar zufällige Traffic-Drops.

6) Identity/SSO (Entra) und Captive Portal: wenn Access “random” wirkt

Das ist die Kategorie Bugs, die im Betrieb besonders perfide ist: Für den User sieht es aus wie “mein Account spinnt”. Für dich sieht es aus wie “das ist doch nur SSO”. In Wahrheit ist es oft die Firewall dazwischen.

Ein paar offene Themen aus dem KIL, wenn Microsoft Entra ID (Azure AD) bei dir im Mix ist:

• Sophos Connect VPN: Conditional Access nicht vollständig supported: NC-167126 (Authentication). Nach dem ersten MFA-Challenge bei der Erstanmeldung greifen Conditional-Access-Checks nicht zwingend bei jeder weiteren Verbindung. Laut KIL passiert erneute Policy Enforcement erst, wenn der User im Sophos Connect Client manuell ausgeloggt wird.
• VPN SSO: UPN und Email unterschiedlich, Login bricht: NC-157635 (Authentication). Wenn Email-ID und UPN in Entra unterschiedlich sind, können User zwar aufs VPN Portal, aber nicht ins SSL VPN oder IPsec Portal. Ursache laut KIL: der OAuth Header liefert Email, die dann als UPN interpretiert wird.
• Captive Portal: Entra SSO Users brauchen Primary Group in der Rule: NC-167130 (Authentication). Internet-Zugriff klappt nur, wenn du die Primary Group im Firewall Rule Match verwendest (Secondary Groups zählen hier nicht). Fix laut KIL in “next maintenance releases”; Workaround: Primary Group explizit matchen oder userbasierte Rules.
• Gelegentliche “no permission” Fehler bei Entra SSO: NC-167128 (Authentication). Kann auftreten, wenn Entra ID Auth und On-Prem AD Auth parallel genutzt werden (Token-Reuse). Workarounds laut KIL: Browser-Cookies löschen oder “force re-logon” im Sophos Connect Client. Alternativ eine Auth-Methode konsistent verwenden.

7) VPN/IPsec Interop: Upgrades scheitern oft am “Gegner”

Zwei KIL-Themen, die nicht erst mit 21.5 gestartet haben, aber in 21.5/v22 weiter relevant sind, sobald du alte Clients oder Gegenstellen im Feld hast:

• IPsec IKEv2: Tunnel kommt nicht hoch (Fragmentation/PMTU): NC-136352 (IPsec). Ab 20.0 MR1 kann das Default-IKEv2-Profil größere Pakete erzeugen (mehr Default-Felder), teils über 1500 Bytes. Wenn Fragmentierung/PMTU in der Strecke schlecht ist (Fragments werden gedroppt), kommt der S2S Tunnel nicht hoch. Mitigation laut KIL: im IPsec Profil die DH Groups reduzieren (Minimum 4) oder exakt die Gruppe(n) konfigurieren, die am Gegenüber verwendet werden.
• SSL VPN/OpenVPN 2.6.0: Inkompatibilität mit EoL Clients/UTM9: NC-128116 (SSLVPN). Ab 20.0 MR1 ist OpenVPN auf 2.6.0. Damit brechen u. a. Site-to-site SSL VPNs mit alten SFOS-Versionen (18.5 und älter), Legacy-SSL-VPN-Clients (EoL) und UTM9 OS. Empfehlung laut KIL: beide Seiten upgraden oder auf IPsec/RED ausweichen; Remote: Sophos Connect oder aktuelle OpenVPN Clients nutzen.

8) Traffic Drops ohne Regel-Hit: Accurate ECN als fiese Ursache

Wenn Traffic “random” dropped wirkt, suchst du als erstes in Regeln, IPS, TLS Inspection und Routing. Und nach Firmware-Upgrades kommt noch ein Klassiker dazu: Die IPS-Engine (Snort) oder Signaturen werden strenger, blocken legitimen Traffic und du findest nicht sofort ein klares Log-Event dazu. Dann debuggt man stundenlang “Routing” oder “Regeln”, obwohl es am Ende Policy- oder Tuning-Arbeit ist.

Im KIL gibt es aber auch einen Kandidaten, der dich sehr lange beschäftigen kann, wenn du ihn nicht auf dem Schirm hast:

• Traffic wird gedroppt wegen Accurate ECN Bits: NC-169842 (Firewall). Accurate ECN setzt TCP Bits (ECE/CWR/NS) anders (RFC 7560). Laut KIL interpretiert der Kernel das als “reserved bit set” und droppt Traffic. In der Eingrenzung hilft ein Blick auf die Client-Seite: In der Praxis kann das eher bei neueren Linux-Kernels oder Apple-Clients auffallen, weil diese RFC 7560/Accurate ECN tendenziell aktiver nutzen (“warum fliegen nur die MacBooks raus?”). RFC: https://www.rfc-editor.org/rfc/rfc7560

9) v22 GA Re-Release Build 411: warum es das überhaupt brauchte

Am 20. Januar 2026 hat Sophos v22 GA als Re-Release (Build 411) nachgeschoben, um “rare and isolated issues” zu fixen. Die Liste liest sich wie ein Best-Of von “unnötige Arbeit im Change Window” (Quelle: Sophos Community Blogpost zum Re-Release):

• NC-171003: WebAdmin nicht erreichbar über Bridge Interface mit VLAN filtering.
• NC-170987: CLI Spam Log “Invalid rule id or family for update”.
• NC-170970: DNAT Traffic failt, wenn DNAT Rule ein spezifisches outbound interface hat.
• NC-171600: SSL/TLS Widget und Session Chart Data falsch/leer.
• NC-172197: Keine SNMP-Konfiguration hinzufügbar.

Blogpost: v22 GA re-release (Build 411) is now available.

Der eigentliche Schaden: Bugs machen Security teurer

Der Punkt ist nicht “Bugs sind schlimmer als CVEs” oder umgekehrt.

Der Punkt ist: Wenn dein Betrieb wackelt, wird Security automatisch schlechter.

• Du upgradest später, weil du Angst vor dem nächsten Regression-Bug hast.
• Du schaltest Features ab (“brauchen wir gerade nicht”), weil sie Stress machen.
• Du verlierst Observability (Logs), also Geschwindigkeit in der Reaktion.
• Du investierst Zeit in Feuerwehrarbeit statt in Segmentierung, Backups und saubere Regeln.

Und ein Punkt, den man in der Praxis komplett unterschätzt: Time-to-Resolution. Bei einer CVE hast du meist Advisory, Mitigation und Fix. Bei einem Bug liegt der Beweisdruck schnell beim Admin: tcpdump, CTR-Logs, Advanced-Shell-Export, “schon neu gestartet?” - während die Produktion brennt. Und erst danach landest du im Support-Karussell: eskalieren, auf einen Hotfix oder das nächste MR warten. Das frisst zusätzliche Ops-Zeit, die du so nicht geplant hast.

Und genau deshalb ist die Frage “Lieber eine Lücke, aber stabil?” zwar menschlich, aber eigentlich die falsche Abzweigung:

Nicht nur “die Lücke” ist ein Sicherheitsproblem. Auch “die instabile Firewall” ist ein Sicherheitsproblem.

Was wir daraus mitnehmen (damit es nicht komplett eskaliert)

Ein paar Dinge, die uns helfen, den Wahnsinn zu begrenzen, ohne jede Woche das Rad neu zu erfinden:

Upgrade-Preflight (bevor du anfängst)

• Backups wie Restore behandeln: Konfig exportieren, offline sichern, Restore mindestens einmal getestet.
• HA-Status “grün” reicht nicht – testet den Failover! Laut GUI war bei uns der Sync ok und der Heartbeat sauber. Aber im Ernstfall hat die Auxiliary Appliance den Failover trotzdem nicht sauber übernommen. Ein grüner Haken in der WebAdmin ist aktuell leider keine Garantie, dass es im Change-Window funktioniert.
• Logging verifizieren: Externer Syslog/Collector bekommt Events, keine Lücken, Zeit/NTP passt.
• Zertifikate/WAF prüfen: Ablaufdaten, Let’s Encrypt Validierung, Fallback-Zertifikat als Plan B.
• SSO/VPN wirklich durchtesten: Entra Login, Captive Portal, Sophos Connect, SSL VPN, IPsec S2S (inkl. Failover) sind eigene Testfälle.
• Break-Glass ready: Konsole/Out-of-band, lokale Admins, Firmware-Images für Rollback.
• Dual-Boot nicht vergessen (und nicht überschätzen): Sophos hat zwei Firmware-Partitionen. Wenn ein Upgrade daneben geht, ist der Rollback zu 21.5 oft nur ein Reboot mit Auswahl der anderen Partition. Aber: Es gibt auch Fälle, in denen die zweite Partition ebenfalls nicht sauber bootet und dann nur ein Reimage hilft (was der Support gefühlt sehr schnell fordert). Und selbst ein Reimage löst nicht immer die eigentliche Ursache.

Während des Upgrades (wenn HA im Spiel ist)

• Passive/Secondary zuerst, dann Failover, dann Active.
• Nach jedem Schritt kurz validieren: Traffic, VPN, DNS, Logging, WAF/Reverse Proxy.

Im laufenden Betrieb

• HA testen, nicht nur konfigurieren: Failover-Drills und klare Kriterien, wann man ein Cluster trennt.
• Logging als Produkt behandeln: Alarme bei Log-Lücken, Service Health, Notfall-Export per CLI, wenn die UI spinnt.
• Zertifikate aktiv monitoren: Renewal ist kein “nice to have”, sondern Betriebsrisiko. ToS-Änderungen wie Changes behandeln.
• Health Check als Hinweis, nicht als KPI: In v22 hat Sophos den Health Check eingeführt (Details in meinem Artikel Sophos Firewall v22 Health Check - Vollständige Übersicht ). Das ist als Best-Practice-Checkliste gut, wirkt aber teilweise wie “Ökosystem-Schalter auf grün stellen”. Beispiel aus der Praxis: Viele aktivieren den Login-Disclaimer nur, damit der Haken im Health Check grün wird. Was mir dort dagegen fehlt: harte Betriebsindikatoren wie “ist die Logging/Reporting-DB gesund?” oder “wie steht es um die SSD?” - gerade weil es bei einigen Appliances schneller als erwartet zu Storage-Problemen kam.

Fazit: Wenn das Tool zum Risiko wird

Am Ende des Tages sitzen wir alle im selben Boot. Wir verwalten kritische Infrastruktur und müssen uns darauf verlassen können, dass die Werkzeuge, die uns eigentlich vor dem Chaos bewahren sollen, nicht selbst das Chaos auslösen. Sophos hat mit der aktuellen Firmware-Qualität (v21.5 / v22) definitiv massive Hausaufgaben zu erledigen. Das Vertrauen in “stabile Releases” hat bei uns und vielen anderen aus der Community einen heftigen Knacks bekommen.

Ich will keine Firewall, die “entweder sicher oder stabil” ist. Ich will – nein, ich brauche – eine Firewall, die beides ist.

Bis Sophos diese Qualitätsmängel wieder in den Griff bekommt, bleibt uns in den Operations nur eins: Wir müssen noch disziplinierter werden, nichts mehr auf “grüne Haken” im UI geben und banale Bugs in der Deployment-Planung genauso ernst nehmen wie kritische CVEs.

Bis zum nächsten Mal,
Joe

Sources

• Fortinet PSIRT Advisories
• Sophos Firewall Release Notes v21.5
• Sophos Firewall Release Notes v22.0
• Sophos KIL (Known issues)
• Sophos Community: v22 GA re-release Build 411
• Sophos Community Thread (Let’s Encrypt/WAF)
• Sophos Community Thread (Let’s Encrypt ToS)
• Apache docs: AllowEncodedSlashes
• Sophos KBA (Garner false positive advanced threat)
• RFC 7560 (Accurate ECN)