Sophos Firewall: bit TCP riservato non valido causato da Accurate ECN

Se Sophos Firewall scarta traffico TCP legittimo con Invalid TCP reserved bit, la causa può essere Accurate ECN. Una regola Allow aggiuntiva o un’eccezione nel filtro Web non risolvono il problema in questo caso, perché il drop avviene già durante la validazione TCP rigorosa.

Sophos indica come workaround la disattivazione globale di strict-policy. Questa modifica deve essere eseguita soltanto dopo aver ottenuto una prova chiara: si applica all’intero firewall e non attenua il controllo unicamente per il flusso interessato.

Identificare l’errore in modo inequivocabile

Il workaround è appropriato solo se si verificano tutte le condizioni seguenti:

• Una specifica connessione TCP fallisce in modo riproducibile o non viene stabilita.
• Log Viewer o Packet Capture mostra Invalid TCP reserved bit come motivo del drop.
• La regola firewall, NAT e il routing corrispondono al percorso previsto del traffico.
• Una regola Allow ampia non modifica il comportamento.
• La cattura dell’handshake TCP mostra AE, CWR ed ECE impostati sul SYN iniziale scartato. AE era precedentemente denominato NS ed è ancora indicato come NS da Sophos e dai decoder meno recenti.

Per il primo test, aprire Log viewer nell’angolo in alto a destra di Web Admin, selezionare il modulo Firewall e limitare i risultati per intervallo di tempo, IP sorgente e IP di destinazione con Timer filter e Add filter. Cercare inoltre Invalid TCP reserved bit come testo libero. Una sessione interrotta potrebbe tuttavia non apparire subito: Sophos Firewall registra normalmente le sessioni firewall quando la connessione viene chiusa.

Occorre quindi confermare il motivo del drop in Diagnostics > Packet capture. In Configure, ad esempio, questo filtro BPF limita la visualizzazione a due indirizzi di documentazione e a HTTPS:

host 192.0.2.10 and host 198.51.100.20 and port 443

Sostituire entrambi gli indirizzi IP e la porta con i valori della connessione che non funziona. Attivare Trace On, generare un solo tentativo di connessione e disattivare nuovamente la cattura. In Display filter, selezionare Status: Violation e Reason: INVALID_TRAFFIC. SFOS conferma così la violazione e il motivo Invalid TCP reserved bit; usare la vista WebAdmin solo per questa conferma.

Per l’analisi completa dell’handshake TCP e dei flag, eseguire separatamente tramite SSH una cattura tcpdump limitata nel tempo e filtrata per host e porta. Salvarla come PCAP e aprirla in Wireshark o in un altro decoder. Seguire la procedura Raccogliere i log con lo strumento tcpdump di Sophos Firewall. Wireshark attuale usa il campo di visualizzazione tcp.flags.ae; tcp.flags.ns è la terminologia precedente.

Se manca il motivo specifico del drop, strict-policy non deve essere disattivato per precauzione. Prima occorre testare la regola firewall, NAT e il flusso dei pacchetti.

Perché Accurate ECN viene identificato come non valido

Explicit Congestion Notification, o ECN, segnala una congestione senza scartare un pacchetto al solo scopo di comunicarla. Accurate ECN estende questo meccanismo e denomina AE il bit precedentemente noto come NS. Sophos NC-169842 e i decoder meno recenti usano ancora il nome NS.

Per riconoscere la firma del problema noto è necessario catturare l’handshake TCP: il SYN iniziale scartato presenta SYN insieme ad AE (in precedenza NS), CWR ed ECE. Se il SYN viene inoltrato, esaminare il SYN/ACK per stabilire se la negoziazione Accurate ECN è riuscita. AE/NS da solo non è conclusivo. In un flusso stabilito, le combinazioni di AE, CWR ed ECE formano il contatore ACE anziché mantenere i significati tradizionali dei singoli flag. Vedere RFC 9768, sezione 3.1.1 e sezione 3.2.2.

Sophos indica in NC-169842 che la validazione rigorosa dei pacchetti può interpretare il bit AE, ancora denominato NS, come un bit TCP riservato impostato e scartare il traffico. Nel log compare quindi Invalid TCP reserved bit, anche se il mittente utilizza i bit per Accurate ECN. La definizione del problema verificata per questa procedura identifica ECE, CWR e NS (ora AE) come firma e indica due alternative: generare traffico privo di tali bit Accurate ECN oppure disattivare dalla CLI il controllo TCP Strict Policy.

