Configurare Direct Web Proxy su Sophos Firewall con un file PAC

Con Direct Web Proxy, i browser e le applicazioni compatibili con i proxy inviano deliberatamente le proprie connessioni HTTP e HTTPS a Sophos Firewall. Questo comportamento è diverso dal proxy web trasparente e da DPI Engine: il client conosce la destinazione proxy e si collega normalmente alla porta TCP 3128.

Direct Web Proxy è utile quando il traffico web deve essere gestito centralmente tramite un file PAC, autenticato per utente o elaborato con funzioni che richiedono il proxy web. Non è però un percorso Internet generale per qualsiasi applicazione. Solo il traffico che utilizza effettivamente la configurazione proxy segue questo percorso.

⚠️ Un client con accesso al proxy web può raggiungere tramite questo percorso i servizi HTTP e HTTPS locali del firewall, anche se WebAdmin, User Portal o VPN Portal non sono attivati per la sua zona in Device access. Per questo motivo, il proxy viene aperto inizialmente solo per un client pilota e queste destinazioni di amministrazione vengono sottoposte esplicitamente a test negativi.

Questa procedura riguarda un client pilota IPv4 gestito. Per i client solo IPv6, configurare NAT64 con Direct Web Proxy spiega la regola IPv6 separata verso il proxy e la regola IPv4 verso la destinazione A-only.

Direct Web Proxy in dieci passaggi

1. Definire un client pilota gestito, il suo IP fisso e le destinazioni web necessarie.
2. Documentare FQDN del proxy, DNS, porta di ascolto e dipendenze proxy esistenti.
3. In Web > General settings, controllare Web proxy listening port e le porte di destinazione consentite.
4. In Administration > Device access, consentire il servizio Web proxy solo per il pilota e l’indirizzo firewall previsto.
5. Creare una regola firewall dedicata e con logging, con il pilota come origine, WAN come destinazione, servizio TCP 3128 e la Web Policy desiderata.
6. Preparare un file PAC con destinazioni interne DIRECT consapevoli e senza fallback Internet che aggiri il proxy.
7. Distribuire l’URL PAC solo al client pilota e verificare la configurazione proxy effettivamente caricata.
8. Testare una richiesta HTTP/HTTPS consentita e una bloccata e controllare la Firewall Rule ID prevista.
9. Eseguire test negativi sui portali locali del firewall, sulla decrittografia TLS, sulle applicazioni senza supporto proxy e su un’interruzione del proxy.
10. Solo a quel punto aggiungere altri client gestiti e documentare rollback, responsabile e data di revisione.

Direct Web Proxy, proxy trasparente o DPI?

I tre termini descrivono percorsi del traffico diversi:

• Direct Web Proxy: Il client è configurato esplicitamente per il firewall e la relativa porta proxy. Il browser, il sistema operativo o l’applicazione invia la richiesta a fw01.corp.example:3128.
• Proxy web trasparente: Il client non conosce il proxy. Quando il servizio è attivo per la sua zona, il firewall intercetta in modo trasparente HTTP sulla porta 80 e HTTPS sulla porta 443.
• DPI Engine: Il firewall elabora il traffico instradato senza imporre un proxy web classico e può ispezionare HTTP o TLS su altre porte in base alle regole firewall e di SSL/TLS inspection.

L’opzione Use web proxy instead of DPI engine in una regola firewall non è necessaria affinché un client configurato esplicitamente utilizzi Direct Web Proxy. Il percorso del client deriva dalla configurazione proxy. L’opzione determina se la regola usa il proxy web al posto di DPI Engine per filtrare il normale traffico web sulle porte comuni.

La scelta completa della modalità, comprese le funzioni esclusive del proxy, la configurazione TLS e la migrazione controllata delle regole, è descritta in Scegliere correttamente DPI Engine o Web Proxy.

Sophos continua a indicare singole funzioni che richiedono Proxy Mode, tra cui SafeSearch, YouTube Restrictions, le restrizioni dei domini Google Workspace, Pharming Protection, Web Cache o un Parent Proxy. Web Protection su Sophos Firewall spiega la scelta della policy e della protezione.

