Sophos Firewall: best practice per la sicurezza di rete

Per molto tempo i firewall sono stati il punto in cui si respingevano gli attacchi. Oggi sono essi stessi tra i bersagli più interessanti. È logico: un firewall si trova in una posizione privilegiata tra Internet, reti di sedi, servizi cloud, accessi VPN e applicazioni interne. Chi trova qui una vulnerabilità, una password debole o una configurazione errata non è più davanti alla porta, ma spesso già dentro l’edificio.

Per questo non basta più considerare un firewall solo come un motore di policy per regole Allow e Deny. La sicurezza di rete moderna ha bisogno di tre pilastri: hardening, protezione e detection and response. Bisogna ridurre la superficie d’attacco prima di un attacco, bloccare correttamente durante l’attacco e capire rapidamente dopo cosa è successo.

Da molti anni seguo ambienti Sophos Firewall di dimensioni e settori molto diversi. Le raccomandazioni seguenti non sono quindi una lista teorica di funzionalità, ma ciò che si è dimostrato utile in ambienti reali di clienti, migrazioni, audit e casi di supporto.

Perché i firewall sono così nel mirino

Un firewall è un bersaglio interessante per gli attaccanti perché è esposto, privilegiato e spesso critico per il business. Inoltre molti ambienti utilizzano firewall, portali VPN o accessi di gestione remota per anni. Non tutti sono patchati correttamente, non tutte le superfici di management sono realmente isolate e non ogni login è protetto da multi-factor authentication.

Nella pratica emergono soprattutto tre cause ricorrenti negli attacchi riusciti:

• Vulnerabilità in firewall e sistemi edge, soprattutto quando le patch vengono installate in ritardo o non installate affatto.
• Credenziali compromesse e attacchi basati sull’identità, spesso senza MFA o con una configurazione MFA debole. Il Sophos Active Adversary Report 2026 indica cause legate all’identità come root cause nel 67.32% dei casi analizzati.
• Sistemi esposti, come RDP, portali VPN, User Portal o interfacce admin raggiungibili direttamente da Internet.

Il punto più importante è questo: molti attacchi oggi non sono più intrusioni spettacolari. Molto spesso gli attaccanti effettuano semplicemente il login. Se un account utente, una password admin o un accesso VPN sono compromessi, il primo passo appare inizialmente al firewall come utilizzo legittimo.

I tre pilastri della sicurezza di rete moderna

Sophos descrive la protezione delle reti moderne come uno spettro da proattivo a reattivo:

1. Hardening: ridurre la superficie d’attacco, rimuovere sistemi obsoleti, usare prodotti sicuri, verificare configurazioni, limitare gli accessi.
2. Protection: bloccare attacchi, controllare traffico cifrato, usare in modo sensato Web, IPS, Zero-Day e Application Control.
3. Detection and Response: rilevare anomalie, isolare dispositivi compromessi, correlare dati di minaccia e reagire automaticamente.

Molti firewall sono tradizionalmente forti nel secondo pilastro. Bloccano traffico, ispezionano pacchetti, riconoscono pattern noti e applicano policy. È importante, ma non basta più. Se il firewall stesso è configurato male, se Remote Access gira senza MFA o se un sistema non patchato resta produttivo, esiste un problema strutturale che una singola regola IPS non può risolvere in modo pulito.

La mia esperienza mostra che i risultati migliori non nascono da una funzione magica, ma da una configurazione di base pulita, review regolari e un firewall integrato nel processo di sicurezza complessivo.

Pilastro 1: Hardening prima dell’attacco

L’hardening è la parte del lavoro di sicurezza che raramente riceve applausi, ma che in caso di incidente fa la differenza. Si tratta di ridurre superficie d’attacco, sistemi legacy, percorsi di management aperti e dipendenza da reazioni manuali.

Ridurre l’infrastruttura e rimuovere sistemi vecchi

Il modo più semplice per ridurre una superficie d’attacco è a volte il più scomodo: spegnere qualcosa. Ogni appliance vecchia, servizio VPN dimenticato, portale di gestione e server non più supportato è un punto d’attacco aggiuntivo. Sono particolarmente critici i sistemi al bordo della rete o quelli che permettono indirettamente accessi privilegiati alle reti interne.

Per gli admin Sophos Firewall significa concretamente:

• Verificare regolarmente quali firewall, RED, gateway VPN, controller WLAN, reverse proxy e componenti Remote Access sono ancora produttivi.
• Rimuovere sistemi end-of-life o end-of-support da posizioni privilegiate.
• Consolidare funzioni quando questo riduce complessità: firewall, SD-WAN, DNS Protection, ZTNA, Threat Feeds, reporting e central management dovrebbero essere allineati nel modo più pulito possibile.
• Documentare quali servizi devono davvero essere raggiungibili da Internet.

L’obiettivo non è inserire più funzioni possibili in un prodotto. L’obiettivo è evitare vecchi elementi ciechi. Un’infrastruttura piccola, aggiornata e ben controllata è quasi sempre più sicura di un ambiente grande, cresciuto storicamente, con molte eccezioni del tipo “è sempre stato così”.

Proteggere in modo coerente l’accesso di management

Una delle best practice più importanti è semplice: Web Admin Console e User Portal non dovrebbero essere inutilmente raggiungibili dalla WAN. Se l’amministrazione remota è necessaria, dovrebbe avvenire tramite Sophos Central, una rete di management dedicata, ZTNA o un altro percorso controllato.

Negli ambienti cliente vedo spesso che il problema non è la tecnica d’attacco più complessa, ma un vecchio accesso admin, un portale cresciuto negli anni o un’eccezione “temporanea” mai rimossa. Proprio questi punti devono far parte di una review regolare del firewall.

In ogni ambiente Sophos Firewall andrebbero verificati questi punti:

• Attivare MFA per gli amministratori, soprattutto per l’admin predefinito e tutti gli account con diritti estesi.
• Imporre MFA per login VPN e portali se questi accessi sono ancora utilizzati.
• Evitare accesso WAN ad Admin Console e User Portal o limitarlo fortemente a reti sorgente dedicate.
• Configurare regole password robuste per utenti e amministratori.
• Proteggere SSH, idealmente con autenticazione a chiave pubblica e senza ampia raggiungibilità WAN.
• Attivare backup centrali e proteggere l’accesso ai backup, perché i backup di configurazione possono contenere informazioni sensibili.
• Attivare notifiche e logging affinché eventi rilevanti per la sicurezza non si perdano nell’operatività quotidiana.

Il tema dei backup viene spesso sottovalutato. Un backup del firewall non contiene solo impostazioni innocue, ma informazioni su reti, regole, certificati, VPN e strutture interne. I backup devono quindi essere cifrati, archiviati in modo controllato e testati regolarmente.

Impostare consapevolmente Device Access e Local Service ACL

Quando si parla di accesso WAN, con Sophos Firewall bisogna parlare concretamente di Device Access e Local Service ACL. La matrice Device Access definisce per zona quali servizi locali del firewall sono raggiungibili: HTTPS admin, User Portal, SSH, ping, DNS, Captive Portal, portali VPN e altri servizi.

La best practice è molto semplice, ma efficace: dalla zona WAN dovrebbe essere raggiungibile solo ciò che serve davvero. Accesso admin, SSH e User Portal non devono essere esposti ampiamente su Internet. Se servono eccezioni, dovrebbero essere limitate con Local Service ACL Exception Rules a indirizzi IP sorgente concreti o reti di management.

Regole paese come protezione minima

Se indirizzi IP sorgente fissi non sono realistici, consiglio almeno di lavorare con regole paese. L’accesso solo da pochi paesi rilevanti è comunque molto meglio della raggiungibilità globale. In alternativa si possono bloccare paesi con cui l’azienda non ha rapporti e in cui collaboratori o admin normalmente non si trovano. Non è un sostituto di MFA, ruoli forti e ACL pulite, ma riduce rumore inutile e molti tentativi automatizzati.

Dal mio punto di vista questo è uno dei primi punti in ogni firewall review. Molte configurazioni rischiose non nascono da cattiva intenzione, ma perché un servizio è stato aperto brevemente per una migrazione, un caso di supporto o un test e poi mai richiuso. Sono proprio questi dettagli a distinguere un firewall che semplicemente funziona da un firewall gestito davvero bene.

Verificare Login Security e ruoli admin