Questa procedura è volutamente limitata all’unica versione allora identificata come interessata: SFOS 21.5.0 GA Build 171 (21.5.0.171); non era indicata alcuna versione correttiva. La guida di SFOS 22.0 documenta ancora il parametro strict-policy, ma ciò non dimostra che NC-169842 interessi anche SFOS 22.0. Su un’altra build, usare il workaround solo dopo aver verificato la firma completa e aprire prima un caso di supporto con cattura dei pacchetti ed estratto del log. Se le note di rilascio di una build più recente indicano esplicitamente la correzione di NC-169842, preferire tale aggiornamento testato al mantenimento del workaround globale.

Controllare Strict Policy

I comandi devono essere eseguiti al prompt console> della Device Console, non nell’Advanced Shell:

1. Accedere al firewall tramite SSH o dalla console locale.
2. Nel menu principale selezionare 4. Device Console.
3. Visualizzare lo stato attuale:

show advanced-firewall

Cercare questa riga nell’output:

Strict Policy                  : on

L’output completo contiene altri parametri globali del firewall. Questi non devono essere modificati per il test. Se l’accesso non è ancora configurato, consultare Connettersi a Sophos Firewall tramite SSH.

In SFOS 22.0, on è il valore predefinito documentato. Per il rollback fa comunque fede il valore appena rilevato con show advanced-firewall. Se è già off, il workaround è già attivo: non modificarlo e analizzare il caso con Sophos Support. Verificare in sicurezza le Advanced Firewall Settings spiega gli altri valori, oltre a baseline, test di controllo e rollback.

Testare il workaround in modo controllato

⚠️ Effetto sulla sicurezza: strict-policy off disattiva globalmente la validazione rigorosa dei pacchetti. Sophos Firewall non respinge più, mediante questo controllo, determinati pattern di pacchetti insoliti o potenzialmente dannosi. Il comando non crea un’eccezione per un singolo indirizzo IP, dominio o regola firewall.

Prima della modifica, salvare uno stato aggiornato della configurazione, documentare il caso di test interessato e pianificare una finestra di manutenzione. Eseguire quindi:

set advanced-firewall strict-policy off

Controllare il nuovo stato:

show advanced-firewall

Riga prevista:

Strict Policy                  : off

A questo punto, ripetere il test esclusivamente sul flusso documentato in precedenza. Se funziona subito e Invalid TCP reserved bit scompare, ciò conferma che Strict Policy causa il drop. Solo un handshake catturato che mostri SYN insieme ad AE/NS, CWR ed ECE sul SYN iniziale scartato associa il drop alla firma di NC-169842.

Se l’errore rimane invariato, riattivare immediatamente strict-policy. La causa si trova quindi probabilmente in un altro punto del flusso dei pacchetti.

Riattivare Strict Policy

Se il valore annotato prima della modifica era on, il comando di rollback è:

set advanced-firewall strict-policy on

Usare quindi nuovamente show advanced-firewall per verificare che venga visualizzato Strict Policy : on e controllare sia il caso di test sia il traffico normale. Se il SYN iniziale ripetuto contiene la stessa firma AE/NS, CWR ed ECE e segue lo stesso percorso, Invalid TCP reserved bit dovrebbe ricomparire. In caso contrario, confrontare i flag dell’handshake e il percorso prima di trarre conclusioni dal test di controllo.

Anche se il workaround funziona, strict-policy off non deve diventare uno stato permanente senza una valutazione. L’ordine da preferire è:

1. Verificare se il mittente, il sistema operativo, l’applicazione o il servizio a monte può disattivare Accurate ECN o negoziarlo in modo diverso.
2. Controllare se le note delle versioni di manutenzione SFOS disponibili menzionano esplicitamente una correzione per NC-169842.
3. Coinvolgere Sophos Support fornendo versione SFOS, timestamp, sorgente e destinazione, motivo del drop e Packet Capture.
4. Solo se non è possibile adottare una soluzione più specifica, mantenere la modifica globale dopo aver accettato il rischio e documentato il monitoraggio e la procedura di ripristino.

Le prove necessarie possono essere raccolte con Salvare i log di Sophos Firewall per un caso di supporto.

Cosa non risolve il problema

• Una regola firewall più ampia: La validazione TCP rigorosa non è normale matching delle regole.
• Eccezioni Web o TLS: Il drop può avvenire prima dell’elaborazione da parte di queste policy.
• Un’eccezione IPS per precauzione: Per NC-169842, Sophos indica esplicitamente Strict Policy come causa e workaround.
• La disattivazione globale senza una baseline: Senza un test prima-dopo riproducibile, non è dimostrato che Accurate ECN fosse la causa.