Sophos Firewall v23: panoramica di tutte le novità

Sophos Firewall v23 affronta diverse attività che richiedono tempo nella gestione quotidiana: cercare tra le regole, associare correttamente gli utenti, pianificare gli aggiornamenti e capire perché un cluster ha eseguito un failover. La nuova versione principale introduce a questo scopo una REST API, un assistente AI e nuove funzioni per WAF, DNS e DHCP.

Stato della release: Come negli anni precedenti, la prossima versione principale prende il via con la fase Early Access di Sophos Firewall v23 intorno a ottobre, quest’anno già il 28 settembre 2026. Questo articolo si basa sulla versione EAP1. Alcune funzioni e alcuni dettagli potrebbero cambiare prima della versione definitiva.

Una parte delle novità è disponibile direttamente sul firewall, mentre altre funzioni richiedono Sophos Fusion o software aggiuntivo. Per la pianificazione è importante soprattutto questo punto: il nuovo riconoscimento degli utenti tramite Synchronized Security richiede Sophos Endpoint sui dispositivi interessati e una licenza Endpoint adeguata. Chi finora utilizza soltanto Microsoft Defender o un’altra soluzione di protezione degli endpoint non ottiene quindi questa funzione con il solo aggiornamento del firewall, ma dovrebbe introdurre e licenziare anche Sophos Endpoint. Se sono già presenti licenze Sophos, l’impegno aggiuntivo dipende dal contratto esistente. I requisiti delle altre funzioni sono spiegati nelle rispettive sezioni.

AI e automazione

REST API: automatizzare la configurazione del firewall

La nuova REST API consente a script e strumenti di gestione di leggere e modificare la configurazione direttamente sul firewall. L’autenticazione avviene tramite chiavi API. Una specifica in formato OpenAPI 3.0 documenta le chiamate disponibili e i campi dati, facilitando l’integrazione dell’interfaccia negli strumenti esistenti. L’accesso avviene direttamente sul firewall ed è indipendente dalla Sophos Central API per esportare e importare configurazioni.

Distribuire impostazioni comuni su più firewall era già un obiettivo centrale di Sophos Central Firewall Management. I gruppi di firewall e i criteri sovraordinati dovrebbero consentire di gestire queste modifiche centralmente. Nella nostra esperienza, tuttavia, ciò funziona solo in parte nel modo necessario per un’operatività affidabile. Per le modifiche ricorrenti preferiamo quindi affidarci a script e processi propri, di cui possiamo controllare sia lo svolgimento sia il risultato. La nuova REST API è un’aggiunta utile proprio per questo.

Un esempio sono gli oggetti di rete per un nuovo server necessari su firewall di diverse sedi. Uno script può prima verificare se l’oggetto esiste già, eseguire solo la modifica necessaria e rileggere il valore salvato. Nel log resta tracciabile quale firewall è stato aggiornato correttamente e dove occorre intervenire. Questo è particolarmente utile se una sede non è raggiungibile durante la modifica e deve essere aggiornata in seguito in modo mirato.

Le chiavi API si gestiscono in Administration > API access. Ereditano i permessi dell’amministratore associato. Per le automazioni conviene quindi utilizzare un account dedicato con un profilo di autorizzazioni appropriato. Devono essere configurati correttamente anche gli indirizzi sorgente consentiti e l’accesso di gestione. L’accesso va limitato ai sistemi che ne hanno effettivamente bisogno per le proprie attività amministrative.

Allowed IP hosts: Anche in v23 si possono autorizzare qui solo indirizzi IP o reti. Non è ancora possibile indicare un FQDN, cioè un nome DNS completo. Per un server di automazione con IP pubblico fisso non è un problema. Se invece lo script opera dietro una connessione con IP pubblico variabile, non è possibile inserire semplicemente il suo nome DNS tra le sorgenti consentite. In quel caso serve, per esempio, un punto di uscita fisso o un accesso VPN controllato. Per un’interfaccia pensata per semplificare l’automazione avremmo voluto maggiore flessibilità.

Il REST API guide si apre dalla WebAdmin in Administration > API access. Il link si trova a destra, sopra l’elenco delle chiavi API, accanto a OpenAPI.yaml. La Sophos Firewall API Reference pubblica descrive gli endpoint, i campi dati e i primi passi per l’autenticazione. Per l’implementazione concreta fa fede il file OpenAPI della build installata sul firewall. Prima di sostituire automazioni XML esistenti occorre verificare che le funzioni necessarie siano completamente coperte. Anche una API moderna richiede gestione degli errori, logging e una procedura di ripristino collaudata.

Assistente AI per le regole firewall

Il nuovo assistente in Sophos Fusion risponde a domande sulle regole firewall. Crea bozze di regole disattivate in fondo alla tabella; l’approvazione resta compito dell’amministratore.