Quando Sophos Firewall deve inviare Web Requests a un’altra istanza proxy, configurare un upstream proxy in WAN o LAN/DMZ spiega il percorso separato di regole, NAT e validazione.

Direct Web Proxy modifica anche la visibilità del traffico. Il client si collega prima al firewall, che poi crea la connessione verso la destinazione. Sophos documenta quindi due limiti importanti:

• Una IPS Policy si applica tra il proxy e WAN, non tra l’utente e il proxy.
• Una Traffic Shaping Policy non si applica al traffico Direct Proxy.

Se un’applicazione non può utilizzare un proxy esplicito, non si deve presumere che un file PAC ne intercetti le connessioni. Per tale applicazione rimane necessario un normale percorso instradato tramite DPI, firewall o proxy dedicato.

Esempio e valori sostituibili

L’articolo utilizza un piccolo progetto pilota:

• Client pilota: CLIENT-PROXY-01
• IP fisso del client: 10.20.30.50
• zona del client: LAN
• FQDN del firewall e destinazione proxy: fw01.corp.example
• porta Direct Web Proxy: 3128
• URL PAC: https://config.corp.example/proxy.pac
• zona DNS interna: .corp.example
• regola firewall: LAN_DirectProxy_Pilot
• Web Policy: Web_Standard_Pilot

Sostituire 10.20.30.50 con l’IP fisso che il firewall vede effettivamente come origine del pilota. DHCP dovrebbe fornire una prenotazione per tale indirizzo. Dietro l’indirizzo non deve trovarsi un NAT che nasconde altri dispositivi.

fw01.corp.example e config.corp.example sono nomi di documentazione. Devono essere sostituiti con FQDN risolvibili internamente e coperti dai certificati appropriati. Il FQDN del proxy punta all’indirizzo LAN o di gestione previsto del firewall. L’URL PAC punta a un server web interno controllato o a un percorso di gestione degli endpoint esistente, non a una posizione pubblica arbitraria.

La porta 3128 è il valore predefinito di Direct Web Proxy. Se si utilizza un altro Web proxy listening port, Device Access, regola firewall, file PAC, browser, SD-WAN Route e test devono contenere la stessa porta. Il nome della regola o della policy è liberamente selezionabile, ma dovrebbe indicare chiaramente scopo, origine e stato pilota.

Preparare l’accesso proxy e la regola di protezione

Definire il listener e le porte di destinazione consentite

Controllare le impostazioni di base del proxy in Web > General settings > Web proxy configuration:

1. Web proxy listening port: 3128 in questo esempio.
2. Allowed destination ports: solo le porte a cui i client devono realmente collegarsi attraverso il proxy.
3. Minimum TLS version: versione minima condivisa per il proxy web e Captive Portal; una modifica interessa entrambe le funzioni.

Le porte di destinazione consentite non corrispondono al listener. Il client si collega alla porta 3128 del firewall, ma può utilizzare HTTP CONNECT per richiedere, ad esempio, una destinazione esterna sulla porta 443. Aggiungere porte di destinazione non standard solo dopo un test specifico dell’applicazione. Un elenco ampio trasforma inutilmente il proxy in un tunnel generico.

Prima di modificare la porta, cercare file PAC, GPO, policy del browser, host RDS, SD-WAN Routes e sistemi di monitoraggio esistenti. Il listener è un’impostazione condivisa e non un valore da cambiare solo per un singolo pilota.

La Device Console può gestire separatamente le versioni TLS minime di Web Proxy e Captive Portal e contiene altri valori globali per timeout, header Via, loop proxy e categorizzazione degli URL. Verificare in sicurezza le impostazioni HTTP Proxy spiega baseline documentata, test controllato e rollback senza confondere la configurazione con il tuning globale.

Decidere separatamente la cache dei contenuti web

In Web > General settings > Web content caching, Enable web content cache conserva una copia dei contenuti visitati di recente per ridurre l’uso della banda e migliorare le prestazioni. SFOS applica questa impostazione solo con il web proxy; non aggiunge una cache al percorso DPI.

