Sophos Firewall: Invalid TCP reserved bit på grund av Accurate ECN

När Sophos Firewall nekar legitim TCP-trafik med Invalid TCP reserved bit kan Accurate ECN vara orsaken. En extra Allow-regel eller ett undantag i webbfiltret hjälper då inte, eftersom trafiken nekas redan under den strikta TCP-kontrollen.

Sophos anger global avstängning av strict-policy som en tillfällig lösning. Ändringen bör endast göras efter ett entydigt belägg: den gäller för hela brandväggen och luckrar inte bara upp kontrollen av det berörda dataflödet.

Identifiera felet entydigt

Den tillfälliga lösningen är endast lämplig om samtliga följande punkter stämmer:

• En viss TCP-anslutning avbryts reproducerbart eller upprättas inte alls.
• Log Viewer eller Packet Capture visar Invalid TCP reserved bit som orsak till nekandet.
• Brandväggsregeln, NAT och routningen stämmer överens med den förväntade datavägen.
• En bred Allow-regel ändrar inte beteendet.
• Insamlingen av TCP-handskakningen visar AE, CWR och ECE på det nekade inledande SYN-paketet. AE kallades tidigare NS och betecknas fortfarande NS av Sophos och äldre avkodare.

Öppna först Log viewer uppe till höger i Web Admin, välj modulen Firewall och begränsa resultatet efter tid, käll-IP och mål-IP med Timer filter och Add filter. Sök även efter Invalid TCP reserved bit som fritext. En avbruten session visas dock inte alltid omedelbart: Sophos Firewall loggar normalt brandväggssessioner när anslutningen stängs.

Bekräfta därför orsaken till nekandet under Diagnostics > Packet capture. Under Configure begränsar exempelvis detta BPF-filter visningen till två dokumentationsadresser och HTTPS:

host 192.0.2.10 and host 198.51.100.20 and port 443

Ersätt båda IP-adresserna och porten med värdena för anslutningen som inte fungerar. Aktivera Trace On, utlös exakt ett anslutningsförsök och stoppa sedan insamlingen igen. Välj Status: Violation och Reason: INVALID_TRAFFIC i Display filter. Därmed bekräftar SFOS överträdelsen och orsaken Invalid TCP reserved bit; använd endast WebAdmin-vyn för denna bekräftelse.

För en fullständig analys av TCP-handskakningen och flaggorna ska en separat tcpdump-insamling göras via SSH, avgränsad efter tid, värdar och port. Spara den som PCAP och öppna den i Wireshark eller en annan avkodare. Följ anvisningarna i Samla in loggar med tcpdump-verktyget på Sophos Firewall. Aktuella Wireshark använder tcp.flags.ae; tcp.flags.ns är äldre terminologi.

Om den konkreta orsaken till nekandet saknas bör strict-policy inte stängas av på grund av en misstanke. Kontrollera då först brandväggsregel, NAT och paketflöde.

Varför Accurate ECN identifieras som ogiltigt

Explicit Congestion Notification, förkortat ECN, signalerar överbelastning utan att ett paket behöver kasseras enbart av den anledningen. Accurate ECN kallar numera biten som tidigare hette NS för AE. Sophos NC-169842 och äldre avkodare använder fortfarande namnet NS.

För att identifiera det kända problemets signatur måste TCP-handskakningen samlas in: det nekade inledande SYN-paketet har SYN samt AE (tidigare NS), CWR och ECE aktiverade. Om SYN vidarebefordras ska SYN/ACK granskas för att fastställa om Accurate ECN förhandlades fram. AE/NS ensamt är inte avgörande. I ett etablerat flöde bildar kombinationerna av AE, CWR och ECE ACE-räknaren i stället för att behålla flaggornas äldre enskilda betydelser. Se RFC 9768 avsnitt 3.1.1 och avsnitt 3.2.2.

Sophos beskriver under NC-169842 att den strikta paketkontrollen kan tolka AE-biten, som där fortfarande kallas NS, som en reserverad TCP-bit och neka trafiken. Loggen visar därför Invalid TCP reserved bit, trots att avsändaren använder bitarna för Accurate ECN. Problemdefinitionen som kontrollerades för den här anvisningen anger ECE, CWR och NS (nu AE) som signatur och två alternativ: generera trafik utan dessa Accurate-ECN-bitar eller stäng av TCP-kontrollen Strict Policy via CLI.