È un approccio sensato alla collaborazione con l’AI. Una richiesta come «Crea una bozza per l’accesso HTTPS dalla rete dei dipendenti al web server interno» può preparare il lavoro. Prima dell’attivazione bisogna comunque chiarire quali oggetti concreti siano coinvolti, se l’accesso vada limitato a determinati utenti e quali controlli di sicurezza siano necessari.

La posizione della regola è particolarmente importante. Una regola corretta dal punto di vista funzionale può non avere alcun effetto se prima ne interviene un’altra. Viceversa, una regola collocata troppo in alto può autorizzare più traffico del previsto. L’assistente non sostituisce quindi la decisione di sicurezza dell’amministratore. Il suo valore consiste nel preparare il lavoro sul set di regole e facilitare la ricerca delle relazioni tra di esse.

Consentire o bloccare selettivamente i servizi AI

Per controllare l’uso dell’AI si aggiungono la categoria web Generative AI e filtri applicativi nell’ambito di Sophos AI Defense.

In Diagnostics > URL category lookup si può controllare come viene classificato un dominio. Per openai.com il firewall mostra la categoria Generative AI. Questo aiuta nella ricerca dei problemi: se un servizio AI viene bloccato inaspettatamente, si può prima verificare la sua categoria e poi controllare il criterio web applicato.

Per le aziende, una configurazione sensata parte da una decisione semplice: quali servizi AI sono consentiti e per quali attività? Un reparto di sviluppo potrebbe aver bisogno di strumenti diversi rispetto alla contabilità. Solo su questa base si può definire un criterio di rete utile.

Un dominio consentito, però, non dice nulla sui dati che gli utenti possono inserirvi. Controllo degli accessi e protezione dei dati sono compiti distinti. Anche per un servizio autorizzato servono regole relative ai dati dei clienti, al codice sorgente e ai documenti riservati. I filtri di rete possono sostenere queste direttive organizzative, ma non sostituiscono la verifica del contenuto di ogni prompt.

Gestione delle regole e usabilità

Nuova tabella delle regole firewall

La vista in Rules and policies > Firewall rules è stata profondamente rivista. Al posto delle cartelle espandibili, Sophos ora mostra le regole in una tabella continua. Il raggruppamento resta disponibile, ma compare nella colonna Group. Si aggiungono ricerca testuale, filtri e una vista con colonne personalizzabili.

Questo risolve un fastidio della vecchia interfaccia: dopo aver modificato e salvato una regola firewall, il gruppo si richiudeva. Per modificare subito la regola successiva dello stesso gruppo era necessario riaprire la cartella. Con molte modifiche consecutive diventava inutilmente laborioso. Mostrando il gruppo in una colonna, non occorre più espanderlo continuamente.

Scegliere e ordinare le colonne

Tramite l’icona a forma di ingranaggio sopra la tabella, sulla destra, si può decidere quali colonne visualizzare. È possibile nascondere le informazioni non necessarie, mostrare ulteriori dettagli e cambiare l’ordine delle colonne. Le colonne possono anche essere bloccate, così da tenere per esempio visibile il nome della regola mentre si scorre una tabella larga.

Un aspetto particolarmente positivo: nel nostro test la vista scelta è rimasta memorizzata anche dopo il logout e un nuovo login. Non occorre quindi ricomporre la panoramica a ogni accesso.

Per una rapida panoramica spesso bastano nome, gruppo, azione, stato e traffico. Durante la ricerca di un problema, invece, interessano reti sorgente e destinazione, servizi e logging. Se, per esempio, bisogna rimuovere l’accesso a un vecchio application server, è utile vedere affiancate le destinazioni delle regole interessate. Non dover aprire ogni regola singolarmente fa risparmiare tempo e facilita il confronto.

Sono disponibili le colonne seguenti. I nomi corrispondono a quelli dell’interfaccia inglese; qui sono raggruppati per argomento per facilitarne la lettura:

• Regola e panoramica: Name, Type, Group, ID, Features, Traffic (In/Out), Status, Action, Schedule, Description.
• Reti e servizi: Src networks, Src zones, Dst zones, Dst networks, Services.
• Utenti e logging: Users, Exclude users from accounting, Web authentication for unknown users, Log.
• Funzioni di protezione e criteri: Email, Web policy, IPS policy, Application policy.
• Banda e priorità: Traffic shaping policy, Traffic shaping (applications), Traffic shaping (web category), DSCP marking.
• Security Heartbeat: Source HB, Block client with no source HB, Destination HB, Block client with no destination HB.
• Eccezioni: Excluded source address, Excluded destination address, Excluded source zone, Excluded destination zone, Excluded service.

La vecchia vista resta selezionabile per ora

Con l’interruttore New design si può ancora tornare alla vista precedente. Chi non si trova bene con la nuova tabella dispone quindi, almeno per il momento, di un’alternativa. Resta da vedere per quanto tempo Sophos manterrà entrambe le viste.

Regole NAT: ancora senza gruppi né clonazione

Purtroppo Sophos non ha esteso la nuova vista alle regole NAT. Anche in v23 queste vengono gestite diversamente: non è possibile né raggrupparle né clonarle. Per le regole firewall la clonazione è disponibile, per quelle NAT continua a mancare.

