Sophos Firewall v22 MR2: aggiornamento o nuovo rischio?

Sophos Firewall v22 MR2 è arrivato. La build 546, pubblicata il 14 luglio 2026, propone un insieme contenuto ma utile di funzioni di sicurezza, modifiche all’autenticazione, aggiornamenti dei certificati e oltre 50 correzioni.

Sulla carta è un classico maintenance release. Nella pratica contiene proprio la combinazione che ormai mi fa esaminare due volte gli aggiornamenti Sophos: nuova logica di rilevamento IPS, comportamento modificato nell’associazione degli utenti, nuove catene di certificati e, insieme, un lungo elenco di crash del kernel, problemi HA, stati failsafe, errori VPN e interruzioni del reporting.

Non è soltanto una buona notizia. Più di 50 fix dimostrano che Sophos sta facendo pulizia, ma anche quanti problemi seri erano ancora presenti in GA e MR1. Ho già criticato questa qualità del firmware in Sophos Firewall: nessuna CVE, ma molti bug (da v21.5 a v22).

Installerò subito MR2 su uno dei miei Sophos Firewall. Non perché mi fidi ciecamente di una release al primo giorno, ma per capire se la build 546 riesca finalmente a stabilizzare il ramo v22 o se, ancora una volta, introduca più bug di quanti ne risolva. Controllerò in particolare HA, logging, IPsec, reattività di WebAdmin, STAS e stabilità dopo gli aggiornamenti dei pattern.

Sophos crea però uno strano contrasto. Config Studio 2.6 occupa ormai molto spazio negli aggiornamenti ufficiali del firewall. Lo strumento esterno nel browser ottiene unione dei template, ricerca migliore, diff tra più file, analisi delle migrazioni e dati di compatibilità hardware. Nell’interfaccia del firewall usata ogni giorno, invece, non cambia quasi nulla di visibile.

Considero quindi MR2 tecnicamente importante, ma strategicamente deludente. Il motore di sicurezza guadagna nuove capacità, mentre i workflow amministrativi moderni vengono ancora una volta spostati in Config Studio.

I punti essenziali

SFOS 22.0 MR2 corrisponde alla build 546 e segue MR1 build 490. Sophos evidenzia sette aree principali:

• rilevamento e controllo della crittografia post-quantistica
• migliore categorizzazione delle applicazioni di IA generativa
• nuova estensione Chromebook User ID basata su Manifest V3
• diverso comportamento predefinito di STAS
• preavviso della fine del supporto Novell eDirectory in SFOS 23.0
• nuove catene di attendibilità Let’s Encrypt e notifiche email migliori
• Config Studio 2.6 con nuove funzioni di analisi, migrazione e confronto

Si aggiungono oltre 50 problemi risolti. Dal punto di vista operativo, alcuni fix sono più importanti delle nuove funzioni: riguardano crash del kernel, errori HA, stati failsafe, guasti VPN e problemi di prestazioni nel reporting.

La mia valutazione in breve:

• Chi usa già v22 GA o MR1 ed è colpito da uno dei problemi elencati ha un motivo concreto per installare MR2.
• Chi dispone di un’installazione 21.5 stabile non dovrebbe aggiornare in fretta soltanto per PQC o Config Studio.
• Le firme PQC vanno inizialmente usate in sola osservazione, non subito con Drop.
• Gli ambienti STAS devono verificare come viene gestito il traffico non autenticato durante l’Identity Probe.
• Le installazioni HA, IPsec, WAF, mail e reporting richiedono test funzionali reali, non una rapida occhiata agli indicatori verdi.
• Config Studio 2.6 è utile, ma non dimostra che WebAdmin di SFOS stia diventando più moderno. Semmai suggerisce il contrario.

Resta fondamentale il limite hardware: SFOS 22.0 non supporta più gli appliance hardware XG e SG. MR2 è destinato a XGS, installazioni virtuali, software e cloud supportate. Chi utilizza ancora hardware XG non può pianificare MR2 come normale passo firmware successivo.

Rilevare e controllare la crittografia post-quantistica

La novità tecnicamente più interessante è il controllo della crittografia post-quantistica, o PQC. Non significa che Sophos Firewall respinga improvvisamente i computer quantistici: riguarda moderni meccanismi di scambio delle chiavi progettati per resistere meglio a futuri attacchi quantistici.

MR2 si concentra su ML-KEM. Standardizzato nel 2024 come FIPS 203, si basa sulla difficoltà presunta del problema Module Learning With Errors. NIST definisce tre set di parametri:

• ML-KEM-512, con chiavi e volume dati più piccoli
• ML-KEM-768, variante intermedia oggi particolarmente diffusa
• ML-KEM-1024, con livello di sicurezza maggiore ma più calcolo e traffico

Nei documenti MR2 Sophos parla soltanto in generale di algoritmi di key exchange puri e ibridi basati su ML-KEM. Non indica i set di parametri, i gruppi TLS o gli ID delle firme coperti. Non si può quindi presumere che venga rilevata ogni possibile variante ML-KEM.

Che cosa fa tecnicamente un KEM

ML-KEM non cifra direttamente l’intero flusso di dati. In forma semplificata, un Key Encapsulation Mechanism comprende tre operazioni:

1. KeyGen genera una encapsulation key e la corrispondente decapsulation key.
2. Encaps usa la chiave pubblica per generare un oggetto ciphertext e un segreto condiviso.
3. Decaps recupera lo stesso segreto sul lato opposto usando la chiave privata.

Il protocollo deriva poi da questo segreto le chiavi simmetriche di sessione. I dati effettivi continuano a essere protetti da algoritmi simmetrici veloci come AES o ChaCha20. ML-KEM sostituisce la parte asimmetrica vulnerabile della negoziazione, non l’intera cifratura TLS.