Anvisningen är avsiktligt begränsad till den enda version som då angavs som berörd: SFOS 21.5.0 GA Build 171 (21.5.0.171); ingen version med korrigering angavs. Hjälpen för SFOS 22.0 dokumenterar fortfarande parametern strict-policy, men det visar inte att NC-169842 även berör SFOS 22.0. På en annan build ska den tillfälliga lösningen användas först efter att hela signaturen har verifierats och ett Support Case med paketinsamling och loggutdrag har öppnats. Om versionsinformationen för en nyare build uttryckligen anger att NC-169842 är korrigerat ska den testade uppdateringen väljas framför att behålla den globala lösningen.

Kontrollera Strict Policy

Kommandona körs vid prompten console> i Device Console, inte i Advanced Shell:

1. Logga in på brandväggen via SSH eller den lokala konsolen.
2. Välj 4. Device Console på huvudmenyn.
3. Visa aktuell status:

show advanced-firewall

Leta efter denna rad i utdata:

Strict Policy                  : on

Den fullständiga utdatan innehåller andra globala brandväggsparametrar. Dessa bör inte ändras för det här testet. Om åtkomsten ännu inte är konfigurerad finns hjälp i Anslut till Sophos Firewall via SSH.

I SFOS 22.0 är on det dokumenterade standardvärdet. För återställningen gäller ändå det aktuella värde som precis lästes av med show advanced-firewall. Om det redan är off är den tillfälliga lösningen aktiv; ändra inget utan undersök fallet med Sophos Support. Kontrollera Advanced Firewall Settings säkert förklarar övriga värden samt baslinje, kontrolltest och återställning.

Testa den tillfälliga lösningen kontrollerat

⚠️ Säkerhetspåverkan: strict-policy off stänger av den strikta paketkontrollen globalt. Sophos Firewall nekar då inte längre vissa ovanliga eller potentiellt skadliga paketmönster genom denna kontroll. Kommandot skapar inget undantag för en enskild IP-adress, domän eller brandväggsregel.

Spara ett aktuellt konfigurationsläge före ändringen, dokumentera det berörda testfallet och fastställ ett underhållsfönster. Kör därefter:

set advanced-firewall strict-policy off

Kontrollera den nya statusen:

show advanced-firewall

Förväntad rad:

Strict Policy                  : off

Testa nu enbart det tidigare dokumenterade dataflödet på nytt. Om det fungerar omedelbart och Invalid TCP reserved bit försvinner bekräftar det att Strict Policy orsakar nekandet. Endast en insamlad handskakning med SYN samt AE/NS, CWR och ECE på det nekade inledande SYN-paketet kopplar nekandet till signaturen för NC-169842.

Om felet kvarstår oförändrat ska strict-policy omedelbart aktiveras igen. Orsaken finns då sannolikt på en annan plats i paketflödet.

Aktivera Strict Policy igen

Om värdet som noterades före ändringen var on är återställningskommandot:

set advanced-firewall strict-policy on

Kontrollera därefter återigen med show advanced-firewall att Strict Policy : on visas och kontrollera både testfallet och den normala datatrafiken. Om det upprepade inledande SYN-paketet innehåller samma AE/NS-, CWR- och ECE-signatur och följer samma väg bör Invalid TCP reserved bit återkomma. Om inte, jämför handskakningens flaggor och vägen innan en slutsats dras.

Även om den tillfälliga lösningen fungerar bör strict-policy off inte bli ett permanent läge utan utvärdering. Föredragen ordning är:

1. Kontrollera om avsändaren, operativsystemet, programmet eller en uppströmstjänst kan stänga av Accurate ECN eller förhandla det på annat sätt.
2. Kontrollera om versionsinformationen för tillgängliga SFOS Maintenance Releases uttryckligen nämner en korrigering för NC-169842.
3. Kontakta Sophos Support med SFOS-version, tidsstämpel, Source och Destination, orsaken till nekandet samt Packet Capture.
4. Fortsätt endast med den globala ändringen tillsammans med riskacceptans, övervakning och en dokumenterad återgångsplan om ingen mer begränsad lösning är möjlig.

Nödvändigt underlag kan sammanställas med instruktionerna i Spara Sophos Firewall-loggar för ett Support Case.

Vad som inte hjälper

• En bredare brandväggsregel: Den strikta TCP-kontrollen är inte vanlig regelmatchning.
• Webb- eller TLS-undantag: Trafiken kan nekas före bearbetning av dessa policyer.
• Ett IPS-undantag på grund av en misstanke: För NC-169842 anger Sophos uttryckligen Strict Policy som orsak och tillfällig lösning.
• Global avstängning utan baslinje: Utan ett reproducerbart test före och efter ändringen är det inte bevisat att Accurate ECN var orsaken.