Sophos Firewall v22 MR2: novità, correzioni e upgrade

Il 14 luglio 2026 Sophos ha rilasciato Sophos Firewall OS 22.0 MR2 Build 546. Questa maintenance release è più contenuta di una major release, ma offre molto più di un semplice pacchetto di bugfix: introduce il controllo della crittografia post-quantistica, un rilevamento più preciso delle applicazioni di intelligenza artificiale generativa, una nuova estensione per Chromebook, un’impostazione predefinita STAS meno invasiva e catene di attendibilità Let’s Encrypt aggiornate. Allo stesso tempo, Sophos corregge 53 problemi documentati che riguardano firewall, HA, IPsec, autenticazione, logging, WAF, reporting e altri componenti.

MR2 è quindi soprattutto una release dedicata all’operatività e alla stabilità. Le nuove funzioni sono interessanti, ma per molti ambienti di produzione i crash del kernel, le cause di failsafe, i problemi HA e gli errori VPN risolti rappresentano un motivo ancora più importante per eseguire l’aggiornamento.

Rilevare e controllare la crittografia post-quantistica

La novità di sicurezza più evidente riguarda la Post-Quantum Cryptography (PQC), ovvero i metodi crittografici progettati per resistere agli attacchi di futuri computer quantistici sufficientemente potenti. Il rischio attuale non consiste soltanto nella possibilità che un computer di questo tipo diventi disponibile un giorno. Per i dati particolarmente sensibili è già rilevante il principio harvest now, decrypt later: il traffico cifrato viene registrato e conservato per poterlo decifrare in futuro con tecnologie più potenti.

SFOS 22.0 MR2 rileva metodi di scambio delle chiavi puri e ibridi basati su ML-KEM. Nel 2024 il National Institute of Standards and Technology ha standardizzato questo metodo come FIPS 203. Il metodo si basa sul problema matematico Module Learning With Errors. NIST definisce tre gruppi di parametri, ML-KEM-512, ML-KEM-768 e ML-KEM-1024, con caratteristiche diverse in termini di sicurezza e prestazioni.

ML-KEM non cifra direttamente il successivo traffico web. È un Key Encapsulation Mechanism e serve a stabilire un segreto condiviso tra client e server attraverso un canale pubblico. Da questo segreto vengono poi derivate le chiavi di sessione simmetriche, utilizzate per cifrare e autenticare in modo efficiente i dati effettivi.

Con uno scambio di chiavi PQC puro, la sicurezza della negoziazione dipende esclusivamente dal metodo post-quantistico. Nelle implementazioni TLS attuali vengono impiegati più spesso metodi ibridi, che combinano ML-KEM con un metodo classico come X25519. L’obiettivo di una negoziazione ibrida progettata correttamente è mantenere protetta la sessione finché almeno uno dei due componenti rimane sicuro. Questa proprietà dipende tuttavia dalla combinazione concreta e non è garantita automaticamente per qualsiasi metodo ibrido. L’approccio riduce il rischio di affidarsi completamente a un metodo crittografico relativamente nuovo durante una prima fase della migrazione.

Sophos non indica ancora né i gruppi di parametri ML-KEM rilevati né gli ID precisi delle firme IPS. L’unica informazione documentata pubblicamente è che SFOS 22.0 MR2 può rilevare e controllare le negoziazioni ML-KEM pure e ibride.

Rilevamento e controllo delle policy tramite IPS

Con TLS 1.3 il client comunica già nel ClientHello i gruppi di scambio delle chiavi supportati. Questi metadati vengono trasmessi prima che venga stabilita la sessione applicativa cifrata. L’IPS può quindi rilevare l’utilizzo di un metodo PQC o ibrido durante la negoziazione TLS senza dover decifrare il successivo contenuto HTTP.

Sophos mette a disposizione nuovi pattern IPS a questo scopo. Perché vengano effettivamente elaborati, IPS Protection deve essere attivo, deve essere disponibile una licenza Network Protection valida e la policy IPS corrispondente deve essere assegnata a una regola firewall. In una policy dedicata è possibile definire azioni come:

consentire il traffico,
registrarlo,
scartare singoli pacchetti o l’intera sessione,
terminare la sessione TCP con un reset oppure
disattivare la firma.

Le firme PQC introdotte con MR2 sono disattivate per impostazione predefinita. È una scelta sensata, perché i browser, le piattaforme cloud, le CDN e le librerie TLS attuali utilizzano sempre più spesso metodi PQC ibridi nel normale funzionamento. Se Sophos distribuisse immediatamente queste firme con un’azione predefinita di blocco, potrebbe interrompere connessioni web e API legittime. Nel primo thread di feedback, Sophos motiva l’impostazione disattivata anche con la crescente diffusione di PQC-TLS e il rischio di generare un gran numero di avvisi inutili.

Non attiverei subito le nuove firme in modalità di blocco. È più opportuno creare una policy IPS separata per un gruppo di test limitato e, inizialmente, limitarsi a registrare le corrispondenze. In seguito, tramite Log Viewer, è possibile verificare quali browser, applicazioni e destinazioni utilizzano ML-KEM. Solo dopo aver chiarito quale policy crittografica applicare e quali servizi legittimi ne sarebbero interessati, utilizzerei Drop session o Reset. PQC non è automaticamente sospetta: nella maggior parte dei casi, una corrispondenza indica semplicemente che un’applicazione utilizza già metodi TLS moderni.

Controllo della negoziazione TLS tramite Web Protection

Oltre all’IPS, Web Protection interviene direttamente sui metodi TLS che possono essere negoziati. Sophos afferma che le sessioni web non possono negoziare algoritmi PQC non supportati dal firewall. Si tratta di un compito diverso dal semplice rilevamento tramite IPS: l’IPS classifica la negoziazione visibile e applica un’azione della policy, mentre Web Protection deve garantire che una sessione web protetta venga stabilita solo con un metodo crittografico supportato dal percorso di elaborazione SFOS.

Questo aspetto è particolarmente importante con TLS Inspection. In questo caso il firewall non è soltanto un componente passivo nel percorso dei dati, ma deve terminare la sessione TLS, verificare o riemettere i certificati e negoziare parametri crittografici compatibili su entrambi i lati. Un algoritmo supportato dal browser e dal server di destinazione non è quindi automaticamente adatto a ogni Inspection Engine intermedia.

Lo scambio di chiavi PQC modifica inoltre la negoziazione TLS a livello tecnico. Le key share ibride sono più grandi dei tradizionali valori X25519 e possono fare in modo che un ClientHello venga suddiviso su più pacchetti. Tali connessioni sono conformi a TLS, ma possono mettere sensibilmente più sotto pressione middlebox, proxy o Inspection Engine meno recenti e non aggiornati. Il nuovo supporto di MR2 non è quindi soltanto una firma aggiuntiva, ma anche un adeguamento di compatibilità per uno stack TLS in fase di trasformazione.

Al momento Sophos non documenta in dettaglio se Web Protection termini la sessione quando incontra un metodo PQC non supportato, ripieghi su un metodo classico o reagisca in modo diverso a seconda del percorso di elaborazione. Dall’annuncio della release non si dovrebbe quindi dedurre uno specifico comportamento di fallback. È chiaro soltanto che le negoziazioni PQC non supportate non devono attraversare il livello di protezione senza controllo.

Dopo l’upgrade, soprattutto gli ambienti con TLS Inspection dovrebbero verificare i seguenti punti:

Testare le versioni attuali di Chrome, Edge, Firefox e Safari con i servizi SaaS e cloud utilizzati più spesso.
Accedere alle stesse destinazioni una volta tramite una regola con TLS Inspection e una volta senza.
Controllare le eccezioni TLS Inspection, gli errori dei certificati e le pagine di blocco.
Esaminare i log IPS e Web Protection alla ricerca di nuovi messaggi PQC, errori di handshake e reset.
Testare separatamente le applicazioni aziendali critiche con librerie TLS, client API o runtime Java propri.
In caso di problemi, usare Packet Capture per verificare se fallisce già l’handshake TLS o se si interrompe soltanto la sessione applicativa protetta.
Solo in seguito decidere se è necessaria un’azione esplicita Allow, Drop o Reset.