MFA è importante, ma il layer di login comprende più di un secondo fattore. Gli amministratori dovrebbero usare account personali e tracciabili e non lavorare stabilmente con un full admin condiviso. I diritti basati sui ruoli aiutano a separare accessi di supporto, reporting o helpdesk dalla vera amministrazione del firewall.

Inoltre dovrebbero essere limitati i tentativi di login falliti, le sessioni dovrebbero terminare correttamente e gli accessi admin dovrebbero essere limitati a reti definite. Un login disclaimer può avere senso legale in alcuni ambienti, ma non sostituisce controlli tecnici reali. Più importanti sono policy password forti, sessioni inattive brevi, protezione brute-force e least privilege.

Evitare la patch fatigue: gli Hotfixes devono agire rapidamente

Il patching è uno dei temi in cui teoria e pratica sono molto distanti. Naturalmente ogni admin sa che gli aggiornamenti firmware sono importanti. Nella realtà però significano finestre di manutenzione, valutazione del rischio, pianificazione HA, comunicazione con reparti aziendali e talvolta downtime. Questo porta alla patch fatigue: gli update vengono rimandati perché impegnativi.

Qui il fattore tempo diventa pericoloso. Gli attacchi basati sull’identità sono ormai la root cause dominante, ma lo sfruttamento di vulnerabilità resta un vettore reale, soprattutto per sistemi edge come firewall, VPN e altri servizi vicini a Internet. Il Sophos Active Adversary Report 2026 cita come esempio CVE-2024-40766 in SonicOS, visibile in una grande parte dei casi di exploit confermati nel dataset. Allo stesso tempo, il tempo mediano tra advisory o patch del produttore e sfruttamento osservato era di 322 giorni. È un segnale chiaro: la patch fatigue non è un problema operativo astratto, ma una finestra d’attacco.

Sophos Firewall compie qui un passo importante: gli Automated Hotfixes permettono live patch di sicurezza senza classica finestra di manutenzione. Per gli admin è molto prezioso, perché l’effetto critico di protezione non deve aspettare il prossimo slot disponibile.

Tuttavia gli Hotfixes non sostituiscono una strategia di update pulita. Chiudono la finestra pericolosa tra vulnerabilità scoperta e firmware upgrade regolare. La best practice è quindi:

• Lasciare attivi gli Hotfixes.
• Verificare regolarmente le versioni firmware e documentare la preparazione del firmware update.
• Leggere in anticipo percorsi di upgrade e compatibilità.
• Preparare backup e piano di rollback.
• Pianificare separatamente cluster HA e sedi remote.

Non trattare la VPN come prova di fiducia

Remote Access VPN è stato lo standard per anni. Il problema: la VPN classica ragiona spesso in reti, non in applicazioni. Chi si connette con successo si trova, dal punto di vista di molti ambienti, già in un’area fidata. Se l’endpoint è compromesso o le credenziali sono state rubate, un attaccante può muoversi da lì.

Zero Trust Network Access (ZTNA) non risolve questo problema per magia, ma con un principio migliore: Trust nothing, verify everything. L’accesso non viene concesso genericamente a una rete, ma valutato per utente, dispositivo, stato e applicazione. Un dispositivo deve essere sano e compliant, l’identità verificata e la policy decide granularmente quale applicazione è raggiungibile.

ZTNA non è automaticamente una decisione Sophos

Il punto importante è questo: ZTNA non è una decisione che deve automaticamente significare Sophos ZTNA. A seconda dell’ambiente, provider specializzati ZTNA, SSE o SASE possono essere funzionalmente più avanzati, offrire integrazioni migliori o adattarsi meglio all’organizzazione. Non conta il nome del produttore, ma se identità, postura del dispositivo, accesso applicativo, logging e operation funzionano insieme in modo pulito.

Questa è anche la mia posizione generale nei progetti Sophos: non scelgo automaticamente Sophos per ogni tema. Se una soluzione di terze parti per ZTNA, SSE, Threat Intelligence, SIEM o NDR si adatta meglio dal punto di vista tecnico, quella è la raccomandazione migliore. Una buona architettura di sicurezza non nasce dal massimo legame a un vendor, ma da componenti integrati bene con responsabilità chiare.

