Creare e testare in sicurezza le Web Exceptions di Sophos Firewall

Una Web Exception si crea rapidamente, ma il suo effetto può essere molto più ampio del previsto. A seconda della selezione, Sophos Firewall non ignora soltanto la decrittazione HTTPS, ma anche la convalida dei certificati, la scansione di malware e contenuti, l’analisi Zero-Day o tutti i controlli della Web Policy.

La sequenza sicura consiste quindi nell’individuare prima il flusso interessato e il controllo che causa realmente il problema, poi restringere il match e solo a quel punto attivare l’eccezione minima necessaria. Un test positivo da solo non basta. Nel test negativo, una destinazione simile non esclusa deve continuare a essere controllata normalmente.

Questa guida si riferisce a SFOS 22.0. Le etichette WebAdmin restano volutamente in inglese, così da poterle individuare direttamente nell’interfaccia.

Web Exception in sette passaggi

1. Documentare client interessato, host di destinazione, percorso URL, protocollo e orario.
2. Verificare se viene usato DPI Mode o Web Proxy Mode e quali firewall rule e Web Policy si applicano realmente.
3. Stabilire se il problema riguarda solo la decrittazione TLS o uno specifico controllo di Web Protection.
4. In Web > Exceptions > Add an exception, definire criteri URL, categoria, sorgente o destinazione ristretti.
5. In Skip the selected checks or actions, selezionare solo l’opzione minima necessaria.
6. Attivare l’eccezione e ripetere il test dello stesso flusso con un nuovo processo del browser o dell’applicazione.
7. Eseguire un test negativo verso una destinazione simile non esclusa e documentare match, effetto, responsabile e data di revisione.

⚠️ HTTPS decryption non è un’opzione di compatibilità innocua. Per il traffico corrispondente vengono meno anche i controlli dipendenti e il firewall consente certificati server non validi. Malware and content scanning ignora automaticamente anche l’analisi Zero-Day. Un’eccezione ampia non deve quindi essere il primo passaggio di troubleshooting.

Verificare i prerequisiti del prodotto prima di scegliere un’eccezione

Per alcuni prodotti gestiti, l’autorizzazione di porte e domini è un prerequisito della funzione interessata. Prima di scegliere una regola firewall, una TLS Exclusion o una Web Exception, definire con il responsabile del prodotto funzione, versione e percorso di connessione effettivo. Annotare nel ticket di modifica destinazioni, porte, protocolli, direzioni ed esclusioni dall’ispezione esplicitamente richieste, senza concedere un’autorizzazione generale a tutti i prodotti Sophos.

• Wireless: La verifica preliminare Wireless separa rete di gestione, DNS, servizio orario e destinazioni regionali dalla successiva configurazione Wi-Fi.
• ZTNA: Nella guida al gateway ZTNA, identificare prima la distribuzione locale o cloud; direzioni delle connessioni e requisiti d’ispezione non sono intercambiabili.
• Registrazione degli switch: La guida all’onboarding degli switch tratta DNS, destinazioni di registrazione e verifiche del percorso proxy/TLS.
• Endpoint, XDR e MDR: I requisiti di rete e proxy distinguono piattaforme, funzioni con licenza e destinazioni specifiche dell’installazione. Un elenco di domini consentiti non è un elenco generale di esclusioni dalla decrittazione.
• NDR e appliance di integrazione: La pianificazione dell’appliance tratta i requisiti di porte e domini in uscita; la guida operativa aiuta a verificare separatamente le funzioni NDR e Log Collector effettivamente ospitate.

La guida interna è un punto di partenza; prima della modifica, il responsabile del prodotto deve confermare i requisiti autorevoli per la distribuzione specifica. Raggiungibilità di rete e bypass dell’ispezione restano decisioni distinte. Se mancano requisiti verificati o le fonti si contraddicono, non ampliare l’eccezione per tentativi: conservare le evidenze e chiarire con i responsabili del prodotto e del firewall. Restano poi validi il progetto pilota, i test positivi e negativi, la revisione e il rollback descritti in questa guida.

Scegliere Web Exception o TLS Exclusion

Entrambi gli strumenti possono impedire la decrittazione del traffico HTTPS, ma non risolvono lo stesso problema.

Una SSL/TLS inspection rule con Action: Don’t decrypt è adatta quando in DPI Mode si deve escludere soltanto la decrittazione per destinazioni chiaramente definite. Un URL Group nella Local TLS exclusion list è particolarmente efficiente, perché il firewall confronta come testo il Server Name Indication, o SNI.

Creare e usare in sicurezza gli URL Groups mostra come creare un elenco di domini di questo tipo, inserirlo in una regola Don't decrypt e verificarlo con una destinazione negativa.

Una Web Exception è adatta quando, in aggiunta o in alternativa, deve essere ignorato un controllo di Web Protection:

• HTTPS decryption
• HTTPS certificate validation
• Malware and content scanning
• Zero-day protection
• Policy checks

In DPI Mode, una Web Exception si applica solo se per il flusso è attiva almeno una Web Policy, Malware and content scanning o ATP. In Web Proxy Mode, la Web Exception appartiene direttamente al percorso di Web Protection basato sul proxy.