Lasciare la cache sullo stato di riferimento documentato se il pilota del proxy non ha un obiettivo misurabile di banda o prestazioni. Se viene attivata, registrare prima lo stato precedente, ripetere dal client pilota la stessa richiesta statica rappresentativa e confrontare i log del proxy e il trasferimento WAN, confermando al tempo stesso la Rule ID e la policy web previste. Le applicazioni aziendali dinamiche o autenticate richiedono anche un test funzionale negativo; un caricamento più rapido non dimostra da solo l’intervento della cache.

Per il rollback, ripristinare lo stato precedente di Enable web content cache e ripetere i test della richiesta e della policy. In questo modo si annulla solo questa modifica di configurazione, senza cambiare scansione, TLS, Policy Overrides o il progetto PAC.

Comprendere Pharming Protection

In Web > General settings > Malware and content scanning, Enable pharming protection protegge il percorso proxy dal pharming: gli utenti vengono reindirizzati da un dominio legittimo a un sito fraudolento dall’aspetto ingannevole. SFOS ripete la query DNS prima di stabilire la connessione per contrastare il domain name poisoning. È una protezione del proxy, non una configurazione del servizio DNS né la prova che ogni risposta DNS sia attendibile.

Prima di una modifica, documentare il valore precedente e i client proxy interessati. Nel pilota, verificare le stesse destinazioni consentite e bloccate e le applicazioni critiche con nuove connessioni, confrontando Rule ID, web policy ed errori in Log Viewer. Il caricamento di una pagina non dimostra da solo che un attacco di pharming sia stato impedito. In caso di regressione, ripristinare lo stato precedente documentato; non modificare contemporaneamente resolver, PAC e web policy.

Limitare Device Access al pilota

Il servizio Web proxy è attivo per impostazione predefinita per LAN e Wi-Fi. Un’ulteriore eccezione Accept non limita un’autorizzazione ampia della zona già attiva. Per un vero accesso pilota, l’autorizzazione ampia deve quindi rimanere disattivata o essere sostituita prima, in modo controllato, con eccezioni più ristrette.

In Administration > Device access > Local service ACL exception rule > Add:

1. Rule name: Allow_DirectProxy_Pilot
2. Rule position: sopra un’eccezione Drop corrispondente
3. IP version: IPv4
4. Source zone: LAN
5. Source Network / Host: CLIENT-PROXY-01 con 10.20.30.50
6. Destination host: indirizzo specifico del firewall a cui viene risolto fw01.corp.example
7. Services: Web proxy
8. Action: Accept

Prima di disattivare un’autorizzazione ampia della zona, controllare se altri client o servizi utilizzano già il proxy diretto o trasparente. La guida a Device Access e Local Service ACL spiega in dettaglio l’ordine delle regole, la matrice delle zone e le regole di eccezione.

Collegare la Web Policy e la regola firewall

Preparare la Web Policy in Web > Policies. Contiene le categorie, URL Groups, regole per utenti o gruppi e azioni desiderate. Per il pilota dovrebbe essere definita almeno una destinazione deliberatamente consentita e una deliberatamente bloccata.

Creare quindi una regola IPv4 dedicata in Rules and policies > Firewall rules:

• Rule name: LAN_DirectProxy_Pilot
• Action: Accept
• Log firewall traffic: attivo
• Source zones: LAN
• Source networks and devices: CLIENT-PROXY-01
• Destination zones: WAN
• Destination networks: Any o un gruppo di destinazioni pianificato in modo più ristretto
• Services: servizio TCP dedicato per 3128
• Match known users: attivare solo se il percorso di autenticazione scelto ha già superato un test positivo
• Use web authentication for unknown users: attivare solo se gli utenti sconosciuti devono autenticarsi tramite AD SSO o Captive Portal e il servizio corrispondente è raggiungibile da LAN in Device access
• Web filtering > Web policy: Web_Standard_Pilot
• Scan HTTP and decrypted HTTPS: solo con la licenza appropriata e un modello di scansione consapevole

Secondo Sophos, per Direct Proxy è possibile usare anche Any come servizio, ma è più ampio del necessario. Un servizio TCP dedicato per il listener effettivo rende il pilota più comprensibile. Dopo aver selezionato una Web Policy e altre funzioni di protezione, controllare nuovamente l’intera regola. I principi delle regole firewall spiegano ordine, logging, corrispondenza degli utenti e campi di protezione.

