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.

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
• Web filtering > Web policy: Web_Standard_Pilot
• Block QUIC protocol: attivare se il traffico web non deve aggirare in parallelo l’ispezione proxy tramite UDP 443; Controllare QUIC su Sophos Firewall spiega il contesto
• 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.

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) || 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, le reti private e il FQDN del proxy al proprio ambiente. 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. A seconda dell’ambiente, i client normali possono utilizzare AD SSO, STAS, Captive Portal o un altro metodo supportato. 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.

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.
• Il file PAC contiene solo eccezioni interne DIRECT giustificate.
• Non è attivo inosservato un fallback Internet che aggiri il proxy.
• 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