La SSL/TLS exclusion list usa nomi di dominio in chiaro e include i relativi sottodomini, anziché usare espressioni regolari. Le esclusioni SSL/TLS possono ignorare i requisiti relativi a certificati e protocolli oltre alla decrittazione. Non equivalgono quindi a una Web Exception limitata a HTTPS certificate validation. I domini confermati possono essere aggiunti alla Local TLS exclusion list da Control Center o Log Viewer; in alternativa, si modifica il URL Group in Web > URL groups o la SSL/TLS inspection rule. Anche le categorie web possono essere criteri di una SSL/TLS inspection rule.

Anche il traffico coperto è diverso: in DPI Mode le Web Exceptions si applicano alle connessioni SSL/TLS su qualsiasi porta; in Web Proxy Mode a SSL/TLS sulla porta 443. Le SSL/TLS Exclusion Rules si applicano solo in DPI Mode, ma anche in questo caso indipendentemente dalla porta. Oltre agli URL Groups, possono utilizzare come criteri zone, reti, indirizzi IP, servizi, utenti e gruppi. Le Web Exceptions offrono pattern URL, Web categories e indirizzi o intervalli IP sorgente e di destinazione.

Una Web Exception attiva può ignorare i controlli di protezione selezionati per i flussi web corrispondenti; questo non garantisce che qualsiasi blocco di sistema possa essere rimosso. Il suo ambito non può quindi essere protetto collocando una regola di Web Policy più avanti nell’ordine. Sono decisivi i criteri dell’eccezione; l’ordine delle regole firewall, Web e SSL/TLS va comunque controllato separatamente, perché determina quale percorso di protezione elabora inizialmente il flusso.

Limite documentato e conflitto irrisolto: Sophos descrive generalmente le eccezioni come indipendenti da policy e regole. La guida alle categorie di SFOS 22.0 e 23.0, però, indica esplicitamente highly objectionable criminal activity come sempre bloccata: nessuna policy o eccezione può consentire queste pagine, e i nomi di dominio sono intenzionalmente nascosti in log e report. Queste affermazioni divergenti non dimostrano un bypass funzionante. La procedura sicura resta non aggirare il blocco e, se necessario, chiarire il conflitto con Sophos Support. Per i test usare solo destinazioni innocue e approvate, mai contenuti vietati.

La configurazione pianificata di DPI o Web Proxy, Decryption Rules e distribuzione della CA è descritta in Introdurre correttamente TLS Inspection. La logica di filtro è spiegata in Configurare Web Protection con Web Policies.

Pianificare un match ristretto e tracciabile

Un’eccezione non deve iniziare con un dominio qualsiasi del vendor. Prima si registra la richiesta concreta nel browser, nel Log Viewer o nei log dell’applicazione. Poi si decide se hostname, percorso, categoria, IP sorgente o IP di destinazione rappresenta il criterio più stabile.

AND tra tipi, OR all’interno di un tipo

Sophos Firewall collega i diversi tipi di criteri con AND. Se, ad esempio, sono specificati pattern URL e Source IP addresses, entrambi i tipi devono corrispondere.

Più valori dello stesso tipo vengono valutati con OR. Con due pattern URL può quindi bastare uno dei due. Con due Source IP addresses può bastare una delle due sorgenti.

Questa logica è importante nel troubleshooting. Un’eccezione può sembrare corretta e non applicarsi perché un tipo di criterio aggiuntivo non corrisponde al flusso reale.

Ancorare in sicurezza l’espressione regolare

In URL pattern matches sono consentite espressioni regolari. Un pattern semplice come vendor.example non è adatto. Il testo può corrispondere anche in una posizione inattesa dell’URL ed escludere troppe richieste.

Per il dominio di esempio riservato updates.vendor.example, un pattern host volutamente ancorato può essere:

^([A-Za-z0-9.-]*\.)?updates\.vendor\.example/

Il valore è solo un esempio. vendor.example è un dominio riservato alla documentazione e viene sostituito con il vero host di destinazione confermato nel log o nella richiesta. Il prefisso opzionale consente i sottodomini. Se si deve escludere un solo host esatto, non viene usato un wildcard di sottodominio non necessario.

I caratteri non ASCII vengono indicati nel pattern come Punycode. Dopo ogni modifica della regex, il test include un match atteso e almeno un non-match volutamente simile.

Verificare punti, limite dell’host e corrispondenze indesiderate nel percorso

In una regex, un punto senza escape rappresenta un carattere qualsiasi. I punti di un nome host fisso si scrivono quindi come \.. Il ^ ancora il match all’inizio; il / finale delimita l’host rispetto a nomi con un inizio simile, come updates.vendor.example.attacker.example. Sophos Firewall accetta / e \/. Per un singolo host esatto, il pattern più ristretto è:

^updates\.vendor\.example/

Gli esempi si riferiscono alla rappresentazione host/URL a cui vengono applicati questi pattern Sophos, senza https:// iniziale. Lo strumento di test deve usare la stessa rappresentazione. Se le porte o la rappresentazione sono diverse, non aggiungere .* per tentativi: chiarire il valore effettivamente valutato e il percorso di protezione. Resta valido il limite HTTPS della sezione seguente.

Per il pattern dell’host esatto valgono i risultati attesi seguenti. Con il pattern esistente che ammette un sottodominio opzionale, anche cdn.updates.vendor.example/file è un match desiderato; gli altri casi negativi continuano a non corrispondere.

Gli ultimi due casi sono particolarmente importanti: il confronto può riguardare l’intero URL, inclusi percorso e query. Un testo di dominio non ancorato può quindi attivare l’eccezione su un altro host. Il test verifica soltanto il matching; l’effettiva omissione dei controlli di protezione viene verificata successivamente con una nuova richiesta e i log.