Il contesto pratico è Harvest now, decrypt later: un attaccante può registrare oggi traffico cifrato sperando di decifrarlo tra anni con un computer quantistico crittograficamente rilevante. Per dati effimeri il rischio è minore; dati sanitari, comunicazioni governative, proprietà intellettuale e informazioni aziendali riservate possono invece dover restare protetti più a lungo del tempo necessario all’arrivo di una nuova classe di attacchi.

Puro e ibrido non sono la stessa cosa

Con uno scambio PQC puro, la sicurezza della negoziazione dipende soltanto dal nuovo metodo post-quantistico. Lo scambio ibrido combina invece un meccanismo classico con ML-KEM. Un esempio già comune nelle implementazioni TLS reali è X25519MLKEM768: sia X25519 sia ML-KEM-768 contribuiscono al segreto finale.

Durante la migrazione questo approccio è sensato. Se ML-KEM rivelasse un errore di implementazione o una debolezza matematica, resterebbe la componente classica. Se un computer quantistico sufficientemente potente violasse la curva ellittica classica, resterebbe ML-KEM. L’ibrido è quindi un ponte di migrazione, non un’inutile doppia cifratura.

X25519MLKEM768 è però un esempio tecnico reale, non l’affermazione che Sophos rilevi soltanto o soprattutto questo gruppo. I documenti MR2 non lo dicono.

Che cosa fa l’IPS

L’Intrusion Prevention System riceve firme capaci di rilevare scambi ML-KEM puri e ibridi. Gli amministratori possono creare regole IPS con azioni come Allow, Drop o Reset.

Tecnicamente il firewall può osservare lo scambio offerto e scelto nel handshake TLS: il client pubblicizza gruppi supportati e key share in ClientHello, il server conferma la scelta in ServerHello. Ciò avviene prima del flusso applicativo cifrato, quindi il rilevamento è possibile senza leggere il contenuto HTTPS successivo.

Sophos non documenta però dove Snort o la pipeline IPS di SFOS analizzino questi campi, quali versioni TLS siano coperte e se il comportamento cambi tra proxy, DPI e traffico FastPath non decifrato. Le release note confermano la capacità, non l’implementazione interna del percorso dati. Per una policy produttiva servono quindi test nei log firewall e IPS.

Le azioni hanno effetti diversi:

• Allow lascia proseguire la connessione e, insieme al logging, è adatto all’inventario.
• Drop scarta silenziosamente i pacchetti corrispondenti; il client vede in genere un timeout o un handshake fallito.
• Reset chiude attivamente la connessione TCP; l’errore appare prima, ma può presentarsi diversamente nei log di client e applicazione.

Le nuove firme sono disattivate per impostazione predefinita, ed è la scelta corretta. PQC non è più tecnologia da laboratorio: browser, servizi cloud e piattaforme web importanti testano o usano già metodi ibridi. Un blocco indiscriminato potrebbe interrompere siti e applicazioni legittimi.

Un’introduzione ragionevole è quindi:

1. Attivare le firme lasciando passare e registrando il traffico.
2. Osservare per giorni o settimane quali applicazioni e destinazioni usano ML-KEM.
3. Verificare se le policy crittografiche interne vietino o richiedano determinati metodi.
4. Solo dopo applicare selettivamente Drop o Reset.

Nella prima discussione della community, un amministratore non trovava le firme cercando PQC, KEM o quantum. Il pattern update potrebbe non essere ancora arrivato oppure i nomi potrebbero essere diversi. Poche ore dopo il rilascio non basta per parlare di difetto, ma emerge un problema di documentazione: una funzione è amministrabile soltanto se nome della firma, SID, categoria e campi di log sono reperibili.

Prima di modificare la policy controllerei:

• L’IPS è attivo e la sottoscrizione Network Protection è valida?
• Quale versione dei pattern IPS è installata?
• Con quale nome e SID compaiono le nuove firme?
• I rilevamenti appaiono nel log IPS e nel reporting centrale?
• Il comportamento resta uguale con eccezioni DPI, TLS Inspection e FastPath?
• Quali browser, sistemi operativi, servizi cloud e applicazioni interne generano eventi?

Che cosa fa Web Protection

Secondo Sophos, Web Protection impedisce anche alle sessioni web di negoziare algoritmi PQC non supportati. È un compito diverso da una firma IPS: l’IPS rileva pattern e applica un’azione; Web Protection interviene nel workflow TLS e web controllato, impedendo l’uso di un metodo che il firewall non sa elaborare o che la policy non consente.

Questo conta soprattutto con TLS Inspection. Il firewall termina la sessione TLS del client e ne crea una seconda verso il server di destinazione. Esistono quindi due handshake e due set di chiavi. Browser e server potrebbero supportare PQC mentre il componente di inspection intermedio non sa gestire correttamente il gruppo offerto.

Senza un comportamento controllato nascono errori difficili da interpretare: il client offre un nuovo gruppo, il firewall non riesce a mediare il handshake, il server seleziona una variante inattesa oppure il fallback si comporta diversamente dal previsto. MR2 dovrebbe impedire la negoziazione di algoritmi PQC non supportati nelle sessioni web.

Sophos non descrive però una matrice di policy PQC per Web Protection, una lista dei gruppi supportati o se un’offerta non supportata venga rimossa, rifiutata oppure sostituita tramite fallback classico. Non va confuso con le azioni IPS configurabili.

La funzione è utile, ma non sostituisce una strategia crittografica. Le aziende devono ancora sapere quali connessioni TLS vengono decifrate, dove esistono eccezioni e se PQC debba essere solo osservato o realmente imposto.

