Sophos Firewall: Niente CVE, ma piena di bug (da v21.5 a v22)

Se in questo periodo lavori nel mondo dei firewall, di solito ti trovi a combattere contro uno di questi due grandi mali: o sei costantemente stressato da vulnerabilità critiche (CVE, come accade ora con Fortinet) e passi le notti a installare patch, oppure i sistemi ti mettono così tanti bastoni tra le ruote durante le normali operazioni a causa di firmware instabili e fastidiosi bug (come succede ora con Sophos) che non riesci a fare nient’altro.

Nel mio lavoro in azienda, è proprio quest’ultima situazione a verificarsi: uno stress che, naturalmente, a volte finisco per portarmi a casa. Il nostro attuale grattacapo si chiama: Sophos Firewall.

Mentre concorrenti come Fortinet sembrano sfornare nuovi avvisi PSIRT quasi ogni settimana, costringendo gli amministratori a ruotare in un ciclo continuo di patch, Sophos ci sta divorando il tempo in modo massiccio. Non per vulnerabilità che fanno notizia, ma per bug del tutto banali, eppure critici nel lavoro quotidiano.

Disclaimer, per non sembrare che si stiano paragonando mele con pere: Sono pienamente consapevole che anche Fortinet lotta con bug enormi (basti pensare al Conserve Mode e ai Memory Leak in FortiOS 7.2/7.4/7.6) e che anche Sophos ha avuto la sua dose di CVE gravi in passato. Tuttavia, nell’attuale fase v21.5/v22, la situazione ci colpisce esattamente in questo modo: da una parte c’è il costante patching delle CVE; con Sophos, è lavoro operativo inutile causato da problemi di stabilità.

Contesto delle versioni (In breve)

Giusto per chiarire che non sto scrivendo di una vecchia v19 impolverata, ma di ciò che molti stanno attualmente eseguendo come “aggiornato”:

• SFOS 21.5 GA (02.06.2025): Note di rilascio: SFOS 21.5
• SFOS 21.5 MR2 (Build 323, 18.02.2026): Secondo le note di rilascio, la 21.5 più recente in questo periodo.
• SFOS 22.0 GA (Dicembre 2025) e v22 GA Re-Release (Build 411, 20.01.2026): Note di rilascio: SFOS 22.0

Queste sono GA (General Availability) e Maintenance Release, non “nightly” a caso.

Per assicurarci che questo paragone non si basi solo su sensazioni, ecco un rapido controllo della realtà.

Fortinet: CVE di FortiOS da novembre 2025 (Al 26.02.2026)

Periodo: dal 01.11.2025 al 26.02.2026 (Data di pubblicazione). Fonte: Avvisi PSIRT di Fortinet (Panoramica PSIRT).

Scelgo deliberatamente di non elencare “tutto Fortinet” qui, ma solo gli avvisi rilevanti per FortiOS/FortiGate in questo periodo, perché nella pratica è lì che fa male: devi patchare, pianificare, testare.

Il CVSS non è tutto, ma rende visibile il contrasto operativo: un livello Medio con 5.x è spesso pianificabile, un 9.x diventa rapidamente uno scenario “molla tutto e patcha”.

Pubblicati il 10 febbraio 2026 (Più avvisi nello stesso giorno)

• FG-IR-25-667 (CVE-2025-55018, CVSSv3 5.2): Request smuggling nella GUI di FortiOS. Spiacevole anche perché coinvolge “richieste non registrate” (unlogged requests).
• FG-IR-25-795 (CVE-2025-64157, CVSSv3 6.7): Problema di Format-String in modalità CAPWAP Fast-Failover (Admin/Config come trigger).
• FG-IR-25-1052 (CVE-2026-22153, CVSSv3 7.5): Bypass dell’autenticazione LDAP in Agentless VPN/FSSO (Workaround nella pratica spesso: disabilitare l’unauthenticated bind sul server LDAP).
• FG-IR-25-934 (CVE-2025-68686, CVSSv3 5.3): Bypass di SSL VPN Symlink Persistence Patch. Importante per il contesto: secondo l’avviso, richiede una precedente compromissione tramite un’altra vulnerabilità a livello di file system.
• FG-IR-25-384 (CVE-2025-62439, CVSSv3 3.8): Policy Bypass nell’Agente FSSO Terminal Services (La soluzione è una combinazione tra la versione di FortiOS e la versione minima dell’Agente TS).

