| 本文書は、Windows NT World誌に寄稿した記事の原稿を、IDGジャパン編集部殿の許可を得た上で掲載したものです。 |
|
今回はWindows NTにおけるIPソースアドレス詐称 (IP Source Address Spoofing) の話題を取り上げる。ご承知の通りIPネットワーク上では、IPアドレスでホストを識別し、相互に通信を行なう。IPパケットの送信元ホストのIPアドレスを「ソースアドレス（Source Address）」、送信先ホストのIPアドレスを「デスティネーションアドレス（Destination Address）」と呼ぶ。「IPソースアドレス詐称」とは、送信するIPパケットのソースアドレスを意図的に「ごまかす」ことにより、実際の送信元である自分自身のホストを他のホストに見せかけることを指す。 IPサーバプログラムによっては、受信したIPパケットのソースアドレスに依存した認証を行なうものがある。良い例はUNIXのrlogindやrshdといったプログラムで、これらは（そのように設定された場合であるが）指定されたIPアドレスをソースに持つ接続をパスワード等による認証なしで受け入れる。また多くのWebサーバプログラムは、IPソースアドレスでアクセス先を許可あるいは拒否する機能を持つ。このようなサーバプログラムは、IPソースアドレスを詐称されることによって、攻撃者に不正にアクセスを許してしまう可能性がある。 さらに通常、IPサーバプログラムにはどのホストからどのようなアクセスがあったかというログを残す機能があるが、アクセス元のホストの情報としては一般的にソースアドレスを記録する。すなわち攻撃者はあるターゲットサイトを攻撃する際に、ソースアドレスを詐称することであたかも別のホストから攻撃しているように見せかけ、自分自身の本来のIPアドレスを隠すことができる。 ここでは、IPソースアドレス詐称による攻撃方法として知られる、
の二つについて、NTがターゲットとなった場合の危険性および回避方法について記述する。 |
「ソースルーティング（Source Routing）」とはIPのオプション機能の一つで、IPパケットのルート（経由するルータ）を、パケット送信元が意図的に指定することを指す。 通常、IPパケットが送信元ホストから送信先ホストへ送られる際には、経路上の個々のルータが次の送り先ルータを決定する。そのため送信元ホストは転送経路について関知しない。これに対し、ソースルーティング・オプションは送信元ホストに転送経路上のルータを明示的に指定する機能を提供する。すなわちソースルーティングを行なうことで送信元ホストは、希望するルータを必ず経由して送信先ホストへ到達するようなIPパケットを発信することが可能になる。一般的にソースルーティングは、ネットワークのテストや標準経路の不具合を回避する目的で使用される。 ソースルーティングには次の二つの形式がある。
ソースルーティングの概要を図1に示す。  図1 |
|
このソースルーティングを利用することにより、送信元ホストのIPアドレスを詐称して送信先ホストとIP通信を行なうことが可能となる。 図2にネットワーク構成例を示す。  図2 この図でターゲットサイトにある「ターゲットホスト」は攻撃対象となるホストである。この「ターゲットホスト」は同じサイト内にある「信頼ホスト」を信頼しているとしよう。すなわち「ターゲットホスト」上のサーバプログラムは、「信頼ホスト」のIPアドレスをソースアドレスに持つIP接続を無条件で受け入れ、それ以外のIPアドレスからの接続は拒否するものと仮定する。 「攻撃元ホスト」から「ターゲットホスト」上のサーバプログラムへ通信を行なう際、通常のIP通信では当然のことながら、
となる。そのため、「ターゲットホスト」はこの接続を拒否する。 それではルーズ・ソースルーティングを利用してみよう。「攻撃元ホスト」はソースルートとして「攻撃元ルータ」を指定し、ソースアドレスがターゲットサイト上の「信頼ホスト」のアドレスであるようなIPパケット送出する。
このIPパケットは、「攻撃元ルータ」を経由して「ターゲットホスト」へたどり着く。「ターゲットホスト」はこのパケットに対する応答を、ソースルートに従って「信頼ホスト」へ返そうとする。すなわち、「攻撃元ルータ」を必ず経由するように返すのである。
攻撃者は自分の管理下にある「攻撃元ルータ」に、「信頼ホスト」のIPアドレスへのルートを「攻撃ホスト」に向けるような設定を予め行なっておく。それにより、「信頼ホスト」のIPアドレスがデスティネーションであるようなIPパケットを、「攻撃ホスト」へ転送することができる。 このようにルーズ・ソースルーティングを利用することで、攻撃者はソースアドレスを詐称した形でTCP/UDPの通信を行なうことが可能となる。上の例では分かりやすくするために「攻撃元ルータ」をソースルート指定したが、「攻撃元ホスト」に複数のIPアドレスを割り当て、その片方をソースルート指定することにより、「攻撃元ホスト」一台でソースルーティングを利用したアドレス詐称を行なうことも可能である。 ソースルーティングによるソースアドレス詐称は、TCP、UDPいずれについても通常のコネクション同様にデータの送受信ができるため、危険度はかなり高い。 |
|
ソースアドレス詐称のもう一つの手法として、「TCPシーケンス番号予測」がある。これはTCPセッションにおけるソースアドレス詐称手法で、TCPセッション確立時にサーバプログラムが発行する初期シーケンス番号（Initial Sequence Number:ISN）を予測することにより、あたかもクライアント-サーバ間でTCPセッションが確立したかのようにサーバプログラムをだまし、不正なTCPパケットを受け入れさせるものである。 通常、クライアント-サーバ間のTCPコネクションは、次のような手順で確立される。  図3
この手順がいわゆるTCPのスリーウェイ・ハンドシェイクである。この手順を見て分かる通り、TCPコネクションを確立するためにはクライアント側はサーバのISNを知る必要がある。 クライアントが単純に別のソースアドレスを持つTCPパケットをサーバに送信した場合、サーバからのSYN+ACKパケットはクライアントに到達しないため、クライアントはサーバのISNを知ることができず、サーバに対する正常なACKを返すことができない。そのためTCPのコネクションは確立されない。それでは、サーバが発行するISNを、クライアントが何らかの方法で知ることができるとすればどうであろうか。クライアントはサーバからの返答パケットを一切受け取ることはできないものの、サーバに対してあたかも詐称したソースアドレスを持つホストとのTCPコネクションが確立したように思い込ませ、不正なTCPパケットを送り込むことが可能になる。  図4 サーバのISN（初期シーケンス番号）が容易に予測できるかどうかは、該当するOSの実装に依存する。 前述のソースルーティングによるソースアドレス詐称とは異なり、TCPシーケンス番号予測による攻撃では、攻撃側のホストはサーバからの返答パケットを受け取ることができない。単にTCPパケットを送り込むだけである（ブラインド・アタック）。またISNを的確に予測することは、ターゲットOSにもよるが、一般的にそれほど簡単ではない。しかしISNが非常に単純なロジックで生成されており、またサーバプログラムがソースIPアドレスに極めて依存した認証を行なっているような場合、この攻撃手法は有効と考えられる。 |
|
さて、それではソースルーティングやTCPシーケンス番号予測によるソースアドレス詐称が、NT4.0で実際にどの程度脅威となり得るのであろうか。 まずソースルーティングであるが、NT4.0はデフォルトでソースルートされたIPパケットの送受信を許可する。そもそもソースルーティングの制御はサービスパック5（SP5）でNTに導入された機能である ため、SP4以前では制御することができない。SP5で初めてソースルートされたIPパケットの転送を禁止する機能が組み込まれた。その後、SP5におけるソースルーティング制御機能に不備があることが指摘され、ホットフィックスが提供された。(Spoof-fix)Spoof-fixはSP5のソースルーティング制御機能の不備を修正すると同時に、ソースルートされたパケットの転送禁止のみならず、受け入れ禁止の機能が追加された。 これらの機能はSP6aにも引き継がれている。ただしSP5+Spoof-fix、SP6aいずれの場合も、後述するレジストリの設定が必要なため、デフォルトではソースルーティングによるソースアドレス詐称の脅威にさらされることに変わりはない。では、TCPシーケンス番号予測についてはどうだろう。以下は、標準的なNT4.0サーバのTCPポート139番に対して約2秒間隔でコネクションを確立させた際の、サーバ側ISNをリストしたものである。
この実例でサーバISNの増分は、1938、1922、1922、1937のように極めて似通った間隔になっている。つまり次の2秒後にコネクション開設要求を出した場合、おおよそどの位のサーバISNになるか、比較的容易に予測可能であることが分かる。 TCPシーケンス番号予測の脆弱性 については、英語版NT4.0に関するホットフィックスは提供されているものの、日本語版NT4.0に関するホットフィックスは本原稿執筆時点ではまだ提供されていない。このフィックス適用により、Windows2000で採用されているのと同様の、よりランダムなISN生成のアルゴリズムが使用されるようになる。ソースアドレス詐称によってサーバプログラムが脅威にさらされるかどうかは、初めに述べた通りサーバプログラムの機能や設定に依存する。NTの基本的な機能であるファイル共有やプリンタ共有に関する認証（SMB認証）については、IPソースアドレスに依存した処理は行なわれないため、例えソースアドレスが詐称されても基本的には問題ないはずである。しかしNTサーバ上で稼動する、いわゆるインターネット・サービス・プログラムについてはどうであろう。 例えばIIS（Internet Information Server）には仮想サーバやディレクトリごとに、IPアドレスでのアクセス制限を行なう機能がある。その場合、本来はアクセスできないはずのクライアントマシンからのアクセスを、ソースアドレス詐称によって許可してしまうことが考えられる。またIISはWebクライアントからのアクセスの記録をログファイルに書き込むが、ログの中でクライアントを特定する部分はソースIPアドレスである。つまり、IISに対して攻撃を行なう際に、ソースアドレスをごまかすことで発信元を分かりにくくする、あるいは他のホストからの攻撃のように見せかけるといったことも考えられる。 DNSやSMTPサーバについても同様である。DNSゾーン転送のIPアドレスによる制限、SMTP不正中継のIPアドレスによる制限などを、ソースアドレス詐称で回避し、不正にアクセスすることも可能であろう。またプロクシ・サーバ、RRAS（Routing and RAS）によるIPフィルタリング、SNMPへのアクセス等、NT上のプログラムでソースIPアドレスに依存したセキュリティを実現しているものは多々ある。これらは基本的にソースアドレス詐称によって、何らかのセキュリティ侵害を受ける危険性がある。 |
|||||||||||||||||||||||||||||||||
IPソースアドレス詐称の脅威を低減させるには、以下の方法が有効であると考えられる。
以上、今回はNTにおけるソースアドレス詐称の脅威について述べた。TCPシーケンス番号予測による攻撃は比較的難易度が高いため、あまり頻繁に行なわれることはないかも知れない。一方でソースルーティングを利用した攻撃は、攻撃者にとってみれば簡便かつ効果的（データの送受信が可能）であるので、危険度は大きいと言える。インターネットからアクセスされるサーバについては、境界ルータまたはファイアウォールでソースルートされたパケットをドロップするように設定する場合が多いが、特に組織内LANではそのようなルータ設定をしていないケースも少なくないと思われるため、十分な注意が必要であろう。 |
2000年3月執筆
セントラル・コンピュータ・サービス株式会社
塩月 誠人