Implementare correttamente l'ispezione TLS su Sophos Firewall

Con l’ispezione TLS, Sophos Firewall termina la connessione crittografata del client e stabilisce una seconda connessione al server di destinazione. Può ispezionare il testo in chiaro tra i due. Il firewall firma nuovamente per il client un certificato server originariamente attendibile con la propria CA (Certificate Authority). Se il client non considera attendibile questa CA, visualizza un avviso relativo al certificato o termina la connessione.

Ciò consente di ispezionare i contenuti decrittografati, inclusi malware e scansione dei contenuti. Senza decrittografia, le funzionalità di protezione potrebbero essere limitate, a seconda del modulo, a informazioni quali indirizzo IP, dominio, SNI, certificato o metadati del protocollo. Ciò non giustifica un’ampia implementazione iniziale: il pinning dei certificati, la privacy, la compatibilità delle applicazioni e il carico aggiuntivo del firewall devono essere affrontati prima dell’implementazione.

La versione breve e sicura è: determinare se utilizzare il percorso DPI o proxy Web, distribuire la CA usata per la ri-firma a un piccolo gruppo, documentare lo stato corrente, creare una regola di decrittografia con ambito ristretto, eseguire un test positivo e uno negativo e solo successivamente espandere l’ambito.

Decisioni da prendere prima del progetto pilota

Licenza, CA e responsabilità

Le regole di ispezione SSL/TLS e i gruppi URL utilizzati in esse vengono applicati con Base License. Web Protection non è un prerequisito generale per l’ispezione TLS. È necessario quando le categorie Web vengono utilizzate come criteri di regola o quando sono necessarie le funzionalità di protezione Web corrispondenti. Malware, Zero-Day e altre ispezioni richiedono ciascuna il relativo abbonamento. Quali pacchetti Sophos Firewall sono disponibili? e Informazioni sulla licenza base di Sophos Firewall spiegano le differenze.

Chiarire quanto segue prima di creare la prima regola:

• Documentare la versione SFOS in uso, la licenza disponibile e il percorso di ispezione previsto.
• Definire un gruppo pilota gestito e una finestra temporale chiara. L’esempio seguente utilizza il client 10.20.30.50 dalla rete di test 10.20.30.0/24; sostituire questi valori con i propri oggetti.
• Ottenere l’approvazione dalle parti interessate responsabili della privacy per l’ambito, la registrazione, la conservazione e la notifica all’utente.
• Eseguire il backup dell’esatto stato iniziale della regola firewall, delle regole TLS, del profilo di decrittografia, della CA e di eventuali impostazioni globali. Registrare il percorso completo di corrispondenza prima del progetto pilota, la regola che corrisponderà dopo la disabilitazione del pilota (compresa qualsiasi regola Decrypt più ampia situata più in basso) e ogni modifica apportata solo per il pilota alle regole firewall, alla modalità DPI/proxy, alla policy Web e alle impostazioni globali. Definire gli esatti passaggi di ripristino autorizzati prima dell’attivazione.
• Definire il responsabile, i criteri di interruzione, il processo di eccezione e il percorso di rollback.

La CA firmataria deve trovarsi nell’archivio di attendibilità dei sistemi operativi o dei browser interessati. In alternativa, utilizzare una CA aziendale subordinata. A questo scopo non è disponibile una CA pubblicamente attendibile poiché il firewall firma nuovamente i certificati per domini di terze parti. Con una CA esterna è necessario importare sia la CA radice che quella subordinata; se la CA firmante contiene una sezione EKU, deve consentire TLS Web Server Authentication. Installa il certificato CA di Sophos Firewall per la scansione HTTPS descrive la distribuzione, mentre Configura una CA subordinata per l’ispezione TLS di Sophos Firewall copre il metodo della CA aziendale.

⚠️ Non iniziare con tutti gli utenti. I dispositivi senza un truststore gestibile, BYOD e le applicazioni che utilizzano il certificate pinning dovrebbero inizialmente rimanere in un ambito separato. Un’eccezione ripristina la connessione, ma ne rimuove il contenuto dalla decrittografia.

Mantieni DPI e proxy Web separati

SFOS utilizza DPI engine per impostazione predefinita. Su questo percorso, il firewall elabora prima la regola del firewall e poi le regole di ispezione SSL/TLS. La regola di ispezione di per sé non consente il traffico: anche Services: Any significa solo che il traffico TLS già consentito dalla regola del firewall su qualsiasi porta TCP è idoneo per questa regola di ispezione.

Per il percorso DPI, apri Rules and policies > Firewall rules, modifica la regola LAN-to-WAN pertinente e controlla Security features > Web filtering:

1. Lasciare Use web proxy instead of DPI engine disabilitato.
2. Selezionare una Web Policy solo se la protezione pianificata lo richiede; non è un prerequisito per la regola di decrittografia.
3. Scan HTTP and decrypted HTTPS abilita la scansione del malware per HTTP e HTTPS che è già stato decrittografato. L’opzione di per sé non abilita la decrittografia HTTPS.

In Web Proxy Mode, il proxy gestisce la decrittografia HTTPS. Decrypt HTTPS during web proxy filtering è l’impostazione rilevante sul percorso proxy. Le regole DPI in Rules and policies > SSL/TLS inspection rules non si applicano alle connessioni decrittografate dal proxy Web. Con il proxy trasparente, le porte 80 e 443 passano attraverso il proxy mentre SSL/TLS su altre porte può ancora essere gestito dal percorso DPI; con il proxy esplicito, il proxy Web esegue la decrittografia.

Anche le CA sono separate: DPI utilizza la CA dalle impostazioni SSL/TLS o dal profilo di decrittografia selezionato. Il proxy Web utilizza la CA di Web > General settings. Quando si cambia modalità verificare non solo le regole ma anche la CA effettivamente presentata. Scegliere correttamente il motore DPI o il proxy Web spiega le differenze in modo più dettagliato.

