Usa DNS Umbrella con un proxy HTTP

Introduzione

In questo documento viene descritto come utilizzare il DNS Umbrella con un proxy HTTP.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Le informazioni fornite in questo documento si basano sul servizio DNS globale Umbrella, non su Secure Web Gateway (SWG).

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Un proxy HTTP intercetta il traffico HTTP/S su una rete. Stabilisce quindi la connessione HTTP/S al server remoto per conto del client originale, inoltrando le risposte a tale client. La maggior parte dei proxy HTTP consente di bloccare le connessioni a siti specifici in base alla categorizzazione o al contenuto di protezione oppure di bloccare le risposte da server remoti che contengono contenuto indesiderato, ad esempio malware. 

Esistono due metodi principali per reindirizzare il traffico HTTP a un proxy: reindirizzamento esplicito e reindirizzamento trasparente. Questi diversi metodi richiedono l'adozione di diverse misure per funzionare correttamente in combinazione con Umbrella.

In questo articolo viene descritto in che modo un proxy HTTP influisce sul comportamento di Umbrella e di ogni parte della soluzione Umbrella e vengono fornite due serie di passaggi per il reindirizzamento esplicito e il reindirizzamento trasparente. 

Il diagramma è un riepilogo delle soluzioni descritte più dettagliatamente:

proxy-ombrello-diagramma.png

Effetti di un proxy HTTP sul servizio DNS globale Umbrella

Quando intercetta il traffico HTTP/S, un proxy HTTP legge l'intestazione dell'host nella richiesta HTTP/S e genera la propria query DNS per tale host. Pertanto, è importante tenere in considerazione il comportamento del proxy quando si distribuiscono le soluzioni Umbrella. A livello astratto, ciò implica la garanzia che le connessioni HTTP/S agli indirizzi IP ombrelli non vengano reindirizzate al proxy, ma vengano invece inviate direttamente alla destinazione prevista.

Protezione della rete

Quando si utilizza solo la protezione Rete Umbrella, si consiglia di configurare il proxy HTTP per l'utilizzo diretto di Umbrella per la risoluzione DNS oppure di utilizzare un server DNS interno che a sua volta inoltra le query DNS a Umbrella. L'indirizzo IP esterno appropriato può essere registrato come identità di rete in Umbrella Dashboard. In questo scenario, non è necessaria alcuna azione aggiuntiva per utilizzare Umbrella.

Se ciò non è possibile per qualche motivo e i client stessi utilizzano Umbrella, è possibile eseguire le azioni descritte in questo articolo per garantire che l'applicazione non venga ignorata dal proxy HTTP.

Umbrella Roaming Client

Quando si utilizza il client di roaming Umbrella, le query DNS dal computer client vengono inviate direttamente a Umbrella. Tuttavia, poiché un proxy HTTP esegue le proprie query DNS, l'imposizione da parte del client di roaming Umbrella diventa inefficace. Pertanto, quando si utilizza il client di roaming Umbrella in un ambiente proxy, è necessario seguire le azioni descritte in questo articolo.

Appliance virtuali e integrazione con Active Directory

L'appliance virtuale (VA) funge da server DNS per i computer client nella rete protetta. Di conseguenza, l'utilizzo di un proxy HTTP rende inefficace l'applicazione allo stesso modo del client di roaming. Di conseguenza, le azioni descritte in questo articolo possono essere seguite per garantire l'efficacia dell'applicazione e l'accuratezza della segnalazione.

Oltre alle azioni riportate di seguito, è consigliabile configurare il proxy HTTP in modo che utilizzi VA come server DNS. In questo modo è possibile definire un criterio specifico per il proxy in modo che sia possibile identificare le query dal proxy. Tale criterio consente inoltre di disabilitare la registrazione per le query originate dal proxy, evitando così la presenza di query duplicate nei report.

Proxy espliciti

La distribuzione di un proxy esplicito comporta la modifica delle impostazioni del proxy del browser per reindirizzare esplicitamente il traffico a un proxy. Questa operazione viene eseguita utilizzando Criteri di gruppo in Windows o, più comunemente, utilizzando un file di configurazione automatica del proxy (PAC). In entrambi i casi, il browser invierà tutto il traffico HTTP direttamente al proxy, anziché al sito remoto. Poiché il browser sa che il proxy genera la propria richiesta DNS, non si preoccupa di risolvere il nome host del sito remoto stesso. Inoltre, come accennato in precedenza, quando la connessione HTTP raggiunge il proxy, quest'ultimo genera una propria query DNS, alla quale può essere assegnato un risultato diverso da quello che otterrebbe il client. 

Pertanto, per funzionare correttamente con Umbrella, sono necessarie due modifiche:

1. È necessario forzare il client a eseguire una query DNS.
2. Le connessioni HTTP destinate agli indirizzi IP degli Umbrella non devono passare al proxy, bensì direttamente a Umbrella.

Entrambe queste modifiche possono essere eseguite utilizzando un file PAC:

function FindProxyForURL(url, host) {    // Generate DNS request on the client    hostIP = dnsResolve(host);    // If the requested website is using an Umbrella IP address, return DIRECT    if (isInNet(hostIP, "67.215.64.0", "255.255.224.0") ||        isInNet(hostIP, "204.194.232.0",  "255.255.248.0") ||        isInNet(hostIP, "208.67.216.0",  "255.255.248.0") ||        isInNet(hostIP, "208.69.32.0",  "255.255.248.0") ||        isInNet(hostIP, "185.60.84.0",  "255.255.252.0") ||
        isInNet(hostIP, "155.190.0.0", "255.255.0.0") ||
        isInNet(hostIP, "146.112.0.0", "255.255.0.0")) ||
        isInNet(hostIP, "151.186.0.0", "255.255.0.0"))   
     {         return "DIRECT";     }     // DEFAULT RULE: All other traffic, use below proxies, in fail-over order.    return "PROXY 192.0.2.5:8080; PROXY 192.0.2.6:8080";}

In questo file PAC di esempio viene prima generata una query DNS, con l'IP risultante acquisito nella variabile hostIP. L'indirizzo IP risultante viene quindi confrontato con ciascun intervallo di indirizzi IP Umbrella. Se esiste una corrispondenza, la query non viene inviata al proxy, ma direttamente al destinatario. In caso contrario, la richiesta viene inviata ai proxy appropriati.

Si noti che, per i siti che non vengono bloccati e quindi non vengono reindirizzati a un indirizzo IP Umbrella, l'effetto dell'utilizzo del file PAC precedente è che sia il client che il proxy effettuano una richiesta DNS per l'host remoto. Se il proxy utilizza anche OpenDNS, ciò significa che nei report vengono visualizzate query duplicate. Se si utilizza l'appliance virtuale, come accennato in precedenza, è possibile tenere conto di questa situazione creando un'identità di rete interna per il proxy. Se lo si desidera, è inoltre possibile creare un criterio per il proxy che disattiva completamente la registrazione per nascondere le richieste duplicate.

Nota: Se si bloccano le richieste HTTP/S in uscita nel firewall da origini diverse dal proxy, è necessario assicurarsi di consentire queste richieste agli intervalli IP discussi in precedenza per consentire ai computer di accedere alle pagine del blocco Umbrella.

Proxy trasparenti

Per un proxy trasparente, il traffico HTTP viene reindirizzato al proxy a livello di rete. Poiché il client non è a conoscenza del proxy, il browser genera la propria richiesta DNS. Ciò significa che se il proxy utilizza anche Umbrella, ogni richiesta viene duplicata. Inoltre, il criterio non viene applicato correttamente poiché il proxy utilizza la risposta DNS ricevuta, non il risultato ricevuto dal client.

A differenza del caso esplicito descritto in precedenza in questo articolo, la risoluzione di questo problema non richiede l'imposizione di una richiesta DNS nel client, poiché tale operazione è già in corso. Tuttavia, è ancora necessario ignorare il proxy per le connessioni HTTP agli indirizzi IP degli Umbrella. Il metodo per eseguire questa operazione varia notevolmente a seconda del meccanismo utilizzato per reindirizzare il traffico al proxy. In generale, tuttavia, comporta l'esenzione dal reindirizzamento degli intervalli di indirizzi IP di Umbrella.

Si supponga, ad esempio, che il protocollo WCCP venga utilizzato su un'appliance Cisco ASA per reindirizzare il traffico al proxy, utilizzando il seguente ACL:

access-list wccp-traffic extended permit ip any any 

L'ACL wccp-traffic può essere modificato in modo da impedire il reindirizzamento al proxy (ignorando così il proxy) per gli intervalli IP Umbrella:

access-list wccp-traffic extended deny ip any 67.215.64.0 255.255.224.0access-list wccp-traffic extended deny ip any 204.194.232.0 255.255.248.0access-list wccp-traffic extended deny ip any 208.67.216.0 255.255.248.0access-list wccp-traffic extended deny ip any 208.69.32.0 255.255.248.0access-list wccp-traffic extended deny ip any 185.60.84.0 255.255.252.0access-list wccp-traffic extended deny ip any 146.112.0.0 255.255.0.0
access-list wccp-traffic extended deny ip any 155.190.0.0 255.255.0.0
access-list wccp-traffic extended deny ip any 151.186.0.0 255.255.0.0

access-list wccp-traffic extended permit ip any any

Nota: Questo ACL non è stato testato e varia a seconda della versione ASA o Cisco IOS® in uso. Accertarsi che gli ACL creati siano appropriati per la soluzione e che siano stati accuratamente testati prima dell'implementazione in un ambiente di produzione.

Nota: Se si bloccano le richieste HTTP/S in uscita nel firewall da origini diverse dal proxy, è necessario assicurarsi di consentire queste richieste agli intervalli IP discussi in precedenza per consentire ai computer di accedere alle pagine del blocco Umbrella.