Configurare la protezione web di Sophos Firewall con le politiche web

La protezione web di Sophos Firewall controlla quali siti web, categorie e contenuti web gli utenti possono raggiungere. In pratica, la protezione web non è semplicemente un singolo flag. Una politica web deve essere pianificata professionalmente, attivata in una regola firewall appropriata e successivamente testata con traffico reale.

Molti errori si verificano perché una politica web esiste, ma non viene applicata a una regola firewall attiva. Altri problemi sono legati a HTTPS, ispezione TLS, QUIC, riconoscimento utente, ordine delle regole o eccezioni troppo generiche. Il flusso logico è quindi: pianificare la politica, costruire la regola, attivarla, testarla e monitorarla in produzione.

Quale articolo sulla protezione web è adatto?

La protezione web si sovrappone a regole firewall, ispezione TLS, QUIC, reportistica ed eccezioni. A seconda del compito, un articolo più specifico potrebbe essere più adatto:

• Configurare fondamentalmente la protezione web e le politiche web: Questo articolo.
• Comprendere Single o Dual Engine, gli errori di scansione, i limiti di dimensione e un vero test malware: Configurare e testare la scansione malware di Sophos Firewall.
• Valutare categorie web, gruppi di URL e avvisi istantanei: Utilizzare le categorie web e gli avvisi istantanei di Sophos Firewall.
• Decrittare e verificare il traffico HTTPS: Implementare correttamente l’ispezione TLS di Sophos Firewall.
• Distribuire il certificato CA per i client gestiti: Distribuire il certificato CA di Sophos Firewall per l’ispezione TLS.
• Classificare QUIC e HTTP/3 in caso di problemi di filtraggio web: Bloccare correttamente QUIC e HTTP/3 su Sophos Firewall.
• Scoprire quale regola firewall e politica sono effettivamente applicate: Testare le regole di Sophos Firewall con Log Viewer, Policy tester e Packet Capture.
• Valutare eventi web e di sicurezza a lungo termine: Central Firewall Reporting o Inviare Syslog a SIEM.

In questo modo l’analisi rimane chiara: prima bisogna verificare se la regola firewall corrisponde. Successivamente, si controllano la politica web, la categoria, il contesto utente, QUIC, l’ispezione TLS e la registrazione.

Cosa controlla la protezione web

La protezione web è composta da diversi componenti. Non tutti i componenti devono essere utilizzati in ogni ambiente, ma le relazioni dovrebbero essere chiare.

• Politica web: Regole per accessi web consentiti, avvisati, bloccati o basati su quota.
• Categorie web: Categorie Sophos e categorie personalizzate per i siti web.
• Gruppi di URL: Liste di domini personalizzate per regole di consentito o bloccato mirate.
• Tipi di file: Controllo di determinati tipi di download o file.
• Filtri di contenuto: Termini o modelli per il controllo dei contenuti.
• Eccezioni: Eccezioni mirate per comportamento web, TLS o di scansione.
• Search engine enforcement: SafeSearch e restrizioni YouTube.
• Advanced settings: restrizioni dei domini di accesso Google Apps e Microsoft Entra ID Tenant Restrictions.
• Registrazione e reportistica: Tracciabilità in Log Viewer, Reporting, Central o SIEM.

La protezione web non sostituisce una base di regole firewall pulita. La regola firewall decide prima quale traffico da quale zona a quale zona di destinazione è consentito. La politica web integra questa regola con il controllo web. Le basi per l’ordine delle regole, la sorgente, la destinazione, i servizi e i profili di sicurezza sono disponibili in Comprendere e costruire correttamente le regole di Sophos Firewall.

Prerequisiti

Prima del rollout, questi punti dovrebbero essere chiariti:

• La protezione web è concessa in licenza o inclusa nel pacchetto utilizzato.
• Le reti client interessate hanno regole firewall proprie.
• La registrazione è attiva nelle regole rilevanti.
• DNS e orario del firewall funzionano correttamente.
• Il riconoscimento utente è chiarito, se le politiche devono applicarsi per utente o gruppo.
• L’ispezione TLS è pianificata, se i contenuti HTTPS devono essere esaminati più da vicino.
• QUIC/HTTP/3 è consapevolmente consentito o bloccato.
• Esiste un gruppo pilota e un percorso di fallback per i siti critici per il business.

Particolarmente importante è la separazione per gruppi target. Una politica web per client normali, server, ospiti, utenti VPN e sistemi di gestione non dovrebbe essere la stessa. I server spesso necessitano di meno controllo di navigazione, ma liste di destinazione e aggiornamento più rigorose. Gli ospiti spesso necessitano di categorie e limitazioni di larghezza di banda, ma non di accesso alle risorse interne.

Se le politiche web devono reagire a utenti o gruppi, il riconoscimento utente deve funzionare. AD SSO, Captive Portal, STAS, SATC o altri metodi non dovrebbero essere scoperti solo durante il rollout della politica web. Nel Log Viewer deve essere visibile se una richiesta è stata valutata come utente noto, come gruppo oppure come Anybody o utente sconosciuto.

I criteri utente della regola firewall corrispondente hanno precedenza su Users nella politica web: la politica può restringere tale ambito, ma non includere utenti esclusi dalla regola.

Percorso minimo per una politica web efficace