Questo percorso di ispezione in uscita non è destinato ai server Web pubblicati su Internet. Protezione server Web/WAF o un proxy inverso è solitamente l’architettura più adatta. Le regole di ispezione SSL/TLS si applicano al traffico in uscita, quindi solo le zone interne possono essere selezionate come Source zones. Rilevano TLS su qualsiasi porta TCP, ma non vengono applicate su UDP.

Contraddizione nella documentazione sulla direzione: La guida alla creazione delle regole menziona connessioni in entrata e in uscita, ma poi limita esplicitamente Source zones alle zone interne e al traffico in uscita. La formulazione generale non dimostra il supporto dell’ispezione in ingresso dalla WAN. Questo rollout rimane sul percorso dei client interni descritto qui; prima di modificare connessioni in ingresso verso server, occorre un chiarimento di Sophos Support per la build utilizzata.

Prima del test di decrittografia devono già funzionare routing, DNS e accesso a Internet autorizzato. In Rules and policies > NAT rules, verificare la regola SNAT che corrisponde effettivamente; in un normale progetto IPv4 potrebbe essere Default SNAT IPv4 con Translated source (SNAT): MASQ. Non sostituire una regola funzionante con un’altra regola NAT ampia. IPv6 e reti instradate richiedono una decisione progettuale specifica, non automaticamente MASQ. La regola firewall del pilota necessita di Action: Accept e dell’ambito autorizzato per origine, destinazione e servizi.

Per il proxy, verificare anche HTTPS scanning certificate authority (CA), Block unrecognized SSL protocols e Block invalid certificates in Web > General settings > HTTPS decryption and scanning. Per Direct Proxy, consentire il listener configurato in Web > General settings > Web proxy configuration e Administration > Device access > Other services > Web proxy soltanto ai client o alle zone necessari. Il proxy trasparente richiede i servizi HTTP/HTTPS; Direct Proxy richiede anche la porta del listener configurato. L’articolo DPI/proxy già collegato illustra il procedimento completo e la protezione dei servizi web locali del firewall.

Esempio di compatibilità obsoleto: La guida di configurazione conservata per SFOS 22/23 richiede TLS 1.1 nell’esempio proxy, mentre la documentazione dei profili considera non sicure le versioni precedenti a TLS 1.2. TLS 1.1 non viene quindi adottato come requisito del rollout. Mantenere protocolli sicuri; se un’applicazione legacy necessita di un’eccezione, chiarire prima versione, percorso interessato, rischio e ambito ristretto con il responsabile del firewall. Abbassare TLS globalmente non è una soluzione per il pilota.

Gestire QUIC in modo deliberato

QUIC, o HTTP/3, utilizza UDP. Block QUIC protocol in una regola firewall scarta i pacchetti UDP in uscita alle porte 80 e 443 nell’ambito di tale regola, inducendo normalmente i client che dispongono di un’alternativa TCP utilizzabile a riprovare tramite TCP; i client che non ne dispongono possono perdere la connettività. SFOS seleziona l’opzione per impostazione predefinita non appena viene selezionata una policy Web nella regola o Scan HTTP and decrypted HTTPS viene abilitato. Questa impostazione si applica per singola regola, non globalmente, quindi controlla la regola del firewall che corrisponde effettivamente. Questa opzione non copre UDP su altre porte. Verifica una connessione TCP effettiva, il funzionamento dell’applicazione e la corrispondenza con il percorso di ispezione previsto; il solo blocco di UDP non dimostra nessuno di questi aspetti.

Questo filtro web non può eseguire la scansione di QUIC. Ciò non significa che tutti gli altri controlli del firewall vengono ignorati, ma il percorso TLS su TCP e quello del filtro web previsti non vengono applicati. Blocco corretto di QUIC e HTTP/3 su Sophos Firewall mostra il test della regola; Creazione di una policy di protezione web per Sophos Firewall riguarda la policy web.

Seleziona l’ambito in base allo scopo e al rischio

Il consueto punto di partenza è il traffico utente gestito da LAN a WAN. In seguito si può includere una rete Wi-Fi aziendale separata con Wi-Fi > WAN. Per l’accesso remoto, VPN > WAN è rilevante solo quando il traffico Internet degli utenti attraversa effettivamente il firewall attraverso un tunnel completo. Includere le connessioni interne da LAN a DMZ solo quando l’ispezione del contenuto presenta un chiaro vantaggio e il client si fida della CA di nuova firma mentre il firewall convalida la catena di certificati originale del server. I normali server di destinazione non richiedono l’installazione di questa CA di ispezione. Valutare separatamente la compatibilità di mutual TLS (mTLS).

La compatibilità tecnica e l’autorizzazione alla decrittografia sono decisioni separate. I portali bancari, sanitari e governativi, i gestori di password, i provider di identità, gli aggiornamenti del sistema operativo e dei fornitori e i servizi vocali, video e di collaborazione richiedono una valutazione funzionale e della privacy prima dell’inclusione. Il certificate pinning o il fallimento di un progetto pilota non giustificano un’eccezione generale per un’intera categoria: identificare innanzitutto la fonte, il dominio e l’applicazione effettivamente richiesti.

Configura un pilota completo

Per un progetto pilota che può essere testato direttamente, utilizziamo questi valori di esempio:

• Client pilota: 10.20.30.50 dalla rete di test documentata 10.20.30.0/24
• Regola firewall: LAN to WAN - TLS pilot
• Regola di ispezione SSL/TLS: TLS decrypt pilot client
• Zona di origine: LAN, Zona di destinazione: WAN
• Reti e Servizi di destinazione: Any
• Azione: Decrypt
• Profilo di decrittazione: inizialmente Block insecure SSL o un profilo pilota da esso derivato
• Logging: Log connections abilitato per il pilota