Per ambienti puramente Sophos, l’integrazione può comunque essere interessante perché ZTNA, Endpoint, Firewall e Sophos Central possono essere usati insieme. Un dispositivo compromesso o non conforme può perdere l’accesso senza che un admin debba prima ricostruire manualmente regole firewall. Vale anche la pena guardare lo ZTNA Gateway su Sophos Firewall. In ambienti misti o più grandi, però, bisogna confrontare consapevolmente e non scegliere automaticamente il produttore del firewall esistente come piattaforma ZTNA.

Chi oggi usa ancora molto SSL VPN o IPsec Remote Access dovrebbe almeno verificare questi punti:

• Imporre MFA per ogni accesso Remote Access.
• Rimuovere utenti VPN vecchi o inutilizzati.
• Controllare l’importazione gruppi da AD o Entra ID affinché Remote Access non venga attivato involontariamente.
• Ridurre al minimo Split-Tunnel, reti consentite e permessi.
• Pianificare una migrazione graduale verso una soluzione ZTNA, SSE o SASE adatta, soprattutto per web app interne, RDP, SSH, portali di amministrazione e applicazioni business.

Segmentazione contro Lateral Movement

Quando gli attaccanti entrano con credenziali valide o tramite un servizio esposto, la segmentazione interna decide fin dove possono muoversi. Un firewall non dovrebbe quindi essere solo gateway perimetrale, ma separare bene le zone interne: utenti, server, management, IoT, rete guest, produzione, backup e sistemi particolarmente critici non devono stare ciecamente nello stesso modello di fiducia.

In pratica significa costruire VLAN e zone non solo per ordine, ma proteggerle con vere regole firewall. Tra reti utenti e server dovrebbero essere consentite solo le applicazioni necessarie. Gli accessi di management appartengono a reti admin dedicate. Reti IoT e stampanti non dovrebbero parlare liberamente con i server. Backup e domain controller meritano regole particolarmente restrittive e buon logging.

Qui si chiude il cerchio con l’idea “gli attaccanti effettuano il login”. Se un account compromesso ha accesso a un’applicazione, ma non a tutta la rete, un incidente non diventa automaticamente una compromissione completa.

Nei nuovi progetti pianifico quindi la segmentazione il prima possibile. Dopo è ancora possibile, ma molto più faticosa perché applicazioni, eccezioni e dipendenze storiche devono prima essere districate.

Rendere visibili le configurazioni errate

Un firewall può essere tecnicamente molto potente e diventare comunque pericoloso per configurazione errata. Regole troppo ampie, oggetti “Any”, autenticazione debole, policy IPS mancanti, pattern update disattivati o portali aperti sono esempi tipici. Il difficile è che negli ambienti cresciuti nel tempo questi rischi non si vedono sempre subito.

Il Sophos Firewall Health Check affronta esattamente questo problema. Verifica decine di impostazioni rispetto a best practice e benchmark e mostra nel Control Center dove le configurazioni sono rischiose o divergono dagli standard raccomandati. I risultati sono prioritizzati per rischio, portano direttamente alle impostazioni interessate e possono essere corretti o ignorati consapevolmente secondo la situazione.

Health Check è particolarmente utile per processi operativi ricorrenti:

• dopo un nuovo rollout firewall,
• dopo grandi modifiche alle regole,
• prima e dopo firmware upgrade,
• prima di audit,
• dopo migrazioni da vecchio hardware,
• come controllo trimestrale regolare.

È però importante anche questo: un Health Check non sostituisce il giudizio degli admin. Non ogni raccomandazione si adatta a ogni ambiente. Alcuni punti hanno motivi di compliance o operation, altri sono chiare lacune di sicurezza. Decisivo è valutare consapevolmente le deviazioni e non lasciarle crescere inosservate.

Dal mio punto di vista, Health Check è forte soprattutto come strumento operativo continuo. Non è utile solo per il primo go-live, ma anche come punto di partenza per review trimestrali, preparazione audit e pulizia di vecchi set di regole.

Secure by Design: rafforzare il firewall stesso

Dal mio punto di vista non servono solo prodotti di sicurezza, ma prodotti di sicurezza sicuri. È una differenza importante. Un firewall non deve solo bloccare attacchi verso altri sistemi, ma deve essere esso stesso rafforzato contro gli attacchi.

Con Sophos Firewall questo comprende diversi livelli:

• Kernel hardened e architettura modernizzata: la nuova architettura Xstream punta maggiormente su isolamento, modularizzazione, containerizzazione e separazione dei privilegi. Questo riduce alcune classi di vulnerabilità e limita gli impatti grazie a migliore isolamento. Si aggiungono mitigazioni contro vulnerabilità side-channel e CPU. Questo rende la piattaforma più robusta, ma non immune da vulnerabilità.
• Automated Hotfixes: le correzioni di sicurezza possono essere distribuite molto rapidamente e senza classica finestra di manutenzione.
• Remote Integrity Monitoring: il Sophos XDR Linux Sensor integrato può monitorare l’integrità del sistema in tempo reale, ad esempio modifiche di configurazione non autorizzate, Rule Exports, esecuzione sospetta di programmi o File Tampering. È utile solo se la funzione è attivata, licenziata, collegata e monitorata in operation.
• Gestione Central sicura: l’amministrazione può avvenire tramite Sophos Central senza esporre ampiamente porte di management su Internet.
• Health Check: le configurazioni rischiose diventano visibili direttamente.
• Backup cifrati: i dati di configurazione vengono trasmessi e salvati in modo protetto.

Inoltre Sophos punta sul monitoraggio proattivo della base firewall installata. La telemetria dai firewall può aiutare a riconoscere prima indizi di attacchi o manipolazioni. Quando un pattern diventa visibile, Sophos può supportare in modo mirato clienti o partner e distribuire Hotfixes rapidamente su larga scala.

Questi punti sono meno spettacolari nel quotidiano di una nuova regola firewall o di un attacco bloccato nel log. A lungo termine però sono decisivi. Un prodotto hardened riduce la probabilità che il firewall diventi esso stesso punto d’ingresso. Ma non sostituisce un processo patch pulito, monitoring o review regolari della configurazione.

Cosa aspettarsi da un produttore di firewall

Secure by Design non è solo una proprietà del prodotto, ma anche una questione di produttore. I clienti dovrebbero aspettarsi che i produttori gestiscano vulnerabilità in modo trasparente, comunichino chiaramente informazioni lifecycle, distribuiscano rapidamente fix di sicurezza e costruiscano prodotti in modo che configurazioni errate e componenti compromessi emergano il prima possibile.

La responsabilità è condivisa. I produttori devono fornire prodotti sicuri e reagire in modo trasparente. I clienti devono installare update, sostituire sistemi EOL, usare MFA e verificare regolarmente l’operation. Le due cose stanno insieme.

Pilastro 2: Protection durante l’attacco

L’hardening è la base. Dopo, il firewall deve continuare a fare ciò per cui viene usato: controllare traffico e bloccare attacchi. Con Sophos Firewall questo include tra l’altro IPS, Web Protection, Application Control, Zero-Day Protection, TLS Inspection, DNS Protection e Threat Intelligence Feeds.

Sophos usa fortemente l’architettura Xstream. Il traffico fidato può essere processato in modo più efficiente, attività intensive come operazioni crypto passano su percorsi ottimizzati, e per traffico a rischio più elevato resta più riserva prestazionale per Deep Packet Inspection, TLS Inspection e Zero-Day Protection.

TLS Inspection è un buon esempio dell’equilibrio tra sicurezza e operation. Senza decrittazione, gran parte del traffico moderno resta invisibile. Con regole TLS pianificate male, però, nascono casi di supporto, problemi di certificati o colli di bottiglia prestazionali. La best practice non è quindi “decrittare tutto alla cieca”, ma classificare bene:

• prima gruppi utenti e server critici,
• escludere correttamente banking, health, privacy e categorie problematiche note,
• testare pagine di blocco e avviso,
• documentare la distribuzione certificati,
• valutare attivamente i log.

La mia raccomandazione è di non avviare TLS Inspection come progetto tutto-o-niente. Meglio un rollout pulito con gruppi utenti chiari, eccezioni, finestre di test e valutazione log. Così aumenta la visibilità senza travolgere l’helpdesk il primo giorno.

Anche Threat Feeds appartengono a quest’area di protezione. Questi feed aiutano a bloccare IP, domini o URL malevoli noti direttamente al bordo rete. Nelle versioni più recenti di Sophos Firewall sono integrati molto più fortemente in Active Threat Response e nei meccanismi di protezione.

