Vai al contenuto
Avanet

Implementare correttamente l'ispezione TLS su Sophos Firewall

Gran parte del traffico web odierno è crittografato. Senza ispezione TLS, il firewall spesso vede solo l’IP di destinazione, SNI, informazioni sui certificati e metadati, ma non il contenuto effettivo della connessione.

Questo rappresenta un problema di sicurezza: molte funzioni di protezione non possono esaminare il payload crittografato o lo fanno in modo molto limitato. La scansione malware, la protezione web, l’analisi zero-day, la scansione dei contenuti e parti del rilevamento delle applicazioni o delle minacce diventano veramente efficaci solo quando il firewall può decrittare, esaminare e poi ricrittografare il traffico TLS. Anche IPS e NDR beneficiano di una maggiore visibilità del testo in chiaro. Senza decrittazione, molti segnali rimangono limitati a metadati, certificati, IP, domini o informazioni sui protocolli.

Tuttavia, l’ispezione TLS non è una funzione che dovrebbe essere attivata senza preparazione per tutti gli utenti. Può interferire con le applicazioni, sollevare questioni di privacy e aumentare il carico sul firewall. Pertanto, l’ispezione TLS dovrebbe essere implementata in modo pianificato, graduale e con una chiara strategia di eccezione.

Orientamento

Per prima cosa si sceglie il metodo di protezione o configurazione adatto al caso concreto. Così si evitano regole troppo ampie e troubleshooting duplicato.

Licenza e requisiti

Per l’ispezione TLS e l’analisi efficace del traffico decrittato, sono necessarie le licenze di protezione appropriate.

Sono particolarmente importanti:

  • Web Protection: Include Web Security, Web Control, Application Control e Web Malware Protection.
  • Network Protection: Include, tra l’altro, IPS, Security Heartbeat e altre funzioni di protezione della rete.
  • Zero-Day Protection: Diventa importante quando file o download devono essere analizzati ulteriormente tramite Machine Learning o Sandbox.

Web Protection è inclusa nel pacchetto di licenze Standard Protection. Xstream Protection e Epic Protection includono anch’essi Web Protection e altri moduli di protezione. Per la classificazione dei pacchetti, consultare Quali pacchetti Sophos Firewall esistono?; per la Base License, lo stato di supporto e le sottoscrizioni, consultare Comprendere la Base License di Sophos Firewall.

Prima del rollout, è necessario verificare:

  • È installato il firmware Sophos Firewall aggiornato.
  • Web Protection è licenziata.
  • Il certificato CA del firewall è distribuito sui client.
  • È definito un gruppo di test o una rete di test.
  • Il rollback è documentato.
  • Il processo di eccezione è chiarito.
  • Il logging è attivato.

Se il certificato CA non è ancora distribuito, l’articolo Installare il certificato CA di Sophos Firewall per la scansione HTTPS può essere utile.

⚠️ L’ispezione TLS può interferire con le applicazioni che utilizzano il Certificate Pinning o eseguono controlli sui certificati propri. Il rollout dovrebbe sempre iniziare con un gruppo di test e non direttamente con tutti gli utenti.

DPI o Web Proxy?

Sophos Firewall può implementare la decrittazione HTTPS in due modalità operative:

  • DPI Mode: La regola del firewall utilizza il motore DPI. Le regole di ispezione SSL/TLS sotto Rules and policies > SSL/TLS inspection rules decidono cosa viene decrittato.
  • Web Proxy Mode: La regola del firewall utilizza il Web Proxy. La decrittazione HTTPS è quindi controllata tramite le impostazioni del Web Proxy e le politiche web.

Per configurazioni moderne, viene spesso utilizzata la modalità DPI. È importante la regola del firewall:

  1. Aprire Rules and policies > Firewall rules.
  2. Modificare la regola LAN-to-WAN interessata.
  3. Aprire Security features > Web filtering.
  4. Attivare la politica web appropriata.
  5. Attivare Scan HTTP and decrypted HTTPS.
  6. Lasciare disattivato Use web proxy instead of DPI engine se si desidera che le regole di ispezione SSL/TLS siano applicate.

Se Use web proxy instead of DPI engine è attivato, il traffico web passa attraverso il Web Proxy. In tal caso, per HTTP/HTTPS si applicano impostazioni di decrittazione diverse rispetto alle regole di ispezione SSL/TLS basate su DPI. Prima del rollout, è quindi importante sapere se l’ambiente utilizza Web Proxy o DPI, altrimenti si rischia di cercare eccezioni nel posto sbagliato.

Quale traffico dovrebbe essere decrittato?