Creare la politica in Web > Policies con almeno una decisione Allow/Block mirata. Modificare poi una regola reale in Rules and policies > Firewall rules con Action: Accept e valori corretti per Source Zone, Source Network, Destination Zone, Destination Network e Services; attivare Log firewall traffic e assegnare la politica in Web filtering. Verificare il NAT esistente senza crearne uno nuovo solo per la politica.

Prima della modifica, registrare la Rule ID e i risultati di un URL volutamente consentito e di uno volutamente bloccato; dopo la modifica, ripetere le stesse richieste da un client con il contesto reale di origine e utente. La modifica va accettata solo se Log Viewer mostra la Rule ID attesa, la nuova politica e le decisioni Allow e Block previste.

Pianificare la politica web

Una buona politica web non inizia nell’interfaccia, ma con alcune decisioni professionali.

Definire i gruppi target

Per prima cosa si stabilisce per chi è valida la politica:

• Client standard nella LAN
• Notebook gestiti tramite VPN
• WLAN ospiti
• Aule o ambienti scolastici
• Server con accesso HTTP/HTTPS in uscita
• Postazioni amministrative privilegiate

Se la stessa regola firewall contiene più gruppi molto diversi, la protezione web diventa difficile da comprendere. Meglio regole e politiche separate, ad esempio LAN_USERS_WEB, GUEST_WEB o SERVER_UPDATES_WEB.

Stabilire categorie e gruppi di URL

La categoria highly objectionable criminal activity è sempre bloccata. Né le regole della politica web né le esclusioni possono consentirla; inoltre, SFOS nasconde il dominio interessato nei log e nei report.

Le categorie web di Sophos sono utili per un controllo ampio: malware, phishing, contenuti per adulti, anonimizzatori, streaming, social media o giochi. I gruppi di URL sono migliori quando si desidera consentire o bloccare singoli domini in modo mirato.

Uso tipico:

• Bloccare categorie di rischio note: Categoria web.
• Consentire determinati domini SaaS: Gruppo di URL.
• Gestire un singolo dominio categorizzato erroneamente: Gruppo di URL o categoria personalizzata.
• Limitare temporalmente lo streaming: Politica web con pianificazione o quota.
• Pagina di avviso invece di blocco rigido: Politica web con azione di avviso.

I gruppi di URL non dovrebbero diventare una lista di raccolta non ordinata. Se vengono inseriti molti domini, la lista necessita di un proprietario, uno scopo e una data di revisione. Per liste molto grandi o dinamiche, Sophos Firewall Threat Feeds o altri componenti architetturali sono spesso più appropriati.

Creare e usare in sicurezza gli URL Groups spiega come interagiscono valori di dominio validi, logica OR, uso nella Web Policy ed esclusioni TLS.

Per corrispondenze basate solo sul dominio, i gruppi di URL sono di solito migliori delle categorie web personalizzate. Sophos indica che i gruppi di URL sono più performanti e possono generare meno falsi positivi. Le categorie personalizzate sono utili quando un dominio deve comparire in una logica di policy propria oltre alla sua categoria standard Sophos.

Le keyword nelle categorie personalizzate vanno usate con molta cautela. Le keyword vengono confrontate con l’intero URL, inclusi percorso e query. Un allow basato su una keyword può quindi applicarsi involontariamente se la parola compare in un parametro di query su un altro dominio. Per decisioni di allow, domini concreti o gruppi di URL sono di solito più puliti; le regole keyword si adattano meglio a casi di blocco stretti.

Impostare con cautela le regole di consentito

Le regole di consentito nelle politiche web dovrebbero essere strette. Una regola di consentito in alto può rendere inefficaci le regole di blocco successive, poiché le regole delle politiche web di Sophos vengono valutate dall’alto verso il basso. Questo è particolarmente rilevante se un gruppo di URL, una regola di tipo di file o un’eccezione di categoria si trova sopra altre regole.

Praticamente si è dimostrato efficace:

1. Eccezioni aziendali specifiche consentite in alto.
2. Categorie di blocco critiche dopo.
3. Regole di avviso o quota per aree grigie.
4. Traffico web generalmente consentito solo alla fine.

Creare una politica web

La politica web viene creata nel seguente menu:

Web > Policies

Procedura di base:

1. Selezionare Add policy.
2. Assegnare un nome significativo, ad esempio LAN_USERS_STANDARD_WEB.
3. Aggiungere regole.
4. Verificare search engine enforcement, ad esempio SafeSearch o YouTube restrictions.
5. Impostare policy quota status se vengono usate azioni Quota.
6. Verificare Advanced settings, in particolare logging, reporting, download di grandi dimensioni, Google Apps e Microsoft Entra ID Tenant Restrictions.
7. Salvare la politica.

Una regola all’interno della politica web viene creata con Add rule. Il firewall crea prima una regola predefinita disattivata che blocca HTTP per Anybody. Poi i campi vengono adattati in modo mirato:

1. Aprire Users e impostare consapevolmente Anybody, utenti specifici o gruppi.
2. Aprire Activities e selezionare All web traffic, User activities, Categories, URL Groups o File types.
3. Per i contenuti scegliere la scheda separata Content filters, selezionare il filtro, attivare and with content e lasciare HTTPS su Use action.
4. Impostare Action per HTTP: Allow, Warn, Block o Quota.
5. Verificare l’azione HTTPS: Use action, Allow HTTPS, Warn HTTPS, Block HTTPS o Quota HTTPS.
6. Impostare Constraints se la regola deve valere solo per un programma.
7. Verificare la posizione della regola all’interno della policy.
8. Attivare lo stato della regola.
9. Salvare la policy.

Importare correttamente gli elenchi dei filtri di contenuto

I Content filters vengono gestiti in Web > Content filters e poi selezionati in Activities nella regola della politica web. Per elenchi di termini più lunghi, Sophos supporta un semplice file .txt. Il file può contenere al massimo 2,000 righe e ogni voce può avere una lunghezza massima di 80 caratteri, inclusi spazi e segni di punteggiatura.

Il file deve contenere un solo termine per riga e ogni riga viene valutata come exact match. Non deve includere intestazioni, commenti, metadati o colonne aggiuntive e, in presenza di caratteri non ASCII, deve essere salvato in UTF-8.

Procedura sicura:

1. Ripulire i termini in un editor di testo e inserire esattamente una voce per riga.
2. Salvare il file come .txt con codifica UTF-8.
3. Importare l’elenco in Web > Content filters e assegnargli un nome descrittivo.
4. In Activities, aprire Content filters, scegliere il filtro, attivare and with content e mantenere Use action per HTTPS.
5. Con un client pilota, testare un termine consentito e uno che corrisponda volutamente, quindi verificare l’azione in Log Viewer.

Se l’importazione viene rifiutata o singoli termini non vengono applicati, controllare prima il numero di righe, la lunghezza dei caratteri, la codifica e gli eventuali caratteri aggiuntivi invisibili. Una regola Allow ampia sopra la regola Content filter non deve aggirare l’elenco.

Creare tipi di file web personalizzati

Sophos Firewall identifica i File types in base all’estensione del file o all’header MIME. I tipi integrati non sono modificabili. Un tipo personalizzato viene creato in Web > File types > Add partendo da un modello adatto e aggiungendo le estensioni necessarie senza punto iniziale oppure gli header MIME. Lo stesso oggetto può poi essere utilizzato nelle policy di protezione web ed email.

Nella finestra Add occorre specificare un nome. Template è facoltativo e inserisce le estensioni e gli header MIME più comuni di una categoria; per il tipo personalizzato è possibile aggiungere altri valori. Salvare quindi con Save. Le estensioni non devono iniziare con un punto: pdf è corretto, .pdf no. I tipi integrati fungono da modelli e non sono modificabili; per apportare variazioni occorre creare un tipo personalizzato.

SFOS include le categorie predefinite All executable files, Audio files, Backup files, Compressed files, Configuration files, Database files, Developer files, Disk image files, Document files, Dynamic files, Encoded files, Executable files, Image files, Page layout files, Plugin files, System files, Video files e Web files. La vista dettagliata in Web > File types è il riferimento operativo per le estensioni e gli header MIME attualmente configurati. Ad esempio, Compressed files comprende voci quali 7z, gz, rar, tar.gz e zip, mentre Document files comprende voci quali docx, xlsx, pptx, odt, rtf e pdf. Prima di consentire una categoria, aprire quindi il tipo integrato specifico nella propria versione di SFOS e confrontarlo con il caso d’uso reale, senza basarsi solo sul nome.

Il nuovo tipo di file non produce alcun effetto da solo. Deve essere selezionato in Activities > File types nella regola della politica web pertinente. Si controllano quindi l’azione, lo stato e l’ordine della regola, oltre all’assegnazione della politica web alla regola firewall che gestisce realmente il traffico.

La verifica usa un download rappresentativo e un file volutamente simile che non deve corrispondere. Nel Log Viewer si controllano la politica web e l’azione. Una corrispondenza basata sull’estensione o sull’header MIME è una classificazione di policy, non una prova di malware né di un’analisi Zero-Day completata. Per HTTPS, la visibilità necessaria dipende anche dal percorso TLS Inspection. Se il tipo non viene riconosciuto, confrontare innanzitutto lo stato e l’ordine della regola, il File Type effettivamente selezionato, la risposta Content-Type del server, l’estensione visibile e lo stato di TLS Inspection. Un tipo MIME errato o generico fornito dal server può produrre un risultato diverso da quello suggerito dal nome del file.

Raggruppare correttamente le User Activities

In Web > User activities > Add, una User activity raggruppa Web Categories, File types e URL Groups in un’attività riutilizzabile. Questi elementi vengono valutati con OR; è sufficiente una sola corrispondenza. Il nome non indica quindi un utente connesso, ma una raccolta di criteri web.

La User Activity viene poi selezionata in Activities nella regola della politica web. È utile quando la stessa combinazione viene impiegata in più policy. Per la verifica si testa almeno una corrispondenza per ogni tipo di oggetto incluso e un caso simile che non deve corrispondere.

Controllare l’ordine delle regole e le policy migrate