Maggiore visibilità per le applicazioni di IA generativa

La seconda funzione di sicurezza migliora la categorizzazione delle applicazioni di IA generativa tramite Synchronized Application Control.

Il principio non è nuovo: Sophos Endpoint vede quale processo locale apre una connessione e comunica il contesto al firewall tramite Security Heartbeat. SFOS può così associare la sessione a un programma anche quando porta, IP di destinazione e traffico cifrato non bastano.

Il percorso dati semplificato è:

1. Un’applicazione su un endpoint protetto apre una connessione.
2. Sophos Endpoint conosce nome del processo, percorso e contesto locale.
3. Security Heartbeat collega la visibilità di endpoint e firewall.
4. SFOS associa la sessione sconosciuta o riconosciuta solo genericamente a un’applicazione.
5. L’applicazione appare in Synchronized Application Control e può essere categorizzata.
6. Una Application Filter Policy permette, blocca o limita il traffico.

In Connection List, Resolve application info può richiedere all’endpoint dati per le connessioni non identificate. L’elenco è ricercabile per nome, percorso, categoria o endpoint. Sophos indica un massimo di 15.000 applicazioni gestite e, per risparmiare memoria, conserva solo le cinque occorrenze più recenti per applicazione ed endpoint.

MR2 migliora in particolare l’associazione delle applicazioni di IA generativa. Sophos Endpoint dovrebbe riconoscerle meglio e passare l’informazione a SFOS. La categoria Generative AI può così essere usata in Application Filter e report.

I vantaggi sono tre:

• Visibilità: reporting più chiaro sull’IA generativa in uso
• Regole: permessi, limitazioni o blocchi più mirati
• Inventario: base migliore per distinguere servizi approvati e non approvati

È utile, ma “rilevare l’IA generativa” non va sopravvalutato. Synchronized Application Control risponde soprattutto a quale applicazione ha creato la connessione. Non determina automaticamente:

• quale prompt ha inserito l’utente
• quale file è stato caricato
• se conteneva dati personali o riservati
• se una sessione browser rappresenta uso privato o aziendale
• se un servizio consentito ha utilizzato una funzione IA integrata

Un client desktop con un percorso di processo univoco è più facile da attribuire rispetto a dieci servizi IA dentro lo stesso browser. Categorizzazione URL, TLS Inspection e cloud-app detection possono aggiungere informazioni, ma sono livelli distinti.

Il valore dipende inoltre da Sophos Endpoint, Security Heartbeat attivo e Synchronized Application Control abilitato inizialmente tramite Sophos Central. Chi usa soltanto SFOS o endpoint fuori dal percorso Heartbeat non ottiene la stessa profondità.

L’aspettativa corretta è una migliore attribuzione delle applicazioni e quindi una base policy più solida, non la soluzione completa a quali servizi IA siano ammessi e quali dati possano trattare.

Non bloccherei subito l’intera categoria Generative AI. Prima va chiarito quali eventi provengano dal contesto endpoint, dalla firma firewall o dalla categorizzazione web. Altrimenti si rischia di bloccare funzioni produttive di Microsoft 365, strumenti di sviluppo, browser o piattaforme di supporto senza comprenderne l’uso reale.

Modifiche all’autenticazione e all’associazione utenti

MR2 introduce tre temi di autenticazione indipendenti. Due richiedono una preparazione concreta; il terzo è un preavviso di migrazione.

Chromebook User ID con Manifest V3

Sophos Chromebook User ID Extension è passata a Manifest V3, l’attuale piattaforma delle estensioni Chrome.

Sophos richiede di disinstallare la vecchia estensione e installare la nuova: un semplice aggiornamento silenzioso non basta. Scuole e aziende con Chromebook gestiti centralmente dovrebbero preparare il cambio nelle policy Google Admin, testarlo su un gruppo pilota e poi distribuirlo ampiamente.

L’estensione è solo una parte del percorso SSO. Sophos richiede tra l’altro:

• un server AD, LDAP o Google Secure LDAP sul firewall
• Chromebook nella rete protetta da SFOS
• indirizzi utente del dominio Google Workspace registrato
• un certificato per la comunicazione cifrata e un CN corrispondente
• la porta Sophos 65123 per impostazione predefinita
• configurazione JSON esportata da SFOS e inserita in Google Workspace
• accesso a accounts.google.com, agli host Google API e al Chrome Web Store

La distribuzione avviene in Devices > Chrome > Apps and extensions > Users and browsers. In produzione è opportuno Force install, per impedire agli utenti di rimuoverla. La Sophos User ID App deve inoltre essere considerata attendibile negli API Controls, altrimenti OAuth può fallire.

Dopo il cambio bisogna testare l’intera catena:

1. L’utente accede al Chromebook.
2. L’estensione raggiunge il firewall tramite rete e certificato previsti.
3. L’utente compare in Live users.
4. Una regola basata sull’utente corrisponde davvero a utente o gruppo.
5. Dopo logout o cambio dispositivo, l’associazione scompare correttamente.

Senza la nuova estensione, gli aggiornamenti futuri possono cessare. A seconda del progetto di autenticazione, possono risentirne l’associazione utenti e le regole firewall o web. In una scuola il filtro può smettere di funzionare anche se firewall, internet e Chromebook sembrano tutti “online”.

STAS non blocca più per impostazione predefinita durante l’Identity Probe

Per Sophos Transparent Authentication Suite, MR2 porta il valore predefinito di Restrict client traffic during identity probe a No.

STAS associa indirizzi IP agli utenti osservati sui domain controller Windows:

1. L’utente accede al dominio Windows.
2. Il domain controller scrive un evento di security audit, normalmente Event ID 4768 nelle versioni recenti.
3. STAS Agent legge nome utente e indirizzo IP.
4. L’agent invia i dati al collector tramite TCP 5566.
5. Il collector segnala le associazioni al firewall tramite UDP 6060.
6. Quando SFOS vede traffico da un IP sconosciuto, può interrogare il collector sulla porta 6677.
7. Il firewall aggiunge l’appartenenza ai gruppi dal server AD e applica regole utente.

Un IP sconosciuto entra in Learning Mode. Finora il traffico veniva normalmente sospeso o scartato durante la verifica. Il periodo predefinito documentato è 120 secondi. Se il collector non risponde, l’IP può poi restare non autenticato per un’ora e vengono applicate le relative regole.

In MR1 esisteva un problema operativo reale. Sophos documenta NC-181885: con Restrict client traffic during identity probe = Yes, verifiche ripetute potevano causare interruzioni intermittenti o bloccare l’upgrade a MR1. MR2 è indicato come versione correttiva e cambia anche il default in No.

Con No il traffico prosegue durante la verifica. Si riducono le interruzioni, ma cambia il compromesso:

• L’utente subisce meno disservizi.
• Il firewall può non avere ancora un’identità confermata.
• Regole e logging basati sull’utente vanno controllati durante la transizione.

È il classico compromesso tra disponibilità e applicazione rigorosa dell’identità. Con Yes, una comunicazione collector guasta può bloccare il client. Con No, il traffico può fluire prima della conferma. Se corrisponda a una regola di rete generale, a una regola non autenticata o poi a una regola utente va verificato nel proprio ruleset.

Le release note dicono che il valore predefinito cambia in No, non che ogni configurazione esistente impostata consapevolmente venga sovrascritta. Dopo l’upgrade bisogna verificare il valore effettivo.

Controllerei inoltre:

• UDP 6060 e 6677 sono aperte tra firewall e collector?
• Il servizio STAS è attivo e associato alla NIC corretta?
• Più collector sono raggruppati per la fault tolerance?
• Esistono Clientless User per stampanti, IoT e dispositivi fuori dominio?
• Gli utenti vengono associati correttamente dopo sleep, roaming, cambio DHCP e logout?
• Le regole durante Learning Mode e stato non autenticato rispettano il security design?

È particolarmente importante dove l’identità è una condizione di accesso reale e non soltanto un attributo di reporting.

Novell eDirectory termina con SFOS 23.0

MR2 segnala per la prima volta che Sophos terminerà il supporto dei server di autenticazione Novell eDirectory in SFOS 23.0.

eDirectory continua a funzionare in MR2. È un preavviso, non una perdita immediata di servizio. Chi lo usa in produzione dovrebbe comunque migrare verso un tipo di autenticazione supportato prima di installare SFOS 23.0.

La migrazione coinvolge più della voce server. Gruppi, regole firewall, web policy, VPN, portali utente e reporting possono dipendere dalla sorgente identità. Distinguished Name, gruppi annidati, percorsi di ricerca e formati username differenti fanno sì che un test LDAP riuscito non dimostri il funzionamento delle policy.

STAS inoltre non supporta LDAP su SSL/TLS per eDirectory già da tempo, quindi la rimozione non sorprende del tutto. L’architettura sostitutiva va comunque gestita come progetto: account di test, gruppi paralleli, riferimenti alle regole documentati e piano di rollback.

Let’s Encrypt: nuove catene e migliore identificazione

Let’s Encrypt sta trasferendo gradualmente la propria infrastruttura a nuovi certificati root e intermediate. MR2 aggiunge il supporto per YE Root, YE1, YE2, YR Root, YR1 e YR2.

Questa gerarchia Generation Y contiene due nuove Root CA con tipi di chiave differenti:

• ISRG Root YE usa ECDSA P-384 e prosegue il percorso ECDSA.
• ISRG Root YR usa RSA 4096 ed è il nuovo percorso root RSA.
• YE1 e YE2 sono intermediate ECDSA P-384.
• YR1 e YR2 sono intermediate RSA 2048.

Le root sono cross-signed dalle precedenti root ISRG. Le nuove catene possono così terminare su trust anchor già diffusi mentre browser e sistemi operativi adottano le nuove root. Gli intermediate YE1, YE2, YR1 e YR2 sono diventati rilevanti per l’emissione attiva nel 2026.

Per SFOS è soprattutto una modifica di compatibilità. Il firewall deve conoscere nuovi issuer e catene affinché emissione automatica, rinnovo, uso WAF e validazione continuino a funzionare. Senza trust chain aggiornate, le operazioni sui certificati potrebbero fallire anche con dominio, porta 80 e validazione HTTP-01 configurati correttamente.

È spiacevole perché un errore ACME viene facilmente attribuito a DNS, DNAT, porta 80, regola WAF o Terms of Service, mentre la vera causa può essere una nuova catena CA.

SFOS continua a usare HTTP-01. Il dominio deve risolvere sull’indirizzo WAN pubblico scelto, la porta 80 deve raggiungere il firewall e una regola DNAT concorrente sullo stesso indirizzo e porta può impedire la validazione. MR2 non cambia il principio, ma amplia la gerarchia CA supportata.

Le email Let’s Encrypt includono ora hostname e numero seriale del firewall. È una piccola modifica molto utile per MSP e grandi ambienti: una segnalazione può finalmente essere attribuita al dispositivo corretto senza indagare su un messaggio generico.

È una classica miglioria pratica. Ogni messaggio generato da un firewall gestito centralmente dovrebbe contenere almeno hostname, seriale, modello e firmware. Le email di backup si erano già mosse in questa direzione; Let’s Encrypt segue con MR2.

Config Studio 2.6: tutte le nuove funzioni spiegate

