2016 年 8 月 26 日 Marc Laliberte

今年の DEFCON でセキュリティエンジニアの Grant Bugher 氏が、キャプティブポータルの回避に関するプレゼンを行いました。DEFCON でのプレゼンであったため、キャプティブポータルを回避しようとする個人を想定した内容でしたが、IT プロフェッショナルにとっても、この種の挙動を防止するための情報として活用できるものでした。

キャプティブポータルは、ゲストネットワークからインターネットに接続する前に、ユーザに認証や利用規定（AUP）への同意を要求する目的で使用されます。ホテルの Wi-Fi に接続したことがある方であれば、キャプティブポータルに部屋番号を入力し、AUP に同意した経験があるのではないでしょうか。ほとんどのキャプティブポータルは、Web ブラウザからの接続要求を検知してリダイレクトを挿入し、クライアントをキャプティブポータルの Web ページを表示するように作成されています。ユーザがポータルの要件を満たしていれば、それ以降は、接続がリダイレクトされることはなく、インターネットへのアクセスが許可されます。

Bugher 氏が紹介した回避方法は、「キャプティブポータルでは、要件の確認が完了時までは通常のインターネットアクセスが許可されないものの、ポータルの要件を満足する情報をユーザが入力するのを待機する間はアウトバウンドのどのポートもブロックされていないことが多い」という盲点を突いています。たとえば、クライアントのブラウザをポータルにリダイレクトするには、Web ページへの HTTP または HTTPS 接続を最初に試行する必要があります。この接続が成功させるには、ブラウザが宛先の Web ページのドメイン名を解決する必要があります。ほとんどの組織は、この名前解決を許可するために、UDP ポート 53 でアウトバウンド DNS を開けたままにしています。組織によっては、TCP ポート 22 の SSH や TCP ポート 3128 の Web キャッシングプロキシなどのように、さまざまな理由から、他のポートも許可している場合もあります。

Bugher 氏はプレゼンで具体的な回避方法の解説に入る前に、ある重要な要件がこの方法の前提であると説明しました。クライアントがキャプティブポータルを回避するには、事前の準備が必要であり、外部サーバがいくつかの異なる回避方法のエンドポイントとして動作するようにクライアントを事前に構成しておく必要があります。この記事では、紹介されたサーバの構成方法の説明は省略しますが、専用または公共の何らかのサーバをクライアントが利用できることを前提に、説明を続けます。

他のネットワークセキュリティ攻撃と同様に、クライアントの最初のステップでは、調査を実行します。ゲストネットワークへの接続後に、悪意のあるクライアントの多くは、ネットワークのゲートウェイ経由で開いている（許可されている）ポートを探す目的で、スキャンを実行します。クライアントは、前述のポート（Web プロキシ用の TCP/3128、SSH 用の TCP/22、または DNS 用の UDP/53 など）と一致する、開いているポートを探します。

キャプティブポータルを経由せずに許可されているポートをクライアントが特定できれば、いくつかの異なる回避方法を試行する段階へと進むことができます。たとえば、TCP/3128 が開いていた場合であれば、クライアントは、Web ブラウザを構成し、事前に構成されているサーバのプロキシサービスを経由して接続を送信するようにできます。プロキシサービスは多くの場合、合法的な手段として、会社のネットワークで、頻繁にアクセスされる Web サイトからの応答をキャッシュして、ネットワークからのアウトバウンド帯域幅を節約する目的で使用されます。キャプティブポータルを回避しようとするクライアントは、外部サーバ経由で要求をプロキシ処理することで、デフォルトの HTTP/HTTPS ポートの制限を回避できます。この回避行動に対抗するために IT 管理者が行わなくてはならないのは、キャプティブポータルによって保護されたネットワークからの TCP/3128 のアウトバウンドアクセスを制限することだけです。

多くの場合に、TCP/3128 のアウトバウンドプロキシアクセスはネットワーク管理者によってブロックされていますが、その一方で、SSH（TCP/22）は見落とされがちです。SSHは 一般的に、リモートサーバのコマンドラインのアクセスを保護する目的で使用されます。SSH のほとんどのクライアントとサーバには、これとは別に、2 つのホスト間に暗号化されたトンネルを開くことができる機能があります。このトンネルも、アウトバウンドトラフィックをプロキシ処理することでデフォルトの HTTP/HTTPS ポートの制限を回避する、前述の方法の場合と同じように使用される可能性があります。クライアントがネットワークスキャンでアウトバウンド TCP/22 を許可されていることを発見できれば、予め決めておいた外部サーバへの SSH トンネルを作成し、そのトンネル経由で接続をプロキシ処理するようにブラウザを構成できます。この回避方法への対策として IT 管理者が行うべきは、キャプティブポータルネットワークでは必要ではない、TCP/22 ポートのアウトバウンドアクセスを制限することです。

ネットワーク管理者が自分の判断で（最初のブラウザ接続を許可するための）DNS を除くすべてのアウトバウンドポートをブロックしていたと仮定します。クライアントのポートスキャンでは、UDP/53 だけが許可されたアウトバウンドポートとして返されますが、これは、Web プロキシと SSH トンネルによる回避方法を使用できないことを意味します。これで、ネットワーク管理者も安心できそうですが、残念ながら、そうではありません。DNS 経由のトンネリングを可能にする、iodine と呼ばれるアプリケーションが存在するからです。クライアントのリモートサーバとクライアントの両方に iodine をセットアップしておくと、クライアントは、すべてのトラフィックを DNS ポート経由でトンネルできます。IT 管理者がこの回避方法を防止する作業は、これまでの方法よりも複雑です。キャプティブポータルネットワークからのアウトバウンド DNS をブロックする方法も考えられますが、ドメイン名を解決できるようにしておかないと、ポータルのリダイレクトが機能しなくなります。そこで、次の手段として、アウトバウンド DNS を制限して内部 DNS サーバだけを許可するようにし、その内部 DNS サーバの IP アドレスを DHCP を使用して接続しようとするクライアントに渡す方法が考えられます。ただし、この方法には、内部 DNS サーバのメンテナンスという余分な作業が必要であり、ハードコーディングされた DNS サーバアドレスを使用するクライアントで問題が発生します。ウォッチガードのお客様であれば、DNS プロキシを使用して、iodine などの DNS トンネリングアプリケーションで使用される異常に長い DNS クエリを検出し、ブロックする方法を選択できます。

Baugher 氏の説明から、キャプティブポータルの要件にクライアントが同意する前の段階で許可するプロトコルを IT 管理者やネットワーク管理者が十分に検討し、設定する必要があることがわかります。キャプティブポータルは、その目的がアクセスを制限して使用条件に同意したゲストだけにアクセスを許可する目的であっても、ネットワークアクセスのコストに見合った売上を上げるためであっても、極めて重要です。制限された DNS を除けば、ポータルでの処理が完了する前の段階で、ネットワークの外部へのどのようなアクセスも許可する必要はないはずです。ゲストネットワークを保護する手段を講じておくことが、悪意のあるクライアントによる正当ではない接続を制限することにつながります。– Marc Laliberte