プロキシ設計のポイント

Webプロキシの機能要件には例えば以下のようなケースがある。

①HTTPSを複合化してアクセスログを取得する

②ユーザ認証を行い、ユーザに応じたポリシーを適用する

③特定の宛先に対してはプロキシを使用しない

④特定の宛先に対しては上位プロトコルを使用する

⑤HTTP、HTTPS以外のプロトコルにも対応する

⑥ウィルススキャン、コンテンツフィルタを行う

⑦セキュリティ製品と連携して動的なフィルタを行う

⑧コンテンツをキャッシュする

⑨HTTPヘッダ、Cookieを挿入する

プロキシは機能的な要求が多くある。記載したものは例であって、すべてではない。また、これ以外に以下のような非機能要求もある。

①ログは一定期間保存する

②プロキシサーバは冗長化する

③一定以上のスループットまたはコネクションを保証する

その他にも一般的な機器に対する非機能要件がつけられる。これらの機能要件、非機能要件にどのような構成をとれるかを1つづつ検討する。

細かい要件はいろいろあるが、プロキシの導入目的にはいくつかのパターンがある。単にキャッシュサーバとして考えるのか、出口対策として考えるのかでは設計要素は大きく変わる。

 

(1)フォワード機能

全てのHTTPおよびHTTPSをプロキシ経由で接続させる構成を考えると、決めなければならないパラメタは以下のようになる。

・プロキシの物理インターフェース構成を検討する

1アームなのか複数アームなのか、またそれぞれのインターフェースをどのセグメントに設置するのか。という検討が必要となる。機能的には1アームでも問題ないが、その場合は実際に必要なトラフィックの2倍のトラフィック量が1インターフェースに流れることを見込む必要がある(キャッシュが効く事を考慮すれば2倍まではいかないが)。

また、ネットワークのセキュリティポリシーを考慮してInternal側のインターフェースとExternal側のインターフェースを異なるIPセグメントに設置するニーズは少なからず存在する。複数インターフェースを使う場合には、Internal側のインターフェースはクライアントの指定するIPアドレスを設定したポートとなるが、External側のインターフェースはプロキシサーバのIPルーティングでExternal側から出力されるように設定する。クライアントのIPセグメントに対してInternal側にスタティックルートを設定し、デフォルトルートをExternal側に設定するケースが多いと考えられる。

 

・多段プロキシについて検討する

下位プロキシと上位プロキシを設置し、下位プロキシは社内サーバ向けに接続し、上位プロキシはインターネットに接続する構成が考えられる。DNSおよび社内LANの構成によっては下位プロキシは社内サーバのIPアドレスを応答する内部DNSを指定し、上位プロキシのは社外接続用のDNSキャッシュサーバを指定する場合がある。また、ルーティングの問題でプロキシを分離する必要があるケースも考えられる。

プロキシの接続構成だけを考慮してセキュリティ的にプロキシを多段構成にする意味はあるだろうか。下位プロキシを社内LANに設置し上位プロキシを外部接続用セグメントに設置する構成と、1台のプロキシサーバのInternal側インターフェースを社内LANに接続してExternal側インターフェースを外部接続用セグメントに接続する構成の違いは、外部と接続するプロキシサーバがファイアウォール無しに社内LANに接続されることを許容できるかという問題だと思う。

これを考える前に外部接続用セグメントの定義をする必要がある。外部接続用セグメントはDMZとは位置づけが違う。ここではDMZは外部からアクセスするためのグローバルIPアドレスを持たせるセグメントと定義する。外部接続用セグメントは内部から外部への接続用セグメントとし、プライベートアドレスを割り振り、NAPTを用いて外部に接続するセグメントと定義する。上位プロキシサーバはグローバルIPアドレスである必要は無いため、外部接続用セグメントに設置する。

これを前提として考えると、DMZの基本的な考え方はDMZ上のサーバがインターネット側から乗っ取られても社内LANには直接通信できないようにするということなので、どちらが良いかといえば、物理筐体をわけるほうが良いと思われるが、そもそもNAPTで外部接続するセグメントは外部から直接通信できない外部接続用セグメントはDMZより安全であるし、プロキシはファイアウォールとして機能しないのかと考えた時に、機器によっては、ポリシー定義に基づいた通信しか許可されず、かつExternal側インターフェースはセッションの確立を受け付けない設定もできるためファイアウォールよりも強固であり、コスト見合いでの検討で良いように考える。

・フォワード機能を定義する

上位プロキシは1つとは限らない。接続先によって上位プロキシを変えることもできる。例えばA社宛にはA社のプロキシサーバを上位プロキシに設定し、B社宛にはB社のプロキシを設定する。もしくは宛先によってセキュリティ対策の異なる上位プロキシを指定するという構成もあるかもしれない。

・プロキシを使用しない接続を定義する

全ての接続をプロキシ経由にするのではなく、例えば社内ネットワーク宛はプロキシを経由せず、クライアントから直接接続させたいケースがある。社内サーバ宛をプロキシ経由にする必要性はあまり無いし、プロキシサーバに負荷がかかる上にクライアントの送信元アドレスが秘匿されてしまう。秘匿されることを回避するためにはプロキシサーバでHTTPヘッダ( X-Forwarded-For)を挿入することで回避できる場合もある。

プロキシを経由するかしないかというのはプロキシサーバの設定ではなく、クライアント端末の設定となる。最も単純な設定は、WEBブラウザの設定に直接例外を設定する。この方法だと設定やポリシーが変わるたびにクライアント端末の設定を変更しなければならないため効率が悪い上に柔軟な設定ができない。よって必要な時にサーバから設定を取得する構成が望ましい。自動取得するには「自動構成スクリプトを使用する」または「設定を自動的に検出する」WPADを用いてPACファイルを取得する設定が必要となる。PACファイルはクライアント端末内にローカルファイルとして持つことはできないためHTTP接続できる場所に設置し、PAC ファイルを配置した Web サーバーには.pac の拡張子に対する MIME タイプを設定する。

PACファイルのURLを直接指定するには「自動構成スクリプト」に直接記載するが、WPADを使用すればDHCPサーバのオプション252を用いてPACファイルのURLを配布することができる。社内端末の配布形態に合わせていずれの構成が良いか検討する。

また、IEのインターネット/イントラネットの判断が問題になる事がある。プロキシ設定が無いとFQDNは全てインターネットに分類される。アドレスに.が無い場合はイントラネットになる。PACファイルを設定すると、ローカルアドレスはイントラネットになる。この判定がプロキシ導入後に変化してしまうことによって動作が変わるサイトが発生する可能性がある点に注意する。

PACファイルはJAVAスクリプト。記載は難しくない。
https://technet.microsoft.com/ja-jp/library/cc817412.aspx

ここまではWinInetの説明であり、InternetExplorerはWinInetを利用する。Windowsにはもう1つインターネットに接続するWinHTTPというAPIがあり、これを利用するアプリケーションは、IEでプロキシ指定しても、それを使用しない。WinHTTPのプロキシ設定はnetshコマンドで行う。

(設定)

netsh winhttp set proxy proxy-server=”192.168.10.100:8080″ bypass-list=”192.168.10.*;172.17.*;10.*”

(確認)

netsh winhttp show proxy

(設定削除)

netsh winhttp reset proxy

WinHTTPがプロキシ認証できないという話が多くあるが、おそらくできるので必要な場合は以下を参照する。

https://msdn.microsoft.com/ja-jp/library/windows/desktop/aa383144(v=vs.85).aspx

また、Windowsのプロキシ設定に関する詳細は以下を参照する。