Sophos presenta ufficialmente Config Studio 2.6 nell’annuncio MR2, sebbene resti uno strumento browser separato e non una nuova interfaccia integrata in SFOS. Il precedente articolo Sophos Firewall Config Studio V2: molto più di un viewer descrive il workflow completo con export, Entities.xml, confronti ed editor.

Sophos dichiara che parsing, analisi e generazione dei report avvengono localmente nel browser dell’endpoint e che la configurazione non viene inviata a Sophos o ad altri server. È essenziale: Entities.xml può contenere reti interne, oggetti, regole, definizioni VPN, riferimenti a certificati e nomi organizzativi.

Elaborazione locale non significa assenza di rischi. Il browser carica comunque l’applicazione da internet. In ambienti molto sensibili vanno considerate versione del codice, cache, uso offline, hardening dell’endpoint e conservazione sicura. Un file Entities.xml non dovrebbe finire senza controllo in Downloads, ticket o sincronizzazione cloud ordinaria.

Config Studio 2.6 copre ormai cinque aree:

• Configuration Report con Policy Test, analisi e ricerca globale
• confronto di due o più configurazioni
• editor visuale con bulk editing e output XML, API o curl
• migrazione da Sophos UTM, SonicWall, FortiGate e Palo Alto Networks
• compatibilità backup/restore, Flexi Port, transceiver e modelli

Unire i template

Merge Templates combina configurazioni baseline e template di settore. Un MSP può unire una base tecnica per logging, DNS, accessi admin e oggetti standard con un modello per studi medici, scuole o filiali.

Il riuso evita di ricominciare da zero, ma la gestione dei conflitti resta critica:

• Che cosa accade a nomi oggetto uguali con valori differenti?
• UUID, riferimenti e ordine delle regole vengono risolti in modo coerente?
• Quali riferimenti a interfacce e zone non si adattano al modello target?
• Nascono regole duplicate o sovrapposte?
• Un oggetto restrittivo può essere sostituito da un valore più ampio?

Dopo l’unione, Duplicate Analysis, Shadow Rule Analysis, Usage References e Policy Test completo sono obbligatori. Un merge tecnicamente riuscito non dimostra che la policy risultante sia sicura.

Ricerca globale migliorata

La ricerca globale trova oggetti e porta direttamente al punto pertinente. È importante nei ruleset grandi, dove un host può essere referenziato in configurazioni firewall, NAT, TLS, web o VPN. A seconda del tipo di dati, possono essere rilevanti anche valori, percorsi ed elementi referenziati. Il salto diretto è prezioso con nomi generici come Server, LAN_Network o host group cresciuti nel tempo.

Search non è Usage Reference. Search risponde “Dove trovo questo oggetto o valore?”, Usage Reference “Quali altri elementi ne dipendono?”. Per una modifica sicura servono entrambe le prospettive. Proprio questa funzione sarebbe urgente anche nell’interfaccia firewall.

Report di configurazione più informativi

I report mostrano per regole firewall, NAT e TLS non solo i nomi dei riferimenti, ma anche valori e dettagli degli oggetti. Invece del solo Webserver-Gruppe, il revisore vede quali host o reti contiene. Un nome rassicurante può infatti nascondere Any, una rete troppo ampia o voci obsolete.

Il report supporta Policy Test e analisi. Policy Test determina quale regola o route corrisponda ai valori sorgente e destinazione indicati. L’analisi cerca anche shadowing e duplicati. Poiché SFOS valuta le regole dall’alto e si ferma alla prima corrispondenza, l’ordine è parte della sicurezza, non solo presentazione.

Config Studio 2.6: migrazione, confronto ed export

Analisi di migrazione con percentuale di successo

Config Studio mostra informazioni su migrazione e conversione, compresa la quota trasferita con successo. La percentuale è un indicatore rapido, non un verbale di collaudo.

Sophos distingue:

• Supported: migrazione automatica senza variazione sostanziale
• Partial: migrazione con lacune da completare
• Manual: ricreazione manuale necessaria su Sophos Firewall
• Not supported: elemento non migrato
• Action required: decisione necessaria prima dell’export

In una conversione al 95 percento, il cinque percento mancante può contenere proprio certificati, password, VPN, NAT o routing speciale. Il valore utile non è il numero verde, ma l’elenco degli elementi irrisolti, parziali o risolti automaticamente.

Le logiche dei produttori differiscono davvero. Le regole FortiGate possono essere più legate alle interfacce, mentre SFOS usa le zone; Palo Alto adotta altri modelli per oggetti, zone e policy. Config Studio converte sintassi e strutture, ma non può dimostrare che il modello di sicurezza conservi la stessa semantica.

Multi-File Configuration Diff

Multi-File Diff confronta due o più configurazioni nel tempo. Config Studio ordina i file per data di modifica e mostra i campi aggiunti, rimossi o cambiati.

Sono disponibili viste Side-by-Side, Unified e Semantic. Il confronto semantico è interessante perché un diff testuale XML viene facilmente disturbato da ordine, ID e formattazione. Il confronto a livello di entity e field cerca invece di mostrare la modifica reale.

È utile per ricostruire change e diagnosticare problemi emersi dopo tempo. Richiede però export regolari, timestamp affidabili e trattamento sicuro dei dati. La data di modifica di un file copiato non coincide necessariamente con quella della modifica firewall. Per una cronologia solida bisogna registrare insieme nome file, ora export, hostname, seriale, firmware e change ticket.

Senza disciplina delle versioni, Multi-File Diff non può inventare una storia. Integrata in Central con audit immutabile, la funzione sarebbe molto più potente del caricamento manuale.

Riferimento per backup/restore, Flexi Port e velocità