Le regole della politica web vengono valutate dall’alto verso il basso. Se, per esempio, una regola Allow per il tipo di file .mdb si trova sopra una regola di blocco di una categoria, i download .mdb da quella categoria restano consentiti. In modalità DPI, la connessione iniziale alla categoria può essere consentita finché non viene identificato il tipo di file; se il file non corrisponde, il firewall interrompe poi la connessione senza mostrare una pagina di blocco. Se la categoria deve essere sempre bloccata, la relativa regola va collocata sopra la regola Allow del tipo di file.

Le vecchie policy migrate sono inoltre soggette a un limite rigido di 128 regole per policy. Se l’origine ne contiene di più, SFOS usa solo le prime 128. Le regole adiacenti per User Activities, Categories, URL Groups, File types e Dynamic Categories vanno quindi consolidate consapevolmente in Activities combinate prima o dopo la migrazione. Il conteggio, l’ordine e test reali di Allow e Block fanno parte della verifica della migrazione.

Le finestre ricorrenti vengono create come pianificazione separata. La procedura e la differenza rispetto a una regola firewall controllata nel tempo sono descritte in Configurare pianificazioni per regole e policy in Sophos Firewall.

Una politica web da sola non ha effetto. La politica deve essere utilizzata successivamente in una regola firewall. Questo è uno degli errori di configurazione più comuni.

Attivare la politica web nella regola firewall

La regola firewall si trova sotto:

Rules and policies > Firewall rules

Per il traffico Internet normale dei client, di solito è responsabile una regola da LAN o una zona client a WAN. Lì, nell’area Web filtering, viene selezionata la politica web appropriata.

Punti di controllo nella regola firewall:

• La zona di origine e le reti di origine corrispondono alla rete client.
• La zona di destinazione è di solito WAN.
• I servizi includono HTTP/HTTPS o i servizi web desiderati.
• Log firewall traffic è attivo.
• Nell’area Web filtering è impostata la politica web corretta.
• Scan HTTP and decrypted HTTPS è attivato quando devono funzionare la scansione malware web o il controllo dei contenuti.
• Use Zero-day protection è utile solo se i file vengono scansionati tramite HTTP o HTTPS decrittato.
• Block QUIC protocol è impostato consapevolmente.
• Sul percorso trasparente della regola firewall, Use web proxy instead of DPI engine è attivo per SafeSearch, YouTube Restrictions e restrizioni di accesso Google Apps; negli altri casi e con Direct Proxy, la modalità viene scelta in base alle funzioni necessarie.
• L’ispezione TLS è pianificata separatamente e non confusa con la politica web.

Sophos Firewall imposta Block QUIC protocol per impostazione predefinita quando nella regola viene selezionata una politica web o viene attivato Scan HTTP and decrypted HTTPS. Spesso è sensato, perché QUIC non può essere scansionato come il traffico HTTPS classico. Tuttavia l’opzione va testata consapevolmente: browser, servizi Google, strumenti di collaborazione e singole applicazioni SaaS possono cambiare comportamento quando QUIC viene bloccato.

Se nella stessa regola firewall viene usato anche Application Control, c’è una sovrapposizione importante: alcune Micro Apps, ad esempio upload o download in Dropbox o Gmail, vengono riconosciute tramite dettagli URL. In ambienti DPI, questo riconoscimento richiede una regola SSL/TLS Inspection adatta con decrittazione. Application Control può quindi valutare queste Micro Apps anche se la politica web non è il principale punto decisionale.

Se una regola più generale sopra la regola web desiderata corrisponde, il traffico non raggiunge la politica web. In tali casi, aiuta Testare le regole di Sophos Firewall con Log Viewer e Packet Capture.

Classificare HTTPS, ispezione TLS e QUIC

Una grande parte del traffico web è HTTPS. Senza ispezione TLS, il firewall vede meno contenuti. Categorie, SNI, certificati, IP di destinazione, informazioni sul dominio e metadati aiutano, ma non sostituiscono una verifica completa dei contenuti.

DPI o Web Proxy?

Con la protezione web, bisogna decidere presto se la regola firewall interessata utilizza il DPI Engine o il Web Proxy. Questa decisione influenza quali funzioni si applicano e quali registri sono rilevanti in seguito.

• Modalità DPI: standard moderno per molte regole Internet client. L’ispezione TLS avviene tramite regole di ispezione SSL/TLS, la quota non è supportata.
• Modalità Web Proxy: ambienti con comportamento proxy esplicito o quota di politica. Verificare consapevolmente il comportamento del proxy, la compatibilità del browser/client e i registri del proxy.

In molte installazioni, la modalità DPI è il punto di partenza migliore. Tuttavia, se sono necessari tempi di quota tramite Quota, una regola puramente DPI non è sufficiente. In tal caso, la modalità Web Proxy deve essere pianificata e testata consapevolmente. Questa decisione dovrebbe essere presa prima del rollout, poiché un cambio successivo può generare altri modelli di errore, registri ed esperienze utente.

In una regola firewall trasparente, Transparent Web Proxy elabora soltanto le porte 80 e 443; sulle altre porte il DPI Engine può ispezionare il traffico HTTP e SSL/TLS se la regola firewall e le regole SSL/TLS Inspection sono adeguate. Direct Proxy è invece un percorso esplicito separato, scelto dal client, e non richiede necessariamente Use web proxy instead of DPI engine. Durante ogni test va quindi annotato se il client usa il percorso trasparente o la propria configurazione proxy esplicita.