Non si dovrebbe decrittare tutto alla cieca. Una buona ispezione TLS inizia con obiettivi chiari.

Obiettivi iniziali sensati:

  • LAN > WAN: traffico web utente classico verso Internet.
  • Wi-Fi > WAN: client gestiti nella rete Wi-Fi aziendale.
  • VPN > WAN: utenti di accesso remoto, se il loro traffico Internet passa attraverso il firewall.
  • LAN > DMZ: accessi interni ai propri server, se è desiderata una verifica di sicurezza e i certificati sono distribuiti correttamente.

Trattare con cautela:

  • Portali bancari, sanitari, governativi e altamente sensibili.
  • Gestori di password e provider di identità.
  • Servizi di aggiornamento del sistema operativo e del produttore.
  • App mobili e dispositivi Android.
  • Applicazioni con Certificate Pinning.
  • Servizi di voce, video e collaborazione, se diventano instabili a causa della decrittazione.

Per le pubblicazioni di server da Internet alla DMZ, l’ispezione TLS non è automaticamente la soluzione migliore. Per i server web, spesso è più utile Protezione del server web / WAF o un Reverse Proxy.

Considerare QUIC e la politica web

Se il traffico web non viene esaminato come previsto nonostante l’ispezione TLS, è necessario controllare anche QUIC o HTTP/3. Molti browser possono stabilire connessioni HTTPS tramite UDP 443. A seconda del design delle regole e delle politiche web, il traffico potrebbe non passare attraverso il percorso HTTPS classico previsto su TCP 443.

Nelle regole client-Internet, è quindi necessario verificare consapevolmente:

  • La politica web appropriata è attiva?
  • Block QUIC protocol è attivo nella regola del firewall effettivamente corrispondente?
  • Scan HTTP and decrypted HTTPS è impostato in modo coerente con la strategia di decrittazione?
  • La regola utilizza DPI o Web Proxy?
  • Si vedono nel Log Viewer eventi UDP 443, TCP 443, eventi di politica web ed eventi di ispezione SSL/TLS in modo coerente?

La procedura per bloccare QUIC è descritta in Bloccare correttamente QUIC e HTTP/3 su Sophos Firewall. Per la politica web stessa, consultare Creare una politica di protezione web su Sophos Firewall.

Pianificare il rollout

TLS Inspection dovrebbe essere introdotta gradualmente, così eccezioni, certificati client e casi di supporto restano gestibili.

Strategia di rollout

Un approccio graduale si è dimostrato efficace:

  1. Distribuire il certificato CA.
  2. Preparare la politica web e la regola del firewall.
  3. Selezionare il profilo di decrittazione.
  4. Definire un piccolo gruppo di test.
  5. Attivare la regola di ispezione SSL/TLS solo per questo gruppo.
  6. Monitorare Control Center e Log Viewer.
  7. Analizzare gli errori e documentare chiaramente le eccezioni.
  8. Espandere gradualmente ad altri gruppi di utenti.

In questo modo si riconoscono presto le applicazioni che causano problemi, senza influenzare l’intera operazione.

Pianificare le fasi di rollout

Un rollout di ispezione TLS dovrebbe essere pianificato in fasi. In questo modo rimane controllabile e si possono separare i problemi tecnici da quelli di accettazione o applicazione.

  • Preparazione: CA, politica web, regola del firewall e gruppo di test sono pronti. Distribuzione CA, licenza, logging, rollback
  • Pilota: pochi client gestiti testano la quotidianità produttiva. Log Viewer, widget Dashboard, feedback degli utenti
  • Espansione: includere altri gruppi di utenti o reti. Documentare eccezioni, monitorare le prestazioni
  • Operazione: L’ispezione TLS viene regolarmente controllata. Revisione di esclusioni, report, errori e nuove applicazioni

È importante che ogni fase abbia un chiaro punto di interruzione. Se un’applicazione critica per il business si interrompe durante il pilota, non si dovrebbe immediatamente impostare un’eccezione globale ampia. È meglio un’analisi accurata: quale dominio, quale client, quale regola, quale profilo di decrittazione e quale errore nel Log Viewer sono coinvolti?

Stabilire pilota, responsabile e processo di eccezione

Prima del primo rollout produttivo, dovrebbe essere chiaro chi gestisce il gruppo di test, chi approva le eccezioni e come vengono segnalati gli errori. L’ispezione TLS altrimenti genera rapidamente eccezioni disordinate: singoli domini vengono impostati frettolosamente su Don't decrypt, senza che sia chiaro in seguito perché l’eccezione esiste.