Config Studio controlla la compatibilità di backup e restore e i layout delle porte tra modelli Sophos Firewall. Mostra anche moduli Flexi Port e standard e velocità supportati fino a 25, 40 o 100 Gbit/s.

Prima di una migrazione hardware aiuta a stabilire:

• se un backup sia generalmente ripristinabile
• quante porte fisiche siano disponibili
• se i moduli Flexi Port esistenti siano compatibili
• quali standard e velocità siano supportati

Non sostituisce il progetto di migrazione. LAG, VLAN, bridge, HA, nomi porte, zone e mapping delle interfacce devono ancora essere pianificati e verificati.

La compatibilità più ampia vale per target da SFOS 20.0 MR2. In base a sorgente e destinazione appare il Backup-Restore Assistant per mappare le interfacce. Le porte fisiche possono essere riassegnate, VLAN e alias seguono la parent interface, LAG e bridge vengono ricostruiti dalle porte mappate.

Per Flexi Port non basta che il modulo entri fisicamente. Generazione del modello, form factor, transceiver, standard, velocità, breakout e versione SFOS devono essere verificati insieme. Config Studio accelera la consultazione, ma non sostituisce test di link e failover.

Dark Mode

Le release note citano anche il Dark Mode. È una piccola miglioria di usabilità, non una funzione firewall. Ma è quasi simbolico: persino la modalità scura arriva prima nello strumento esterno, mentre la console WebAdmin locale progredisce da anni solo lentamente sul piano visivo ed ergonomico.

Quale output può generare l’editor

L’editor importa o crea configurazioni, esegue Bulk Changes e mostra il risultato come Import XML, API Request o curl. In alternativa scarica XML o un archivio TAR importabile tramite Backup & firmware > Import export.

È potente, ma aumenta la responsabilità dell’amministratore. Una API request generata non è automaticamente idempotente. Un import riuscito non prova che ordine regole, oggetti, NAT, VPN e security policy siano corretti. L’output va inserito nel change ticket, il diff revisionato e il firewall testato su percorsi dati reali.

Oltre 50 fix sono il vero motivo per MR2

Sophos elenca oltre 50 correzioni di affidabilità, stabilità e sicurezza. Non tutte riguardano ogni installazione, ma diverse sono operative e serie.

HA e failsafe non sono temi marginali

Diversi fix riguardano l’operatività dell’appliance:

• NC-181331: una partizione di configurazione piena poteva portare il firewall in failsafe.
• NC-180110: il Logging Daemon non si avviava sul primary e il dispositivo HA entrava in failsafe.
• NC-177441: dopo upgrade a v22 GA, un problema Postgres poteva mandare in failsafe il primary originale.
• NC-178906: RED Server Service poteva non avviarsi e causare failsafe.
• NC-177467: l’auxiliary non partiva correttamente con molte connessioni SSH non autenticate simultanee.

Cause diverse, stesso risultato operativo: servizi persi, modalità di protezione o peer HA non disponibile nonostante il quadro cluster verde. Dopo l’upgrade, HA status: Active-Passive non basta: bisogna testare sincronizzazione, servizi, failover e traffico reale.

I fix IPsec entrano in profondità nel percorso dati

• NC-180433: traffico multicast attraverso una VPN poteva causare crash ripetuti.
• NC-171719: il traffico ESP seguiva un routing errato in uno scenario SD-WAN.
• NC-180520: con IPsec Acceleration, un gateway XFRM restava indisponibile dopo upgrade quando il tunnel era legato a un alias IP ed ESP arrivava da un’altra WAN.
• NC-176855: throughput IPv6 degradato su IPsec route-based.
• NC-178121: il drag-and-drop poteva spostare connessioni site-to-site in posizioni errate dentro un Failover Group.

Uno stato tunnel Active non prova nulla in questi casi. Per VPN route-based vanno testati separatamente XFRM, routing table, decisione SD-WAN, percorso ESP, MTU, IPv4 e IPv6. Nei Failover Group bisogna verificare ordine e commutazione rispetto alla priorità documentata.

Logging e reporting potevano causare disservizi

NC-155252 è particolarmente spiacevole: un alto disk I/O nel reporting causava picchi CPU e interruzioni internet intermittenti fino a un minuto. Un sottosistema di analisi influenzava il percorso dati produttivo.

NC-178745 descrive il riavvio automatico di un dispositivo HA per out-of-memory nel Logging Framework; NC-181520 migliora le prestazioni di Log Viewer. Insieme dimostrano che il logging SFOS non è una funzione secondaria innocua. Storage, database, Garner, Log Viewer e Central Reporting sono più vicini al sistema di quanto suggerisca l’interfaccia.

Dopo MR2 non basta verificare nuove righe di log:

• Gli eventi firewall, IPS, WAF, autenticazione e VPN arrivano completi?
• La cronologia è priva di lacune?
• Il collector syslog esterno riceve ancora dati?
• CPU, RAM e disk I/O restano stabili sotto carico normale?
• I report vengono generati senza influire sul percorso dati?

I fix Central mostrano i limiti del “Single Pane of Glass”

Con NC-181175 le Group Policy da Sophos Central potevano restare in Pending. NC-180513 riguardava l’import dalla Central View dopo MR1. NC-181904 impediva di rilasciare email in quarantena tramite Central.

Il punto comune è che l’interfaccia centrale può accettare o mostrare un’operazione senza provare che il firewall l’abbia eseguita. Dopo un push bisogna verificare sul dispositivo oggetto, regola, ordine e timestamp. Una finestra di successo chiusa in Central non è prova tecnica del commit.

Per questo non valuto i maintenance release soltanto dalla lista di funzioni. Un fix che impedisce failsafe o riavvio per logging, Postgres, SD-WAN o multicast vale più di una nuova dashboard.