Gennaio 2026

• FG-IR-26-060 (CVE-2026-24858, CVSSv3 9.4), pubblicato il 27.01.2026: Bypass dell’autenticazione SSO amministrativa in FortiCloud. L’avviso descrive anche lo sfruttamento “in the wild” e le contromisure specifiche.
• FG-IR-25-084 (CVE-2025-25249, CVSSv3 7.4), pubblicato il 13.01.2026: Heap-based buffer overflow nel demone cw_acd (FortiOS/FortiSwitchManager).

Pubblicati il 9 dicembre 2025

• FG-IR-25-647 (CVE-2025-59718, CVE-2025-59719, CVSSv3 9.1): Bypass dell’autenticazione FortiCloud SSO Login tramite messaggio SAML manipolato (Funzionalità non obbligatoriamente attiva di default, ma reale sul campo).
• FG-IR-25-411 (CVE-2025-62631, CVSSv3 5.3): Scadenza della sessione insufficiente in SSL VPN (Durata della sessione/Caso limite di cambio password).
• FG-IR-24-268 (CVE-2024-47570, CVSSv3 6.3): Informazioni sensibili finiscono nei Log dell’API REST (se la registrazione dell’API REST è attiva).
• FG-IR-24-133 (CVE-2024-40593, CVSSv3 5.9): La chiave privata può essere letta da un Admin (Errore di gestione delle chiavi, risolvibile tramite patch).

Pubblicati il 18 novembre 2025

• FG-IR-25-358 (CVE-2025-53843, CVSSv3 6.9): Stack buffer overflow nel demone CAPWAP.
• FG-IR-25-632 (CVE-2025-58413, CVSSv3 6.9): Un altro Stack buffer overflow nel demone CAPWAP.
• FG-IR-25-545 (CVE-2025-54821, CVSSv3 1.8): Bypass di Trusted hosts tramite SSH (Caso limite CLI).

Sì, è molto. E sì, lo si può gestire con i processi (Finestre di patch, Staging, Change Management, Finestre di manutenzione).

E poi c’è l’altra faccia della medaglia.

Sophos: Nessun titolone, ma le Operations sono in fiamme

Con Sophos, ovviamente, parliamo anche di sicurezza. Ma quello che ci sta davvero mangiando il tempo in questo momento sono semplicemente i bug.

Attualmente abbiamo così tanto lavoro inutile in azienda perché il firewall continua a creare problemi. E a un certo punto, ti ritrovi a farti una domanda in realtà assurda:

Cosa preferisco: un firewall con una vulnerabilità di sicurezza che funziona in modo stabile, o un firewall senza grandi titoli sulle CVE che non si riavvia dopo un boot?

Questo non è un dibattito accademico. Questo è Operations. Tristemente, ormai preferisco quasi una vulnerabilità teorica che potrebbe essere sfruttata prima o poi, rispetto a un cliente la cui rete è completamente inattiva per diverse ore a causa di un bug banale.

I nostri attuali punti deboli (Sì, tutti insieme)

E per essere chiari: questi sono solo i bug che abbiamo riscontrato molte volte e su sistemi diversi negli ultimi mesi. È semplicemente estenuante e frustrante quando la gestione operativa si trasforma in un progetto. Soprattutto quando finisci di nuovo nel tritacarne del Supporto Sophos e a loro piace fingere che tu sia “il primo e unico cliente in tutto il mondo con esattamente questo problema”. No, non lo siamo.

• A volte il firewall non si avvia in modo pulito dopo un riavvio.
• Il cluster HA si sfascia o si comporta come uno split-brain.
• Il logging improvvisamente diventa inaffidabile (o scompare del tutto).
• I certificati Let’s Encrypt non si rinnovano, e ti tocca sistemarli a mano di notte.
• Manca un’interfaccia o improvvisamente non è più visibile nella GUI.
• Gli SSD muoiono (hardware difettoso).
• Il login di WebAdmin fa sciopero: non puoi più accedere, spesso aiuta solo un riavvio.
• Le interfacce spariscono improvvisamente del tutto dalla configurazione.
• Il disco dei log si riempie, provocando la comparsa di messaggi di errore o il blocco diretto dei servizi interessati.