Sarebbe particolarmente utile quando si pubblicano più servizi simili. Se per un altro web server serve quasi lo stesso inoltro, sarebbe comodo copiare una regola NAT esistente e modificare poi destinazione e servizio. Invece bisogna ricreare la regola. Questo richiede tempo e aumenta il rischio di discostarsi involontariamente dalle altre impostazioni.

Avevamo già segnalato questi desideri nell’articolo su Sophos Firewall v22. La nuova vista delle regole firewall è un progresso gradito. Proprio per questo dispiace che la gestione NAT continui a essere indietro su funzioni operative così fondamentali.

WebAdmin, numero di serie e stato del cluster

L’interfaccia WebAdmin utilizza HTTP/2 per accelerare il trasferimento degli elementi della pagina. Inoltre, il numero di serie e lo stato del cluster HA restano visibili quando si passa da una pagina di impostazioni all’altra.

HTTP/2 può aiutare a caricare pagine con molti elementi, soprattutto su connessioni con latenza elevata. La rapidità percepita di una vista dipende però anche dall’elaborazione sul firewall. Una query lenta al database o il salvataggio di una configurazione complessa non diventano veloci solo cambiando protocollo di trasporto. Nel mio primo test, comunque, il guadagno di velocità è stato modesto: il salvataggio di una regola firewall richiedeva ancora diversi secondi.

L’identità del dispositivo sempre visibile ha un’utilità immediata: con più sessioni firewall aperte è più semplice controllare su quale sistema si sta lavorando. Prima di modificare un cluster HA conviene verificare anche il ruolo e lo stato dei dispositivi coinvolti.

Chi nell’assistenza tiene aperti diversi ambienti clienti quasi identici conosce quel momento di incertezza prima di salvare una modifica. Un numero di serie sempre visibile facilita il confronto con il ticket, senza dover abbandonare la pagina delle impostazioni. È una piccola modifica con un vantaggio molto concreto.

Alta disponibilità: rilevare più rapidamente, eseguire failover in modo mirato

Lo stato dell’hardware come causa del failover

Oltre a connessioni e servizi, il cluster HA ora controlla anche lo stato di determinati componenti hardware, tra cui l’SSD. Se il suo stato peggiora, il cluster può passare all’altro firewall.

Un cluster HA può reagire in modo utile solo se rileva il problema. Un dispositivo può essere ancora raggiungibile attraverso le sue interfacce di rete pur avendo già problemi interni. Per l’operatività, questo controllo hardware aggiuntivo è quindi importante.

Un’SSD difettosa può, per esempio, compromettere le operazioni di scrittura mentre il collegamento HA continua a funzionare. Il solo monitoraggio delle connessioni non rileverebbe lo stato dell’unità. Il controllo hardware aggiuntivo interviene qui prima che un nodo degradato smetta del tutto di funzionare.

Dopo un failover di questo tipo bisogna comunque indagarne la causa. Il secondo nodo mantiene operativo il servizio, ma non ripara l’SSD guasta. La procedura operativa deve quindi includere la verifica del dispositivo interessato, la valutazione della ridondanza residua ed eventualmente la sostituzione dell’hardware.

Intervallo di rilevamento più breve

Con il monitoraggio accelerato, il cluster HA rileva il guasto dell’altro firewall entro 300 ms invece dei precedenti quattro secondi.

I 300 ms indicano il tempo necessario al firewall per rilevare il guasto dell’altro dispositivo nel cluster. Prima che un’applicazione torni a funzionare normalmente possono essere necessari altri passaggi: il firewall rimasto deve assumere il servizio, i dispositivi di rete adiacenti devono instradare il traffico lungo il percorso corretto e le connessioni esistenti devono proseguire oppure essere ristabilite.

Per una prova significativa occorre quindi osservare più di un ping. Una telefonata in corso, un trasferimento di file e un accesso VPN mostrano impatti diversi. Solo misurazioni di questo tipo permettono di capire se il failover è abbastanza rapido per i propri processi aziendali.

Meno failover non necessari sotto carico elevato

I due firewall si scambiano regolarmente brevi messaggi di stato, i cosiddetti HA heartbeat. Ora questi messaggi vengono elaborati con priorità e separatamente dal normale traffico dati.

La modifica affronta un problema che può presentarsi con carichi elevati: se un sistema è molto impegnato, una risposta tardiva può sembrare un guasto. Il failover attivato di conseguenza aggiunge instabilità a un ambiente già sotto pressione.

Nella verifica finale sono quindi interessanti entrambe le situazioni: il cluster riconosce un guasto reale? E rimane stabile sotto carico elevato quando nessun dispositivo è guasto? Un semplice test funzionale a sistema inattivo risponde solo alla prima metà della domanda.

Sicurezza DNS, Hotfixes e firmware

DNS over HTTPS e DNSSEC