Intelligenza artificiale generativa con Synchronized Application Control

MR2 migliora la categorizzazione delle applicazioni di intelligenza artificiale generativa. Il limite decisivo è già contenuto nel nome della funzione: la visibilità aggiuntiva viene fornita da Synchronized Application Control. Sophos Endpoint rileva le applicazioni localmente e condivide queste informazioni con il firewall tramite Security Heartbeat. SFOS può quindi classificare l’applicazione in modo più preciso nel reporting e nelle regole di Application Control.

Questo è utile per le applicazioni che comunicano tramite protocolli web generici, CDN condivise o destinazioni variabili e che risultano difficili da riconoscere in modo univoco soltanto con le firme firewall tradizionali. Una categoria più precisa facilita, ad esempio, la distinzione tra normali applicazioni web e strumenti GenAI, oltre all’analisi degli utenti o dei dispositivi che utilizzano tali applicazioni.

La funzione non è però un sistema CASB o DLP universale. Non viene eseguita un’analisi automatica dei contenuti riservati dei prompt e, senza un Sophos Endpoint compatibile, non è disponibile la stessa visibilità delle applicazioni. Negli ambienti Microsoft Defender o con endpoint eterogenei rimangono quindi rilevanti i controlli DNS, web, TLS, proxy o SSE/CASB.

Per ottenere una policy utile, la nuova categoria da sola non basta:

Sophos Endpoint e Security Heartbeat devono essere collegati correttamente.
Le applicazioni sconosciute in Synchronized Application Control devono essere classificate regolarmente.
Le regole firewall richiedono una policy Application Control adeguata e il logging attivo.
Devono essere definiti i servizi GenAI consentiti, gli account aziendali e i requisiti di protezione dei dati.
Per i dati sensibili sono necessari ulteriori controlli DLP, browser, endpoint o SaaS.

Il blocco indiscriminato di tutte le applicazioni GenAI raramente è la prima misura migliore. È più utile una policy graduale: consentire i servizi aziendali approvati, registrare o bloccare quelli sconosciuti o non verificati e valutare l’utilizzo in base alle effettive esigenze aziendali.

Autenticazione: Chromebook, STAS ed eDirectory

MR2 modifica tre aree tecnicamente distinte dell’identificazione degli utenti. Nel lavoro quotidiano riguardano tutte lo stesso punto critico: se il firewall riesce a riconoscere un utente in modo affidabile e ad assegnargli la policy corretta.

Chromebook User ID con Manifest V3

La nuova Sophos Chromebook User ID Extension supporta Chrome Manifest V3. Manifest V3 è l’attuale piattaforma per le estensioni di Chrome e modifica, tra le altre cose, le autorizzazioni, i processi in background e il modo in cui le estensioni gestiscono gli eventi di rete. Senza la nuova versione, la precedente estensione Sophos non riceverebbe più aggiornamenti regolari a lungo termine.

Secondo Sophos, non è previsto un aggiornamento in-place. La vecchia estensione deve essere disinstallata e quella nuova installata. Negli ambienti Chromebook gestiti, l’operazione deve essere eseguita nella Console di amministrazione Google o nella piattaforma di Endpoint Management utilizzata:

Rimuovere la vecchia Sophos Chromebook User ID Extension dall’installazione forzata.
Aggiungere la nuova versione Manifest V3 e assegnarla ai gruppi di destinazione.
Accedere con un utente di test.
Verificare sul firewall che nome utente e indirizzo IP siano associati correttamente.
Attivare una policy firewall o web basata sull’utente e controllare il risultato in Log Viewer.

La sequenza è importante. Se la vecchia estensione viene rimossa prima che la nuova versione sia distribuita, l’associazione degli utenti viene temporaneamente a mancare. Le regole possono quindi ricorrere a una policy di fallback più generica o bloccare l’accesso.

La procedura completa per Device Access, certificato, regole firewall, policy JSON e API Controls è descritta in Configurare Chromebook SSO con Google Workspace.

STAS non blocca più il traffico durante l’identity probe per impostazione predefinita