Per Direct Proxy, Destination zones deve essere WAN o Any, affinché SFOS inoltri la richiesta al componente web proxy. Questo vale anche quando il web server richiesto si trova effettivamente in LAN o DMZ. Destination networks, invece, può contenere la destinazione web reale o Any.

Block QUIC protocol in questa specifica regola non controlla in modo affidabile il bypass: una regola limitata a TCP 3128 non corrisponde al traffico UDP 443 diretto. Bloccare o controllare quindi l’accesso Internet diretto del pilota con una regola separata i cui criteri corrispondano a tale traffico. Se l’accesso web diretto rimane consentito, bloccare QUIC in quella regola. Controllare QUIC su Sophos Firewall spiega il contesto.

Un Linked NAT non è automaticamente necessario per questo pilota. Il percorso Internet creato dal firewall richiede tuttavia un gateway WAN appropriato e la traduzione dell’origine valida per l’ambiente. Routing e NAT vengono verificati separatamente.

Creare e distribuire il file PAC

Un esempio PAC deliberatamente ristretto

Un file PAC è JavaScript con la funzione FindProxyForURL. Questo esempio lascia passare direttamente solo i nomi interni brevi, la zona DNS interna e le reti private elencate. Tutte le altre destinazioni devono utilizzare il proxy:

function FindProxyForURL(url, host) {
  if (isPlainHostName(host) || host === "corp.example" ||
      dnsDomainIs(host, ".corp.example")) {
    return "DIRECT";
  }

  var isIPv4Literal = /^\d{1,3}(\.\d{1,3}){3}$/.test(host);
  if (isIPv4Literal && (
      isInNet(host, "10.0.0.0", "255.0.0.0") ||
      isInNet(host, "172.16.0.0", "255.240.0.0") ||
      isInNet(host, "192.168.0.0", "255.255.0.0"))) {
    return "DIRECT";
  }

  return "PROXY fw01.corp.example:3128";
}

Adattare corp.example, .corp.example, le reti private e il FQDN del proxy al proprio ambiente. Il confronto separato con corp.example include l’apice della zona; dnsDomainIs(host, ".corp.example") include i suoi sottodomini. Non tutte le reti RFC1918 devono essere raggiungibili internamente. È più corretto mantenere un elenco dei domini e delle reti interne effettivamente necessari.

L’esempio non chiama deliberatamente dnsResolve() per i nomi host pubblici. Queste funzioni PAC causano risoluzioni DNS aggiuntive sul client e possono rallentare l’elaborazione; in questo caso il proxy risolve i nomi esterni. I nomi interni vengono classificati tramite le regole di dominio o, quando la richiesta contiene direttamente un indirizzo IPv4, tramite isInNet(). Se un ambiente richiede eccezioni più complesse dipendenti dal DNS, pianificarle singolarmente e testarle con i browser utilizzati.

L’esempio non contiene deliberatamente DIRECT dopo l’istruzione proxy. Un valore di ritorno come PROXY fw01.corp.example:3128; DIRECT consente al traffico Internet di proseguire direttamente in caso di guasto del proxy. Questo aumenta la disponibilità, ma aggira la Web Policy, l’autenticazione proxy e il logging del proxy. Non consigliamo questo fallback fail-open per un percorso di sicurezza obbligatorio.

Anche le eccezioni interne DIRECT sono bypass. Vanno aggiunte solo se la destinazione deve davvero essere raggiunta direttamente ed esiste un altro percorso di controllo. Domini SaaS sensibili, provider di identità o wildcard generiche non devono essere aggiunti per precauzione all’elenco dei bypass.

Distribuire il file PAC in modo controllato

1. Ospitare il file PAC su un endpoint HTTPS interno con un certificato attendibile.
2. Assicurarsi che https://config.corp.example/proxy.pac possa essere scaricato senza un proxy già funzionante.
3. Assegnare l’URL PAC solo al pilota tramite GPO, MDM o una policy del browser gestita.
4. Documentare in precedenza eventuali configurazioni proxy manuali esistenti e altre impostazioni PAC o WPAD.
5. Riavviare completamente il browser e le applicazioni interessate.
6. Controllare quale URL PAC è stata effettivamente caricata nella policy del browser o del sistema operativo.
7. Bloccare in modo controllato l’accesso diretto a Internet al di fuori del percorso proxy per il pilota o almeno testarlo come bypass.