Per l’operazione, questi punti dovrebbero essere documentati:

  • Gruppo pilota, reti interessate e periodo.
  • Responsabile per politica web, profilo di decrittazione e regole di ispezione SSL/TLS.
  • Processo per nuove eccezioni con motivo, ticket e data di revisione.
  • Criteri per quando un’applicazione viene esclusa e quando viene prima esaminata la causa.
  • Luogo in cui vengono raccolti Log Viewer, widget Dashboard e feedback degli utenti.
  • Rollback, se le applicazioni critiche per il business vengono disturbate.

Particolarmente importante è la separazione tra eccezione tecnica e decisione di sicurezza permanente. Un’eccezione temporanea può essere utile per far funzionare di nuovo un servizio. Tuttavia, questa eccezione dovrebbe essere rivalutata in seguito, una volta che causa, rischio e alternativa sono chiari.

Testare il rollback prima del rollout

Il rollback non dovrebbe essere inventato solo durante un’interruzione. Prima del pilot deve essere chiaro come ritirare TLS Inspection per il gruppo di test senza confondere altre regole, web policy o eccezioni.

Controllo pratico del rollback:

  • Rimuovere il gruppo di test: verificare che la SSL/TLS Inspection Rule non faccia più match per il client pilota.
  • Disattivare la rule: controllare che il traffico torni sul percorso previsto senza decryption.
  • Testare l’eccezione: una regola mirata Don't decrypt deve trovarsi sopra la regola generale Decrypt ed essere visibile nel Log Viewer.
  • Mantenere la Web Policy: il rollback della decryption non deve rimuovere accidentalmente web filtering, malware scanning o logging.
  • Documentare la prova: annotare client di test, dominio di destinazione, nome della regola, evento di log e orario.

Questa prova è particolarmente importante quando più amministratori lavorano su web policy, regole firewall e SSL/TLS Inspection Rules. Un rollback pulito ritira solo lo scope interessato e non rende cieca l’intera catena Web Protection.

Configurazione

La configurazione deve essere precisa, verificabile e semplice da controllare in seguito.

Comprendere i profili di decrittazione

Un Decryption Profile stabilisce quanto rigorosamente il firewall gestisce le connessioni TLS. I profili si trovano sotto Profiles > Decryption profiles.

Un profilo di decrittazione risponde, tra l’altro, a queste domande:

  • Cosa succede con certificati non validi o non attendibili?
  • Vengono bloccate le vecchie versioni TLS?
  • Vengono bloccate le suite di cifratura non sicure?
  • Cosa succede con la compressione SSL?
  • Cosa succede con suite di cifratura non riconosciute?
  • Cosa succede se il firewall non può decrittare una connessione?
  • Quale CA viene utilizzata per la nuova firma?

Per un primo rollout, è utile un profilo più compatibile, ad esempio Maximum compatibility o un profilo conservativo personalizzato. Per regole di sicurezza produttive, può essere utilizzato in seguito un profilo più rigoroso come Block insecure SSL.

Importante: il profilo di decrittazione viene selezionato direttamente nella regola di ispezione SSL/TLS. Il profilo può sovrascrivere le impostazioni globali di ispezione SSL/TLS per questa regola. Pertanto, durante il troubleshooting, si dovrebbe sempre esaminare la regola concreta e non solo le impostazioni globali.

Creare una regola di ispezione SSL/TLS

Il percorso del menu è Rules and policies > SSL/TLS inspection rules.

Una prima regola dovrebbe essere il più mirata possibile:

  • Azione: Decrypt
  • Profilo di decrittazione: profilo di test conservativo
  • Zone di origine: LAN o rete di test
  • Reti e dispositivi di origine: gruppo di test o subnet di test
  • Zone di destinazione: di solito WAN
  • Reti di destinazione: inizialmente Any
  • Servizi: per iniziare spesso Any, poiché SSL/TLS può essere riconosciuto anche su altre porte TCP
  • Siti web / Categorie: opzionalmente limitare

Le regole di ispezione SSL/TLS possono riconoscere connessioni TLS anche al di fuori della porta HTTPS classica. Le regole vengono elaborate dall’alto verso il basso. Eccezioni specifiche e regole pilota dovrebbero quindi essere posizionate sopra le regole di decrittazione generali, altrimenti sarà difficile capire perché una connessione è stata decrittata o esclusa.

Liste di esclusione

Non tutto il traffico TLS dovrebbe essere decrittato. Sophos lavora con regole di esclusione e liste di esclusione TLS.

Lista di esclusione TLS locale