La scelta completa delle funzioni, la migrazione pilota e i test specifici per modalità sono descritti in Confrontare correttamente DPI Engine e Web Proxy.

Configurare Direct Web Proxy con un file PAC spiega come integrare listener, file PAC, Device Access e una regola proxy funzionante.

I client solo IPv6 che accedono a destinazioni web solo IPv4 utilizzano un percorso distinto con due regole. NAT64 con Direct Web Proxy separa la Web Policy nella regola IPv6 da Application Control e IPS nell’egress IPv4.

Se Sophos Firewall deve inoltrare le proprie Web Requests a un parent proxy, configurare un upstream proxy in WAN o LAN/DMZ illustra il percorso corretto di regole e NAT per ogni topologia.

Quando più utenti RDS condividono lo stesso IP del server, Per-Connection AD SSO per host multiutente può distinguere le singole connessioni proxy HTTP e HTTPS. Il metodo non si applica al traffico non proxy e deve quindi essere consapevolmente distinto da SATC.

Ispezione TLS

Se si desidera verificare in modo affidabile download, scansione malware, determinate categorie web o controlli dei contenuti, è necessario pianificare l’ispezione TLS. Per questo è necessario un certificato CA attendibile sui client, regole TLS appropriate, eccezioni e un pilota pulito.

Il rollout è descritto in Distribuire gradualmente l’ispezione TLS su Sophos Firewall. Per distribuire e convalidare il certificato CA, è adatto Installare il certificato CA di Sophos Firewall per la scansione HTTPS.

QUIC e HTTP/3

I browser moderni utilizzano spesso QUIC o HTTP/3 su UDP 443. Questo può disturbare le aspettative di filtraggio web, ispezione TLS e scansione, se si desidera effettivamente esaminare il traffico HTTPS classico su TCP.

In molte aziende, è utile bloccare QUIC nelle regole Internet client, in modo che i browser tornino a HTTPS su TCP. I dettagli sono disponibili in Bloccare correttamente QUIC e HTTP/3 su Sophos Firewall.

SafeSearch, YouTube e restrizioni tenant

SafeSearch e YouTube si trovano in Search engine enforcement; Google Apps ed Entra in Advanced settings.

Opzioni tipiche:

• Enforce SafeSearch per Google, Yahoo e Bing.
• Enforce YouTube restrictions per contenuti YouTube limitati.
• Restrict login domains for Google Apps per domini Google consentiti.
• Apply Microsoft Entra ID tenant restrictions per il controllo dei tenant cloud Microsoft.

Sul percorso trasparente della regola firewall, SafeSearch, YouTube Restrictions e le restrizioni Google Apps richiedono Use web proxy instead of DPI engine; un Direct Proxy esplicito può offrire queste funzioni proxy senza tale opzione della regola firewall. Per Bing e Yahoo su HTTPS, SafeSearch richiede inoltre HTTPS scanning, mentre le restrizioni di accesso Google Apps valgono solo per i domini ospitati da Google. Le Microsoft Entra ID Tenant Restrictions sono separate, richiedono valori tenant corretti e devono essere provate con accessi reali al cloud Microsoft, non soltanto con un URL di esempio. Questi controlli non sostituiscono la governance delle identità e delle applicazioni cloud in Microsoft 365 o Google Workspace.

Quota e pagine di avviso

Le politiche web possono non solo bloccare o consentire. Con azioni di avviso o quota, è possibile informare consapevolmente gli utenti o consentire l’accesso limitato nel tempo.

Esempi significativi:

• Gli utenti possono confermare consapevolmente un avviso per determinate aree grigie.
• Lo streaming o lo shopping è consentito solo per un tempo limitato.
• Gli ambienti scolastici o di laboratorio consentono determinate categorie solo durante orari definiti.

Importante: la quota di politica non è supportata in modalità DPI. Se sono necessari tempi di quota, deve essere utilizzata la modalità Web Proxy. Questo dovrebbe essere deciso presto, poiché DPI e Web Proxy hanno caratteristiche e limiti diversi.

La allowed time quota viene impostata a livello di politica web e vale per tutte le regole di questa policy che usano un’azione Quota. Se due categorie richiedono quote temporali diverse, politiche web separate sono più pulite di una singola policy con aspettative di quota miste. Le quote vengono reimpostate localmente a mezzanotte e non possono essere impostate a zero.

Policy Quota non vale per Content filters o Dynamic Categories. Le modifiche non hanno effetto se la policy non è valida, non resta tempo o una sessione Quota è già attiva. DPI non supporta Policy Quota.

Questa Policy Quota si applica alle categorie web e non è la Surfing Quota basata sull’utente. La creazione, l’assegnazione e il controllo del consumo di Surfing Quota e Network Traffic Quota seguono una procedura separata.

Verificare la Policy Quota durante l’esercizio

In Web > Policy quota status, SFOS mostra per i singoli utenti il tempo restante nelle Web Policy interessate entro un periodo di 24 ore. L’utente selezionato può essere reimpostato tramite Reset. Si tratta di una modifica deliberata dello stato e non di un pulsante diagnostico: prima si documentano utente, policy, tempo residuo, motivo e ora.

Questo reset riguarda la Policy Quota temporale di una categoria web. Non equivale a Reset user accounting per Surfing Quota o Network Traffic Quota. Un reset non corregge né un ordine errato delle regole né la mancata identificazione dell’utente.