La quantità dei fix non è però un certificato di qualità. Dimostra che i problemi sono stati risolti e quanti problemi seri esistevano nei build precedenti. Un ambiente HA, VPN o WAF critico non dovrebbe né restare per paura eternamente su un vecchio build né distribuire MR2 ovunque senza test il primo giorno.

Che cosa controllare prima dell’upgrade

Sophos consiglia di installare MR2 tempestivamente per sicurezza, stabilità e prestazioni. È comprensibile, ma in produzione “tempestivamente” non significa alla cieca.

Il vecchio VLAN tagging sui bridge blocca MR2

MR2 introduce un blocco rigido per il vecchio VLAN tagging via CLI sulle interfacce bridge. Una configurazione che usa ancora il metodo legacy system vlan-tag non può aggiornare a SFOS 22.0 MR2 o successivi.

Va ripulita o migrata prima. Inoltre, i backup con questa configurazione non possono essere ripristinati su SFOS 22.0 GA o successivi. È importante nelle installazioni storiche modificate via CLI anni fa.

Restano gli ostacoli già noti di v22

• Legacy Remote Access IPsec va rimosso o migrato prima di MR1 o MR2.
• SFOS 22 richiede più spazio; alcuni appliance desktop, virtuali o software richiedono adeguamenti.
• Il comportamento delle VPN IPsec policy-based è cambiato da GA e va verificato.
• Hardware XG e SG non supporta SFOS 22.
• RED 15, RED 15w e RED 50 non sono più supportati da v21.5.

La mia procedura di upgrade

Per firewall produttivi procederei almeno così:

1. Creare un backup corrente e conservarlo esternamente.
2. Verificare supporto, licenze e percorso di upgrade approvato.
3. Escludere Legacy Remote Access IPsec e VLAN tagging CLI sui bridge.
4. Controllare gli avvisi di spazio nel Control Center.
5. In HA, verificare entrambi i nodi, sincronizzazione e firmware disponibile.
6. Documentare VPN critiche, pubblicazioni WAF, mail flow, regole SD-WAN e autenticazione.
7. Installare prima MR2 su un appliance rappresentativo ma meno critico.
8. Testare log, pattern, HA, routing, DNS, VPN, WebAdmin, reporting e policy push centrali.

Con molti fix, un test prima/dopo è particolarmente prezioso. Altrimenti si sa che il firmware è nuovo, non che i percorsi dati critici funzionino ancora esattamente come previsto.

Da SFOS 20 esiste un rollback automatico se la migrazione della configurazione fallisce. Riduce il rischio di avvio con Factory Configuration, ma non copre ogni scenario, tra cui percorsi non supportati e alcuni flussi Setup Assistant. Dopo un rollback automatico vanno analizzati migration.log e migrationhash.log.

Il rollback non sostituisce backup esterno, Secure Storage Master Key e accesso console. Protegge soprattutto da una migrazione fallita; non prova che WAF, VPN, HA o reporting siano corretti dopo un upgrade tecnicamente riuscito.

Nel mio test diretto MR2 misurerò o provocherò gli stessi controlli prima e dopo:

• riavvio e avvio completo dei servizi
• login WebAdmin e reattività di grandi liste di regole
• flusso log locale ed esterno
• traffico IPsec, rekey e failover
• Central Policy Push verificato sul firewall
• aggiornamento pattern IPS e Application Control
• nuova autenticazione STAS e comportamento di un IP client sconosciuto
• sincronizzazione HA e cambio ruolo controllato, se il test usa un cluster

Solo allora potrò dire se MR2 è davvero migliore nel mio ambiente. Installazione riuscita e Control Center verde non bastano.

Che cosa dicono i primi feedback della community

Il thread di feedback è stato aperto il giorno della release e, al momento di questa analisi, ha solo poche ore. Non dimostra né stabilità né problemi di MR2.

Due discussioni meritano comunque attenzione:

• Un gestore di XGS 5500 Active-Passive HA chiede espressamente la profondità dei test perché NC-177467 lo ha colpito per mesi sotto MR1. Sophos lo elenca come corretto in MR2; riguarda un auxiliary che non si avvia con molti tentativi SSH non autenticati simultanei.
• Per le firme PQC, un dipendente Sophos conferma che sono volutamente disattivate. Poiché PQC TLS aumenta nei browser e nelle applicazioni, l’attivazione immediata può creare moltissimi eventi. La direzione raccomandata è prima Allow con logging e solo dopo, se necessario, un’azione bloccante.

È il tipo giusto di discussione iniziale: test concreti, case ID e feedback riproducibili invece di generici “funziona” o “è rotto”. Continuerò a seguire il thread, soprattutto per HA, IPsec, WAF, STAS e reporting.

Config Studio diventa il magazzino ricambi di una vecchia interfaccia

Ora la parte scomoda.

Config Studio 2.6 è un buon tool. Unire template, cercare oggetti, risolvere riferimenti nei report, confrontare più configurazioni e preparare migrazioni hardware sono vere funzioni amministrative. Non critico che Sophos le sviluppi, ma dove le sviluppa.

Sophos cita ormai Config Studio direttamente nelle release note del firewall e nell’annuncio MR2. Sembra sempre più la risposta strategica a problemi che andrebbero risolti in WebAdmin o Sophos Central.

L’interfaccia locale resta vecchia e spesso lenta con configurazioni grandi. Le modifiche massive sono inadeguate. Utilizzo degli oggetti, vera ricerca globale, diff puliti, clonazione NAT, conflitti tra regole e workflow di change moderno mancano proprio dove gli amministratori lavorano ogni giorno. Central colma solo parte del divario.