Testare localmente stringhe lunghe che non devono corrispondere

Molti pattern non ancorati possono richiedere ulteriore lavoro di ricerca, soprattutto quando la decrittazione HTTPS rende disponibile il testo completo dell’URL. Da questo non si può dedurre un numero universale di passi o un tempo di esecuzione sempre costante, lineare o esponenziale per qualsiasi pattern. L’ancoraggio non sostituisce nemmeno la verifica dei quantificatori complessi. Non usare un wildcard generico .* per i nomi host.

Un test di 1000 caratteri integra i casi brevi. Su un computer locale di amministrazione con Python 3, questo esempio genera un testo URL interamente fittizio con un percorso lungo e il dominio di destinazione solo nella query. Verifica entrambi i pattern mostrati qui senza contattare un firewall:

import re
from time import perf_counter

prefix = "other.example/"
suffix = "?next=updates.vendor.example/file"
value = prefix + "a" * (1000 - len(prefix) - len(suffix)) + suffix
assert len(value) == 1000
patterns = [
    r"^updates\.vendor\.example/",
    r"^([A-Za-z0-9.-]*\.)?updates\.vendor\.example/",
]
for pattern in patterns:
    regex = re.compile(pattern)
    start = perf_counter()
    for _ in range(100):
        assert regex.search(value) is None
    print(pattern, "Nicht-Treffer, Sekunden:", perf_counter() - start)

Sono attesi due risultati senza match. Altri casi sintetici dovrebbero includere nomi host lunghi quasi corrispondenti e percorsi lunghi; confrontare i pattern prima e dopo con gli stessi input. Per pattern complessi sospetti, usare uno strumento locale con un limite di tempo e interrompere un test bloccato. I tempi di Python e i contatori di passi di altri motori regex non sono misurazioni SFOS né promesse di prestazioni. Non copiare URL di produzione, token, nomi utente o dati dei clienti in siti esterni per test regex; per queste prove bastano dati fittizi.

Distinguere hostname e percorso URL

Le eccezioni per HTTPS decryption e HTTPS certificate validation possono valutare l’hostname dal contesto TLS. Un pattern che punta soltanto a un percorso URL, invece, funziona per HTTPS solo se la connessione è già decrittata. Con HTTP non cifrato, il percorso URL è visibile senza decrittazione TLS.

Questo stabilisce un limite importante: un’eccezione non può disattivare la decrittazione e poi usare in modo affidabile come criterio una parte visibile solo nel percorso HTTP cifrato. In questo caso serve un ambito basato sull’host o un altro design.

Creare la Web Exception

L’esempio esclude dalla decrittazione HTTPS un singolo client pilota per un host vendor confermato. Non è una regola di eccezione universale.

1. Aprire Web > Exceptions.
2. Selezionare Add an exception.
3. Impostare un nome descrittivo, ad esempio Vendor API no decrypt.
4. Attivare URL pattern matches.
5. Inserire il pattern testato e ancorato in Search/Add e confermarlo con Add.
6. Per il pilota, attivare anche Source IP addresses, inserire l’IP specifico del client e confermarlo con Add.
7. In Skip the selected checks or actions, selezionare esclusivamente HTTPS decryption.
8. Selezionare Save.
9. Nell’elenco, attivare l’interruttore della nuova eccezione.
10. Ricontrollare nome, Matching URLs, sorgenti e controllo ignorato.

Nell’esempio l’IP sorgente è impostato volutamente. Senza di esso, l’eccezione si applicherebbe subito a tutti i client la cui richiesta corrisponde al pattern URL. Dopo un pilota riuscito, l’ambito può essere esteso in modo controllato alle sorgenti che ne hanno realmente bisogno.

Per una pura TLS Exclusion su molte destinazioni, un URL Group in una regola Don't decrypt è generalmente più facile da mantenere ed efficiente. Molti FQDN Host Objects nella sorgente o destinazione di una SSL/TLS inspection rule sono sfavorevoli, perché possono causare numerose query DNS per le nuove connessioni TLS.

Preparare una nuova eccezione per un host in Config Studio

Config Studio può creare una nuova Web Exception a partire da un nome di dominio senza prima importare un’eccezione esistente. È una procedura distinta; Bad regex e Apply Fix servono invece a riparare le voci esistenti, come descritto più avanti. La nuova eccezione viene inizialmente preparata solo in locale e applicata al firewall soltanto mediante l’importazione TAR.

Prima di iniziare, conservare in una posizione protetta un backup completo del firewall e un’esportazione selettiva invariata di WebFilterException dello stesso firewall. La sezione Esportare WebFilterException e verificarlo con Config Studio descrive l’esportazione di Entities.xml, la gestione dei file e il successivo download. Annotare nel ticket di modifica un nome non ancora utilizzato, l’host di destinazione confermato, l’opzione di esclusione necessaria e l’ambito di client previsto. Un nome esistente non è un modo sicuro per aggiungere un’altra voce: l’importazione aggiorna le eccezioni esistenti corrispondenti. Un nome modificato crea invece una nuova voce senza eliminare quella precedente.