Con la Sophos Transparent Authentication Suite (STAS), quando rileva un client nuovo o modificato, il firewall verifica quale utente Active Directory si trova dietro un indirizzo IP. L’impostazione Restrict client traffic during identity probe determina se il client può già inviare traffico durante questa verifica.

Con MR2 il valore predefinito passa a No. Il traffico può quindi proseguire mentre il firewall verifica utente e indirizzo di destinazione. Ciò riduce le brevi interruzioni che possono essere percepite soprattutto con nuove sessioni, cambi di utente, roaming o risposte ritardate dello STAS Collector.

Il vantaggio in termini di praticità comporta un compromesso: durante il probe, il firewall deve lavorare con il contesto di identità disponibile in quel momento. Negli ambienti con regole basate sugli utenti molto rigide è quindi opportuno verificare quale policy si applica in questa breve finestra. Dopo l’aggiornamento non si dovrebbe presumere che le configurazioni esistenti adottino automaticamente lo stesso valore. Occorre controllare il valore attuale, il comportamento desiderato e i log effettivi.

Novell eDirectory termina con SFOS 23.0

MR2 mostra inoltre un avviso di fine vita per Novell eDirectory Authentication Server. Il supporto terminerà con SFOS 23.0. In MR2 eDirectory continua a funzionare; il messaggio è un avviso anticipato e non una rimozione immediata della funzione.

Questa integrazione non ci mancherà. Novell eDirectory non è più in uso presso nessuno dei nostri clienti e da molto tempo non svolge più alcun ruolo nei nuovi progetti. I pochi ambienti che lo utilizzano ancora hanno tempo fino a SFOS 23.0 per migrare a una fonte di identità supportata. Oltre all’Authentication Server, occorre verificare i gruppi importati, le regole firewall, le autorizzazioni VPN, le web policy, il Captive Portal e i report basati sugli utenti.

Let’s Encrypt e gestione dei certificati

SFOS 22.0 MR2 aggiorna il supporto per i nuovi certificati root e intermediate di Let’s Encrypt. Ora vengono considerate le catene YE Root, YE1, YE2, YR Root, YR1 e YR2. In questo modo Sophos Firewall si prepara all’emissione e al rinnovo automatici dei certificati con le catene Let’s Encrypt attuali e future.

Questo è importante perché una richiesta ACME corretta da sola non basta. Anche firewall, controparte e client devono poter costruire e convalidare correttamente la catena del certificato emesso. Trust store obsoleti possono altrimenti provocare errori di certificato apparentemente inspiegabili, anche se il certificato leaf è valido.

Le notifiche email di Let’s Encrypt includono ora anche hostname e numero di serie del firewall. Negli ambienti con più appliance è quindi possibile identificare più rapidamente il dispositivo che ha generato un rinnovo, un errore o un altro messaggio relativo ai certificati. Il numero di serie è però un dato rilevante per l’inventario; le notifiche devono quindi essere inviate soltanto a destinatari e caselle di posta controllati.

Dopo l’upgrade vale la pena eseguire un test completo dei certificati:

Controllare lo stato ACME e la data del prossimo rinnovo.
Verificare hostname, risoluzione DNS e raggiungibilità della challenge.
Convalidare la catena del certificato nel browser o con un test TLS esterno.
Esaminare separatamente i certificati WAF, WebAdmin, User Portal e VPN.
Verificare la ricezione della nuova notifica email e l’elenco dei destinatari.

Config Studio 2.6 amplia analisi e migrazione

Parallelamente a MR2, Sophos mette in evidenza Firewall Config Studio 2.6. Lo strumento funziona nel browser al di fuori del firewall e quindi, tecnicamente, non è una funzione WebAdmin integrata nella Build 546. Integra però le attività operative proprio nei punti in cui SFOS continua a offrire possibilità limitate di analisi e confronto.

Le principali funzioni della versione 2.6 sono:

Merge templates: Una configurazione di base può essere combinata con un modello specifico per il settore o lo scenario d’impiego. Questo accelera i rollout standardizzati, ma non sostituisce la verifica di oggetti, interfacce o regole in conflitto.
Enhanced Global Search: Gli oggetti possono essere cercati a livello globale e aperti direttamente nel punto in cui vengono utilizzati. È particolarmente utile con set di regole estesi e per eliminare dipendenze poco chiare.
Improved Configuration Report: Le regole firewall, NAT e TLS mostrano non solo i nomi degli oggetti referenziati, ma anche i relativi valori e dettagli. Le revisioni diventano così più comprensibili senza dover aprire ogni oggetto separatamente.
Migration Insights: Dopo una conversione, Config Studio mostra la percentuale migrata con successo. Il valore percentuale è un’indicazione, non un collaudo: VPN, autenticazione, certificati e funzioni specifiche del produttore non trasferiti devono comunque essere controllati manualmente.
Multi-file Configuration Diff: È possibile confrontare più versioni della configurazione. In questo modo si può individuare tra quali backup è comparsa una modifica, un errore o una deviazione indesiderata.
Compatibilità del ripristino dei backup: Lo strumento aiuta a verificare se un backup può essere ripristinato su un altro modello Sophos Firewall.
Riferimento per Flexi Port e velocità delle porte: Prima delle migrazioni hardware è possibile confrontare layout delle porte, moduli Flexi e velocità supportate fino a 25, 40 o 100 Gbit/s.

Config Studio 2.6 è stato analizzato in dettaglio nell’articolo Sophos Firewall Config Studio 2.6: migrazione integrata. Il flusso di lavoro pratico per report, confronti, Editor e reimportazione controllata è descritto in Utilizzare Sophos Firewall Config Studio.

I 53 problemi risolti nella Build 546

Sophos indica più di 50 correzioni relative a stabilità, affidabilità e sicurezza. La seguente classificazione comprende tutti i 53 ID riportati nelle note di rilascio ufficiali. L’elenco non sostituisce una valutazione individuale del supporto, ma mostra quale funzione era interessata e perché la correzione è rilevante per l’operatività.

Firewall, kernel, HA e stabilità del sistema

NC-180331 – Gestione errata della memoria in algif_aead e algif_skcipher: Risolve una vulnerabilità del kernel Linux nei componenti crittografici.
NC-181331 – La partizione di configurazione piena portava il firewall in modalità failsafe: Riduce il rischio di interruzioni operative dovute all’esaurimento dello spazio di configurazione.
NC-180974 – Un crash del kernel in sdwan_profile attivava un failover HA: Stabilizza gli ambienti SD-WAN ed evita cambi di ruolo non necessari nel cluster.
NC-178354 – Crash del kernel durante il matching delle regole SD-WAN: Impedisce i crash durante la valutazione delle regole SD-WAN.
NC-178413 – Un valore vuoto nei servizi provocava un errore ipset e la modalità failsafe: Gestisce in modo più robusto gli oggetti servizio danneggiati o incompleti.
NC-177934 – Il firewall entrava in modalità failsafe dopo l’upgrade a SFOS 22.0 GA: Risolve una conseguenza diretta dell’upgrade nelle prime build v22.
NC-177441 – Il dispositivo HA primario iniziale entrava in modalità failsafe dopo l’upgrade a SFOS 22.0 GA: Migliora la stabilità di avvio del nodo primario dopo l’upgrade.
NC-177467 – Il dispositivo ausiliario non si avviava a causa di un numero molto elevato di connessioni SSH simultanee non autenticate: Importante per i sistemi HA esposti o sottoposti a molte scansioni; questa specifica correzione viene osservata attentamente nel primo feedback MR2 per XGS 5500 HA.
NC-173031 – Le Application Policy importate non venivano sincronizzate automaticamente con il dispositivo ausiliario: Garantisce uno stato delle policy più coerente sui due nodi HA.
NC-177536 – L’upgrade del firmware a SFOS 22.0 GA non riusciva sul dispositivo HA primario: Stabilizza il percorso di upgrade nei cluster HA.
NC-178745 – Un dispositivo HA si riavviava automaticamente a causa dell’esaurimento della memoria: Riduce i riavvii imprevisti causati dal sottosistema di logging.
NC-180110 – Il dispositivo HA primario entrava in modalità failsafe perché il demone di logging non si avviava: Impedisce che un errore di avvio del logging metta fuori servizio l’intero nodo primario.
NC-180933 – Gli amministratori non riuscivano ad accedere alla console WebAdmin: Ripristina l’accesso amministrativo alla GUI.
NC-177769 – Il servizio eBPF smetteva di rispondere dopo un aggiornamento dei pattern: Stabilizza il percorso dati accelerato dopo gli aggiornamenti delle firme.
NC-180152 – Gli aggiornamenti delle interfacce richiedevano più tempo in SFOS 22.0 GA rispetto alla 21.5: Riduce i ritardi nell’applicazione delle modifiche alle interfacce.
NC-179462 – Avvisi ripetuti durante la lettura delle statistiche hardware: Elimina rumore inutile nei log delle appliance XGS.