Personalizzare le pagine di avviso e blocco

In Web > User notifications si possono configurare immagini personalizzate e messaggi di blocco, override, quota e avviso. I segnaposto {category}, {user} e {url} inseriscono categoria web, nome utente e URL bloccato. La preview verifica presentazione e testo, ma non dimostra che la Web Policy e la regola firewall corrette corrispondano alla richiesta di produzione.

Il messaggio deve spiegare brevemente perché l’accesso è stato bloccato o ha generato un avviso e dove segnalare un legittimo caso aziendale. Nomi utente e URL possono contenere informazioni sensibili; la pagina non deve quindi includere segreti interni, password o dati di contatto non necessari.

Limitare in sicurezza i Policy Overrides

I Policy Overrides sono uno strumento diverso dalle quote. Con Enable policy override, gli utenti autorizzati possono creare nel User Portal un accesso temporaneo a siti web normalmente bloccati. Authorized users and groups limita chi può farlo, mentre Blocked websites and categories definisce le destinazioni che non possono mai essere ignorate. Allow manual access code entry viene attivato solo se i codici creati dagli utenti sono compatibili con il processo di approvazione.

In Web > General settings > Policy overrides, documentare prima lo stato precedente e gli utenti autorizzati. Nel User Portal, l’utente autorizzato specifica siti o categorie, un intervallo di tempo limitato e un codice di accesso per l’override. Quando si richiede una destinazione bloccata corrispondente, la pagina di blocco contiene un campo aggiuntivo per quel codice. Se Allow manual access code entry è attivo, gli utenti specificati possono creare i propri codici; se è disattivato, devono utilizzare codici generati. Questa scelta non va confusa con l’inserimento di un codice già valido nella pagina di blocco.

View overrides permette di visualizzare, attivare, disattivare ed eliminare gli override esistenti. Per la verifica, usare un utente di test autorizzato per accedere a una destinazione corrispondente entro l’intervallo di tempo con un codice valido; senza codice, fuori dall’intervallo e per una destinazione che non può mai essere autorizzata tramite override, deve restare il normale blocco. Correlare utente, Rule ID, web policy, azione e orario in Log Viewer. Per HTTPS, la pagina di blocco deve poter essere visualizzata; una semplice interruzione della connessione non offre un campo di inserimento.

Per il rollback, disattivare l’override pilota tramite View overrides e verificare il blocco originale con una nuova richiesta. Solo dopo eliminare un override non più necessario e ripristinare esclusivamente i valori globali modificati nel pilota allo stato precedente documentato. Non rimuovere indiscriminatamente gli override esistenti degli altri utenti.

Per gli utenti AD, My policy overrides si applica solo al gruppo principale e ai singoli utenti, non alle altre appartenenze a gruppi. Una regola di ispezione SSL/TLS corrispondente con Action > Deny continua ad avere la precedenza. Se in questa situazione deve funzionare un override approvato, si pianifica una Web Exception strettamente limitata per saltare la decrittazione HTTPS e la si testa separatamente con un caso negativo; la regola TLS non viene indebolita in modo generalizzato.

Web Exceptions ed eccezioni TLS

Le Web Exceptions sono potenti e quindi pericolose quando vengono usate come soluzione rapida: un’eccezione in Web > Exceptions può saltare i controlli sul traffico corrispondente indipendentemente dalla politica web applicata. Se si salta HTTPS decryption, vengono eliminati i controlli che ne dipendono e sono consentiti certificati server non validi; se si salta Malware and content scanning, viene saltata automaticamente anche Zero-day protection.

Per ambienti DPI vale una limitazione importante: le Web Exceptions si applicano solo se è impostata una politica web, Malware and content scanning è attivo o ATP è attivo. Le SSL/TLS Exclusion Rules sono invece il punto corretto quando si vuole solo evitare di decrittare determinate connessioni TLS. La differenza operativa è importante:

• SSL/TLS Exclusion Rule: esclude in modo mirato connessioni TLS dalla decrittazione, tipicamente per Certificate Pinning o incompatibilità.
• Web Exception: può saltare controlli di politica web, scansione malware, analisi Zero-Day o validazione dei certificati.
• URL Group in Web Policy: controlla Allow, Warn, Block o Quota; non è un criterio di Web Exception.

Per le eccezioni vanno evitati i domini radice e i pattern regex URL troppo ampi: un pattern come example.com può comparire anche nel percorso o nei parametri di query di un altro dominio. Un pattern hostname specifico può già corrispondere nel contesto TLS, mentre un percorso URL è visibile soltanto in HTTP o in HTTPS già decrittato. Occorre inoltre definire un ambito chiaro per origine, destinazione, categoria o gruppo di utenti.

Le eccezioni combinano i diversi criteri con AND. All’interno dello stesso tipo di criterio, ad esempio più URL Patterns, vale invece OR. È pratico ma soggetto a errori: un’eccezione con URL Pattern e Source IP si applica solo se entrambi corrispondono. Un’eccezione con molti URL Patterns può invece avere un effetto molto più ampio del previsto.