1. Aprire Config Studio tramite il collegamento di accesso più avanti, selezionare Configuration editor e passare a Rules > Web exceptions.
2. Selezionare Add e inserire il nuovo nome univoco, ad esempio Vendor API exact host no decrypt.
3. In Skip these checks, attivare soltanto l’opzione necessaria per il caso specifico. Per l’esempio di decrittazione è Skip HTTPS decryption. Le altre opzioni si chiamano Skip policy check, Skip cert validation, Skip malware scan e Skip zero-day protection. Le conseguenze sulla protezione descritte sopra valgono anche per la creazione nell’editor; non selezionare più opzioni per precauzione.
4. In Match by URL/Domain, scegliere l’ambito: Exact host only per il solo host confermato oppure Domain + all subdomains se tutti i suoi sottodomini sono esplicitamente necessari e approvati. Per updates.vendor.example, nell’esempio resta selezionato Exact host only; cdn.updates.vendor.example non deve essere incluso.
5. Inserire il nome di dominio confermato nel campo di testo, senza percorso URL, ad esempio updates.vendor.example. Sostituire questo valore di documentazione con l’host di destinazione reale. La regex generata e l’anteprima compaiono automaticamente; verificare entrambe rispetto all’ambito previsto e ai casi positivi e negativi descritti sopra.
6. Selezionare Add to URL Regex list. Il pattern deve quindi comparire in URL Regex Patterns. Un valore visibile nell’anteprima non è ancora una voce aggiunta alla lista.
7. Facoltativamente, in URL Regex Patterns, usare + Add URL regex per aggiungere direttamente un proprio pattern già verificato. Non è necessario per la creazione a partire da un dominio; i pattern aggiuntivi ampliano le possibili corrispondenze a causa di OR.
8. Infine, selezionare Add in fondo al modulo laterale. Solo così la nuova eccezione viene creata nell’editor.

Prima del download, confrontare in Preview l’XML di importazione con lo stato precedente salvato e il ticket di modifica. Deve essere aggiunta soltanto la nuova eccezione approvata; nomi, criteri, stati di attivazione e opzioni di esclusione esistenti non devono cambiare involontariamente. Anche l’ambito di client deve essere corretto: Exact host only limita la destinazione, non le origini. Se non è dimostrabile che la configurazione generata contenga un’origine pilota necessaria, non importarla; usare invece la procedura WebAdmin descritta sopra con Source IP addresses. Non aggiungere all’XML campi supplementari non verificati.

Selezionare quindi Download > Download TAR e conservare l’archivio in una posizione protetta. La sezione Importare, verificare l’effetto e ripristinare copre i messaggi di importazione, il confronto prima/dopo in Web > Exceptions, il controllo dell’attivazione e le nuove connessioni con test positivi e negativi. L’anteprima XML o un’importazione riuscita non sostituiscono questo test dell’effetto sulla protezione. In caso di risultato inatteso, disattivare la nuova voce in modo controllato e verificare nuovamente il normale percorso di protezione. Reimportare l’esportazione selettiva originale non elimina automaticamente l’eccezione appena creata; rimuoverla in modo mirato solo dopo aver chiarito le dipendenze. Le eccezioni esistenti devono rimanere intatte.

Escludere una categoria anziché un singolo dominio

Se i dati finanziari riservati non devono essere decrittati, la categoria Financial services può essere il criterio appropriato. Un’eccezione di categoria comprende però più destinazioni di un singolo host; la classificazione deve corrispondere all’ambito previsto.

1. In Web > Exceptions > Add an exception, inserire un nome come Financial services no decrypt.
2. Attivare Web site categories, selezionare Add new item e scegliere Financial services.
3. Confermare con Apply selected items. Per il pilota, impostare anche Source IP addresses con l’IP del client e Add.
4. Selezionare solo HTTPS decryption, scegliere Save e attivare l’interruttore nell’elenco.
5. Testare un servizio finanziario approvato e una destinazione innocua esterna alla categoria con nuove connessioni. Per la logica AND, devono corrispondere sia la sorgente pilota sia la categoria.

Le connessioni HTTPS corrispondenti perdono la decrittazione e i controlli del contenuto che ne dipendono; vale anche la conseguenza sui certificati descritta sopra. Questo non autorizza l’intera categoria né significa che tutte le altre funzioni di protezione vengano disattivate.

Eccezione malware per un host di download confermato

Un fornitore valutato a basso rischio non è, da solo, un motivo per disattivare la scansione. Se occorre un’eccezione giustificata, utilizzare la procedura sopra con un nome distinto, come Vendor download scan exception, il pattern dell’host confermato e la sorgente pilota. Selezionare Malware and content scanning anziché HTTPS decryption. Zero-day protection viene selezionato automaticamente; anche le vecchie eccezioni che ignorano la scansione malware ignorano l’analisi Zero-Day. Quindi scegliere Save e attivare l’interruttore. Per i download corrispondenti vengono meno la scansione malware e dei contenuti e l’analisi Zero-Day, inclusi i relativi report. Non deselezionare anche gli altri controlli. Verificare il percorso di protezione previsto con un download innocuo e controllato dall’host approvato e una destinazione di confronto non esclusa; un download riuscito da solo non basta.

Inserire altri criteri e gestire le eccezioni esistenti

Compilare Destination IP addresses con l’IP confermato del sito web e premere Add, non con l’IP del client. Nelle combinazioni consentite del criterio di destinazione con URL o categoria, tutti i tipi selezionati devono corrispondere. I pattern URL usano caratteri ASCII; i nomi di dominio internazionalizzati sono scritti in Punycode. Matching URLs nell’eccezione predefinita Apple Update può servire come esempio di sintassi, non come modello di autorizzazione non verificato.