L’individuazione automatica WPAD non è necessaria per questa procedura. Un URL PAC esplicito e gestito è più facile da identificare e ripristinare. In questo modello SFOS fornisce il listener; la distribuzione, l’hosting e il versionamento del file PAC rimangono compiti della gestione dei client e dei server web.

Testare Direct Web Proxy

Verificare il listener e l’applicazione del PAC

Questi controlli in sola lettura sono utili su un client pilota Windows:

Resolve-DnsName fw01.corp.example
Test-NetConnection fw01.corp.example -Port 3128

Il DNS deve restituire l’indirizzo previsto del firewall e il test TCP deve raggiungere il listener. Un test della porta riuscito non dimostra ancora Web Policy, autenticazione, decrittografia TLS o connettività Internet.

Controllare quindi nel browser la policy proxy o PAC effettivamente applicata. Una vecchia impostazione locale, un secondo profilo di gestione o contenuto PAC memorizzato nella cache può sostituire la configurazione prevista.

Verificare il traffico consentito e bloccato

1. Aprire una nuova finestra privata del browser.
2. Aprire una destinazione HTTP o HTTPS deliberatamente consentita.
3. Aprire una destinazione deliberatamente bloccata da Web_Standard_Pilot.
4. In Log viewer, controllare ora, origine, utente, Web Policy, azione e Firewall Rule ID.
5. Per HTTPS, annotare se la connessione è stata decrittografata o deliberatamente non decrittografata.
6. In Diagnostics > Packet capture, se necessario limitare la cattura all’origine 10.20.30.50, alla porta proxy e alla destinazione.
7. Testare un’applicazione senza supporto proxy e confermare che non venga valutata erroneamente come traffico proxy.
8. Assegnare temporaneamente al client pilota una copia PAC di test con una porta proxy deliberatamente non utilizzata e verificare che il traffico Internet fallisca come previsto anziché aggirare il proxy. Ripristinare quindi la versione PAC di produzione.

Il successo non significa semplicemente che un sito web viene caricato. La richiesta deve utilizzare la Rule ID e la Web Policy previste, il test di blocco deve effettivamente bloccare e un guasto del proxy deve corrispondere al modello fail-closed scelto.

Verificare che i servizi di gestione non siano esposti

Dal client pilota testare gli indirizzi HTTP e HTTPS noti del firewall, in particolare:

• WebAdmin
• User Portal
• VPN Portal
• Captive Portal
• altri servizi HTTP/HTTPS locali sull’indirizzo firewall utilizzato

Lo scopo non è forzare un accesso riuscito. Il test determina se il servizio diventa raggiungibile attraverso il proxy. Se è visibile un servizio locale non consentito dal modello di sicurezza, interrompere il rollout. Device Access non può bloccare successivamente, in base al portale di destinazione, queste richieste HTTP/HTTPS generate internamente dal proxy.

Separare autenticazione, TLS, SD-WAN e HA

L’identità utente è un componente separato

Direct Web Proxy può essere utilizzato con o senza identità utente. Gli utenti già identificati tramite STAS o un altro metodo clientless possono essere associati con Match known users. Per autenticare attivamente gli utenti sconosciuti, la regola richiede anche Use web authentication for unknown users; selezionare AD SSO o Captive Portal in Authentication > Web authentication. I servizi corrispondenti devono essere consentiti per la zona client in Administration > Device access. La sola configurazione proxy non autentica nessuno.

Per RDS o altri host multi-utente sui quali più persone condividono lo stesso IP di origine, Per-Connection AD SSO è la procedura specialistica adatta. Autentica separatamente ogni connessione proxy HTTP/HTTPS; il traffico non proxy non riceve questa identità utente.

La decrittografia HTTPS richiede una CA attendibile