10.20.30.0/24, l’IP host e i nomi degli oggetti sono esempi. La sorgente di produzione deve essere sufficientemente ristretta da identificare un singolo client in modo inequivocabile. Any per Destinazione e Servizio semplifica l’osservazione di TLS al di fuori del TCP 443 durante il progetto pilota; non amplia ciò che consente la precedente regola del firewall. Se l’ispezione è consentita solo per un gruppo di destinazione specifico, aggiungere un gruppo URL o un altro criterio di destinazione appropriato.

Seleziona un profilo di decrittazione

In Profiles > Decryption profiles sono disponibili tre profili predefiniti non modificabili:

• Maximum compatibility massimizza la compatibilità e non limita i cifrari.
• Block insecure SSL blocca i cifrari deboli e consente il traffico che non può essere decrittografato.
• Strict compliance applica requisiti rigorosi, inclusi i requisiti basati su PCI DSS.

Maximum compatibility può aiutare a isolare temporaneamente un client problematico, ma i suoi controlli rilassati lo rendono inadatto come criterio di accettazione della produzione. Per il pilota, Block insecure SSL o un profilo derivato deliberatamente è il punto di partenza più trasparente. Tollera vecchie versioni TLS o chiavi RSA inferiori a 2048 bit solo per un server legacy denominato e in una regola con ambito ristretto.

Rifiuto delle connessioni legacy con Decrypt: Con Action: Decrypt, Sophos Firewall continua a rifiutare le connessioni che utilizzano SSL 2.0 and SSL 3.0, SSL compression o Unrecognized cipher suites, anche se nel profilo è selezionato Allow without decryption per queste opzioni. Un’autorizzazione legacy esplicitamente approvata e con ambito ristretto richiede sia Allow without decryption per i campi pertinenti del profilo sia Action: Don’t decrypt; la sola autorizzazione nel profilo non è sufficiente.

Un profilo personalizzato può sovrascrivere le impostazioni SSL/TLS globali. Le opzioni della CA di ri-firma sono Use CAs defined in SSL/TLS settings, Re-sign RSA with e Re-sign EC with. Per il traffico che non può essere decrittografato, le opzioni sono Use SSL/TLS settings default, Allow without decryption, Drop e Reject. Il riferimento predefinito globale non si applica a Unrecognized cipher suites; questo caso deve essere valutato esplicitamente nel profilo. A seconda dell’impostazione, gli errori del certificato, la dimensione minima RSA, le versioni TLS e i cifrari bloccati utilizzano Drop, Reject o Reject and notify come Block action.

L’ispezione non rende affidabile un certificato server autofirmato o uno con una catena incompleta. Invece di escluderlo frettolosamente, controlla prima il nome host, il certificato originale e la catena completa.

Per un originale autofirmato, il firewall sostituisce la chiave e firma con essa, non come CA attendibile: il client continua a vedere un certificato autofirmato. Se manca la catena completa verso una CA considerata attendibile dal firewall, viene utilizzato un certificato generato dal sistema il cui CN spiega il problema. Un avviso non indica quindi automaticamente un errore nella distribuzione della CA.

Creare un profilo personalizzato in Profiles > Decryption profiles > Add, con nome e descrizione, oppure clonare un profilo adeguato; quindi salvarlo e assegnarlo alla regola di ispezione. I certificati originali RSA ed EC possono spesso utilizzare la stessa CA firmataria. Se un’applicazione richiede un tipo di chiave specifico, selezionare la CA corrispondente in Re-sign RSA with o Re-sign EC with. Scaricare ogni CA effettivamente utilizzata tramite il pulsante accanto alla selezione; con due CA diverse, i client devono considerarle entrambe attendibili.

Prima di salvare, valutare Certificate errors to block, Minimum RSA key size, Minimum SSL/TLS version, Maximum SSL/TLS version e Cipher algorithms to block. TLS inferiore a 1.2 e RSA inferiore a 2048 bit non sono impostazioni sicure. Maximum supported consente la versione massima supportata del protocollo. Il controllo Revoked richiede una CRL importata (Certificate Revocation List); la sola selezione della casella non dimostra che il controllo della revoca funzioni. Una Web Exception per HTTPS decryption può consentire connessioni corrispondenti con certificati non validi: non è quindi una semplice correzione del pinning.

Gli errori del certificato includono Invalid date, Self-signed, Untrusted user, Revoked, Name mismatch e Invalid for other reasons. Name mismatch confronta il nome del server in Client Hello con i nomi nel certificato. Per scegliere i cifrari bloccati, valutare separatamente scambio di chiavi, autenticazione, cifrari dei dati e algoritmi hash. La compressione SSL prima della cifratura presenta vulnerabilità note; i cifrari sconosciuti non possono essere decrittografati.

Le impostazioni globali sono in Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings. TLS 1.3 decryption offre Decrypt as 1.3 e Downgrade to TLS 1.2 and decrypt. La seconda opzione interessa tutte le regole di ispezione SSL/TLS; non abbassare TLS globalmente per un normale pilota.

When SSL/TLS connections exceed limit determina cosa accade quando la capacità di decrittografia si esaurisce: Allow without decryption mantiene la raggiungibilità ma elimina l’ispezione del contenuto; Drop scarta senza avviso e Reject invia un reset. È una scelta esplicita tra disponibilità e protezione per il pilota, non soltanto un valore prestazionale. Reject and notify tenta di mostrare una pagina di blocco HTTPS con il motivo dell’errore, senza garantirlo; impedisce il trasferimento di dati al server.

Con TLS 1.3, gli errori del certificato, la dimensione minima RSA, un downgrade globale e Reject and notify si comportano come documentato solo con Action: Decrypt. Con Don’t decrypt o Deny, per la gestione di questo profilo viene invece utilizzato Reject. Un downgrade globale a TLS 1.2 introduce un rischio per la sicurezza e non rappresenta una soluzione generale per la compatibilità.

Crea la regola e controllane l’ordine

In Rules and policies > SSL/TLS inspection rules > Add, impostare i campi come segue:

1. Rule name: TLS decrypt pilot client
2. Rule position:Top, quindi la regola pilota precede le regole generali di decrittografia personalizzate
3. Action:Decrypt
4. Log connections: abilitato per il monitoraggio pilota
5. Decryption profile: il profilo pilota selezionato
6. Source zones: LAN
7. Source networks and devices: oggetto host per 10.20.30.50
8. Destination zones: WAN
9. Destination networks: Any
10. Services: Any
11. Categories and websites: vuoto o limitato all’ambito di destinazione approvato

Log connections è facoltativo e non è necessario per il funzionamento della regola. È comunque utile per un pilota a tempo limitato perché è possibile tracciare l’handshake TLS e la chiusura della connessione. La conservazione deve seguire la politica operativa e sulla privacy concordata.

La tabella viene valutata dall’alto verso il basso e l’elaborazione si interrompe alla prima corrispondenza. Tutti i criteri configurati devono corrispondere contemporaneamente. La regola fissa predefinita Exclusions by website or category rimane in alto e non può essere preceduta dalla selezione di Rule position: Top. Posiziona le eccezioni Don't decrypt personalizzate immediatamente sotto, seguite da regole pilota specifiche e, infine, regole di decrittografia più ampie.

I criteri utente e gruppo sono affidabili solo se SFOS conosce il contesto utente per la connessione. Se ciò non è garantito, iniziare con un host o un oggetto di rete inequivocabile e aggiungere criteri di identità solo dopo un test di corrispondenza separato.

Dopo Save, ricontrollare stato e posizione della regola nella tabella. More options permette di modificare, clonare, inserire accanto a una regola ed eliminare; Rule handle ne cambia l’ordine. I filtri Source, Destination e Rule ID aiutano nel confronto; Reset filter ripristina la tabella completa. Action: Deny impedisce di stabilire la connessione e non equivale a Don’t decrypt. Categories and websites viene identificato tramite SNI nell’handshake TLS. Le nuove installazioni attivano le regole di ispezione SSL/TLS per impostazione predefinita, ma lo stato reale rimane una verifica preliminare.

Distinguere le configurazioni TLS tramite XML API

Nei rollout automatizzati, la Inspection Rule, le impostazioni DPI globali e la configurazione della scansione HTTP/HTTPS sono tre oggetti distinti. La selezione di una CA non attiva né la regola pilota né la scansione nella Firewall Rule. Le corrispondenze seguenti si riferiscono a SFOS 22/23. Prima di un’operazione di scrittura, l’operazione esplicita e il payload completo devono essere confermati in API help della build installata. L’autorizzazione delle sorgenti, l’account, la verifica TLS, i segreti e la distinzione tra esito positivo HTTP e stato XML sono spiegati in Limitare in modo sicuro l’accesso alla XML API e verificare le risposte.

Inspection Rule: identità, gerarchia e ordine

L’oggetto si chiama SSLTLSInspectionRule. Il suo campo diretto Name identifica la regola; nell’esempio, NewName è il nome modificato per una ridenominazione, non il nome della regola di riferimento per uno spostamento. Per il nome della regola sono documentati un massimo di 60 caratteri, la codifica UTF-8 e l’assenza di virgole; Description è limitato a 255 caratteri. IsDefault è di sola lettura e non viene utilizzato per rendere predefinita una propria regola pilota.

I campi di corrispondenza restano sotto i rispettivi nodi padre, anche quando la tabella dei parametri riporta più volte lo stesso nome di nodo figlio:

• SourceZones > Zone e SourceNetworks > Network: zona sorgente interna e oggetto host pilota approvato.
• DestinationZones > Zone e DestinationNetworks > Network: zona di destinazione e oggetti di destinazione autorizzati.
• Identity > Members: utenti o gruppi sorgente, solo con una corrispondenza dell’identità verificata.
• Services > Service: oggetti servizio per l’ambito approvato.
• Websites > Activity > Name e Websites > Activity > Type: nome e tipo del criterio relativo ai siti web; l’esempio indica Web Category e URL Group.
• MoveTo > Name e MoveTo > OrderBy: regola di riferimento e posizione relativa; OrderBy utilizza Before o After.

Zone, Network, Service e le attività relative ai siti web possono comparire più volte. Un campo Name o Network non annidato sotto il nodo padre corretto non descrive la stessa finalità. I nomi degli oggetti vengono ripresi dalla configurazione esistente; l’ambito e il profilo non vengono sostituiti da campi mancanti o valori predefiniti non verificati.

Position utilizza Top o Bottom e serve solo per il posizionamento iniziale durante ADD. In assenza di un’indicazione, l’esempio specifica Bottom; per UPDATE o APIImport, Position non è necessario e qui non viene adottato come meccanismo di spostamento. Il campo opzionale MoveTo viene applicato durante ADD dopo Position. Chi imposta entrambi deve quindi verificare la posizione relativa risultante, non soltanto il valore Top iniziale. L’esclusione predefinita fissa rimane in cima; continua a valere l’ordine sopra descritto delle eccezioni approvate, delle regole pilota e delle regole di decrittazione più ampie.

I campi diretti Enable, LogConnections, DecryptAction e DecryptionProfile hanno compiti distinti: stato della regola, registrazione nei log, decisione di decrittazione e assegnazione del profilo. Per Enable, la tabella indica Yes, No, t, f; per LogConnections, Enable, Disable, t, f. DecryptAction utilizza esattamente Decrypt, Do not decrypt o Deny. L’etichetta UI Don’t decrypt non è quindi un valore XML da utilizzare senza verifica. Il profilo selezionato viene assegnato in DecryptionProfile con il suo nome effettivo; una Source circoscritta e l’intero ambito approvato di destinazioni e servizi restano obbligatori anche nell’automazione.

Le righe di stato XML specifiche dell’oggetto distinguono operazione e simbolo:

Message.* rimane qui un identificatore della documentazione non risolto, non un testo di runtime garantito né una causa definitiva dell’errore. Prima di ogni nuovo tentativo, la risposta depurata viene confrontata con lo stato effettivamente salvato: nome originale o nuovo della regola, stato, criteri completi, DecryptionProfile e posizione relativa alle altre regole. Nemmeno una riga 200 sostituisce questo confronto o il test con nuove connessioni. Se lo stato non è chiaro, fermarsi e chiarire, anziché generare una seconda regola o una regola più ampia mediante un nuovo ADD o una posizione diversa.

Impostazioni DPI globali: la CA non è un interruttore di attivazione/disattivazione

Sotto SSLTLSInspectionSettings, RSACA ed ECCA rappresentano direttamente la selezione della CA di rifirma per i certificati server RSA ed EC, rispettivamente. Fanno riferimento a oggetti CA, non a percorsi di file o valori di attivazione. Il profilo può sovrascrivere la selezione della CA per la propria regola. Prima di una modifica vengono quindi verificati congiuntamente il profilo, la CA effettivamente presentata, l’attendibilità per i client e la catena root/subordinata; se vengono utilizzate CA diverse, i client devono considerarle entrambe attendibili.

Da questi sono distinti i campi globali diretti SSLTLSEngine e SSLTLSInspection, ciascuno con Enabled o Disabled. Il primo controlla la TLS engine, il secondo la SSL/TLS Inspection globale, non lo stato di una singola regola pilota. La disattivazione dell’Inspection impedisce l’applicazione delle regole e la visualizzazione dei dettagli di connessione/decrittazione in Control Center e Log viewer. La disattivazione dell’Engine rimuove inoltre dal percorso l’applicazione della policy web DPI al traffico HTTPS; la decrittazione HTTPS tramite proxy rimane invariata. Nessuna delle due operazioni costituisce un normale rollback del pilota.

Anche TLS13Decryption si trova direttamente sotto SSLTLSInspectionSettings e utilizza Decrypt as 1.3 o Downgrade to TLS 1.2 and decrypt. Seleziona il trattamento globale di TLS 1.3, non la CA di firma né l’azione di una singola regola. Un downgrade interessa tutte le Inspection Rules e non viene introdotto come correzione di compatibilità per un singolo client. Restano determinanti i limiti già illustrati per TLS 1.3 e Action: Decrypt.

Gli ulteriori campi diretti SSLv2SSLv3, SSLCompression e SSLConnectionsExceeded utilizzano ciascuno Allow without decryption, Drop o Reject. Riguardano casi diversi e non vengono equiparati a DecryptAction. Dopo una modifica autorizzata vengono verificati i valori globali salvati, le sovrascritture del profilo e il percorso reale del pilota. Vengono ripristinate soltanto le modifiche documentate dovute al pilota, riportandole esattamente allo stato precedente, senza disattivare indiscriminatamente i controlli.

Scansione HTTP/HTTPS: rispettare il relativo nodo padre

L’oggetto separato AntiVirusHTTPsConfiguration contiene direttamente ScanMode, FileSizeThreshold, AudioVideoFileScanning e PUADetection. Nel nodo figlio HTTPSConfigurations si trovano invece HTTPSScanningCA, DenyUnknownProtocol, AllowInvalidCertificate e NoHttpsNotification. HTTPSScanningCA appartiene quindi alla configurazione HTTP/HTTPS del percorso proxy, non a RSACA o ECCA delle impostazioni DPI. Questi campi non sostituiscono né la corrispondenza della regola DPI né Decrypt HTTPS during web proxy filtering nella Firewall Rule appropriata. Il contesto della scansione è illustrato in Inquadrare la scansione antimalware su Sophos Firewall.

ScanMode indica RealTime e BatchMode. FileSizeThreshold è espresso in KB; la tabella indica da 1 a 1572864, un massimo di 7 cifre e il valore predefinito 1024. I file che superano la soglia non vengono sottoposti a scansione; il valore predefinito documentato non è una raccomandazione valida per ogni ambiente.

Incongruenza dei valori non risolta: l’esempio XML mostra per AudioVideoFileScanning Enable/Disable, mentre la tabella dei parametri riporta on/off e il valore predefinito Disable. Da ciò non vengono dedotti alias intercambiabili. Anche DenyUnknownProtocol e AllowInvalidCertificate mostrano nell’esempio Enable/Disable, mentre la tabella indica soltanto on e on/off, rispettivamente; per PUADetection vi sono riportati valori simbolici. Prima di una modifica automatizzata, API help o Support devono confermare i valori validi per l’oggetto e la build. In assenza di chiarimenti, non eseguire la richiesta di scrittura interessata; non allentare i controlli sui certificati per rendere compatibile un’importazione.

Dopo una modifica approvata, la selezione della CA e i controlli salvati in Web > General settings, il percorso proxy/DPI che effettivamente determina la corrispondenza e l’emittente del certificato visibile vengono confrontati con lo stato precedente. Solo dopo si eseguono il test funzionale, il test positivo e il test negativo delle eccezioni. Una configurazione di scansione formalmente accettata non dimostra né la decrittazione né l’efficacia della scansione antimalware.

Limita le eccezioni

La regola predefinita Exclusions by website or category utilizza Don’t decrypt con Maximum compatibility e rimane nella prima posizione. Per impostazione predefinita, la lista Local TLS exclusion list è vuota; la lista Managed TLS exclusion list contiene siti incompatibili noti e viene mantenuta tramite aggiornamenti del firmware.

Modifica l’elenco locale in:

Web > URL groups > Local TLS exclusion list

I gruppi URL o le corrispondenze SNI sono più efficienti per le eccezioni di dominio rispetto a molti host FQDN. Secondo Sophos, ad esempio, 200 host FQDN comportano 200 ricerche per ogni nuova connessione SSL/TLS. La limitazione sulle eccezioni combinate di origine e destinazione va distinta dalla normale corrispondenza delle regole. Crea e utilizza gruppi URL in modo sicuro spiega l’ambito del dominio, i caratteri jolly e i test negativi.