Cosa dice la community (Non siete soli!)

Se si dà un’occhiata alla Sophos Community (a inizio 2026), il quadro di un calo della qualità purtroppo coincide con la nostra esperienza. Oltre ai nostri problemi, in v21.5 / v22 altri utenti si scontrano con blocchi (showstopper) ancora più pesanti:

• Profili SSL-VPN corrotti (v22.0 Build 411): Alcuni utenti segnalano che, dopo l’aggiornamento all’ultima v22, la creazione dei profili SSL-VPN fallisce. A volte hanno dovuto effettuare un rollback alla v21.5 perché la nuova versione è semplicemente troppo piena di bug.
• SNAT rotto / Accesso ai server web (v22.0 Build 365): Ci sono segnalazioni che, dopo l’aggiornamento, l’accesso ai server web interni dall’esterno si interrompe. Spesso, il routing Internet si blocca completamente finché lo SNAT non viene reimpostato manualmente sull’opzione standard MASQ.
• Spam CLI / “Invalid rule id”: Sulla console compaiono in massa avvisi del tipo “Invalid rule id or family for update”. (Questo sembra essere “solo” un errore di visualizzazione, ma inonda i log senza motivo).

E la cosa più amara di tutte: ognuna di queste cose non è solo fastidiosa, è un rischio enorme. Se mancano i log, voli alla cieca. Se l’HA traballa, perdi fiducia nel failover. Se i certificati non si rinnovano, ti inventi soluzioni tampone (workaround). E i workaround sono terreno fertile per futuri incidenti.

I bug di Sophos (da v21.5 a v22): L’impatto diretto sui tuoi sintomi

Elenco qui volutamente degli NC-ID specifici tratti dalle Release Note ufficiali o dai Known Issues (Problemi noti) ufficialmente documentati, in modo che tu, come amministratore, possa verificarli in modo chiaro.

TL;DR: Sintomo -> Cosa dicono le note

Una storia di frustrazione dalle Operations

La mattina ci sediamo a fare quello che si fa sempre: evadere i ticket, pianificare le modifiche, leggere il monitoraggio.

E poi il firewall bussa alla porta, senza bussare.

Non con una CVE, non con un “Critical Advisory”. Ma con la quotidianità.

Primo caffè, primo riavvio e la domanda in testa: Ripartirà o no?

Se va bene, si riavvia. Se va male, finisce da qualche parte tra il “Failsafe” e “vivo, ma non elabora il traffico”. E mentre ti stai ancora chiedendo se hai davvero di nuovo bisogno di usare la console, si apre il capitolo successivo.

L’HA (High Availability). Il tuo airbag. E a volte sembra che l’airbag si apra mentre stai parcheggiando.

Poi i log. Lo sappiamo tutti: se non riesci a vedere cosa succede, non puoi controllarlo. E all’improvviso mancano i log, i report sono vuoti o un servizio ti dice addio. Resti lì a chiederti se hai un problema di sicurezza, un problema di qualità dei dati o entrambi.

E poi arriva il colpo di grazia: WAF, Reverse Proxy, Let’s Encrypt.

Non vuoi nemmeno fare lo splendido. Vuoi solo che i certificati vengano rinnovati e che i tuoi siti web non urlino “connection refused” alle 02:13 del mattino.

E come bonus, un’interfaccia è “sparita”. Non scomparsa per davvero, solo invisibile nella UI. Il traffico magari passa pure, ma tu non riesci a vedere quello di cui hai bisogno per il debug.

A un certo punto, ti fai questa domanda che è davvero assurda:

Cosa preferisco: un firewall con una vulnerabilità di sicurezza che funziona in modo stabile, o un firewall senza grandi titoli sulle CVE che operativamente mi brucia nuovi buchi nel pavimento ogni settimana?

1) Avvio, Riavvio, Aggiornamento: “È vivo, ma non lavora”

Se un firewall non si avvia in modo pulito dopo un reboot, non è solo questione di “Uptime” (tempo di attività). È un giorno perso più il rischio, perché in una situazione del genere tendi a fare cose che non faresti mai altrimenti.

Alcuni esempi dalle Note di Rilascio di SFOS 21.5:

• Failsafe durante il riavvio: NC-151715 (Gestione del firmware): Il dispositivo ausiliario è andato in Failsafe durante il riavvio; riavvio fallito.
• Il traffico si ferma dopo l’aggiornamento: NC-152641 (Gestione del firmware): Dopo l’aggiornamento (21.0 MR1 Build 237), non è stato elaborato più alcun traffico (Modifiche alla configurazione della memoria SWAP).
• Kernel Panic: NC-123910 (Firewall): Problema di Kernel panic.

E sì: SFOS 22.0 introduce un ulteriore fattore di aggiornamento: Sophos fa notare nelle Release Note che la v22 apporta modifiche architettoniche e che in rari casi potrebbero essere necessari passaggi manuali aggiuntivi. Questo è esattamente il tipo di situazione limite (edge case) in un aggiornamento che fa male in Operations.

2) HA: L’airbag che esplode mentre parcheggi

L’HA è la tua rete di salvataggio. Ed è per questo che fa così male quando i casi limite esplodono proprio lì.

Dalle Note di Rilascio di SFOS 21.5 (Selezione):

• L’HA Event Tracking si blocca in caso di riavvii simultanei: NC-142962 (HA).
• Il caricamento del firmware sul Nodo Passivo si blocca: NC-132291 (HA).
• Il Failover porta a un Restart Loop (ciclo di riavvii): NC-147307 (HA) (Nelle note è esplicitato, ad esempio, XGS 2300).
• La sincronizzazione fallisce dopo un’interruzione di corrente: NC-147739 (HA).
• Lo stato dell’HA sfarfalla, Crash Dump sul link dedicato: NC-149039 (HA).

3) Log e Report: Quando voli alla cieca

Questo è il vero motivo per cui i “bug” non sono solo “gestione operativa”. Quando il logging/reporting vacilla, è un problema di sicurezza.

Dalle Note di Rilascio di SFOS 21.5 (Selezione):

• Logging/Reporting si interrompono sporadicamente; Garner va in coredump frequentemente: NC-158526 (Framework di Logging).
• Garner e fwcm-heartbeatd si fermano: NC-160962 (Framework di Logging).
• Dopo l’aggiornamento: non ci sono più report: NC-157663 (Framework di Logging).
• Il visualizzatore dei log (Log Viewer) perde eventi a causa della corruzione del DB: NC-169237 (Framework di Logging).
• Corruzione del descrittore di file (fd) di Syslog, i dati vanno all’FD sbagliato: NC-135594 (Framework di Logging).

Inoltre, nella Known Issues List (KIL) di Sophos troverai un paio di punti che sono altrettanto dolorosi nella vita di tutti i giorni:

• Il Log Viewer non mostra nuovi dati (manca active.db): NC-175936 (Framework di Logging). Su alcuni sistemi 21.5.1, potrebbe mancare active.db in /tmp/eventlogs/. Di conseguenza il Log Viewer si “congela”, anche se il traffico e le funzioni di sicurezza continuano a funzionare. Secondo il KIL, il problema è risolto nella v22 e dovrebbe essere incluso in una fix per la 21.5 MR2.
• Falso positivo “advanced threat detected” in HA: NC-170292 (Framework di Logging). Sophos Central può inviare un alert nelle distribuzioni HA, includendo raw log nella descrizione. Soluzione temporanea secondo il KIL: riavviare il servizio Garner. KBA: https://support.sophos.com/support/s/article/KBA-000043672
• ReportDB_v9 mostra STOPPED (sembra grave, ma non lo è): NC-166381 (Reporting). Dopo l’aggiornamento alla v21.0 GA o successiva, il servizio appare come STOPPED dopo un periodo di tempo molto specifico. Secondo il KIL, questo è previsto e non ha alcun impatto operativo perché influisce solo sul reporting legacy precedente alla v21.

E qui entra in gioco il “Fattore Sophos Central”: Se usi Central come tuo unico punto di controllo (Single Pane of Glass), un problema di logging fa male il doppio. Se il processo di log locale (Garner/DB) si blocca, anche il caricamento verso il Central Firewall Reporting (CFR) può fallire o bloccarsi. E in ogni caso, il CFR non è sempre in “tempo reale”. Il che significa: nel peggiore dei casi, non solo ti mancano i log locali, ma ti manca esattamente la visione centrale su cui volevi fare affidamento nella vita di tutti i giorni.

