Sophos Firewall: Invalid TCP reserved bit durch Accurate ECN

Wenn Sophos Firewall legitimen TCP-Traffic mit Invalid TCP reserved bit verwirft, kann Accurate ECN die Ursache sein. Eine zusätzliche Allow-Regel oder eine Ausnahme im Webfilter hilft dann nicht, weil der Drop bereits bei der strikten TCP-Prüfung erfolgt.

Sophos nennt als Workaround das globale Abschalten von strict-policy. Diese Änderung sollte erst nach einem eindeutigen Nachweis erfolgen: Sie gilt für die ganze Firewall und lockert nicht nur den betroffenen Datenstrom.

Fehler eindeutig erkennen

Der Workaround passt nur, wenn alle folgenden Punkte zusammenkommen:

• Eine bestimmte TCP-Verbindung bricht reproduzierbar ab oder baut sich gar nicht auf.
• Log Viewer oder Packet Capture zeigt Invalid TCP reserved bit als Drop-Grund.
• Firewall-Regel, NAT und Routing passen zum erwarteten Datenpfad.
• Eine breite Allow-Regel ändert das Verhalten nicht.
• Der Mitschnitt des TCP-Handshakes zeigt beim verworfenen initialen SYN die Flags AE, CWR und ECE. AE hiess früher NS und wird von Sophos sowie älteren Decodern weiterhin als NS bezeichnet.

Für den ersten Test Log viewer oben rechts im Web Admin öffnen, das Modul Firewall wählen und mit Timer filter sowie Add filter nach Zeit, Quell- und Ziel-IP eingrenzen. Zusätzlich im Freitext nach Invalid TCP reserved bit suchen. Eine abgebrochene Sitzung erscheint jedoch nicht zwingend sofort im Log: Sophos Firewall protokolliert Firewall-Sitzungen normalerweise erst beim Verbindungsabbau.

Den Drop-Grund deshalb unter Diagnostics > Packet capture bestätigen. Unter Configure begrenzt beispielsweise dieser BPF-Filter die Anzeige auf zwei Dokumentationsadressen und HTTPS:

host 192.0.2.10 and host 198.51.100.20 and port 443

Beide IP-Adressen und den Port durch die Werte der gestörten Verbindung ersetzen. Dann Trace On einschalten, genau einen Verbindungsversuch auslösen und die Aufzeichnung wieder ausschalten. In Display filter Status: Violation und Reason: INVALID_TRAFFIC wählen. Damit bestätigt SFOS die Violation und den Grund Invalid TCP reserved bit; die WebAdmin-Ansicht dient hier nur dieser Bestätigung.

Für die vollständige Analyse des TCP-Handshakes und der Flags separat über SSH einen zeitlich und nach Hosts sowie Port begrenzten tcpdump-Mitschnitt erstellen, als PCAP speichern und in Wireshark oder einem anderen Decoder öffnen. Die Schritte stehen unter Sophos Firewall tcpdump Tool: Logs sammeln. Aktuelles Wireshark verwendet für AE das Anzeigefeld tcp.flags.ae; tcp.flags.ns ist die frühere Bezeichnung.

Fehlt der konkrete Drop-Grund, sollte strict-policy nicht auf Verdacht deaktiviert werden. Dann zuerst Firewall-Regel, NAT und Paketfluss prüfen.

Warum Accurate ECN als ungültig erkannt wird

Explicit Congestion Notification, kurz ECN, signalisiert eine Überlastung, ohne ein Paket allein zu diesem Zweck zu verwerfen. Accurate ECN erweitert dieses Verfahren und nennt das früher als NS bezeichnete Bit heute AE. Sophos NC-169842 und ältere Decoder verwenden weiterhin den Namen NS.

Für die bekannte Signatur muss der TCP-Handshake erfasst werden: Das von der Firewall verworfene initiale SYN hat SYN sowie AE (früher NS), CWR und ECE gesetzt. Wird das SYN weitergeleitet, zeigt die Prüfung des SYN/ACK, ob Accurate ECN erfolgreich ausgehandelt wurde. AE/NS allein ist kein eindeutiger Nachweis. In einem etablierten Datenstrom bilden die Kombinationen aus AE, CWR und ECE den ACE-Zähler; sie haben dort nicht die einzelnen Bedeutungen der klassischen TCP-Flags. Dies ist in RFC 9768, Abschnitt 3.1.1 und Abschnitt 3.2.2 definiert.

Sophos beschreibt unter NC-169842, dass die strikte Paketprüfung das dabei verwendete, dort noch NS genannte AE-Bit als gesetztes reserviertes TCP-Bit interpretieren und den Traffic verwerfen kann. Im Log erscheint deshalb Invalid TCP reserved bit, obwohl der Sender die Bits für Accurate ECN verwendet. Die für diese Anleitung geprüfte Problemdefinition nennt als Signatur ECE, CWR und NS (heute AE) und als Alternativen Traffic ohne diese Accurate-ECN-Bits oder das Abschalten der strikten TCP-Prüfung per CLI.