Esclusione TLS: indicazioni contrastanti sull’ambito. Le pagine Add an exception di SFOS 22.0 e 23.0 descrivono la logica generale AND tra tipi di criteri, ma Exclude a website from TLS inspection afferma esplicitamente che le eccezioni di sorgente e destinazione non possono essere combinate. L’ambito esatto della restrizione non è chiaro; la logica generale di corrispondenza non dimostra che la combinazione sia consentita. Combinare Source IP addresses e Destination IP addresses non è quindi una procedura di cui sia stata verificata l’ammissibilità. Prima di attivare un’esclusione TLS, confermare la build effettiva di SFOS, il percorso DPI/proxy, il controllo da escludere e l’ambito ristretto di host/categoria. Mantenere l’approccio precedente con sorgente pilota e nome host o categoria confermati, senza aggiungere un criterio di IP di destinazione. Destinazione più nome host/categoria confermati è un’opzione separata solo se l’ambito dei client è limitato in modo indipendente e approvato. Non sostituire la restrizione prevista con un’eccezione basata solo sulla sorgente né rimuovere un criterio semplicemente per ottenere una corrispondenza: ciò amplia l’esclusione delle protezioni. Se sono necessarie restrizioni sia dell’IP sorgente sia dell’IP di destinazione, fermarsi senza attivare o ampliare l’esclusione e ottenere da Sophos Support un chiarimento per la build specifica insieme al responsabile del firewall.

Le eccezioni predefinite supportano gli aggiornamenti software e altre funzioni importanti dei siti web. In Web > Exceptions, Edit apre un’eccezione esistente e Clone ne crea una copia. Verificare tutti i criteri e le opzioni ereditati prima di attivarla. Web > General settings gestisce la convalida generale dei certificati HTTPS; un’eccezione di certificato individuale non sostituisce questa impostazione di base.

Comprendere l’effetto delle opzioni di esclusione

Prima di salvare deve essere chiaro quale protezione viene persa.

HTTPS decryption

Il firewall non decritta il traffico HTTPS corrispondente. Di conseguenza, non può eseguire neppure i controlli che richiedono il contenuto decrittato. Sophos documenta inoltre che, per questo match, viene consentito il traffico con un certificato server non valido.

Se il problema riguarda soltanto una particolarità del certificato, questa opzione è spesso troppo ampia. Prima si verifica se HTTPS certificate validation rappresenta l’eccezione più precisa.

HTTPS certificate validation

Il firewall ignora il controllo di validità del certificato server. La decrittazione configurata può continuare. Questa eccezione è adatta solo a una destinazione nota con un problema di certificato accettato consapevolmente e richiede una data di revisione ravvicinata.

Un certificato scaduto, con nome errato o non attendibile dovrebbe essere corretto sul sistema di destinazione, se possibile. La distribuzione della corretta Inspection CA risolve un altro problema ed è descritta in Distribuire il certificato CA per TLS Inspection.

Malware and content scanning

Il firewall ignora la scansione di malware e contenuti per il match. In questo modo viene automaticamente ignorato anche Zero-day protection. Una singola selezione rimuove quindi due livelli di protezione dal percorso dati.

Prima di questa eccezione si controllano tipo di file, limite di scansione, cifratura, azione in caso di errore e download che corrisponde realmente. La procedura completa è in Configurare e testare la scansione malware.

Zero-day protection

L’analisi Zero-Day viene ignorata. Non vengono creati report di analisi per i file corrispondenti, anche se la scansione malware classica segnala un rilevamento. Questa opzione è più limitata rispetto a ignorare completamente Malware and content scanning.

Policy checks

I controlli della Web Policy vengono ignorati per la richiesta corrispondente. Un’eccezione di questo tipo può rendere inefficaci categorie, logica di utenti o gruppi e altre decisioni di policy. Deve essere usata soltanto per un problema di policy chiaramente dimostrato, non come soluzione generica per un sito web bloccato.

Questo non autorizza a usare Policy checks per rimuovere il blocco assoluto documentato di highly objectionable criminal activity descritto sopra.

Verificare l’effetto con test positivi e negativi

Il caricamento riuscito di una pagina dimostra soltanto che qualcosa è cambiato. Non dimostra ancora che l’eccezione sia precisa.

1. Registrare orario, client pilota, host di destinazione ed effetto previsto.
2. Chiudere la sessione esistente del browser o dell’applicazione e creare una nuova connessione.
3. Ripetere la richiesta interessata.
4. Nel Log Viewer, confrontare IP sorgente, host di destinazione, Web Policy, Firewall Rule ID e Action.
5. Per un’eccezione di decrittazione, confrontare il certificato server visibile al client con lo stato precedente alla modifica.
6. Aprire una destinazione simile che non è stata esclusa.
7. Verificare che tale destinazione continui a essere coperta da Web Policy, Decryption Rule e catena di scansione normali.
8. Disattivare brevemente l’eccezione e riprodurre l’errore originale, se è sicuro farlo nella finestra di manutenzione.
9. Riattivare l’eccezione e confermare nuovamente il risultato.

Se QUIC o HTTP/3 evita il percorso TLS su TCP previsto, il test può essere fuorviante. La distinzione è descritta in Bloccare correttamente QUIC e HTTP/3. Log Viewer, Policy Tester e Packet Capture mostrano quale regola e quale policy corrispondono realmente.

Il Policy tester si apre in Diagnostics > Tools, nella sezione Pop-out tools. Il metodo Firewall, SSL/TLS, and web aiuta a individuare firewall rule, SSL/TLS inspection rule e Web Policy previste. Tuttavia verifica il traffico web solo in Transparent Mode e non rappresenta quindi un flusso direct web proxy esplicito. L’effettiva applicazione della Web Exception va sempre confermata con una nuova richiesta e log reali.

