Sophos Firewall: Invalid TCP reserved bit door Accurate ECN

Wanneer Sophos Firewall legitiem TCP-verkeer met Invalid TCP reserved bit verwerpt, kan Accurate ECN de oorzaak zijn. Een extra Allow-regel of een uitzondering in het webfilter helpt dan niet, omdat de drop al tijdens de strikte TCP-controle plaatsvindt.

Sophos noemt het globaal uitschakelen van strict-policy als workaround. Deze wijziging mag pas na eenduidig bewijs worden uitgevoerd: ze geldt voor de volledige firewall en versoepelt niet alleen de controle van de betrokken gegevensstroom.

Fout eenduidig herkennen

De workaround is alleen geschikt als alle volgende punten van toepassing zijn:

• Een bepaalde TCP-verbinding valt reproduceerbaar uit of wordt helemaal niet opgebouwd.
• Log Viewer of Packet Capture toont Invalid TCP reserved bit als reden voor de drop.
• Firewallregel, NAT en routing komen overeen met het verwachte gegevenspad.
• Een brede Allow-regel verandert niets aan het gedrag.
• De capture van de TCP-handshake toont AE, CWR en ECE op de gedropte eerste SYN. AE heette vroeger NS en wordt door Sophos en oudere decoders nog als NS aangeduid.

Open voor de eerste test Log viewer rechtsboven in Web Admin, selecteer de module Firewall en beperk de resultaten met Timer filter en Add filter op tijd, bron-IP en doel-IP. Zoek daarnaast in de vrije tekst naar Invalid TCP reserved bit. Een afgebroken sessie verschijnt echter niet altijd meteen: Sophos Firewall logt firewallsessies normaal pas wanneer de verbinding wordt gesloten.

Bevestig de reden voor de drop daarom onder Diagnostics > Packet capture. Onder Configure beperkt bijvoorbeeld dit BPF-filter de weergave tot twee documentatieadressen en HTTPS:

host 192.0.2.10 and host 198.51.100.20 and port 443

Vervang beide IP-adressen en de poort door de waarden van de mislukte verbinding. Schakel Trace On in, start precies één verbindingspoging en stop de capture weer. Selecteer in Display filter Status: Violation en Reason: INVALID_TRAFFIC. Daarmee bevestigt SFOS de overtreding en Invalid TCP reserved bit; gebruik de WebAdmin-weergave alleen voor deze bevestiging.

Maak voor een volledige analyse van de TCP-handshake en flags afzonderlijk via SSH een tcpdump-capture die in tijd en op hosts en poort is begrensd. Sla deze als PCAP op en open hem in Wireshark of een andere decoder. Volg de handleiding Logs verzamelen met de tcpdump-tool van Sophos Firewall. Actueel Wireshark gebruikt tcp.flags.ae; tcp.flags.ns is verouderde terminologie.

Als de concrete reden voor de drop ontbreekt, mag strict-policy niet op basis van een vermoeden worden uitgeschakeld. Controleer dan eerst firewallregel, NAT en pakketstroom.

Waarom Accurate ECN als ongeldig wordt herkend

Explicit Congestion Notification, kortweg ECN, signaleert overbelasting zonder uitsluitend daarvoor een pakket te laten vallen. Accurate ECN noemt het voorheen als NS bekende bit nu AE. Sophos NC-169842 en oudere decoders gebruiken nog de naam NS.

Voor de bekende probleemsignatuur moet de TCP-handshake worden vastgelegd: de gedropte eerste SYN heeft SYN plus AE (voorheen NS), CWR en ECE. Als de SYN wordt doorgestuurd, controleer dan de SYN/ACK om vast te stellen of Accurate ECN succesvol is onderhandeld. AE/NS alleen is niet doorslaggevend. In een bestaande stroom vormen combinaties van AE, CWR en ECE de ACE-teller en niet de oude betekenis per flag. Zie RFC 9768, paragraaf 3.1.1 en paragraaf 3.2.2.

Sophos beschrijft onder NC-169842 dat de strikte pakketcontrole het AE-bit, daar nog NS genoemd, als een gereserveerd TCP-bit kan interpreteren en het verkeer kan verwerpen. Het log toont daardoor Invalid TCP reserved bit, hoewel de afzender de bits voor Accurate ECN gebruikt. De voor deze procedure gecontroleerde probleemdefinitie noemt ECE, CWR en NS (nu AE) als signatuur en geeft twee alternatieven: verkeer zonder deze Accurate-ECN-bits genereren of de TCP-controle van Strict Policy via de CLI uitschakelen.