Il firewall può ora inviare richieste DNS cifrate tramite HTTPS a un resolver e verificare le risposte DNS con DNSSEC. Anche l’attivazione di Sophos DNS Protection è stata semplificata.

Le due tecnologie DNS risolvono problemi diversi. DNS over HTTPS, o DoH, cifra il trasporto verso il resolver. DNSSEC verifica i dati DNS firmati. Una connessione cifrata da sola non conferma l’autenticità di una risposta DNS; una firma valida, a sua volta, non nasconde la richiesta a chi osserva il percorso di trasporto.

Prima dell’introduzione bisogna capire come funziona la risoluzione DNS esistente. Il client interroga il firewall, un server DNS Windows interno oppure direttamente un resolver pubblico? I nomi interni devono continuare a essere risolti nel posto giusto. A questo scopo restano rilevanti, per esempio, le DNS Request Routes.

Anche i browser con impostazioni DoH proprie richiedono attenzione. Se un client usa un resolver diverso, il suo percorso DNS effettivo potrebbe non corrispondere alla configurazione centrale prevista. Una prova funzionale dovrebbe quindi comprendere nomi interni, risoluzione esterna e decisioni di filtro desiderate.

Aggiornamenti Hotfix e di sicurezza visibili

Esaminando l’interfaccia abbiamo notato anche un’altra modifica: in Backup & firmware è tornata una sezione dedicata agli Hotfixes. La scheda si chiama Hotfix: Security updates. In passato l’impostazione degli Hotfixes si trovava nell’area Firmware, dove una casella consentiva di scegliere se installare automaticamente gli Hotfixes importanti. Dopo essere scomparsi dall’interfaccia, gli Hotfixes tornano ora ad avere una posizione visibile.

Nella nuova vista si tratta dello stato degli aggiornamenti di sicurezza. Il vecchio interruttore di attivazione e disattivazione non compare nella schermata mostrata. Inoltre, l’assenza temporanea dell’impostazione non significa che il firewall avesse smesso di ricevere Hotfixes: l’installazione automatica è rimasta disponibile come funzione.

A cosa servono gli Hotfixes

Gli Hotfixes sono correzioni mirate per problemi urgenti, in particolare vulnerabilità di sicurezza. Possono essere distribuiti al di fuori delle normali release del firmware. Una correzione importante non deve quindi attendere il successivo Maintenance Release e la pianificazione in azienda di un aggiornamento completo del firmware.

Se, per esempio, viene scoperta una vulnerabilità in un servizio di gestione, un Hotfix appropriato può correggere il componente interessato. L’installazione automatica riduce il tempo che intercorre tra la disponibilità della correzione e la sua applicazione sul firewall. È attivata per impostazione predefinita e dovrebbe restare tale nel normale esercizio. Gli Hotfixes non sostituiscono comunque i regolari aggiornamenti del firmware, che comprendono anche altre correzioni, modifiche ai componenti e nuove funzioni.

Verificare direttamente lo stato delle patch

L’interfaccia mostra ora quali vulnerabilità di sicurezza sono state corrette dagli Hotfixes installati. Ogni voce comprende l’identificativo CVE, la gravità, la data di installazione e un link al relativo avviso di sicurezza. Queste informazioni sono disponibili anche nei report.

Questo aiuta a rispondere a una domanda operativa frequente: una determinata vulnerabilità è già stata risolta proprio su questo firewall? Il numero di versione del firmware non sempre basta per rispondere, se vengono distribuiti anche Hotfixes.

Se un cliente chiede informazioni su un nuovo Security Advisory, è quindi più facile documentare lo stato locale. Invece di dedurre la protezione dalla sola versione del firmware, si possono verificare la CVE interessata e la data di installazione dell’Hotfix e registrarli nel ticket.

Per documentare lo stato delle patch, le informazioni visualizzate vanno valutate insieme all’Advisory corrispondente. Un fix installato risponde alla domanda sulla specifica correzione. Non dimostra che l’intero sistema sia configurato in modo sicuro né esclude che in precedenza sia avvenuto un attacco. Per queste verifiche servono ancora il controllo della configurazione, l’analisi dei log ed eventualmente un’indagine.

Aggiornamenti firmware ricorrenti

In Sophos Fusion si possono definire finestre di manutenzione ricorrenti durante le quali i firewall installano automaticamente nuove versioni del firmware. Non è necessario aggiornare tutti i dispositivi contemporaneamente. Si possono aggiornare prima alcuni firewall e far seguire gli altri in un secondo momento. Sono possibili impostazioni diverse per singoli dispositivi, per esempio quando una sede richiede una finestra di manutenzione propria.

Questo è utile soprattutto per aziende con più filiali. Per esempio, si aggiorna inizialmente il firewall di un ufficio piccolo. Poi si controllano le connessioni VPN, gli accessi degli utenti e i servizi pubblicati in quella sede. Solo dopo l’esito positivo dei controlli si procede con le altre sedi. In questo modo non occorre avviare ogni installazione separatamente, mantenendo però il controllo sulla sequenza.