Per avere una prova nei log, Log firewall traffic deve essere attivo nella firewall rule; va attivato anche Log connections nella SSL/TLS inspection rule. In System services > Log settings, i tipi di log pertinenti devono essere attivi per Local reporting. Quindi si limita Log Viewer all’orario del test e all’IP sorgente e si confrontano i moduli Web filter e SSL/TLS inspection con Firewall Rule ID, policy e Action. Usare correttamente Sophos Firewall Log Viewer spiega i controlli. Se l’intera vista resta vuota, si segue Log Viewer non si aggiorna invece di ampliare l’eccezione sulla base di un sospetto.

Delimitare sistematicamente gli errori

L’eccezione non si applica

• Il blocco assoluto documentato di una categoria non è un errore di corrispondenza. Un dominio intenzionalmente nascosto non è, in questo caso, un difetto di logging. Le categorie web e le Web Policies spiegano il limite; non tentare un’eccezione più ampia o test su questi contenuti.
• L’interruttore in Web > Exceptions non è attivo.
• Un tipo di criterio aggiuntivo non corrisponde a causa della logica AND.
• La regex non è ancorata all’inizio o non rappresenta l’hostname reale.
• Per un’eccezione di percorso HTTPS il traffico non viene decrittato, quindi il percorso non è visibile.
• In DPI Mode non è attiva per il flusso né una Web Policy, né Malware and content scanning, né ATP.
• Si applica una firewall rule, Web Policy o modalità operativa diversa da quella prevista.
• La sessione esistente del browser o dell’applicazione non è stata ricreata.

L’eccezione si applica in modo troppo ampio

• Il pattern contiene un wildcard non controllato o soltanto il testo nudo di un root domain.
• Mancano Source IP addresses o un altro ambito pilota.
• Più pattern URL dello stesso tipo hanno un effetto più ampio del previsto a causa di OR.
• È stata esclusa un’intera Web category invece dell’host specifico.
• Sono state attivate più opzioni di esclusione anche se il problema riguarda un solo controllo.

Il sito funziona, ma l’effetto sulla protezione non è chiaro

L’eccezione non viene ulteriormente estesa. Prima si confrontano certificato del browser, log Web e SSL/TLS Inspection, Firewall Rule ID, Web Policy e un download controllato. Senza queste prove, l’eccezione è soltanto un workaround funzionale, non ancora una decisione di sicurezza accettata.

Se gli strumenti WebAdmin non isolano la causa, Associare correttamente i service log di Sophos Firewall collega i log DPI, proxy, malware e Zero-Day al percorso di protezione interessato. Il debug non viene attivato come primo passaggio.

CPU elevata e accessi web lenti dopo modifiche alle regex

In Diagnostics > System graphs, confrontare prima gli orari e l’andamento del carico con le richieste lente e le ultime modifiche alle eccezioni. In Web > Exceptions, verificare Selection criteria o Matching URLs di tutte le eccezioni attive: mancano ^, punti dell’host con escape o un limite chiaro dell’host? Sono presenti wildcard ampi o molti testi di dominio non ancorati?

Con accesso autorizzato alla console, eseguire il seguente comando di sola lettura in Device Management > Advanced Shell. Mostra il carico attuale dei processi senza modificare la configurazione; uscire dalla vista con q.

top

Se awarrenhttp o snort sono in cima all’utilizzo CPU, le regex delle Web Exceptions possono contribuire al carico. È un indizio, non la prova di un’unica causa: entrambi i processi eseguono altri controlli. Esaminare insieme carico, richieste e pattern, effettuare solo una modifica limitata e misurare di nuovo con un carico di traffico comparabile. Se la CPU resta elevata, continuare a isolare le altre cause nel percorso di protezione interessato; non disattivare indiscriminatamente l’ispezione o tutte le eccezioni per fare una prova comparativa.

Riparare selettivamente le regex esistenti

Per poche eccezioni, Web > Exceptions > Edit è il percorso più chiaro. Conservare prima nomi, stato di attivazione, criteri e opzioni di esclusione; poi correggere solo il pattern URL verificato. Per molte voci si può invece esportare il modulo WebFilterException. L’esportazione comprende le configurazioni delle Web Exceptions selezionate, non automaticamente solo l’eccezione difettosa. Anche le voci invariate devono essere conservate nel confronto prima/dopo.

Prima di entrambe le varianti di importazione, conservare in sicurezza un backup aggiornato del firewall e un’esportazione selettiva non modificata. Definire rollback, finestra di manutenzione e accesso amministrativo prima di importare. Un’esportazione selettiva non sostituisce un backup completo. Conservare separatamente file originale, copia di lavoro e risultato approvato; configurazioni e report generati contengono dettagli interni e devono trovarsi solo su un computer di amministrazione autorizzato e con accesso protetto.

Esportare WebFilterException e verificarlo con Config Studio