Una regola di ispezione SSL/TLS personalizzata con Action: Don’t decrypt dovrebbe registrare il dominio, l’origine interessata, il motivo, il ticket, il proprietario e la data di revisione. Don’t decrypt non è un bypass incondizionato: restano valide le restrizioni del profilo di decrittazione selezionato. Per consentire SSL 2/3, compressione o cifrari sconosciuti per un caso legacy esplicitamente approvato, utilizzare un profilo con Allow without decryption insieme a Action: Don’t decrypt. Questa combinazione non rientra in una regola generale di Internet.

Le esclusioni SSL/TLS e le eccezioni Web risolvono diversi problemi. Un’eccezione TLS controlla la decrittografia su qualsiasi porta TCP in modalità DPI. Un’eccezione Web modifica i controlli della policy Web selezionati; in modalità proxy, influisce sul percorso proxy pertinente. Prima di apportare una modifica, determinare se è necessario escludere la decrittografia o solo il controllo web. Crea e testa le eccezioni Web in modo sicuro mostra il flusso di lavoro di selezione e regex.

Ambito dell’eccezione non chiaro: La guida all’esclusione dei siti afferma che le eccezioni di origine e destinazione non possono essere combinate; la guida alle regole offre entrambi i campi di corrispondenza. Questo non dimostra che sia consentita una Web Exception con IP di origine e destinazione combinati. Mantenere la limitazione dell’origine del pilota con un nome host confermato o un URL Group. Se sono indispensabili anche entrambi i criteri di eccezione IP, non attivare né ampliare l’esclusione prima di un chiarimento di Support specifico per la build. Non rimuovere un criterio solo per ottenere una corrispondenza.

Per un caso legacy esplicitamente approvato, creare un profilo come Allow_non-decryptable_profile in Profiles > Decryption profiles > Add. Impostare su Allow without decryption soltanto i campi necessari: SSL 2.0 and SSL 3.0, SSL compression o Unrecognized cipher suites. In Rules and policies > SSL/TLS inspection rules > Add, assegnare il profilo a una regola Don’t decrypt ristretta, con l’origine del pilota, un ambito di origine interno, la destinazione adeguata e un obiettivo noto. Questo riduce la protezione per un caso legacy giustificato; non autorizza generalmente questi protocolli.

Se manca un SNI utilizzabile, un URL Group o una regex di dominio non può identificare l’obiettivo. Dopo aver verificato il flusso reale, può essere adeguato un IP Host ristretto in Destination networks; un FQDN Host rimane un’alternativa basata su DNS con i costi indicati. Per le regex sono importanti l’inizio ancorato ^ e un test negativo; caratteri jolly ampi possono anche rallentare l’elaborazione. Il collegamento Web Exceptions precedente spiega la sintassi sicura completa e la differenza rispetto alle liste di domini.

Supporta Android con un ambito ristretto

Alcune connessioni Android utilizzano il certificate pinning. Il controllo della connettività, il Play Store o gli aggiornamenti potrebbero quindi fallire durante la decrittografia. Il flusso di lavoro documentato da Sophos utilizza una VLAN isolata o una rete wireless e un gruppo host FQDN contenente:

• *.play.googlezip.net
• *.gvt1.com
• *.app-measurement.com
• il dominio Google locale, ad esempio *.google.ch in Svizzera

Creare il gruppo in Hosts and services > FQDN host group > Add. In Hosts and services > FQDN host > Add, creare un host per dominio e assegnarlo direttamente al gruppo. Creare una nuova rete wireless Sophos in Wireless > Wireless networks > Add e il relativo oggetto di rete in Hosts and services > IP host > Add, con IP version: IPv4, Type: Network, indirizzo e maschera della propria rete. Per una VLAN o rete wireless isolata già esistente, utilizzare l’oggetto appropriato invece di creare una rete senza una necessità confermata. Confermare la zona di ingresso effettiva assegnata a tale interfaccia o VLAN; Wi-Fi è l’esempio per la rete wireless Sophos, non un requisito per ogni rete mobile.

La documentazione generale raccomanda un’eccezione per tutti i dispositivi Android; il procedimento concreto la limita alle destinazioni Google in una rete mobile isolata. Questo rollout segue il procedimento più ristretto con test positivi e negativi, non un bypass generale per tutte le connessioni Android. Passare a Web Proxy è una decisione architetturale distinta, non una correzione automaticamente equivalente del pinning.

Sopra la regola generale di decrittografia, aggiungi una regola di ispezione SSL/TLS con Action: Don’t decrypt, Decryption profile: Maximum compatibility, Source zone impostata sulla zona di ingresso effettiva della rete mobile (ad esempio Wi-Fi, LAN o una zona personalizzata configurata), la rete di dispositivi mobili come Source networks and devices, WAN come Destination zone e il gruppo Google come Destination networks. Si trova al di sotto dell’esclusione predefinita fissa ma al di sopra della regola generale di Decrittografia. Mantieni la rete mobile isolata dalle risorse interne sensibili.

Verifica la modifica con un dispositivo pilota Android: controlla la connettività e l’accesso tramite browser, scarica un’app di test approvata da Google Play e aggiorna un’app installata tramite Google Play. Ogni operazione deve concludersi con successo. Nel Log viewer, soltanto le destinazioni Google previste devono corrispondere all’eccezione; un’altra destinazione HTTPS dalla stessa VLAN deve comunque utilizzare la regola di decrittografia prevista. Conferma la zona di origine e l’oggetto di origine effettivi, la corrispondenza con l’eccezione Google e la corrispondenza con la regola di decrittografia prevista per questi flussi reali. Utilizza un dispositivo pilota gestito il cui specifico browser o app di test si fidi della CA di ispezione; verifica il corretto funzionamento e le evidenze nel certificato e nei log per la destinazione decrittografata. Mantieni i client o le app per cui non è possibile gestire l’attendibilità della CA di ispezione fuori dall’ambito di Decrypt. Questo test negativo impedisce l’accettazione di un’eccezione che funziona ma è troppo ampia. Crea eccezioni Web ed esclusioni TLS in modo sicuro copre ulteriori metodi e limitazioni SNI.