Prima bisogna stabilire chi verifica i risultati e, in caso di problemi, interrompe gli aggiornamenti successivi. L’installazione automatica non sostituisce né il backup né una procedura di ripristino preparata. Le operazioni necessarie sono descritte nelle nostre guide agli aggiornamenti del firmware e al backup e ripristino.

Identità e autenticazione

Entra ID con Synchronized User ID

Tramite Synchronized Security, il firewall ora può identificare anche gli utenti che lavorano con Entra ID. Si possono quindi gestire insieme dispositivi integrati nell’AD locale e dispositivi con identità cloud. Il riconoscimento richiede Sophos Endpoint sui dispositivi interessati e una licenza Endpoint adeguata.

La domanda pratica è: come fa il firewall a sapere quale utente si trova dietro una connessione? Un indirizzo IP da solo non sempre basta per applicare in modo utile una regola legata all’utente. Durante il passaggio da un dominio locale a un’identità cloud, anche questa associazione deve continuare a funzionare in modo affidabile.

Un caso tipico è un’azienda che collega i nuovi notebook solo a Entra ID, mentre i dispositivi più vecchi appartengono ancora al dominio AD locale. Per il criterio web della contabilità questa fase di transizione tecnica non dovrebbe fare differenza: ciò che conta è il gruppo dell’utente. Questa continuità è importante in una migrazione graduale al cloud.

Per la pianificazione è essenziale distinguere questa novità dall’accesso tramite Entra ID al Captive Portal, già disponibile. Qui si tratta dell’interazione con Sophos Endpoint. La semplice presenza di un ambiente Entra ID non implica quindi che il firewall possa riconoscere correttamente gli utenti. In una prova pilota occorre verificare quale utente viene effettivamente rilevato e quale regola di gruppo viene poi applicata.

Google Workspace come Identity Provider

Gli utenti possono accedere al Captive Portal, al VPN Portal, a Sophos Connect e alla WebAdmin con il proprio account Google Workspace. Google Workspace svolge il ruolo di Identity Provider e può richiedere l’autenticazione multifattore durante l’accesso.

Per le organizzazioni che utilizzano Google come directory centrale degli utenti si tratta di un’aggiunta importante. Account e requisiti di accesso dovrebbero, per quanto possibile, essere gestiti dove si amministrano anche gli altri accessi aziendali.

Una scuola che utilizza Google Workspace, per esempio, non deve mantenere sul firewall un archivio separato di password per l’accesso VPN degli insegnanti. Questo riduce la doppia amministrazione e facilita la protezione dell’accesso tramite l’Identity Provider centrale.

Un accesso riuscito, però, è solo una parte dell’integrazione. Occorre poi assegnare le autorizzazioni corrette. Un dipendente ordinario non deve ottenere accesso amministrativo soltanto perché l’SSO funziona. Nei test bisogna quindi controllare insieme gli attributi degli utenti, l’appartenenza ai gruppi, i servizi consentiti e la revoca dei diritti di accesso.

Configurazione MFA tramite e-mail

Per configurare l’autenticazione multifattore, il firewall può inviare il codice QR necessario via e-mail. Se la registrazione non viene completata entro 24 ore, il codice inutilizzato scade. Nelle installazioni esistenti rimane inizialmente disponibile la precedente configurazione tramite il portale.

Questo cambia la procedura di configurazione per i nuovi utenti. Prima della distribuzione occorre verificare gli indirizzi e-mail e la consegna dei messaggi. Altrimenti il primo accesso VPN può diventare un caso per l’assistenza, anche se l’autenticazione in sé è configurata correttamente.

Un codice QR di registrazione contiene informazioni rilevanti per la sicurezza. Anche la casella che lo riceve deve quindi essere protetta. Il servizio di assistenza deve inoltre disporre di una procedura chiara per le registrazioni scadute e per gli indirizzi errati. Un nuovo invio non deve portare a trascurare la verifica dell’identità del richiedente.

SSO per Chromebook

Una nuova estensione per Chromebook permette di comunicare al firewall l’identità dell’utente senza richiedere un ulteriore accesso al Captive Portal. L’estensione supporta tutte le versioni SFOS ancora supportate.

Soprattutto nelle scuole, gli accessi ripetuti al portale sono fastidiosi. Qui però non conta solo il primo accesso riuscito, ma anche il passaggio tra utenti e dispositivi. Una prova con Chromebook condivisi dovrebbe verificare che, dopo il cambio utente, non venga riutilizzata una vecchia associazione.

Poiché l’estensione è pensata per funzionare con diverse versioni, la sua introduzione dovrebbe essere pianificata separatamente dall’aggiornamento a v23. Distribuire contemporaneamente un nuovo componente client e un nuovo firmware firewall rende più difficile individuare le cause di eventuali problemi.

Terminal server: associazione degli utenti con XDR Sensor

Per Sophos Authentication for Thin Client, o SATC, si può usare un XDR Sensor leggero. Aiuta il firewall ad associare il traffico di rete di un server condiviso ai singoli utenti e può funzionare accanto a una soluzione di protezione degli endpoint già presente.