1. Sullo stesso firewall, aprire Backup & firmware > Import export e scegliere Export selective configuration.
2. Cercare WebFilterException tramite Add new item e confermare con Apply selected items. Non selezionare Include dependent entity: non si devono modificare contemporaneamente altre aree di configurazione.
3. Salvare l’archivio API-[timestamp].tar con Export o Download. Estrarre una copia di lavoro; contiene Entities.xml.
4. Aprire Sophos Firewall Config Studio. Scegliere Configuration editor e Rules > Web exceptions, quindi caricare la Entities.xml selettiva tramite Import.
5. In Config Analysis, cercare Bad regex. Aprire la voce interessata con Edit, esaminare la proposta tramite Apply Fix e confermare con Update. Non cambiare i nomi; un nome modificato fa sì che l’importazione sul firewall crei una nuova eccezione invece di aggiornare quella esistente.
6. Verificare la proposta con i casi positivi, negativi e le stringhe lunghe senza match. Per i nuovi pattern host, Exact host only e Domain + all subdomains distinguono l’ambito desiderato; la riparazione non deve autorizzare sottodomini incidentalmente. Una correzione automatica non sostituisce questa decisione né il test dell’effetto sulla protezione.
7. In Preview, verificare la configurazione da importare e confrontarla con l’originale: devono cambiare solo le regex approvate, non nomi, sorgenti, criteri di destinazione, attivazione o opzioni di esclusione. Salvare l’archivio approvato tramite Download > Download TAR.

Config Studio elabora i dati di configurazione nel browser sul computer; parsing, analisi e generazione dei report non caricano questi dati all’esterno. File locali, download e report HTML restano comunque riservati. Non trasferire configurazioni ad altri strumenti di analisi online. Modificare o scaricare in Config Studio non cambia ancora nulla sul firewall.

Alternativa: modificare Entities.xml in modo controllato

Senza Config Studio, modificare la stessa copia di lavoro esportata selettivamente in un editor di testo. Cambiare solo i pattern URL interessati; non sostituire indiscriminatamente tutti i punti nel file XML. Struttura XML, nomi degli oggetti e altri campi restano invariati. Prima di creare l’archivio, verificare che l’XML sia ben formato e controllare il diff completo. Non importare se la sintassi è incerta o compaiono file aggiuntivi inattesi.

Mantenere esattamente il nome Entities.xml e inserire i file in un nuovo archivio TAR con la stessa struttura dell’originale, non in ZIP né all’interno di una cartella aggiuntiva. Se l’originale contiene altri file, non scartarli silenziosamente. Questa semplice procedura per Web Exceptions non deve essere applicata ad altri moduli o a oggetti sensibili e interdipendenti.

Importare, verificare l’effetto e ripristinare

L’importazione sovrascrive le impostazioni esistenti corrispondenti. Un archivio caricato correttamente non dimostra né un match ristretto né una protezione invariata. Approvare prima il diff e importare poi nella finestra di manutenzione concordata.

In Backup & firmware > Import export > Import, scegliere il .tar verificato con Browse ed eseguire Import. Controllare i messaggi di importazione per individuare errori; quindi, in Web > Exceptions, confrontare nomi e numero delle voci, stato di attivazione, Matching URLs, criteri e opzioni di esclusione con lo stato previsto. Le impostazioni senza una voce d’importazione corrispondente restano presenti; l’importazione non elimina automaticamente eventuali eccezioni aggiuntive indesiderate.

Creare poi nuove connessioni, ripetere i test positivi e negativi esistenti con i log e, in caso di riparazione delle prestazioni, confrontare andamento CPU e carico dei processi con la baseline. In caso di errori, interrompere il rollout e disattivare in modo controllato l’eccezione interessata, purché l’impatto sull’applicazione sia accettabile. Per un ripristino mirato si può importare l’esportazione selettiva non modificata dello stesso firewall; escludere prima eventuali modifiche intermedie, che altrimenti verrebbero sovrascritte. Non riattivare senza verifica uno stato precedente dimostratosi troppo ampio. Il ripristino di un backup completo resta una procedura di emergenza pianificata separatamente, non il primo passo indietro per una singola regex. Dopo ogni rollback, verificare nuovamente configurazione e percorso di protezione.

Pianificare WebFilterException tramite la XML API

L’importazione selettiva di Entities.xml descritta sopra non è una procedura generale per la XML API. I riferimenti degli oggetti per SFOS 22.0 e 23.0 descrivono Add Web Filter Exception / Update Web Filter Exception con l’oggetto WebFilterException. Le corrispondenze seguenti aiutano a verificare un’automazione pianificata; non costituiscono una richiesta completa e pronta per l’invio. Accesso, credenziali protette, operazione esplicita, struttura della richiesta specifica per la versione e valutazione sicura della risposta fanno parte della procedura centrale Usare la XML API in sicurezza. Senza una sintassi confermata per la build specifica, non si eseguono scritture.

Distinguere attivazione, flag di esclusione e DomainList

Enabled attiva l’eccezione e ammette on oppure off. Anche i cinque flag di esclusione ammettono on oppure off, ma indicano che un controllo viene ignorato, non attivato: HttpsDecrypt per la decrittazione HTTPS, VirusScan per la scansione malware, PolicyCheck per i controlli della Web Policy, ZeroDayProtection per la protezione Zero-Day e CertValidation per la convalida dei certificati HTTPS. Un flag di esclusione impostato su on significa quindi bypass della protezione. Restano valide le conseguenze sulla protezione spiegate sopra, in particolare il bypass automatico di Zero-Day quando viene ignorata la scansione malware. Non dedurre da un flag di esclusione impostato che una voce sia già attiva o corrisponda al traffico.

Il riferimento mostra, sotto DomainList, criteri ripetibili e interruttori separati a livello di oggetto:

• EnableSrcIP con SrcIp: controllo dell’IP sorgente; è qui che va indicato il client.
• EnableDstIP con DstIp: controllo dell’IP di destinazione; è qui che va indicato l’indirizzo del sito web.
• EnableURLRegex con URLRegex: controllo dei pattern URL, non un elenco di domini che include automaticamente i sottodomini.
• EnableWebCat con WebCategory: controllo della categoria web.

I quattro interruttori sono valori scalari yes/no, non on/off. I quattro criteri sono array di stringhe che ammettono più valori; per ogni voce di SrcIp e DstIp, il riferimento indica un massimo di 43 caratteri. Un array semplicemente compilato non sostituisce un interruttore di attivazione confermato. Secondo la logica di matching, i diversi tipi di criteri attivati devono corrispondere con AND, mentre i valori all’interno dello stesso tipo sono collegati con OR. Pattern URL aggiuntivi possono quindi ampliare il match. Resta irrisolto il limite TLS documentato sopra per le eccezioni che combinano IP sorgente e di destinazione: la presenza di entrambi i campi API non dimostra che la combinazione sia consentita. Non creare un bypass più ampio omettendo un criterio.

Per URLRegex restano necessari ancoraggi iniziali, punti dell’host con escape, un limite chiaro dell’host, ASCII/Punycode e test positivi, negativi e con stringhe lunghe senza match. Il pattern del riferimento API non è un’allowlist approvata e non sostituisce né questi test né il limite relativo ai percorsi HTTPS. La sola verifica della sintassi XML non dimostra che il match sia sicuro.

Name è l’unico parametro contrassegnato come obbligatorio: una stringa scalare di massimo 60 caratteri; sono esclusi ^, ;, ', " e \. Il parametro opzionale NewName serve a rinominare e ha gli stessi limiti. Non equivale alla creazione di una nuova voce mediante un nome modificato nell’importazione selettiva. Desc è una stringa scalare opzionale di massimo 250 caratteri; IsDefault identifica un’eccezione predefinita con un valore scalare yes/no e non autorizza a modificare gli oggetti predefiniti. Gli altri parametri sono opzionali e le relative colonne dei valori predefiniti sono vuote. Da questo non si può dedurre né un valore predefinito concreto né la garanzia che i valori omessi vengano mantenuti durante un aggiornamento. Prima, salvare lo stato memorizzato e definire il confronto completo tra stato previsto ed effettivo.

Interpretare le risposte in base a operazione, codice e simbolo

Entrambi i riferimenti degli oggetti contengono esattamente queste corrispondenze. Le denominazioni delle operazioni e i simboli restano volutamente invariati:

Questi codici XML non sono codici di stato HTTP. Message.* resta un simbolo della documentazione non risolto, non un messaggio verificato a runtime né una causa di errore univoca. In particolare, da Message.WebExceptionsLimit non si deve dedurre un limite massimo numerico. Add e Update hanno simboli di successo/errore differenti; le corrispondenze di Add per 502 e 522 non vengono trasferite a Update.

Conservare in una posizione protetta la risposta effettiva con operazione e codice XML, anche in caso di timeout o risultato poco chiaro. Prima di ogni nuovo tentativo di scrittura, verificare la voce effettivamente memorizzata mediante una query di lettura confermata per la build specifica oppure in Web > Exceptions: nome precedente ed eventualmente nuovo nome, numero delle voci, attivazione, tutti i criteri e i flag di esclusione. Neppure un successo segnalato sostituisce questo confronto. Se una voce è già presente, non crearla nuovamente, rinominarla, sovrascriverla o rimuoverne i criteri alla cieca. Se lo stato non è chiaro o è stato modificato solo in parte, fermarsi e chiarire con il responsabile del firewall sulla base della risposta, dello stato precedente e dello stato previsto. Dopo una modifica confermata, creare nuove connessioni ed eseguire i test positivi e negativi esistenti; solo questi verificano l’effetto sulla protezione. La guida centrale alla API spiega inoltre avvisi, successi parziali e la procedura sicura senza tentativi ripetuti alla cieca.

Revisione e rollback

Ogni Web Exception di produzione include almeno:

• motivazione tecnica e ticket
• responsabile dell’applicazione e del firewall
• host, percorsi, sorgenti e gruppi di utenti interessati
• controlli esatti ignorati
• data dei test positivi e negativi
• data di revisione o scadenza
• stato precedente documentato

Per il rollback, prima si disattiva l’eccezione invece di eliminarla subito. Poi si testano nuovamente l’errore originale, il normale percorso di protezione e le destinazioni non interessate. L’eccezione viene rimossa solo quando non rimane più alcuna dipendenza.

Le eccezioni predefinite e del vendor non vengono modificate senza controllo. Per un’eccezione personalizzata deve rimanere chiaro perché esiste e chi la rivaluterà in seguito.

Checklist operativa

• DPI Mode o Web Proxy Mode identificato.
• Firewall rule e Web Policy che corrispondono realmente confermate.
• Hostname e, se applicabile, percorso URL acquisiti dal traffico reale.
• Regex ancorata all’inizio e testata contro non-match.
• Considerati AND tra tipi di criteri e OR all’interno di un tipo.
• Selezionata solo l’opzione minima necessaria.
• Considerata l’esclusione automatica di Zero-Day con Malware and content scanning.
• Sorgente pilota limitata.
• Test positivi e negativi eseguiti.
• Log Viewer, certificato ed effetto sulla protezione verificati insieme.
• Responsabile, ticket, data di revisione e rollback documentati.

Domande frequenti