I Threat Feeds diventano particolarmente interessanti quando non si usano solo liste generiche, ma feed di terze parti curati con contesto attuale. Un esempio è Cybora.io, dove IP e domini malevoli provenienti da diverse fonti e telemetria firewall vengono uniti in feed utilizzabili. Ho descritto più in dettaglio come usare questi feed sui firewall nell’articolo Threat Intelligence Feeds per il firewall.

Anche qui vale: i Threat Feeds devono essere testati e osservati. Feed troppo aggressivi, processi allowlist mancanti o responsabilità poco chiare possono bloccare traffico legittimo e creare più danni che benefici in operation. Buoni feed non sostituiscono una rule review, ma sono un componente aggiuntivo con tuning proprio.

Non bisogna dimenticare nemmeno gli hardening classici di SFOS: Spoof Protection, impostazioni DoS adeguate e Geo-IP-Blocking possono ridurre accessi semplici, rumorosi o palesemente indesiderati. Questo non sostituisce una policy pulita, ma toglie rumore inutile al firewall e blocca percorsi d’attacco che in molti ambienti non hanno uno scopo legittimo.

Qui raccomando un approccio pragmatico: controllare prima bene i grandi rischi, poi rafforzare gradualmente le funzioni di protezione e dimostrare con i log cosa funziona davvero. Una policy sovraccarica che nessuno capisce più non è un guadagno di sicurezza a lungo termine.

Pilastro 3: Detection and Response dopo il primo segnale

La parte più interessante della sicurezza di rete moderna è la risposta. Un firewall non dovrebbe lavorare isolato, ma usare segnali da Endpoint, Server, NDR, MDR, XDR e Threat Intelligence. Sophos può sfruttare vantaggi di ecosistema, ma solo se queste integrazioni si adattano davvero all’ambiente.

Gli ecosistemi aiutano solo se si adattano

Synchronized Security e Security Heartbeat sono buone idee: il firewall può considerare lo stato degli endpoint e limitare o bloccare la comunicazione di dispositivi compromessi. Nella realtà però sempre più aziende usano Microsoft Defender o altre soluzioni endpoint. Allora questa parte dell’ecosistema Sophos funziona solo in modo limitato o non funziona. Proprio per questo non bisogna prendere automaticamente tutto dallo stesso produttore solo perché viene offerto come ecosistema integrato.

La mia raccomandazione è chiara: conta ciò che si adatta all’azienda e può essere implementato bene. Se Microsoft Defender, un altro EDR, un NDR di terze parti o un SIEM esterno sono la base migliore, il firewall deve essere integrato pulitamente in quell’architettura. Più importante del cross-selling è che i log arrivino nel posto giusto, gli allarmi siano compresi e qualcuno controlli regolarmente cosa riportano i sistemi. Senza analisi dei log, tuning e processo incident, anche la migliore integrazione aiuta poco.

Con Active Threat Response, le minacce rilevate possono essere tradotte automaticamente in decisioni di rete. E con NDR Essentials, il firewall ottiene ulteriore visibilità sul traffico di rete sospetto, anche dove non è installato un classico endpoint agent.

L’automazione ha bisogno di runbook

L’automazione ha bisogno di paletti. Deve essere chiaro quali segnali possono bloccare automaticamente, chi rimuove un isolamento, come vengono gestiti i false positive e come questi processi vengono testati. Senza runbook, responsabilità ed esercitazioni regolari, in caso di incidente nessuno sa se un blocco fosse voluto, corretto o troppo aggressivo.

Cosa succede in caso di incidente? Un dispositivo compromesso può essere isolato, la comunicazione C2 interrotta, l’esfiltrazione bloccata e un analista MDR o XDR può attivare Active Threat Response senza costruire prima manualmente una regola nel firewall. Questo è particolarmente prezioso quando un attacco viene rilevato fuori dal normale orario operativo.

Per gli admin è soprattutto importante una cosa: la reazione deve essere abbastanza veloce. Se un analista MDR o XDR deve prima chiamare, scrivere un ticket e poi un admin locale deve creare manualmente una regola il venerdì sera, il tempo di risposta è troppo lungo. Risposta automatizzata non significa sostituire le persone. Significa che il primo contenimento avviene subito e il team può poi analizzare con ordine.

Questa automazione è preziosa soprattutto nei team IT piccoli. Non ogni azienda ha uno specialista firewall disponibile 24/7. Quando Endpoint, Firewall, NDR, MDR e SIEM collaborano in modo sensato anche tra vendor diversi, si guadagna tempo, e il tempo è spesso il fattore più importante durante attacchi attivi.