Su un terminal server molte sessioni condividono lo stesso IP del server. Una regola basata sull’indirizzo IP non distingue quindi fra la contabilità e un collaboratore esterno che utilizza lo stesso host. Per regole web o firewall basate sull’utente serve un’associazione aggiuntiva.

La possibilità di usare un sensore insieme a un prodotto di protezione esistente è interessante negli ambienti misti. Questo però non equivale a una garanzia generale di compatibilità per qualsiasi combinazione. Licenza, sistema operativo e interoperabilità supportata vanno verificati in anticipo. Una prova funzionale dovrebbe prevedere almeno due utenti collegati contemporaneamente ai quali si applicano regole diverse. Gli effetti sul terminal server stesso vanno valutati separatamente dalle decisioni del firewall.

WAF: maggiore controllo sulle applicazioni pubblicate

Azioni diverse per ogni percorso URL

La Web Application Firewall introduce azioni per percorso: Protect, Block, Redirect e Passthrough. Quest’ultima è destinata ai WebSocket senza ispezione WAF.

Con Protect il percorso resta sottoposto alla verifica WAF. Block respinge l’accesso con HTTP 403. Redirect invia il browser a un altro indirizzo. Passthrough è quindi un’eccezione scelta consapevolmente per il traffico WebSocket corrispondente, non un livello di controllo aggiuntivo.

In questo modo il trattamento di un’applicazione può essere adattato meglio alla sua struttura. Dopo la sostituzione di un portale, per esempio, /altes-portal potrebbe essere reindirizzato a /kundenportal, mentre un’area dismessa in /legacy viene bloccata con HTTP 403. L’area applicativa vera e propria resta sotto controllo WAF. Gestire queste decisioni direttamente sul punto di accesso a monte può ridurre le modifiche necessarie al backend.

Per i reindirizzamenti, la destinazione deve essere precisa. Un percorso errato può danneggiare le procedure di accesso o i link salvati; un reindirizzamento mal progettato può creare loop. Per un’eccezione senza ispezione WAF bisogna invece chiarire quali protezioni rimangono sull’applicazione stessa. Il fatto che la connessione funzioni non dimostra che sia sottoposta a controlli di sicurezza equivalenti.

Più percorsi e regole

Per ogni voce relativa ai percorsi sono previsti fino a 128 percorsi. Il limite delle regole WAF è di 100 per impostazione predefinita e può essere aumentato a 200.

In fase di pianificazione bisogna distinguere il limite delle regole dalle prestazioni. La possibilità di configurare più regole non significa automaticamente che un’appliance possa servire un numero arbitrario di applicazioni attive mantenendo gli stessi tempi di risposta. Elaborazione TLS, ispezione, upload e velocità dei server backend contribuiscono al fabbisogno di risorse.

Una verifica adeguata usa quindi richieste tipiche delle applicazioni reali. Una pagina di test statica, per esempio, rappresenta male un portale con upload di file di grandi dimensioni.

Nuova elaborazione con Apache Event MPM

La WAF passa ad Apache Event MPM per gestire meglio le richieste simultanee.

In termini semplici, l’obiettivo è sfruttare meglio la capacità di elaborazione mentre alcune connessioni attendono ulteriori operazioni. Con molti accessi simultanei questa distribuzione è decisiva: non tutte le connessioni aperte devono occupare inutilmente risorse necessarie ad altre richieste. La capacità del backend resta comunque un limite a sé.

L’indicatore operativo decisivo è il comportamento sotto carico. Un’applicazione può rimanere tecnicamente raggiungibile e tuttavia rispondere così lentamente da indurre gli utenti a interrompere il lavoro. Nei test di carico vanno quindi valutati non solo le connessioni riuscite, ma anche i tempi di risposta e i tassi di errore.

Per un confronto affidabile tra prima e dopo, hardware, profilo di sicurezza, backend e traffico di test devono rimanere uguali. Solo allora è possibile valutare la differenza prodotta dalla nuova elaborazione nel proprio ambiente. Il solo cambiamento architetturale non consente di dedurre un valore generale di throughput.

DHCP, routing e servizi di rete

DHCP sulla nuova Control Plane

Il servizio DHCP ora opera sulla nuova Control Plane e può gestire pool di indirizzi più grandi e più prenotazioni. Il traffico DHCP viene inoltre verificato dal firewall prima di arrivare al servizio, per limitare gli effetti di una valanga di richieste. Le impostazioni che prima richiedevano la riga di comando sono ora accessibili nell’interfaccia.

Questo riguarda una dipendenza fondamentale della rete. Se i client non ricevono un indirizzo, anche molti altri servizi sembrano non funzionare. Dopo un aggiornamento, il server DHCP va quindi controllato con la stessa attenzione riservata a VPN e accesso Internet.