Regole firewall, traffico utente e routing

NC-181741 – Il traffico degli utenti non autenticati veniva scartato ogni ora: Impedisce interruzioni periodiche negli ambienti con traffico non autenticato.
NC-178903 – Gli utenti SATC perdevano l’accesso a Internet dopo l’upgrade a SFOS 22.0 GA: Ripristina l’accesso basato sugli utenti con Sophos Authentication Thin Client.
NC-178141 – Determinati messaggi di errore ICMP venivano scartati dalla Local ACL dopo l’upgrade GA: Migliora Path MTU Discovery e la diagnostica degli errori nei casi in cui ICMP è tecnicamente necessario.
NC-178197 – Il traffico applicativo si interrompeva temporaneamente con una Bandwidth Policy basata sulle applicazioni: Stabilizza il QoS per le regole che gestiscono la larghezza di banda in base alle applicazioni rilevate.
NC-180226 – La GUI non mostrava errori in presenza di un indirizzo MAC duplicato in Spoof protection trusted MAC: Impedisce configurazioni errate silenziose nell’elenco delle eccezioni Spoof Protection.
NC-181299 – Il database GeoIP assegnava un indirizzo IP al Regno Unito anziché alla Germania: Corregge l’assegnazione del Paese per regole e report GeoIP.

IPsec e VPN

NC-180433 – Il multicast attraverso un tunnel VPN causava ripetuti crash del firewall: Importante per scenari di routing, streaming o discovery con multicast su IPsec.
NC-178121 – Le connessioni IPsec site-to-site finivano nella posizione errata del gruppo di failover dopo il drag and drop: Garantisce che la priorità configurata dei tunnel venga mantenuta.
NC-171719 – Problema di routing SD-WAN con traffico ESP: Migliora la selezione del percorso per IPsec/ESP nativo negli scenari SD-WAN.
NC-180520 – Il gateway XFRM restava irraggiungibile con accelerazione IPsec, alias IP e traffico ESP in entrata su un’altra porta WAN: Risolve un caso particolare e complesso in ambienti multi-WAN con tunnel IPsec accelerati.
NC-176855 – Basso throughput IPv6 su IPsec route-based: Migliora le prestazioni IPv6 nelle architetture VPN basate su tunnel.
NC-181687 – La creazione di una policy SSL VPN causava un errore interno del server: Ripristina la creazione delle policy nella nuova architettura control plane/HA.
NC-175860 – Remote Access IPsec non funzionava dopo un failover HA se l’Appliance Certificate era stato rigenerato: Stabilizza le connessioni di accesso remoto basate su certificato durante i cambi di ruolo.

Autenticazione, Central e gestione della configurazione

NC-180824 – I nuovi utenti AD in un gruppo AD secondario non riuscivano ad accedere al VPN Portal: Corregge la gestione delle appartenenze a gruppi annidati o secondari per l’accesso al portale.
NC-176806 – Microsoft Entra ID SSO non riusciva a causa di CA intermediate mancanti: Migliora la convalida dei certificati per gli accessi Entra ID.
NC-160157 – Last access time rimaneva dopo l’eliminazione dell’utente e compariva per l’utente appena creato: Impedisce dati storici di accesso fuorvianti dopo la ricreazione di un account.
NC-181175 – Il push di una Group Policy da Sophos Central rimaneva su pending e non veniva applicato: Risolve le modifiche ai gruppi bloccate nella gestione centralizzata.
NC-180513 – L’importazione della configurazione dalla vista Sophos Central non funzionava dopo l’upgrade a MR1: Ripristina il percorso di importazione basato su Central.
NC-181904 – Non era possibile rilasciare le email in quarantena tramite Sophos Central: Corregge il noto flusso di lavoro Central; in precedenza la WebAdmin locale rappresentava la soluzione pratica.