Verificare l’efficacia

Una simulazione delle policy, un client reale e i log rispondono a domande diverse. Combinateli per un test di accettazione affidabile.

In Diagnostics > Tools > Pop-out tools > Policy tester, seleziona Firewall, SSL/TLS, and web e imposta l’IP di origine, la destinazione o l’URL, il protocollo e, se necessario, la porta. Senza un protocollo, lo strumento testa HTTP utilizzando la porta predefinita specifica del protocollo. Il tester delle policy simula il traffico web trasparente; non simula le rotte SD-WAN e le regole con gli indirizzi MAC in Source networks and devices non trovano corrispondenza nel test. Web policy only verifica solo la policy Web. Il risultato è quindi una previsione, non una prova del percorso effettivo dei dati.

Esegui quattro test mirati sul client:

1. Prima della modifica, registrare il dominio di destinazione, l’emittente del certificato, il tempo di risposta e se l’applicazione aziendale funziona.
2. Aprire una destinazione positiva approvata e verificare il percorso di ispezione scelto. Per DPI, il browser deve mostrare la CA di nuova firma selezionata per DPI come emittente e nel Log viewer deve risultare una corrispondenza con la regola di decrittografia e il profilo di decrittografia previsti. Per Web Proxy, verificare la CA selezionata in Web > General settings > HTTPS scanning certificate authority (CA), la regola firewall effettivamente corrispondente con Use web proxy instead of DPI engine e Decrypt HTTPS during web proxy filtering, e le evidenze corrispondenti nei log proxy/Web della richiesta riuscita. Non richiedere una corrispondenza con una regola o un profilo DPI né una voce nel widget DPI per una connessione decrittografata dal proxy.
3. Apri una destinazione deliberatamente esclusa. Deve corrispondere alla regola Don't decrypt prevista; il browser non deve mostrare un certificato rifirmato dal firewall lì.
4. Una seconda destinazione non esclusa dallo stesso ambito client deve essere ancora decrittografata. Questo è il test negativo dell’eccezione.

Se una policy web fa parte della progettazione, blocca anche una categoria di test o un URL di test specificamente approvato per questo scopo. Eseguire un test del malware solo con un oggetto di test del fornitore documentato e innocuo e un risultato atteso predefinito. Prima e dopo il progetto pilota, confronta il carico della CPU e della memoria, i tempi di risposta e gli errori dell’utente nello stesso intervallo di tempo.

Leggi correttamente Control Center e Log viewer

Il widget Centro di controllo è denominato SSL/TLS connections. I suoi dettagli vengono aggiornati ogni cinque minuti. Le sessioni coprono le ultime 24 ore e gli errori gli ultimi 7 giorni; Failed si reimposta a mezzanotte. I dati dettagliati non includono le connessioni Web Proxy. Decryption peak appare solo vicino o sopra il picco e Decryption limit solo vicino al limite specifico del dispositivo. Non esiste quindi una soglia universale per tutti gli apparecchi.

Apri Log viewer in alto a destra e seleziona il modulo SSL/TLS inspection. Una connessione TLS viene registrata al termine dell’handshake e alla sua chiusura. Contano l’azione, la regola, il profilo di decrittografia, l’origine, la destinazione, il dominio e il motivo dell’errore; i colori da soli non costituiscono un criterio di accettazione affidabile. In Manage > Exclude è possibile aggiungere domini o sottodomini all’elenco di esclusione TLS locale e categorie all’esclusione predefinita. Exclude non è disponibile per gli ID errore 19004 e 19005.

Un evento Don't decrypt dimostra solo che la connessione non è stata decrittografata. Solo la Regola, la corrispondenza dell’elenco e il test negativo mostrano se l’eccezione è giustificata e sufficientemente ristretta.

Circoscrivere gli errori ed eseguire il rollback in sicurezza

Quando si verifica un incidente, inizialmente limitare il caso a un client, un dominio, un punto nel tempo, una regola del firewall e una regola di ispezione SSL/TLS.

• Se il browser visualizza un avviso relativo al certificato, confrontare l’emittente visibile con la CA utilizzata dal percorso DPI o proxy effettivamente in uso. Quindi controllare l’archivio attendibilità del client, la catena root/subordinata e il nome host.
• Se mancano eventi SSL/TLS, verificare innanzitutto la corrispondenza della regola del firewall e la modalità. Quindi verificare che Rules and policies > SSL/TLS inspection rules e Advanced settings > SSL/TLS engine > Enabled siano attivi.
• Se il traffico è consentito ma non decrittografato, cercare dall’alto verso il basso l’esclusione predefinita fissa, l’elenco gestito/locale o una regola Don't decrypt personalizzata. Quindi ripetere il test negativo.
• Se il filtro web non si applica, controlla l’effettiva regola del firewall per la sua politica web, Scan HTTP and decrypted HTTPS, Block QUIC protocol e la modalità DPI/proxy. La presenza di una policy Web non dimostra la decrittografia.
• Se solo un’applicazione fallisce, utilizzare il motivo dell’errore, la versione TLS, il cifrario, la catena di certificati e il certificate pinning per guidare la decisione successiva. Limita qualsiasi eccezione temporanea e assegnale una data di revisione.
• Se il carico aumenta, ridurre l’ambito pilota e confrontare la stessa finestra temporale prima e dopo la modifica. Valutare gli avvisi di picco o limite per l’appliance specifica.

Disabilitare SSL/TLS engine solo brevemente per la risoluzione dei problemi. Mentre è disabilitato, non si applica alcuna regola di ispezione SSL/TLS e il motore DPI non applica la policy Web del firewall a HTTPS; la decrittografia HTTPS del proxy Web rimane inalterata. Disabilitarlo non è quindi un sostituto equivalente e a basso rischio della disabilitazione specifica della regola pilota.

Testare l’IPS indipendente dalla porta solo con uno stato iniziale noto