4) WAF e Let’s Encrypt: Servizio pubblico, ma niente drammi per favore

Se i certificati non vengono rinnovati e il reverse proxy impazzisce, non stiamo parlando di un “piccolo bug”. È un impatto diretto sul cliente (Customer Impact).

Nelle Release Note di SFOS 21.5 troverai un’intera famiglia di problemi con WAF/Let’s Encrypt:

• La creazione del certificato Let’s Encrypt fallisce: NC-148937 (WAF).
• La richiesta LE fallisce perché manca la regola automatica del firewall (Auto-Firewall-Rule): NC-152022 (WAF).
• Una configurazione LE non valida fa riavviare continuamente il Reverse Proxy: NC-140663 (WAF).
• ACME non emette certificati per gli IP: NC-141062 (WAF).
• La regola WAF si attiva/disattiva da sola: NC-152540 (WAF).

E poi ci sono quelle questioni che “sembrano bug, ma sono compromessi per la sicurezza”. Esempio dal KIL:

• Slash codificati (%2F) negli URL: il WAF restituisce 404: NC-159041 (WAF). Se la tua app utilizza slash codificati nell’URL, Apache li blocca per impostazione predefinita (la direttiva AllowEncodedSlashes è impostata su No di default) e visualizzi un errore 404, sebbene il backend “di fatto” abbia quel percorso. Contesto: gli slash codificati possono aggirare le restrizioni sui percorsi (esempio classico: .../something%2F..%2Fadmin). Dettagli: https://httpd.apache.org/docs/2.4/mod/core.html#allowencodedslashes

E se vuoi sapere com’è la situazione reale: In questo thread della community, qualcuno descrive che dopo l’aggiornamento a 21.5.x, i certificati con rinnovo automatico erano “spariti”, il WAF non partiva e i siti web morivano con ERR_CONNECTION_REFUSED. La soluzione alla fine è stata: ripulire le Regole di Web Protection ed eliminare le CSR di LE rotte; dopodiché ha ripreso a funzionare. (Thread: WAF/Let’s Encrypt dopo aggiornamento, ERR_CONNECTION_REFUSED).

E a volte non è nemmeno un “bug”, ma una procedura: Nella Community Sophos, ci sono stati anche casi in cui i Termini di Servizio (Terms of Service) di Let’s Encrypt risultavano scaduti su WebAdmin e dovevano essere accettati nuovamente. (Thread: Let’s Encrypt Terms of Service have expired).

Un altro classico delle “trappole da aggiornamento” nella Known Issues List: Un aggiornamento può fallire se un certificato già a bordo ha lo stesso nome di certificati Let’s Encrypt appena introdotti nel CA Store (NC-146082).

5) “Manca un’interfaccia” (o è solo invisibile)

Questo è il tipo di bug che suona banale nelle Note di Rilascio, ma in pratica ti costringe a volare alla cieca.

Ufficialmente documentato come un Problema Noto (Known Issue):

Se un’interfaccia fisica o logica in SFOS 21.5 GA e versioni successive ha un nome che termina con 10 o più numeri (Esempio nelle note: VLAN_1234567890), le interfacce fisiche non sono visibili in WebAdmin sotto Rete > Interfacce, o le interfacce logiche non possono essere espanse. Importante: Secondo le Release Note, la funzionalità non è compromessa, ma solo la sua visualizzazione nella Console WebAdmin.

Conclusione provvisoria (fino a qui): Avvio/Aggiornamento, HA, Logging/Report, WAF/Let’s Encrypt e persino la UI possono farti inciampare tutti in una volta. Da qui in poi arrivano quegli argomenti che inizialmente sembrano “dettagli di rete” ma che a livello operativo costano altrettanto: Entra SSO, interoperabilità VPN e cadute di traffico apparentemente casuali.

6) Identità/SSO (Entra) e Captive Portal: Quando l’accesso sembra “casuale”

Questa è la categoria di bug che risulta particolarmente insidiosa nelle Operations: Per l’utente, sembra che “il mio account stia facendo i capricci”. Per te, sembra “solo questione di SSO”. In realtà, spesso di mezzo c’è proprio il firewall.