Checklist pratica per admin Sophos Firewall

Chi vuole rafforzare oggi una Sophos Firewall può iniziare con questa lista:

Da verificare subito

• Gli Hotfixes sono attivati?
• MFA è attivo per gli amministratori?
• Web Admin Console e User Portal sono raggiungibili dalla WAN?
• SSL VPN o IPsec Remote Access sono protetti con MFA?
• Esistono ancora account admin locali inutilizzati?
• I backup sono pianificati, cifrati e testati?
• Device Access e Local Service ACL sono ridotti al minimo?
• I servizi raggiungibili dalla WAN sono limitati almeno a paesi rilevanti o reti sorgente note?
• Pattern update e versioni firmware sono aggiornati?

Nelle prossime settimane

• Eseguire Health Check e prioritizzare i findings.
• Verificare vecchie regole firewall con “Any” come sorgente, destinazione o servizio.
• Verificare ruoli admin, Login Security, session timeout e protezione brute-force.
• Inventariare servizi esposti come RDP, SSH, web server, portali e regole NAT.
• Verificare zone interne e regole VLAN contro Lateral Movement.
• Confrontare opzioni ZTNA, SSE o SASE per applicazioni Remote Access tipiche.
• Verificare Threat Feeds e DNS Protection.
• Attivare Spoof Protection, protezione DoS e Geo-IP-Blocking in base al rischio.
• Testare TLS Inspection in modo strutturato e distribuirla gradualmente.

Pianificare strategicamente

• Sostituire sistemi end-of-life.
• Allineare in modo sensato operation di firewall, VPN, DNS, SD-WAN e ZTNA/SSE.
• Standardizzare management centrale, reporting e alerting, ad esempio tramite Sophos Central, SIEM o piattaforme security esistenti.
• Definire export Syslog/SIEM e log retention per analisi forensi.
• Integrare segnali MDR/XDR/NDR nel processo incident.
• Introdurre review ricorrenti di firewall hardening.

Conclusione

Le Network Security Best Practices non sono un progetto una tantum, ma un modello operativo. Proprio perché i firewall al bordo rete sono così privilegiati, devono essere regolarmente rafforzati, patchati, verificati e integrati nella detection.

La mia raccomandazione dopo molti anni con Sophos Firewall è quindi chiara: un firewall moderno deve essere più di un prodotto di protezione. Contano design sicuro, configurazioni errate visibili, correzioni di sicurezza rapide e una risposta che in caso di incidente collabori con Endpoint, NDR, XDR e MDR.

O detto in modo pratico: se un firewall è così vecchio da stare meglio in un museo che in un rack, non è solo un rischio operativo. È una superficie d’attacco. Ed è proprio questa superficie d’attacco che tengo il più piccola possibile.

Supporto da Avanet

Se serve supporto per l’hardening di una Sophos Firewall, Avanet può aiutare. Come specialista Sophos di lunga data supporto i team IT con firewall audit, Health Check review, pulizia delle regole, pianificazione Remote Access e ZTNA/SSE, strategie di update e formazione.

Uno sguardo esterno su accessi di management, configurazione VPN, vecchie regole, servizi esposti via WAN e stato update spesso vale la pena. Molti rischi non nascono da una singola impostazione errata, ma da eccezioni cresciute nel tempo che nella quotidianità nessuno mette più in discussione.

In caso di interesse basta un breve messaggio tramite il modulo di contatto. Poi si può chiarire insieme se per l’ambiente specifico sia più sensata una review compatta del firewall, un audit o una formazione.

FAQ

Link correlati

• Avanet Blog: Sophos Firewall v22: panoramica e tutte le nuove funzionalità
• Avanet Blog: Threat Intelligence Feeds per il firewall
• Avanet Blog: Sophos ZTNA Gateway su Sophos Firewall
• Avanet Blog: Sophos NDR - eliminare i punti ciechi nella rete
• Avanet KB: Sophos Firewall Firmware Update - preparazione e best practice

Fonti

• Sophos: Firewall: Network Security Best Practices
• Sophos Docs: Hardening your Sophos Firewall
• Sophos X-Ops: Nowhere, man: The 2026 Active Adversary Report