La Local TLS exclusion list è la lista di esclusione locale del firewall. Questa lista è vuota di default e può essere riempita tramite il troubleshooting nel Control Center o nel Log Viewer.

Può anche essere modificata manualmente:

Web > URL groups > Local TLS exclusion list

Questa lista è utile per domini che causano problemi nell’ambiente locale, ad esempio a causa di Certificate Pinning o applicazioni client speciali.

Lista di esclusione TLS gestita

La Managed TLS exclusion list contiene eccezioni mantenute da Sophos per servizi noti problematici. Questa lista viene aggiornata tramite aggiornamenti del firmware.

Esempi tipici sono servizi per i quali l’ispezione TLS causa problemi o non è tecnicamente sensata.

Regole di esclusione personalizzate

Inoltre, è possibile creare regole di ispezione SSL/TLS personalizzate con Action > Don’t decrypt. Queste dovrebbero essere posizionate direttamente sotto la regola di esclusione standard e contenere solo traffico che non deve essere decrittato.

Criteri possibili:

  • Categorie web
  • Gruppi URL
  • Utenti e gruppi
  • Reti di origine e destinazione
  • Indirizzi IP
  • Servizi

Le eccezioni dovrebbero essere documentate: dominio, motivo, utenti interessati, data e termine di revisione.

Controllo e analisi

Dopo l’attivazione, dashboard e Log Viewer mostrano se il traffico viene davvero decifrato o escluso.

Monitorare il widget Dashboard

Nel Control Center c’è un widget per SSL/TLS Inspection. Questo widget è molto utile per monitorare il rollout e gli errori.

Mostra, tra l’altro:

  • Percentuale di sessioni SSL/TLS decrittate.
  • Percentuale di sessioni SSL/TLS non decrittate.
  • Altro traffico.
  • Errori degli ultimi giorni.
  • Principali siti web o utenti con problemi.
  • Picco di decrittazione e limite di decrittazione.
Sophos Firewall - Widget di ispezione SSL/TLS con traffico decrittato e non decrittato
Sophos Firewall - Control Center > Widget di ispezione SSL/TLS

Se nel widget compaiono molti errori, non si dovrebbe disattivare immediatamente l’intera ispezione TLS. È meglio esaminare in modo mirato gli obiettivi interessati tramite Fix errors e creare eccezioni pulite se necessario.

Valutare il Log Viewer

Nel Log Viewer è possibile selezionare il filtro SSL/TLS inspection. Qui si può vedere cosa è successo con le singole connessioni.

Sophos Firewall - Log Viewer con eventi di ispezione SSL/TLS
Sophos Firewall - Log Viewer > Ispezione SSL/TLS

I colori aiutano nella prima valutazione:

  • Rosso: Errore. La connessione non è stata decrittata o elaborata correttamente. Qui si dovrebbero controllare errori di certificato, suite di cifratura, versioni TLS o applicazioni incompatibili.
  • Verde: Do not decrypt. La connessione non è stata decrittata intenzionalmente, ad esempio a causa di una regola di esclusione o di una lista di esclusione TLS.
  • Blu: Decrypt. La connessione è stata decrittata e poi ricrittografata e inoltrata.

Nel log si vedono anche profilo di decrittazione, IP sorgente, IP di destinazione, utente, categoria e dominio di destinazione. Questo permette di verificare se la regola corretta è stata applicata e se un’eccezione è effettivamente valida.

Test

Dopo l’attivazione dell’ispezione TLS, si dovrebbe verificare:

  • Il certificato CA di Sophos viene utilizzato nel browser?
  • Le applicazioni aziendali importanti funzionano?
  • Ci sono errori TLS nel Log Viewer?
  • Gli eventi di malware o di politica web vengono rilevati correttamente?
  • Il traffico viene visualizzato come decrittato nel widget del Control Center?
  • Le prestazioni del firewall rimangono nell’intervallo previsto?
  • Ci sono lamentele da parte degli utenti di test?

Per la ricerca degli errori, sono particolarmente utili Log Viewer, Policy Test, visualizzazione dei certificati del browser, Packet Capture e il widget di ispezione SSL/TLS.

Troubleshooting e operatività

I problemi di TLS Inspection si risolvono di solito con eccezioni chiare, rollback controllato e review regolari.