Per impostazione predefinita, SFOS controlla il traffico decrittografato rispetto alle firme IPS su ogni porta TCP. Per un falso positivo riproducibile, documentare l’ID firma, l’origine, la destinazione, la porta TCP, la regola del firewall, la regola di ispezione e la build SFOS. Preferire un’eccezione di firma ristretta con Action: Allow packet nella policy IPS attualmente in uso; Configura e testa Sophos Firewall IPS descrive questo metodo.

Un possibile sintomo di un problema con l’ispezione indipendente dalla porta è il rilevamento ripetuto della stessa firma IPS sullo stesso sito web. La sola ripetizione non dimostra un falso positivo. Si verifica la corrispondenza esatta della Signature ID e della destinazione nei log, si controlla il flusso di lavoro legittimo interessato e si valuta il rischio prima di approvare un’eccezione di firma con ambito ristretto e reversibile.

L’ispezione più approfondita delle potenziali minacce può aumentare il carico e ridurre leggermente il throughput del traffico HTTPS decrittografato rispetto alle versioni precedenti di Sophos Firewall. Si tratta di un possibile effetto legato alla versione, non di un calo garantito né di una prova di regressione della build attualmente in uso. Per contestualizzare i risultati, si confrontano il throughput, il carico della CPU e della memoria e il tempo di risposta con un carico di traffico comparabile nella stessa finestra temporale; un singolo confronto non sostituisce l’analisi delle cause.

Un confronto globale nella Console dispositivo è consentito solo se il valore corrente esatto, on o off, è già noto dal record di modifica o da una configurazione di cui è stato eseguito il backup in modo affidabile. La documentazione ufficiale di SFOS 22 non fornisce alcun controllo preliminare di sola lettura per questa impostazione. Se lo stato iniziale è sconosciuto, non eseguire il test.

Solo con uno stato iniziale documentato di on è possibile impostare quanto segue per un confronto preparato:

set ips scan_decrypted_port_agnostic off
set ips scan_decrypted_port_agnostic on

Il secondo comando qui ripristina solo lo stato iniziale noto di on. Se lo stato iniziale era off, non abilitarlo ciecamente; conservare off o ripristinarlo esattamente dopo qualsiasi modifica autorizzata. Questa impostazione globale influisce sull’intero firewall e potrebbe ridurre leggermente il throughput o, con off, restringere l’ambito di ispezione. Documentare il risultato e l’intervallo temporale senza considerarlo, da solo, una prova di una causa generale.

Eseguire il rollback in un ordine prestabilito

Un rollback ripristina lo stato iniziale documentato anziché introdurre una nuova architettura:

1. Prima di disabilitare TLS decrypt pilot client, controllare la regola registrata che corrisponderà in seguito e il piano di ripristino approvato: una regola Decrypt più ampia situata più in basso può subentrare. Disabilitare la regola pilota e ripristinare, nell’ordine preparato, le modifiche documentate apportate solo per il pilota alle regole firewall, alla modalità DPI/proxy, alla policy Web e alle impostazioni globali, senza modifiche simultanee non correlate.
2. Stabilire nuove connessioni dal client pilota e verificare il percorso di corrispondenza iniziale registrato, l’emittente del certificato, i log e il funzionamento dell’applicazione. Non dare per scontato che le sessioni esistenti vengano immediatamente rivalutate. Se subentra una regola Decrypt situata più in basso o il ripristino non riesce, interrompere la pulizia: il rollback non è completo. Identificare la corrispondenza effettiva e ripristinare solo l’ordine delle regole, i criteri e le impostazioni autorizzati necessari a riprodurre lo stato iniziale, quindi ripetere questi controlli con nuove connessioni.
3. Solo se il percorso iniziale non era decrittografato e il piano di ripristino approvato lo richiede, utilizzare una regola Don't decrypt limitata nel tempo e con ambito ristretto per l’origine pilota e le destinazioni necessarie, posizionata prima della regola Decrypt inferiore che corrisponde involontariamente, ma sotto le esclusioni approvate applicabili. Eseguire sia il test positivo sia quello negativo; non improvvisare un’esclusione ampia né sostituire un percorso precedentemente verificato con uno non verificato.
4. Rimuovere le eccezioni temporanee, gli oggetti di test e l’attendibilità e le impostazioni della CA introdotte solo per il progetto pilota soltanto dopo aver verificato il ripristino e ottenuto l’approvazione della rimozione. Mantenere l’attendibilità della CA ancora richiesta dal percorso attivo finché questi controlli non hanno esito positivo; non rimuovere le CA condivise senza verificare le dipendenze.
5. Registrare l’ID regola, il client, la destinazione, la CA visibile, l’evento di registro, l’ora e le impostazioni ripristinate nel record delle modifiche.

La policy Web può rimanere configurata, ma senza la decrittografia non può eseguire la scansione del payload HTTPS crittografato. Ripristina il proxy Web solo se quello era lo stato iniziale verificato. Non disabilitare l’intero motore SSL/TLS come rollback standard perché ciò interrompe tutte le regole TLS DPI e l’applicazione della policy Web DPI a HTTPS.

Interrompi l’implementazione non appena un’applicazione business-critical fallisce, vengono visualizzati avvisi di certificato all’esterno del gruppo pilota, l’ambito corrisponde in modo più ampio del previsto o il carico e gli errori superano i limiti predefiniti. Espandere gradualmente il gruppo di origine solo dopo che il test positivo, il test negativo dell’eccezione, le applicazioni aziendali, i registri, il feedback degli utenti e il profilo di carico soddisfano tutti i criteri concordati per tutto il periodo concordato.

Durante il funzionamento, esamina le esclusioni, gli errori TLS, le nuove applicazioni, il carico e il feedback degli utenti secondo una pianificazione definita. Mantieni le eccezioni temporanee solo finché il proprietario, il motivo e la data di revisione rimangono validi; in caso contrario, rimuovile dopo un nuovo test positivo e negativo.

Domande frequenti