Il problema non è soltanto il design. Un’interfaccia firewall moderna dovrebbe offrire:

• Candidate Configuration invece di singole modifiche immediatamente distribuite
• diff completi prima/dopo il commit
• controllo dipendenze tra oggetti, regole, NAT, VPN e TLS
• commit atomico o stato transazione chiaro
• rollback validato all’ultimo stato noto
• attribuzione reale di utente, ora e fonte nell’Audit Trail
• Bulk Operations con anteprima e verifica conflitti
• output API coerente per change riproducibili

Config Studio ne ricrea alcune parti fuori dal sistema. Analizza un export, produce XML o richieste API e aiuta con i diff. Ma tra questa vista offline e lo stato runtime del firewall resta un vuoto. Sessioni, routing dinamico, stato HA, pattern attuali, certificati e configurazione realmente caricata non equivalgono a un Entities.xml locale.

Sarebbe eccessivo dedurre da un annuncio che Sophos non modernizzerà mai SFOS. Non esiste una dichiarazione ufficiale. Il segnale resta negativo: i progressi più visibili su usabilità, ricerca, confronto e configurazione arrivano ancora una volta fuori dalle interfacce di gestione reali.

Il workflow resta frammentato:

1. Esportare la configurazione dal firewall.
2. Estrarre l’archivio e cercare Entities.xml.
3. Caricare il file in un tool browser separato.
4. Analizzarlo, confrontarlo o modificarlo.
5. Esportare il risultato e riportarlo tramite XML, API o curl.

Va bene per un audit, ma è tortuoso per un’amministrazione moderna, sicura e tracciabile. Config Studio non copre solo una nicchia: riceve proprio le funzioni più semplici richieste da anni dagli amministratori Sophos.

Se Config Studio viene ormai presentato come tema importante nelle normali release note, non è più una piccola utility. È visibilmente parte della strategia amministrativa. Sophos dovrebbe spiegare quali funzioni arriveranno in WebAdmin o Central e quali resteranno nel tool browser.

Senza roadmap nasce l’impressione che l’interfaccia vecchia, lenta e sempre meno amichevole resterà, mentre agli amministratori verrà detto di usare Config Studio per workflow moderni. Non è un piano Sophos confermato, ma è la direzione comunicata oggi dal prodotto.

Perché così UniFi ha vita facile

UniFi non sostituisce completamente ogni Sophos Firewall. In base a licenza e architettura, Sophos offre sicurezza più profonda, IPS, Web Protection, WAF, integrazione endpoint, MDR/XDR e funzioni enterprise classiche. Un confronto corretto non può ignorare le differenze.

Ma la qualità percepita passa ogni giorno dall’usabilità.

Ubiquiti investe visibilmente in design, app mobile, navigazione coerente, topologia, adozione semplice e un’interfaccia comprensibile anche senza anni di esperienza. Non ogni funzione UniFi è tecnicamente più profonda, ma il prodotto appare più moderno, e ciò influenza le decisioni di acquisto più di quanto i produttori tradizionali ammettano.

Un piccolo team IT non guarda soltanto le schede IPS. Si chiede:

• Quanto rapidamente trovo un dispositivo, una regola o un client?
• Posso controllare l’ambiente in modo sensato dallo smartphone?
• Capisco avvisi e dipendenze senza conoscenze specialistiche?
• Quanti clic richiede una modifica quotidiana?
• Il prodotto sembra una piattaforma unica o più strumenti affiancati?

Sophos facilita inutilmente produttori come Ubiquiti. Sophos Firewall può fare di più sul piano della sicurezza e resta più adatto a molti ambienti PMI. Ma se ricerca moderna, diff, template e modifiche massive richiedono Config Studio mentre l’interfaccia centrale resta vecchia e lenta, Sophos perde fiducia proprio al livello più visibile.

La buona sicurezza non richiede soltanto un motore potente. Richiede un’interfaccia in cui le persone comprendano le regole, individuino errori ed eseguano change in sicurezza. L’usabilità fa parte della sicurezza operativa, non è cosmetica.

Conclusione: installare MR2, ma il problema del prodotto resta

SFOS 22.0 MR2 non è una grande feature release. È un maintenance release importante con aggiunte sensate.

Il controllo PQC arriva al momento giusto, ma va inizialmente usato in osservazione. Il migliore rilevamento dell’IA generativa aiuta visibilità e policy, ma non sostituisce DLP o governance IA. Gli amministratori Chromebook devono distribuire attivamente l’estensione Manifest V3. STAS dovrebbe essere meno soggetto a interruzioni, ma richiede test consapevoli delle regole identità. Let’s Encrypt è pronto per le nuove catene. E i molti fix correggono problemi capaci di causare veri outage produttivi.

Installerò MR2 subito dopo backup e preflight, poi testerò questi percorsi dati. Chi è colpito dai problemi HA, VPN, reporting, Central o failsafe ha buoni motivi per aggiornare. Se la build 546 sarà davvero più tranquilla o introdurrà nuove regressioni non si può stabilire seriamente il giorno del rilascio.

La mia critica resta chiara: Config Studio 2.6 è utile, ma il suo ruolo prominente rafforza l’impressione che Sophos stia spostando l’amministrazione moderna in uno strumento secondario. Non conferma l’abbandono di una nuova interfaccia SFOS, ma è un segnale strategico d’allarme.

Sophos dispone di una base firewall solida. Dovrebbe finalmente offrire agli amministratori un’esperienza di gestione all’altezza. Altrimenti le piattaforme moderne vinceranno non necessariamente grazie a una sicurezza migliore, ma perché prendono più sul serio la persona davanti allo schermo.

Alla prossima,
Joe

FAQ