Errori tipici

  • Il browser mostra un avviso di certificato: CA mancante nel Trust Store o CA errata utilizzata. Distribuzione CA, catena di certificati nel browser, riavvio del client
  • Il Log Viewer non mostra eventi di ispezione SSL/TLS: modalità errata, nessuna regola corrispondente o motore SSL/TLS non attivo. Regola del firewall, DPI/Web Proxy, regola di ispezione SSL/TLS
  • Il traffico è consentito, ma non decrittato: Regola Don't decrypt, esclusione gestita o ordine delle regole errato. Verificare le regole di ispezione SSL/TLS dall’alto verso il basso
  • Il filtro web non funziona come previsto: Politica web mancante, QUIC attivo o Scan HTTP and decrypted HTTPS frainteso. Regola del firewall corrispondente, QUIC, log della politica web
  • Singole applicazioni si interrompono: Certificate Pinning, vecchia versione TLS, suite di cifratura incompatibile o controllo certificati proprio. Log Viewer, profilo di decrittazione, eccezione mirata
  • Molti errori nel widget Dashboard: rollout troppo ampio o profilo di decrittazione inadeguato. Ridurre il gruppo pilota, ordinare gli errori per dominio e categoria
  • Le prestazioni diminuiscono dopo l’attivazione: ambito troppo ampio, grandi download o troppe sessioni simultanee. Verificare l’ambito di decrittazione, il carico del firewall e i principali utenti
  • L’eccezione non funziona: L’eccezione è sotto una regola di decrittazione più generale. Verificare l’ordine delle regole e i criteri corrispondenti

In caso di dubbi, non si dovrebbero modificare più cose contemporaneamente. È meglio un test ristretto: un client, un dominio di destinazione, una regola del firewall, un profilo di decrittazione e un momento chiaro nel Log Viewer.

Rollback

In caso di problemi, dovrebbe essere possibile un rollback chiaro:

  • Disattivare la regola di ispezione SSL/TLS.
  • Rimuovere il gruppo di test dalla regola.
  • Allentare il profilo di decrittazione.
  • Aggiungere un’eccezione per il dominio o l’applicazione interessata.
  • Ripristinare la regola del firewall su Web Proxy, se desiderato consapevolmente.

Le regole di ispezione SSL/TLS e il motore SSL/TLS devono essere visibilmente attivi affinché Control Center e Log Viewer mostrino i dettagli. Se si disattiva l’ispezione SSL/TLS per scopi di troubleshooting, si dovrebbe riattivarla successivamente e documentare brevemente lo stato.

Raccomandazioni operative

L’ispezione TLS non è un progetto a clic singolo. Se implementata correttamente, offre una visibilità significativamente maggiore e migliora l’efficacia della protezione web, della scansione malware, di IPS, NDR e delle funzioni zero-day.

Per ambienti produttivi, consigliamo:

  • Iniziare con LAN-to-WAN per un piccolo gruppo di test.

  • Distribuire correttamente il certificato CA.

  • Scegliere consapevolmente la modalità DPI/Web Proxy.

  • Non iniziare con profili di decrittazione troppo aggressivi.

  • Monitorare quotidianamente Log Viewer e Dashboard.

  • Documentare e verificare regolarmente le eccezioni.

  • Espandere solo dopo test riusciti.

  • Mantenere testato il rollback per gruppo pilota ed eccezioni.

FAQ

Si dovrebbe attivare immediatamente l'ispezione TLS per tutti gli utenti?

No. L’ispezione TLS dovrebbe iniziare con un gruppo di test. Solo quando la distribuzione CA, la politica web, il profilo di decrittazione, le eccezioni, i log e le applicazioni aziendali sono stati verificati, si dovrebbe ampliare l’ambito.

Perché l'ispezione TLS non funziona nonostante il certificato CA installato?

Il certificato CA garantisce solo che i client si fidino della CA del firewall. Inoltre, devono essere corretti la regola del firewall, la politica web, la regola di ispezione SSL/TLS, il profilo di decrittazione e l’ordine delle regole.

Qual è la differenza tra modalità DPI e modalità Web Proxy?

In modalità DPI, le regole di ispezione SSL/TLS si applicano al traffico della regola del firewall. In modalità Web Proxy, il traffico web passa attraverso il proxy e la decrittazione è controllata diversamente. Pertanto, è necessario verificare consapevolmente la modalità della regola del firewall interessata.

Quando è necessaria un'eccezione TLS?

Un’eccezione è utile quando un’applicazione non può essere decrittata correttamente a causa di Certificate Pinning, controllo certificati proprio o incompatibilità tecnica. L’eccezione dovrebbe essere documentata e verificata successivamente.

QUIC deve essere bloccato per l'ispezione TLS?

Nelle reti client gestite, è generalmente consigliabile se si desidera che il filtraggio web, la scansione malware o l’ispezione TLS funzionino in modo affidabile. QUIC su UDP 443 può altrimenti aggirare il percorso HTTPS classico previsto su TCP 443.