La scalabilità conta, per esempio, in una scuola quando al mattino molti dispositivi si collegano quasi contemporaneamente al Wi-Fi e richiedono un indirizzo. Per gli utenti, un’assegnazione lenta degli indirizzi appare rapidamente come un problema Wi-Fi. Un’elaborazione rapida dei lease migliora un punto che nella ricerca dei guasti è facile trascurare.

I test devono includere nuovi lease, rinnovi di lease esistenti e indirizzi prenotati. Devono essere corretti anche i valori trasmessi, come gateway, server DNS e opzioni DHCP personalizzate. Proprio le impostazioni usate di rado spesso si notano solo al riavvio di un dispositivo particolare.

È stata rivista anche la consultazione degli indirizzi assegnati. Le opzioni DHCP vengono elaborate in modo più uniforme secondo gli standard sottostanti. Le configurazioni speciali esistenti meritano quindi un confronto mirato prima e dopo l’aggiornamento.

Fra le impostazioni trasferite nell’interfaccia ci sono le conferme negative e la limitazione a un lease per client. Una conferma negativa segnala a un client che non può utilizzare l’indirizzo richiesto e deve negoziare nuovamente la configurazione IP. Queste impostazioni vanno valutate in base alla propria architettura di rete, in particolare quando sono coinvolti più servizi DHCP.

mDNS Reflector per Bonjour e rilevamento dei dispositivi

Con mDNS Reflector i dispositivi possono scoprire servizi anche in altre reti selezionate. Funziona sia con IPv4 sia con IPv6. Per la successiva connessione al dispositivo individuato continua a servire una regola firewall appropriata.

È rilevante, per esempio, se stampanti e dipendenti si trovano in VLAN diverse. La stampante può avere un indirizzo corretto ed essere generalmente raggiungibile, senza però comparire nella ricerca automatica dei dispositivi. La scoperta del servizio e la successiva connessione dati sono due passaggi distinti.

Nella configurazione conviene autorizzare solo le coppie di reti e i servizi necessari. Una rete guest non deve poter scoprire tutti i dispositivi dell’infrastruttura interna. Dopo la configurazione bisogna verificare sia il comportamento desiderato sia i limiti: la stampante prevista viene trovata ed è utilizzabile, mentre gli altri servizi interni restano inaccessibili.

Motore di routing e BFD sperimentale

Il firewall utilizza una versione aggiornata del software di routing FRR. I diversi protocolli di routing possono essere gestiti da una console comune. Si aggiunge il supporto sperimentale di BFD per BGP e rotte statiche sui firewall utilizzati singolarmente.

BFD, per esteso Bidirectional Forwarding Detection, serve a individuare rapidamente la perdita della connessione tra vicini di routing. È una funzione diversa dal cambio di ruolo in un cluster HA di firewall. Una rilevazione più rapida del guasto può aiutare a spostare prima il traffico su un percorso alternativo.

Intervalli di monitoraggio molto brevi, però, non sono un obiettivo in sé. Se il dispositivo remoto o il percorso di trasporto non rispondono in modo affidabile sotto carico, un’impostazione aggressiva può causare cambi di stato inutili. Lo stato sperimentale va quindi preso sul serio e BFD dovrebbe essere valutato inizialmente in un ambiente di test adatto.

Un caso interessante riguarda due collegamenti instradati tra sedi: se l’interfaccia locale resta attiva benché il vicino non sia più raggiungibile attraverso il percorso preferito, lo stato del link da solo non basta a rilevare il guasto. In un’architettura del genere, un’integrazione BFD adeguata può aiutare a individuare prima l’interruzione.

IPv6 IPoE e 4in6

Il firewall supporta ulteriori modalità di connessione con IPv6 IPoE e tunnel 4in6, incluso il servizio Internet giapponese Xpass.

Con 4in6 il traffico IPv4 viene trasportato su una connessione IPv6. Queste funzioni sono particolarmente rilevanti quando il provider Internet richiede proprio questo modello di accesso. Per una connessione tradizionale, da sole non costituiscono un motivo per modificare la configurazione WAN.

Le estensioni riguardano anche indirizzi dinamici, endpoint dei tunnel e MTU/MSS. Nella ricerca dei guasti conta la loro interazione: il corretto avvio di un tunnel non garantisce che i pacchetti grandi o tutte le applicazioni funzionino senza problemi. Parametri del provider, risoluzione dei nomi e dimensioni dei pacchetti vanno quindi verificati insieme.

Installazione su IONOS Cloud

Sophos Firewall può ora essere eseguito anche su IONOS Cloud con l’immagine ufficiale SFOS. L’installazione avviene manualmente mediante un’immagine propria e non tramite una voce pronta nel Marketplace.

Nella pianificazione dell’architettura bisogna quindi chiarire come collegare le reti pubbliche e interne, come proteggere l’accesso di gestione e chi si occupa del ciclo di vita della macchina virtuale. La disponibilità di una piattaforma di installazione supportata non risponde ancora alle domande su ridondanza, ripristino e monitoraggio.