Alcune questioni aperte dal KIL se Microsoft Entra ID (Azure AD) fa parte del tuo mix:

• Sophos Connect VPN: Conditional Access non completamente supportato: NC-167126 (Autenticazione). Dopo la prima richiesta di MFA al login iniziale, i controlli di accesso condizionale (Conditional Access) non si attivano necessariamente a ogni connessione successiva. Secondo il KIL, l’applicazione della policy non si ripete finché l’utente non si disconnette manualmente nel client Sophos Connect.
• VPN SSO: UPN ed Email differiscono, il Login si rompe: NC-157635 (Autenticazione). Se l’ID email e l’UPN in Entra sono diversi, gli utenti possono accedere al VPN Portal, ma non al portale SSL VPN o IPsec. Causa secondo il KIL: l’header OAuth fornisce l’email, che viene poi interpretata come UPN.
• Captive Portal: Gli utenti Entra SSO necessitano del Gruppo Principale nella regola: NC-167130 (Autenticazione). L’accesso a Internet funziona solo se si utilizza il Gruppo Principale (Primary Group) nel match della regola del firewall (i gruppi secondari non contano qui). Correzione secondo il KIL prevista per le “prossime release di manutenzione”; Workaround: creare un match esplicito sul Gruppo Principale o usare regole basate sull’utente.
• Ocasionali errori “no permission” con Entra SSO: NC-167128 (Autenticazione). Può verificarsi quando l’autenticazione Entra ID e l’autenticazione On-Prem AD vengono utilizzate in parallelo (Token-Reuse). Soluzioni alternative secondo il KIL: cancellare i cookie del browser o “forzare un nuovo accesso” (force re-logon) nel client Sophos Connect. In alternativa, utilizzare un solo metodo di autenticazione in modo coerente.

7) Interoperabilità VPN/IPsec: Gli aggiornamenti spesso falliscono a causa dell’“Avversario”

Due argomenti del KIL che non sono iniziati solo con la 21.5, ma restano rilevanti in 21.5/v22 non appena si hanno vecchi client o sedi remote nel proprio ambiente:

• IPsec IKEv2: Il tunnel non sale (Frammentazione/PMTU): NC-136352 (IPsec). Dalla 20.0 MR1, il profilo IKEv2 predefinito può generare pacchetti più grandi (più campi di default), a volte superiori a 1500 byte. Se la frammentazione/PMTU nel percorso è pessima (i frammenti vengono scartati), il tunnel S2S non si avvierà. Mitigazione secondo il KIL: ridurre i Gruppi DH nel profilo IPsec (minimo 4) o configurare esattamente il/i gruppo/i utilizzato/i dalla controparte.
• SSL VPN/OpenVPN 2.6.0: Incompatibilità con i Client EoL/UTM9: NC-128116 (SSLVPN). Dalla 20.0 MR1, OpenVPN è passato alla 2.6.0. Questo blocca, tra le altre cose, le VPN SSL site-to-site con versioni SFOS precedenti (18.5 e precedenti), vecchi client VPN SSL legacy (EoL) e sistemi operativi UTM9. Raccomandazione secondo il KIL: aggiornare entrambi i lati o passare a IPsec/RED; Dispositivi remoti: utilizzare Sophos Connect o client OpenVPN aggiornati.

8) Calo di traffico senza violazione di regole: L’Accurate ECN come subdola causa

Quando il traffico sembra cadere “in modo casuale”, le prime cose che controlli sono le regole, l’IPS, la TLS inspection e il routing. E dopo gli aggiornamenti del firmware, alla lista si aggiunge un classico: Il motore IPS (Snort) o le firme diventano più severi, bloccano il traffico legittimo e non trovi subito un evento chiaro nei log. Poi passi ore a fare il debug di “routing” o “regole”, quando alla fine si tratta di un lavoro sulle policy o sul tuning.

Tuttavia, nel KIL c’è anche un candidato che può tenerti occupato per molto tempo se non ce l’hai sul radar:

• Traffico bloccato a causa dei bit Accurate ECN: NC-169842 (Firewall). L’Accurate ECN imposta i bit TCP (ECE/CWR/NS) in modo diverso (RFC 7560). Secondo il KIL, il kernel lo interpreta come un “reserved bit set” (set di bit riservato) e scarta il traffico. Per circoscrivere il problema, aiuta dare un’occhiata al lato client: Nella pratica, questo potrebbe farsi notare di più con i kernel Linux più recenti o con i client Apple, perché tendono a utilizzare RFC 7560/Accurate ECN in modo più attivo (“perché vengono buttati fuori solo i MacBook?”). RFC: https://www.rfc-editor.org/rfc/rfc7560

9) Re-Release v22 GA Build 411: Perché ce n’è stato bisogno

Il 20 gennaio 2026, Sophos ha rilanciato la v22 GA come re-release (Build 411) per correggere “problemi rari e isolati”. L’elenco si legge come una compilation del “lavoro inutile nella finestra di manutenzione” (Fonte: Post sul blog della community Sophos dedicato alla Re-Release):

• NC-171003: WebAdmin irraggiungibile tramite un’interfaccia Bridge con filtraggio VLAN.
• NC-170987: Spam sulla console CLI con il messaggio “Invalid rule id or family for update”.
• NC-170970: Il traffico DNAT fallisce se la regola DNAT ha un’interfaccia di uscita specifica.
• NC-171600: Il widget SSL/TLS e i dati del grafico di sessione sono errati/vuoti.
• NC-172197: Impossibile aggiungere alcuna configurazione SNMP.

Post sul blog: v22 GA re-release (Build 411) is now available.

Il vero danno: I bug rendono la sicurezza più costosa

Il punto non è “i bug sono peggiori delle CVE” o viceversa.

Il punto è: quando il tuo ambiente operativo traballa, la sicurezza ne risente automaticamente.

• Ritardi gli aggiornamenti perché hai paura del prossimo bug di regressione.
• Disabiliti alcune funzioni (“al momento non ci servono”) perché causano stress.
• Perdi l’osservabilità (i log), e con essa la rapidità di reazione.
• Investi tempo a spegnere incendi invece che a dedicarti a segmentazione, backup e a scrivere regole pulite.

C’è un aspetto che viene spesso completamente sottovalutato nella pratica: il Time-to-Resolution (Tempo di risoluzione). Con una CVE, di solito hai un avviso, una mitigazione e una patch. Con un bug, l’onere della prova ricade improvvisamente sull’amministratore: dump TCP, log CTR, esportazione da shell avanzata, “hai provato a riavviare?” – tutto questo mentre la produzione va a fuoco. E solo allora finisci nel circo del supporto: un’escalation e l’attesa di un hotfix o della successiva release di manutenzione (MR). Questo divora tempo operativo aggiuntivo che non avevi messo in conto.

Ed è proprio per questo che domandarsi “Meglio una vulnerabilità, ma stabile?” è molto umano, ma in fondo rappresenta un vicolo cieco:

Non solo “la vulnerabilità” è un problema di sicurezza. Anche “un firewall instabile” è, a tutti gli effetti, un problema di sicurezza.

Cosa impariamo da questo (Per evitare che scoppi il caos)

Alcune cose che ci aiutano a contenere la follia senza dover reinventare la ruota ogni settimana:

Verifiche pre-aggiornamento (Upgrade-Preflight)

• Tratta i backup come se fossero dei ripristini (Restore): Esporta la configurazione, esegui backup offline e verifica che il ripristino funzioni almeno una volta.
• Lo stato “verde” dell’HA non basta – fai i test di failover! Secondo la GUI, la nostra sincronizzazione era a posto e l’heartbeat era pulito. Ma in caso di vera emergenza, l’unità Ausiliaria (Auxiliary Appliance) non ha preso in carico il failover in modo fluido. Una bella spunta verde in WebAdmin, al momento, purtroppo non garantisce che le cose andranno bene durante la finestra di manutenzione.
• Verifica il logging: Assicurati che il Syslog/Collector esterno riceva gli eventi, senza buchi nei log, e che il tempo/NTP sia corretto.
• Controlla Certificati/WAF: Date di scadenza, validazione di Let’s Encrypt e tieni pronto un certificato di ripiego (Fallback) come Piano B.
• Testa a fondo SSO/VPN: Il login su Entra, il Captive Portal, Sophos Connect, VPN SSL, IPsec S2S (incluso il failover) devono essere trattati come casi di test a sé stanti.
• Piano di emergenza (Break-Glass) pronto: Accesso via console/Out-of-band, amministratori locali configurati e immagini del firmware salvate per un eventuale rollback.
• Non dimenticare il Dual-Boot (e non fidarti troppo): Sophos ha due partizioni per il firmware. Se un aggiornamento va male, fare il rollback alla 21.5 spesso si riduce a un semplice riavvio selezionando l’altra partizione. Ma attenzione: ci sono casi in cui anche la seconda partizione non si avvia correttamente e a quel punto l’unica soluzione è una reinstallazione completa (Reimage), che il supporto tende a richiedere fin troppo velocemente. E non è detto che un reimage risolva la vera causa del problema.