Dopo l’aggiornamento è comunque opportuno controllare la Central Firewall Task Queue. La correzione di un errore del prodotto non garantisce che task bloccati più vecchi o stati dei gruppi incoerenti scompaiano automaticamente.

Logging e reporting

NC-181520 – Log Viewer era troppo lento: Migliora i tempi di risposta durante le ricerche e la risoluzione dei problemi.
NC-172912 – Il System Graph sfarfallava: Stabilizza la visualizzazione delle metriche di sistema.
NC-172020 – I firewall senza reporting on-box inviavano PDF vuoti della Traffic Dashboard: Impedisce l’invio di report giornalieri privi di contenuto.
NC-169646 – I PDF on-demand contenevano grafici e tabelle errati in Chrome: Corregge la generazione dei report nel browser.
NC-155252 – Un elevato I/O del disco provocava picchi della CPU e interruzioni di Internet fino a un minuto: Una correzione di stabilità particolarmente rilevante per i sistemi con carichi intensivi di reporting e logging.

NC-178745 e NC-180110 dell’elenco sulla stabilità riguardano anch’essi il Logging Framework, ma a causa rispettivamente del riavvio e della modalità failsafe avevano effetti diretti sull’intera appliance.

Email, antivirus e Security Heartbeat

NC-180066 – Gli aggiornamenti dei pattern SAVI e AVIRA non riuscivano e arrestavano il servizio antivirus: Garantisce che un errore dei pattern non termini l’intero servizio AV.
NC-177930 – Le email rimanevano nello spool a causa di un crash di mailpoller: Impedisce il blocco della consegna della posta in modalità MTA.
NC-171602 – Le notifiche del firewall non superavano la verifica DKIM: Migliora la consegna delle email di sistema firmate.
NC-176012 – Veniva segnalato un heartbeat mancante quando due endpoint utilizzavano la stessa docking station o interfaccia USB: Riduce i falsi allarmi Heartbeat quando dispositivi diversi utilizzano hardware condiviso.

Chi utilizza la modalità MTA dovrebbe testare mail spool, quarantena, DKIM e rilascio da Central dopo l’aggiornamento seguendo i passaggi nell’articolo Sophos Firewall Mail Protection in modalità MTA.

WAF, Web Protection e RED

NC-180200 – WAF si arrestava durante la sincronizzazione notturna delle licenze nella Home Edition: Impedisce interruzioni periodiche di WAF nelle installazioni Home Edition.
NC-177457 – Con il debug WAF attivo, la password era visibile in reverseproxy.log: Elimina l’esposizione di dati sensibili in chiaro nel log di debug. I vecchi log di debug dovrebbero comunque essere controllati e protetti oppure eliminati secondo le direttive applicabili.
NC-176788 – ResponseFieldSize tornava al valore predefinito quando si cambiava il certificato in una regola WAF: Mantiene il limite di dimensione impostato intenzionalmente durante le modifiche dei certificati.
NC-167019 – Snort provocava un elevato carico della CPU con traffico Veeam senza eccezione: Riduce i picchi di carico durante il traffico di backup; è comunque opportuno verificare se le eccezioni esistenti sono ancora necessarie.
NC-178906 – Il firewall entrava in modalità failsafe con Failed to start Red server service: Stabilizza il servizio RED Server e impedisce una condizione failsafe dell’intera appliance.

Firmware, DDNS e interfaccia utente