In particolare, il proprio modello operativo non deve presumere implicitamente funzioni tipiche di un servizio cloud completamente gestito. Anche un firewall virtuale richiede manutenzione programmata e backup verificabili.

Segnalazioni di minacce e modifiche minori

Segnalazioni NDR senza isolamento automatico

I rilevamenti di NDR Essentials e NDR Active Threat Intelligence possono generare una segnalazione senza isolare automaticamente dalla rete il dispositivo interessato.

Questo separa più chiaramente rilevamento e risposta. Può essere utile quando si introducono nuove fonti di rilevamento: prima se ne valuta la qualità delle segnalazioni, poi si stabilisce quali eventi debbano attivare un blocco. Le differenze tra i metodi sono spiegate nel nostro articolo su NDR Active Threat Intelligence.

Una semplice segnalazione è però utile solo se qualcuno la gestisce. Devono essere definiti responsabilità, tempi di risposta e percorso di escalation. Bisogna inoltre controllare separatamente quali azioni di blocco rimangono configurate in Active Threat Response. Da una modifica alle segnalazioni non si può dedurre che tutte le azioni di protezione siano state disattivate.

Liste di contenuti e-mail e categorie web

Altre modifiche riguardano i riferimenti basati su ID per le liste di contenuti e-mail e il versionamento delle categorie web.

Per le liste di contenuti e-mail, le Content Control Lists, il riferimento viene così separato dal nome visibile. Un nome aiuta le persone a orientarsi, mentre un ID stabile assicura un’associazione univoca. Il versionamento delle categorie web riguarda invece l’allineamento, in background, delle definizioni delle categorie utilizzate con Sophos.

Questi aspetti sono meno visibili di una nuova interfaccia, ma fanno parte di una panoramica completa della release. Quando si modificano o ripristinano configurazioni, un criterio deve continuare a riferirsi all’oggetto previsto. Per i filtri web, inoltre, le pagine di test note come consentite o bloccate dovrebbero produrre la decisione attesa anche dopo un aggiornamento.

eDirectory non è più supportato

Sophos Firewall v23 non supporta più il tipo di server eDirectory nativo. Un’integrazione eDirectory ancora presente impedisce quindi l’aggiornamento. Le alternative comprendono Entra ID SSO, Active Directory, RADIUS oppure una connessione LDAP al server eDirectory esistente.

È importante distinguere tra autenticazione e riconoscimento automatico degli utenti: LDAP può autenticare gli utenti rispetto alla directory esistente, ma non sostituisce l’SSO nativo di eDirectory. La precedente integrazione eDirectory non viene acquisita nemmeno durante il ripristino di un backup o l’importazione di una configurazione.

Descriviamo la migrazione e i suoi effetti su utenti, gruppi e servizi nella nostra guida Sophos Firewall: migrare eDirectory prima di SFOS 23.

Conclusione

A mio avviso, la REST API è una delle novità più utili di Sophos Firewall v23. Semplifica le modifiche ricorrenti e offre una buona base per analizzare le configurazioni con strumenti propri. Le API sono utili anche per l’analisi con l’AI: regole e oggetti possono essere letti in modo strutturato, confrontati ed esaminati alla ricerca di anomalie. Le eventuali modifiche restano una decisione dell’amministratore. Ma già raccogliere e preparare le informazioni in questo modo può risparmiare molto lavoro manuale.

Mi piace anche la nuova panoramica delle regole firewall. L’appartenenza al gruppo mostrata in una colonna, i dettagli selezionabili e la vista salvata in modo permanente rendono il lavoro più comodo. Peccato che questa revisione non sia arrivata anche alle regole NAT. Proprio lì continuano a mancare raggruppamento e clonazione, funzioni utili nella creazione e nella manutenzione di configurazioni più estese.

Avrei inoltre voluto vedere più funzioni di Sophos Firewall Config Studio integrate direttamente nel firewall: il confronto tra più versioni della configurazione, l’unione di modelli di configurazione e i report che mostrano, per le regole firewall, NAT e TLS, anche i valori degli oggetti a cui si riferiscono. Questi strumenti aiutano a comprendere e preparare le modifiche. In questa forma restano esclusivi del Config Studio separato.

Quanto alla velocità, nel mio primo test non ho riscontrato miglioramenti sostanziali. Il salvataggio di una regola firewall richiede ancora diversi secondi. Per una singola modifica è poco rilevante. Quando però si riordina un set di regole e se ne modificano molte di seguito, i tempi di attesa si sommano e interrompono continuamente il lavoro. I miglioramenti dell’interfaccia sono benvenuti. Nell’uso quotidiano vorrei soprattutto poter completare più rapidamente le attività frequenti e gestire le regole firewall e NAT in modo più uniforme.

FAQ

Fonti

• Sophos Firewall v23: annuncio della release, pubblicato il 28 settembre 2026.
• Sophos Firewall OS v23: Key New Features, guida tecnica alle funzioni, aggiornata al 28 settembre 2026.
• Sophos Firewall v23: feedback ed esperienze, riscontri aggiornati della community.