Prestare particolare attenzione a Policy checks. Se una Web Exception salta i Policy checks, può indebolire indirettamente altre decisioni di regola. In combinazione con Synchronized Security Heartbeat, una tale eccezione può far sì che le richieste web non vengano bloccate come previsto, anche se nella regola firewall sono impostati controlli Heartbeat.

Testare la protezione web

Dopo il salvataggio, non si dovrebbe solo verificare se la politica esiste. È fondamentale verificare se si applica al traffico reale.

1. Utilizzare il Policy Tester

Il percorso esatto è Diagnostics > Tools > Pop-out tools > Policy tester. Firewall, SSL/TLS, and web verifica il percorso trasparente combinato, mentre Web policy only isola la decisione della politica web. Il test web rappresenta soltanto gli accessi trasparenti, non considera le route SD-WAN e non accetta Source Networks con indirizzi MAC. Se non si specifica un protocollo usa HTTP; se non si specifica una porta usa quella standard del protocollo scelto.

Prima della modifica, eseguire entrambi i modi pertinenti come riferimento e registrare il risultato e la Rule ID attesa; dopo la modifica, ripetere gli stessi test. Il Policy Tester resta una verifica preliminare e deve essere completato con veri test Allow e Block da un client pilota, perché NAT, ispezione TLS, QUIC, routing o un percorso Direct Proxy esplicito possono gestire diversamente il traffico reale.

2. Test reale con client pilota

Con un client pilota, verificare:

• sito aziendale consentito
• categoria bloccata
• categoria di avviso
• gruppo di URL consentito
• gruppo di URL bloccato
• sito HTTPS con e senza ispezione TLS
• download di un tipo di file di test innocuo
• comportamento con QUIC attivo o bloccato

3. Verificare il Log Viewer

Nel Log Viewer dovrebbe essere visibile:

• quale regola firewall è stata colpita
• quale utente è stato riconosciuto, se rilevante
• quale categoria web o gruppo di URL è stato coinvolto
• se HTTPS, ispezione TLS o scansione malware sono stati coinvolti
• se l’azione ha consentito, avvisato o bloccato
• se si è applicata una Web Exception o TLS Exclusion
• se un download è stato trattato diversamente per dimensione, errore di scansione malware o analisi Zero-Day

Per Syslog o SIEM, URL e azione non bastano. Per un’analisi affidabile servono anche Firewall Rule ID, utente, categoria, politica web, metodo HTTP, stato, risultato della scansione, indicazione di eccezione e relazione SSL/TLS. Se questi campi mancano nel SIEM o sono normalizzati male, la protezione web appare rapidamente meno chiara nei report di quanto sia realmente sul firewall.

Per un troubleshooting più approfondito, sono rilevanti anche i file di log. L’assegnazione è disponibile in Sophos Firewall Troubleshooting: Servizi e Log.

Avvisi istantanei e reportistica

Se determinate categorie non solo devono essere bloccate, ma segnalate attivamente, gli avvisi istantanei possono essere utili. Questo è particolarmente utile nelle scuole, in ambienti strettamente regolamentati o in aree con una chiara politica di utilizzo di Internet.

I tre modi di valutazione rispondono a domande diverse:

• Email rapida per poche categorie web sensibili: Avvisi istantanei.
• Report ricorrenti, tendenze e valutazioni per utente o categoria: Central Firewall Reporting.
• Conservazione a lungo termine, correlazione con altri sistemi o processi SOC: Syslog o SIEM.

Prima degli avvisi istantanei, dovrebbe essere chiaro chi riceve la notifica, quali categorie richiedono davvero una reazione, come vengono gestiti i falsi positivi e quando viene verificata la selezione delle categorie. Una lista di avvisi ampia senza proprietario genera rapidamente rumore email, ma non una maggiore sicurezza.

Per l’attivazione tecnica e il triage, consultare Utilizzare le categorie web e gli avvisi istantanei di Sophos Firewall. Per valutazioni a lungo termine, dovrebbero essere esaminati Central Firewall Reporting o Inviare Syslog a SIEM.

Gestire modifiche ed eccezioni in produzione

La protezione web cambia continuamente in produzione. Nuovi servizi SaaS vengono aggiunti, singoli domini vengono categorizzati erroneamente, i dipartimenti necessitano di accesso temporaneo e il comportamento del browser cambia. Senza un flusso chiaro, si creano rapidamente eccezioni ampie che nessuno può più spiegare in seguito.

Per ogni modifica, si dovrebbe almeno annotare:

• Chi necessita dell’accesso? previene eccezioni globali per pochi utenti.
• Quale dominio, categoria o tipo di file è coinvolto? separa chiaramente gruppo di URL, categoria web e tipo di file.
• È un’eccezione temporanea o permanente? impone una revisione invece di autorizzazioni ombra permanenti.
• Quale regola firewall e politica web sono coinvolte? previene modifiche alla regola sbagliata.
• Come viene testato? rende il successo dimostrabile nel Log Viewer.

Si è dimostrato efficace un piccolo flusso di cambiamento:

1. Registrare la richiesta con utente, URL, orario, motivo aziendale e screenshot o messaggio di errore.
2. Verificare nel Log Viewer quale regola firewall, politica web, categoria e azione sono state applicate.
3. Decidere se la categoria è fondamentalmente errata, se solo un singolo dominio deve essere autorizzato o se la richiesta viene respinta.
4. Se è necessaria un’eccezione, lavorare il più strettamente possibile: singolo gruppo di URL invece di intera categoria, singolo gruppo di utenti invece di intera LAN.
5. Verificare la modifica in una regola di test o gruppo pilota.
6. Dopo il salvataggio, eseguire un test reale e documentare Log Viewer, categoria, ID regola e contesto utente.
7. Impostare una data di revisione, specialmente per eccezioni aziendali temporanee.

Le eccezioni temporanee dovrebbero essere chiaramente denominate, ad esempio TMP_ALLOW_vendor-portal_until_2026-07-31. Anche le eccezioni aziendali permanenti necessitano di un proprietario. Se nessuno è responsabile di un’eccezione, non dovrebbe rimanere permanentemente nella politica.

Se molti singoli domini per lo stesso servizio emergono, spesso non è la politica web il problema, ma l’architettura del servizio. In tal caso, si dovrebbe verificare se una regola firewall separata, una politica web separata, un gruppo di URL ben gestito o un altro punto di controllo sono più adatti. Per liste IOC o di blocco dinamiche, le eccezioni delle politiche web sono spesso il luogo sbagliato; in tal caso, sono più adatti Sophos Firewall Threat Feeds.

Rollback e autorizzazione di emergenza

Una modifica alla politica web può influenzare immediatamente il lavoro produttivo. Pertanto, prima di apportare modifiche significative, si dovrebbe stabilire come ripristinare lo stato precedente.

Opzioni pratiche di rollback:

• duplicare o documentare la politica web interessata prima della modifica
• testare la modifica prima in una regola pilota o in un piccolo gruppo di utenti
• non eliminare immediatamente la vecchia regola firewall o la vecchia politica web
• definire una finestra temporale, utenti di test e criterio di fallback
• dopo il salvataggio, verificare Log Viewer, ID regola e decisione di categoria

Per blocchi acuti, non si dovrebbe inserire automaticamente una regola di consentito ampia in alto. Meglio è un’eccezione stretta e temporanea con un chiaro gruppo di URL, gruppo di utenti e data di revisione. Se la pressione è alta, un’eccezione temporanea può stabilizzare l’operazione, ma deve essere rivalutata successivamente.

Errori tipici

La politica web non si applica

Spesso la politica non è attivata nella regola firewall corretta, la regola non viene colpita, una regola più in alto consente il traffico o il contesto utente non è corretto. Prima verificare Log Viewer e ID regola.

HTTPS non viene bloccato come previsto

Senza ispezione TLS, il firewall vede meno dettagli. A seconda della destinazione, una decisione di dominio o categoria può funzionare, mentre la verifica dei contenuti, i tipi di file o determinate funzioni di ricerca rimangono limitate.

Se la connessione non viene decrittata, il firewall può comunque usare informazioni SNI o di dominio per decisioni di policy. Pagine di blocco, pagine di avviso, tipi di file, Content Filters, scansione malware e analisi Zero-Day richiedono però maggiore visibilità. Nel Log Viewer si dovrebbe quindi controllare non solo l’azione della politica web, ma anche lo stato SSL/TLS Inspection.

QUIC aggira l’aspettativa

Se i browser utilizzano UDP 443, il traffico può essere elaborato diversamente rispetto all’HTTPS classico su TCP. Nelle regole client, si dovrebbe decidere consapevolmente se bloccare QUIC.

La regola di consentito è troppo in alto

Una regola di consentito ampia all’inizio della politica web può annullare le regole di blocco successive. L’ordine delle regole all’interno della politica web è importante quanto l’ordine delle regole nella lista delle regole firewall.

Troppe eccezioni

Le eccezioni risolvono rapidamente un problema singolo, ma possono ridurre l’efficacia della protezione. Ogni eccezione necessita di uno scopo, un proprietario e una data di revisione. Se emergono molte eccezioni, spesso la struttura della politica è errata o un’applicazione aziendale necessita di una regola propria.

Sono particolarmente rischiose le Web Exceptions che saltano Policy checks o Malware and content scanning. Se disturba solo HTTPS decryption, una SSL/TLS Exclusion è di solito più stretta e più comprensibile.

La reportistica non mostra nulla

In tal caso, si devono verificare registrazione, reportistica, regola firewall, selezione della politica o inoltro dei log. Una politica senza registrazione è difficile da valutare in produzione.

Lista di controllo operativa

• Stato della licenza di protezione web verificato.
• Traffico client, server, ospiti e VPN valutato separatamente.
• Politica web creata con nome significativo.
• Categorie critiche e gruppi di URL pianificati consapevolmente.
• Ordine delle regole all’interno della politica web verificato.
• Politica web attivata nella regola firewall appropriata.
• Log firewall traffic, logging della politica web e Reporting attivi.
• Regole della politica web attivate e nell’ordine corretto.
• Ispezione TLS e certificato CA verificati per il gruppo pilota.
• Strategia QUIC definita.
• Web Exceptions e TLS Exclusions documentate separatamente.
• Tester di politica e test reali eseguiti.
• Log Viewer e reportistica controllati.
• Processo di modifica per eccezioni di politica web definito.
• Eccezioni temporanee con data di scadenza impostata.
• Eccezioni documentate con proprietario e data di revisione.

FAQ