HTTPプロキシでのUmbrella DNSの使用

はじめに

このドキュメントでは、HTTPプロキシでUmbrella DNSを使用する方法について説明します。

前提条件

要件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

このドキュメントの情報は、Secure Web Gateway(SWG)ではなく、UmbrellaグローバルDNSサービスに基づいています。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

HTTPプロキシは、ネットワーク上のHTTP/Sトラフィックを代行受信します。次に、元のクライアントに代わってリモートサーバへのHTTP/S接続を行い、応答をそのクライアントにリレーします。ほとんどのHTTPプロキシには、カテゴリまたはセキュリティコンテンツに基づいて特定のサイトへの接続をブロックする機能、またはマルウェアなどの望ましくないコンテンツを含むリモートサーバからの応答をブロックする機能があります。 

HTTPトラフィックをプロキシにリダイレクトする主な方法には、明示的リダイレクトと透過的リダイレクトの2つがあります。Umbrellaと組み合わせて適切に機能させるには、これらの異なる方法で異なる手順を実行する必要があります。

この記事では、HTTPプロキシがUmbrellaの動作とUmbrellaソリューションの各部分にどのように影響するかを説明し、明示的なリダイレクションと透過的なリダイレクションの2つの手順を示します。 

次の図は、ソリューションの概要を詳細に示したものです。

proxy-umbrella – ダイアグラム.png

HTTPプロキシがUmbrellaグローバルDNSサービスに与える影響

HTTP/Sトラフィックを代行受信すると、HTTPプロキシはHTTP/S要求のホストヘッダーを読み取り、そのホストに対して独自のDNSクエリを生成します。したがって、Umbrellaソリューションを導入する際には、プロキシの動作を考慮に入れることが重要です。抽象的なレベルでは、これはUmbrella IPアドレスへのHTTP/S接続がプロキシにリダイレクトされず、代わりに意図された宛先に直接送信されることを保証することを含みます。

ネットワーク保護

Umbrellaネットワーク保護のみを使用する場合は、HTTPプロキシ自体がDNS解決に直接Umbrellaを使用するか、内部DNSサーバを使用してDNSクエリをUmbrellaに転送するように設定することをお勧めします。適切な外部IPアドレスは、UmbrellaダッシュボードでネットワークIDとして登録できます。このシナリオでは、Umbrellaを使用するために追加のアクションは必要ありません。

何らかの理由でこれが不可能であり、クライアント自身がUmbrellaを使用している場合は、この記事で説明するアクションを実行して、HTTPプロキシによって適用がバイパスされないようにすることができます。

Umbrellaローミングクライアント

Umbrellaローミングクライアントを使用する場合、クライアントマシンからのDNSクエリはUmbrellaに直接送信されます。ただし、HTTPプロキシは独自のDNSクエリを実行するため、Umbrellaローミングクライアントによる強制は無効になります。したがって、プロキシ環境でUmbrellaローミングクライアントを使用する場合は、この記事で説明するアクションに従う必要があります。

仮想アプライアンスとActive Directoryの統合

仮想アプライアンス(VA)は、保護されたネットワーク上のクライアントマシンのDNSサーバとして機能することを目的としています。そのため、HTTPプロキシを使用すると、ローミングクライアントと同じ方法でその適用が無効になります。したがって、この記事で説明するアクションに従うことで、適用が効果的で、レポートが正確であることを確認できます。

次のアクションに加えて、DNSサーバとしてVAを使用するようにHTTPプロキシを設定することを推奨します。これにより、プロキシに固有のポリシーを定義して、プロキシからのクエリを識別できます。このようなポリシーでは、プロキシから発信されたクエリのロギングを無効にして、レポートで重複するクエリを回避することもできます。

明示的なプロキシ

明示的なプロキシを展開するには、トラフィックを明示的にプロキシにリダイレクトするために、ブラウザのプロキシ設定を変更する必要があります。これは、Windowsのグループポリシーを使用するか、より一般的にはプロキシ自動設定(PAC)ファイルを使用して行われます。 どちらの場合も、ブラウザはすべてのHTTPトラフィックをリモートサイトに送信する代わりに、プロキシに直接送信します。ブラウザは、プロキシが独自のDNS要求を生成することを認識しているため、リモートサイト自体のホスト名を解決する必要はありません。また、前述したように、HTTP接続がプロキシに到達すると、プロキシは独自のDNSクエリを生成します。このクエリは、クライアントが取得するものとは異なる結果を返す場合があります。 

したがって、Umbrellaで正しく機能させるには、次の2つの変更が必要です。

1. クライアントは強制的にDNSクエリを実行する必要があります。
2. UmbrellaのIPアドレスを宛先とするHTTP接続は、プロキシに向かうのではなく、Umbrellaに直接向かいます。

これらの変更はどちらも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";}

このサンプルPACファイルでは、最初にDNSクエリが生成され、その結果IPがhostIP変数にキャプチャされます。この結果のIPアドレスは、それぞれのUmbrella IPアドレス範囲と比較されます。一致が見つかった場合、クエリはプロキシに送信されず、直接送信されます。一致しない場合、要求は適切なプロキシに送信されます。

ブロックされないためにUmbrella IPアドレスにリダイレクトされないサイトでは、以前のPACファイルを使用すると、クライアントとプロキシの両方がリモートホストにDNS要求を行うことになります。プロキシもOpenDNSを使用している場合、レポートに重複クエリが表示されることを意味します。前述のように、仮想アプライアンスを使用している場合は、プロキシの内部ネットワークIDを作成することで、これを把握できます。必要に応じて、これらの重複する要求を非表示にするために、完全にロギングを無効にするプロキシのポリシーを追加で作成することもできます。

注：ファイアウォールでプロキシ以外の発信元からの発信HTTP/S要求をブロックする場合、マシンがUmbrellaブロックページにアクセスできるように、前述のIP範囲に対するこれらの要求を許可する必要があります。

透過プロキシ

トランスペアレントプロキシの場合、HTTPトラフィックはネットワークレベルでプロキシに再ルーティングされます。クライアントはプロキシを認識しないため、ブラウザは独自のDNS要求を生成します。これは、プロキシもUmbrellaを使用している場合、各要求が複製されることを意味します。また、プロキシはクライアントが受信した結果ではなく、受信したDNS応答を使用するため、ポリシーが正しく適用されません。

この記事で前述した明示的なケースとは異なり、この問題を解決するために、クライアントに対して強制的にDNS要求を行う必要はありません。これは、すでに発生しているためです。ただし、Umbrella IPアドレスへのHTTP接続のプロキシをバイパスすることは引き続き必要です。これを行う方法は、トラフィックをプロキシにリダイレクトするために使用しているメカニズムによって大きく異なります。ただし、一般的には、UmbrellaのIPアドレス範囲をリダイレクトから除外する必要があります。

たとえば、Cisco ASAでWCCPを使用してトラフィックをプロキシにリダイレクトする場合は、次のACLを使用します。

access-list wccp-traffic extended permit ip any any 

wccp-traffic ACLを変更して、Umbrella IP範囲のプロキシへのリダイレクトを拒否（プロキシをバイパス）できます。

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

注：このACLはテストされておらず、使用されているASAのバージョンまたはCisco IOS®のバージョンによって異なります。作成するACLがソリューションに適しており、実稼働環境に展開する前に十分なテストが行われていることを確認してください。

注：ファイアウォールでプロキシ以外の発信元からの発信HTTP/S要求をブロックする場合、マシンがUmbrellaブロックページにアクセスできるように、前述のIP範囲に対するこれらの要求を許可する必要があります。