NC-170200 – Più tentativi di upgrade nell’arco di pochi minuti causavano il fallimento degli aggiornamenti firmware: Rende Firmware Management più robusto; è comunque opportuno evitare avvii paralleli o ripetuti in rapida successione.
NC-180219 – Cloudflare DDNS non funzionava dopo l’upgrade a SFOS 22.0 MR1: Ripristina gli aggiornamenti DNS dinamici per Cloudflare.
NC-181575 – Il campo dell’ora in Schedules veniva visualizzato in modo errato: Impedisce interpretazioni errate durante la modifica delle regole pianificate.
NC-171424 – Dopo aver eliminato l’unica eccezione nell’ultima pagina, l’elenco Web Exceptions appariva vuoto: Riporta correttamente alla pagina precedente invece di mostrare una configurazione apparentemente vuota.

Pianificare l’upgrade e convalidare MR2

Sophos supporta l’upgrade a v22 MR2 da tutte le versioni supportate delle serie v21.5, v21 e v20. L’immagine firmware può essere ottenuta manualmente tramite Sophos Central; la distribuzione automatica ai dispositivi collegati avverrà gradualmente nelle settimane successive. Secondo Sophos, l’aggiornamento è disponibile senza costi firmware aggiuntivi per i firewall provvisti di licenza con supporto Enhanced o Enhanced Plus.

Nonostante il lungo elenco di correzioni, MR2 non dovrebbe essere distribuito contemporaneamente su tutti i sistemi senza test. Il thread pubblico di feedback è stato aperto soltanto il giorno del rilascio. I primi contributi chiedono in particolare informazioni sulla stabilità di XGS 5500 in modalità HA active-passive e sulla correzione NC-177467. Non si tratta ancora di un nuovo problema MR2 confermato, ma è un buon motivo per aggiornare gradualmente i sistemi HA e le sedi critiche per l’azienda.

Prima dell’aggiornamento

Verificare il percorso di upgrade supportato e lo stato della licenza.
Creare un backup completo e cifrato e conservarlo in una posizione esterna.
Eseguire il controllo per l’upgrade a SFOS 22.
Valutare i risultati ancora aperti del Sophos Firewall Health Check.
Controllare lo stato HA, lo stato degli SSD, lo spazio libero sulle partizioni e lo stato dei pattern.
Documentare le funzioni critiche: WAN, SD-WAN, IPsec, SSL VPN, WAF, MTA, DDNS, autenticazione e Central Management.
Preparare la finestra di manutenzione, l’accesso alla console locale e i criteri per il rollback.

Dopo l’aggiornamento

Verificare Build 22.0 MR2 546, stato del sistema e hotfix attivi.
In HA, controllare entrambi i nodi, la sincronizzazione, i ruoli e il failover.
Testare WAN, DNS, DHCP/DDNS, SD-WAN e accesso a Internet.
Verificare le VPN site-to-site e Remote Access, inclusi IPv6 e failover.
Convalidare AD, Entra ID, STAS, SATC e accesso al portale con utenti di test.
Controllare WAF, Let’s Encrypt, MTA, quarantena e notifiche.
Controllare Central Task Queue e le modifiche ai gruppi applicate più di recente.
Cercare in Log Viewer nuovi errori, avvisi failsafe, riavvii dei servizi e messaggi PQC.
Aggiornare altre appliance soltanto dopo un periodo di osservazione stabile.

La procedura completa per backup, finestra di manutenzione e controlli successivi è descritta in Preparare un aggiornamento firmware di Sophos Firewall.

Conclusione

Sophos Firewall v22 MR2 è una maintenance release utile con una combinazione di modifiche insolitamente ampia. La crittografia post-quantistica e la migliore categorizzazione GenAI indicano la direzione in cui si stanno evolvendo il controllo della rete e delle applicazioni. Chromebook Manifest V3, STAS e Let’s Encrypt sono meno spettacolari, ma risolvono problemi concreti di lifecycle e operatività.

Il motivo principale per installare la Build 546 rimane la stabilità: sono stati corretti diversi crash del kernel, condizioni failsafe, problemi HA, errori VPN, una password in chiaro nel log di debug WAF e guasti rilevanti in logging, reporting, antivirus ed email. Proprio per la profondità di questi interventi, l’aggiornamento non dovrebbe essere trattato come un clic di routine. Backup, rollout graduale e controlli mirati delle funzioni restano indispensabili.