Durante l’aggiornamento (se c’è l’HA di mezzo)

• Procedi prima sul nodo Passivo/Secondario, fai il Failover, poi sull’Attivo.
• Dopo ogni passaggio, esegui una rapida validazione: Traffico, VPN, DNS, Logging, WAF/Reverse Proxy.

Nelle operazioni quotidiane

• Non limitarti a configurare l’HA, testalo: Esegui simulazioni di failover (drill) e stabilisci criteri chiari su quando dividere (split) un cluster.
• Tratta il logging come se fosse un prodotto a sé: Imposta allarmi se ci sono buchi nei log, monitora lo stato di salute dei servizi (Service Health) e prepara una via di esportazione d’emergenza tramite CLI se l’interfaccia utente si blocca.
• Monitora attivamente i certificati: Il rinnovo non è una questione accessoria (“nice to have”), ma un rischio operativo. Gestisci i cambiamenti dei Termini di Servizio (ToS) come se fossero cambiamenti di infrastruttura (Change).
• Usa l’Health Check come indizio, non come indicatore assoluto (KPI): Dalla versione 22, Sophos ha introdotto l’Health Check (Maggiori dettagli nel mio articolo Sophos Firewall v22 Health Check - Panoramica Completa ). Funziona bene come checklist per le buone pratiche, ma a volte sembra solo un modo per “mettere tutto su verde nell’ecosistema”. Esempio dalla realtà: Molti attivano il disclaimer al login solo per ottenere la spunta verde nell’Health Check. Quello che mi manca lì, invece, sono indicatori operativi concreti del tipo: “Il database di logging/reporting è sano?” o “Qual è lo stato dell’SSD?” - specialmente considerato che alcuni dispositivi hanno manifestato problemi di archiviazione ben prima del previsto.

Conclusione: Quando lo Strumento diventa un Rischio

Alla fine dei conti, siamo tutti sulla stessa barca. Gestiamo infrastrutture critiche e dobbiamo poter confidare sul fatto che gli strumenti concepiti per difenderci dal caos non siano essi stessi la causa di quel caos. Sulla qualità attuale dei suoi firmware (v21.5 / v22), Sophos ha indubbiamente molti compiti a casa da fare. La fiducia nei cosiddetti “rilasci stabili” ha subìto un duro colpo, per noi e per molti altri all’interno della community.

Non voglio un firewall che sia “o sicuro o stabile”. Io voglio – anzi, mi serve – un firewall che sia entrambe le cose.

Fino a quando Sophos non riprenderà il controllo su questi difetti di qualità, a noi delle Operations non resta che una strada: dobbiamo diventare ancora più disciplinati, non dare più peso alle “spunte verdi” della UI e iniziare a prendere i bug più banali, durante la pianificazione dei deployment, con la stessa gravità con cui trattiamo le CVE più critiche.

Alla prossima,
Joe

Fonti

• Avvisi PSIRT di Fortinet
• Note di rilascio Sophos Firewall v21.5
• Note di rilascio Sophos Firewall v22.0
• Sophos KIL (Problemi noti - Known issues)
• Sophos Community: v22 GA re-release Build 411
• Thread della Sophos Community (Let’s Encrypt/WAF)
• Thread della Sophos Community (ToS Let’s Encrypt)
• Documentazione Apache: AllowEncodedSlashes
• Sophos KBA (Falso positivo per minacce avanzate in Garner)
• RFC 7560 (Accurate ECN)