Die Anwendbarkeit dieser Anleitung ist bewusst auf die dabei einzig als betroffen ausgewiesene Version SFOS 21.5.0 GA Build 171 (21.5.0.171) begrenzt; eine Fix-Version war nicht ausgewiesen. Die SFOS-22.0-Hilfe dokumentiert zwar weiterhin den Parameter strict-policy, belegt aber nicht, dass NC-169842 auch SFOS 22.0 betrifft. Auf einem anderen Build den Workaround deshalb nur nach der vollständigen Signaturprüfung verwenden und zuvor einen Support Case mit Paketmitschnitt und Logauszug eröffnen. Wenn Release Notes eines neueren Builds NC-169842 ausdrücklich als behoben nennen, ist das getestete Update dem dauerhaften globalen Workaround vorzuziehen.

Strict Policy prüfen

Die Befehle werden am Prompt console> der Device Console ausgeführt, nicht in der Advanced Shell:

1. Per SSH oder über die lokale Konsole an der Firewall anmelden.
2. Im Hauptmenü 4. Device Console wählen.
3. Aktuellen Zustand anzeigen:

show advanced-firewall

In der Ausgabe nach dieser Zeile suchen:

Strict Policy                  : on

Die vollständige Ausgabe enthält weitere globale Firewall-Parameter. Diese sollten für diesen Test nicht verändert werden. Falls der Zugang noch nicht eingerichtet ist, hilft Sophos Firewall per SSH verbinden.

In SFOS 22.0 ist on der dokumentierte Standardwert. Massgebend für den Rückweg ist trotzdem der soeben mit show advanced-firewall ausgelesene Istwert. Steht er bereits auf off, ist der Workaround schon aktiv; dann nichts umschalten, sondern den Fall mit Sophos Support untersuchen. Die Funktion der übrigen Werte sowie Baseline, Kontrolltest und Rollback erklärt Advanced Firewall Settings sicher prüfen.

Workaround kontrolliert testen

⚠️ Sicherheitswirkung: strict-policy off schaltet die strikte Paketprüfung global aus. Sophos Firewall verwirft dann bestimmte ungewöhnliche oder potenziell schädliche Paketmuster nicht mehr über diese Prüfung. Der Befehl ist keine Ausnahme für eine einzelne IP, Domain oder Firewall-Regel.

Vor der Änderung einen aktuellen Konfigurationsstand sichern, den betroffenen Testfall dokumentieren und ein Wartungsfenster festlegen. Anschliessend:

set advanced-firewall strict-policy off

Den neuen Zustand prüfen:

show advanced-firewall

Erwartete Zeile:

Strict Policy                  : off

Jetzt ausschliesslich den zuvor dokumentierten Datenstrom erneut testen. Funktioniert er unmittelbar und verschwindet der Drop-Grund Invalid TCP reserved bit, bestätigt dies, dass Strict Policy den Drop auslöst. Erst der mitgeschnittene Handshake mit SYN sowie AE/NS, CWR und ECE im verworfenen initialen SYN ordnet den Drop der Signatur von NC-169842 zu.

Bleibt der Fehler unverändert, strict-policy sofort wieder aktivieren. Die Ursache liegt dann wahrscheinlich an einer anderen Stelle im Paketfluss.

Strict Policy wieder aktivieren

Wenn der vor der Änderung notierte Wert on war, lautet der Rückkehrbefehl:

set advanced-firewall strict-policy on

Danach erneut mit show advanced-firewall prüfen, ob Strict Policy : on angezeigt wird, und sowohl den Testfall als auch normalen Datenverkehr kontrollieren. Enthält das wiederholte initiale SYN dieselbe Signatur aus AE/NS, CWR und ECE und nimmt es denselben Pfad, sollte Invalid TCP reserved bit erneut auftreten. Ist das nicht der Fall, zuerst die Handshake-Flags und den Pfad vergleichen, bevor ein Schluss aus dem Kontrolltest gezogen wird.

Auch wenn der Workaround funktioniert, sollte strict-policy off nicht ohne Bewertung zum Dauerzustand werden. Die bevorzugte Reihenfolge ist:

1. Prüfen, ob Sender, Betriebssystem, Anwendung oder vorgelagerter Dienst Accurate ECN deaktivieren beziehungsweise anders aushandeln kann.
2. In den Release Notes der verfügbaren SFOS Maintenance Releases prüfen, ob NC-169842 ausdrücklich als behoben genannt wird.
3. Sophos Support mit SFOS-Version, Zeitstempel, Source und Destination, Drop-Grund sowie Packet Capture einbeziehen.
4. Nur wenn keine engere Lösung möglich ist, die globale Änderung mit Risikoakzeptanz, Monitoring und dokumentiertem Rückweg weiterbetreiben.

Die benötigten Nachweise lassen sich mit der Anleitung Sophos Firewall Logs für einen Support Case sichern zusammenstellen.

Was nicht hilft

• Eine breitere Firewall-Regel: Die strikte TCP-Prüfung ist kein normales Rule-Matching.
• Web- oder TLS-Ausnahmen: Der Drop kann vor der Verarbeitung durch diese Policies erfolgen.
• Eine IPS-Ausnahme auf Verdacht: Sophos nennt für NC-169842 ausdrücklich die Strict Policy als Ursache und Workaround.
• Das globale Abschalten ohne Baseline: Ohne reproduzierbaren Vorher-nachher-Test ist nicht belegt, dass Accurate ECN die Ursache war.