Scan HTTP and decrypted HTTPS non attiva la decrittografia. In modalità proxy web occorre utilizzare anche Decrypt HTTPS during web proxy filtering. La CA distribuita ai client deve corrispondere esattamente a quella selezionata in Web > General settings > HTTPS decryption and scanning.

Il rollout sicuro è descritto in Introdurre correttamente TLS Inspection. Distribuire il certificato CA di Sophos Firewall spiega distribuzione e verifica della CA di ri-firma. Certificate Pinning, trust store separati e applicazioni con un comportamento TLS insolito richiedono test mirati invece di un’eccezione ampia.

Verificare i blocchi HTTPS senza decrittografia abituale

La Web Policy può agire anche sulle destinazioni HTTPS normalmente non decrittografate, usando le informazioni sul dominio trasmesse in chiaro nel primo handshake TLS. Scegliere il comportamento di notifica in Web > General settings > HTTPS decryption and scanning > Block undecrypted connections:

• Decrypt connection and show block page: SFOS decrittografa la connessione per mostrare una pagina HTML di blocco con il motivo. Per le pagine di blocco, avviso, quota o errore, il client deve considerare attendibile la Signing CA; altrimenti può apparire un avviso sul certificato anziché la spiegazione. Non equivale alla decrittografia e all’ispezione abituali di tutti i contenuti HTTPS consentiti.
• Drop connection without the block page: SFOS interrompe la connessione durante l’handshake SSL/TLS. Il browser mostra un errore di connessione, senza il motivo del blocco. Questo non dimostra un guasto del listener o della WAN.

Registrare il valore precedente prima di modificarlo: l’impostazione è condivisa e non limitata al client pilota. Tramite il proxy esplicito, provare un dominio HTTPS deliberatamente bloccato e normalmente non decrittografato e una destinazione consentita; correlare Rule ID, Web Policy, azione e risultato del browser in Log Viewer. Verificare anche gli strumenti di aggiornamento e gli altri client non browser per rilevare errori di certificato, errori di connessione e cicli di tentativi. In caso di regressione, ripristinare il valore di notifica precedente e ripetere entrambe le richieste invece di allentare globalmente la Web Policy.

Testare separatamente SD-WAN e HA

Una SD-WAN Route con i servizi HTTP e HTTPS non corrisponde al traffico Direct Proxy su 3128. Utilizzare la porta proxy effettiva oppure consapevolmente Any. Source Network e Incoming Interface non corrispondono ai reply packets in questo caso particolare. Il percorso di ritorno del proxy richiede inoltre almeno un gateway WAN o una rotta statica adatta. La spiegazione completa si trova in Configurare e testare le SD-WAN Routes.

In HA non si deve promettere la continuazione senza interruzioni delle sessioni proxy o di autenticazione esistenti. Dopo un failover controllato, creare una nuova connessione del browser e verificare nuovamente file PAC, Rule ID, policy e decrittografia. Ogni nodo conserva i log del traffico che ha elaborato; durante l’analisi conta quindi il nodo che gestiva il traffico al momento dell’evento.

Risoluzione sistematica dei problemi

La porta proxy non è raggiungibile

Controllare risposta DNS, indirizzo firewall, listener, zona client e Web proxy in Device Access. Per un’eccezione ACL devono corrispondere origine, Destination host, servizio, azione e posizione. Un ping riuscito non dimostra il listener TCP; Test-NetConnection è il controllo preliminare più specifico.

Il browser accede direttamente a Internet

Controllare URL PAC effettivo, contenuto del file caricato, eccezioni locali del browser e altri profili GPO o MDM. Un fallback DIRECT dopo PROXY crea deliberatamente un bypass quando il proxy non è raggiungibile. Anche le applicazioni con un proprio stack di rete possono ignorare le impostazioni proxy del sistema.

Il proxy restituisce l’errore 407 o richiede credenziali

Si tratta di un problema di autenticazione, non di un guasto del listener. Controllare metodo di autenticazione, rilevamento utenti, importazione gruppi, supporto del browser e, se applicabile, FQDN/SPN. Non ampliare preventivamente la regola a Any solo per eliminare la richiesta di credenziali.

Il sito web si carica, ma la Web Policy non viene applicata