Deze procedure is bewust beperkt tot de enige versie die toen als getroffen was aangeduid: SFOS 21.5.0 GA Build 171 (21.5.0.171); er was geen versie met een oplossing vermeld. De SFOS 22.0-help documenteert de parameter strict-policy nog steeds, maar dat toont niet aan dat NC-169842 ook SFOS 22.0 treft. Gebruik de workaround op een andere build alleen nadat de volledige signatuur is bevestigd en open eerst een Support Case met packet capture en logfragment. Als de release notes van een nieuwere build NC-169842 uitdrukkelijk als opgelost noemen, verdient die geteste update de voorkeur boven het behouden van de globale workaround.

Strict Policy controleren

De opdrachten worden uitgevoerd bij de prompt console> van de Device Console, niet in de Advanced Shell:

1. Via SSH of de lokale console aanmelden bij de firewall.
2. Selecteer in het hoofdmenu 4. Device Console.
3. Toon de huidige status:

show advanced-firewall

Zoek in de uitvoer naar deze regel:

Strict Policy                  : on

De volledige uitvoer bevat andere globale firewallparameters. Deze mogen voor deze test niet worden gewijzigd. Als de toegang nog niet is ingesteld, helpt Via SSH verbinding maken met Sophos Firewall.

In SFOS 22.0 is on de gedocumenteerde standaardwaarde. Voor de rollback blijft de zojuist met show advanced-firewall uitgelezen actuele waarde bepalend. Als deze al off is, is de workaround al actief; schakel niets om en onderzoek de situatie met Sophos Support. Advanced Firewall Settings veilig controleren legt de overige waarden, de nulmeting, controletest en rollback uit.

Workaround gecontroleerd testen

⚠️ Beveiligingsimpact: strict-policy off schakelt de strikte pakketcontrole globaal uit. Sophos Firewall verwerpt dan bepaalde ongebruikelijke of potentieel schadelijke pakketpatronen niet langer via deze controle. De opdracht maakt geen uitzondering voor één IP-adres, domein of firewallregel.

Sla vóór de wijziging een actuele configuratiestatus op, documenteer de betrokken testcase en plan een onderhoudsvenster. Voer daarna uit:

set advanced-firewall strict-policy off

Controleer de nieuwe status:

show advanced-firewall

Verwachte regel:

Strict Policy                  : off

Test nu uitsluitend de eerder gedocumenteerde gegevensstroom opnieuw. Als deze meteen werkt en Invalid TCP reserved bit verdwijnt, bevestigt dit dat Strict Policy de drop veroorzaakt. Alleen een vastgelegde handshake met SYN plus AE/NS, CWR en ECE op de gedropte eerste SYN koppelt de drop aan de signatuur van NC-169842.

Als de fout ongewijzigd blijft, schakel strict-policy dan onmiddellijk weer in. De oorzaak bevindt zich dan waarschijnlijk op een andere plaats in de pakketstroom.

Strict Policy weer inschakelen

Als de vóór de wijziging genoteerde waarde on was, is de rollbackopdracht:

set advanced-firewall strict-policy on

Controleer daarna opnieuw met show advanced-firewall of Strict Policy : on wordt weergegeven en controleer zowel de testcase als het normale gegevensverkeer. Als de herhaalde eerste SYN dezelfde AE/NS-, CWR- en ECE-signatuur bevat en hetzelfde pad volgt, zou Invalid TCP reserved bit opnieuw moeten verschijnen. Zo niet, vergelijk dan eerst de handshake-flags en het pad.

Ook als de workaround werkt, mag strict-policy off niet zonder beoordeling de permanente toestand worden. De voorkeursvolgorde is:

1. Controleer of Accurate ECN op de afzender, in het besturingssysteem, in de toepassing of op een bovenliggende dienst kan worden uitgeschakeld of anders kan worden onderhandeld.
2. Controleer of de release notes van beschikbare SFOS Maintenance Releases uitdrukkelijk een oplossing voor NC-169842 noemen.
3. Betrek Sophos Support met de SFOS-versie, tijdstempel, Source en Destination, de drop-reden en de Packet Capture.
4. Zet de globale wijziging alleen voort met risicoacceptatie, monitoring en een gedocumenteerde terugkeerprocedure als geen beperktere oplossing mogelijk is.

De benodigde informatie kan met de instructies in Sophos Firewall-logs voor een Support Case opslaan worden verzameld.

Wat niet helpt

• Een bredere firewallregel: De strikte TCP-controle is geen normale Rule Matching.
• Web- of TLS-uitzonderingen: De drop kan plaatsvinden voordat deze policies worden verwerkt.
• Een IPS-uitzondering op basis van een vermoeden: Sophos noemt voor NC-169842 uitdrukkelijk de Strict Policy als oorzaak en workaround.
• Globaal uitschakelen zonder baseline: Zonder reproduceerbare vergelijking voor en na de wijziging is niet bewezen dat Accurate ECN de oorzaak was.