Controllare insieme regola firewall, ordine, origine, servizio 3128, Web Policy selezionata e Rule ID. Una richiesta proxy riuscita potrebbe aver trovato corrispondenza con un’altra regola o una regola più ampia. Il test controllato delle regole combina Policy Test, Log Viewer e Packet Capture.

HTTPS mostra errori di certificato

Controllare se la decrittografia è attiva, quale CA usa il proxy web e se quella stessa CA è presente nel trust store del client. Se falliscono solo singole applicazioni, esaminare Certificate Pinning, un trust store dedicato, la versione TLS e un’eccezione il più possibile ristretta.

Una singola applicazione o porta di destinazione non funziona

Stabilire innanzitutto se l’applicazione supporta un proxy esplicito. Controllare quindi Allowed destination ports, bypass PAC, DNS e comportamento TLS. Aggiungere una porta di destinazione non standard solo per l’applicazione specifica e convalidarla con una richiesta reale.

La SD-WAN Route o il percorso WAN è imprevisto

Controllare la corrispondenza del servizio con la porta proxy, Rule ID, gateway WAN, rotta statica e Route Precedence. Source Network e Incoming Interface non sono criteri di corrispondenza affidabili per i reply packets del proxy. Non modificare globalmente Route Precedence come prima soluzione.

I log mancano o mostrano troppo poco

Controllare Log firewall traffic nella regola e le destinazioni locali, Central o Syslog in System services > Log settings. awarrenhttp.log è rilevante per il proxy web e access_server.log per l’autenticazione. Servizi e file di log di Sophos Firewall spiega classificazione e raccolta sicura.

Rollback e gestione operativa

Preparare il rollback prima del pilota:

1. Documentare la precedente impostazione proxy, PAC, GPO o MDM.
2. Assegnare nomi inequivocabili alla regola pilota e all’eccezione Local Service ACL.
3. Testare il precedente percorso DPI o firewall diretto come via di ritorno.
4. Rimuovere l’assegnazione PAC dal client pilota o ripristinare la versione precedente.
5. Riavviare completamente browser e applicazioni.
6. Disattivare la regola pilota e testare un flusso web diretto reale sul percorso di ritorno.
7. Rimuovere l’eccezione ACL del pilota e riportare al loro stato precedente le autorizzazioni temporanee ampie della zona Web proxy.
8. Controllare dati live e log e documentare da quale momento non è più previsto traffico proxy.

Durante l’esercizio, il file PAC dispone di una cronologia delle versioni, un responsabile e una data di revisione. Ogni nuova eccezione DIRECT è un’eccezione di policy e deve essere motivata, testata e riesaminata in seguito come un’eccezione firewall o web. Anche listener, porte di destinazione consentite e autorizzazioni ampie della zona rientrano nelle revisioni periodiche.

Checklist

• Direct Proxy è il modello adatto ai browser e alle applicazioni interessati.
• Il client pilota IPv4 e l’IP di origine fisso sono documentati.
• FQDN del proxy, URL PAC e certificati vengono risolti correttamente.
• Listener e porte di destinazione consentite sono il più possibile limitati.
• L’autorizzazione ampia della zona del proxy web è stata controllata e sostituita se necessario.
• L’eccezione Local Service ACL limita origine e indirizzo di destinazione del firewall.
• La regola firewall utilizza porta proxy, logging e Web Policy prevista.
• La corrispondenza degli utenti e l’autenticazione web sono state configurate separatamente e testate con esito positivo.
• Il file PAC contiene solo eccezioni interne DIRECT giustificate.
• Non è attivo inosservato un fallback Internet che aggiri il proxy.
• L’egress diretto, incluso QUIC, viene bloccato o controllato deliberatamente al di fuori della regola TCP 3128.
• Il traffico reale consentito e bloccato corrisponde alla Rule ID prevista.
• I servizi HTTP/HTTPS locali del firewall sono stati sottoposti a test negativi.
• Autenticazione, decrittografia TLS, QUIC e applicazioni non proxy sono stati valutati separatamente.
• Il comportamento di SD-WAN e HA è stato testato quando queste funzioni sono utilizzate.
• Rollback, responsabile, versionamento e data di revisione sono documentati.

Domande frequenti