Tweet

第3回 脆弱なホストを狙った不正中継を見抜く

猛威をふるったBlasterワーム。これが大流行したのは2003年でしたが、いまだにこのワームの痕跡はインターネット上に残っています。その理由の1つは、いまだにセキュリティパッチが適用されていないホストが残っていることにもあります。今回は脆弱なホストや設定ミスによって発生する「穴」への攻撃を見抜く方法を解説します（編集部）

　不正中継、踏み台といった脆弱なホストの悪用

　インターネット上には、無数の脆弱なホストが存在していると考えられる。過去に猛威をふるったSQL slammer、Blaster、Nimdaなどのワーム、およびその亜種と思われるさまざまなトラフィックがいまだ絶えることなく観測されていることからもそれは証明されている。

　それらはなぜ存在しているのだろうか。設置されていることさえ忘れ去られているサーバ、ファイアウォールがなくほぼ初期インストール状態のマシン、単なる設定ミス、そしてブロードバンドでつながれセキュリティは考慮されていない個人用PC……脆弱なホストがネットにつながれてしまう理由は多岐にわたるであろう。

　今回は、これらインターネット上の脆弱なホストの悪用方法として、特に不正中継を取り上げよう。

　被害者が加害者になり得る不正中継の怖さ

　攻撃者の狙いは、本来彼らが実現したい不正行為をより確実なものとすることであり、匿名性やCPU／メモリリソースを確保する手段として、脆弱なホストを積極的に悪用する。

　本来彼らが実現したい行為とは、迷惑メールを大量にばらまいたり、彼らの個人的な趣味のため、掲示板への書き込みや成人向けサイトへ匿名性を保持したままアクセスすることなどが挙げられる。

　悪用されたホストは、ホームページの改ざんや情報取得（情報漏えい）など直接的で分かりやすい事象とは異なるため、正しく運用管理されていなければ被害に遭っていることを見落とすことになる。

　不正中継の怖さは、被害者であるはずの管理者が、気付いたときには加害者となり得る点で、例えば迷惑メールの配信を助長したということで、強いクレームとその対応に追われる、といったことはよく耳にする話ではある。

　HTTPプロキシを利用した不正中継

　プロキシは代替サーバの総称で、HTTPの通信を代替するものはHTTPプロキシなどと呼ばれている。

　HTTP通信代替の仕組みは簡単で、クライアントから受け取ったHTTPのリクエストをそのままプロキシがWebサーバに対して行い、HTTPの戻り（レスポンス）をクライアントに渡すだけである。

図1　HTTPプロキシの動作

　そのため、HTTPの通信を代替するプロキシを探すには、HTTPリクエストをサーバに送り、応答があるかを確かめればよい。単純な手順で探せることから、攻撃者は常にHTTPプロキシを探すような通信を発生させているのが現状である。

　なお、プロキシに送信するHTTPリクエストには特徴があり、“GET http://www.example.com/ HTTP/1.0”というようにGETやPOSTといったメソッドの形式がURIになる。

　HTTP CONNECTを利用した不正中継

　ここ数年はHTTP CONNECTメソッドを用いて、スパムなどのSMTPメールを送るという不正中継の通信もよく目にするようになった。

　「HTTPなのにSMTPの通信？」と思われるかもしれないが、HTTP/1.1（RFC 2616）のCONNECTメソッドを用いることで、SMTPに限らずTCPの通信をトンネリングさせることができる。

図1　HTTP CONNECTの動作

　もともとCONNECTメソッドとは、通常のHTTPプロキシが代理応答のできない通信を透過的に中継（トンネリング）させるために考案されたものだ。その代表的な例がSSLの通信である。

　SSLは通信を確立するために暗号鍵交換の手順が必要になる。この手順はプロキシが代替できない部分であり、負荷も高い部分である。そのため、効率的に処理できるよう、SSLの通信をHTTP CONNECTで、単に中継のみ行うよう設計しているプロキシは多い。

　しかし先に述べたように、すべてのTCPプロトコルもトンネリングできることから、攻撃者はHTTP CONNECTで有効なプロキシを探し出し、その仕組みを悪用してスパムメールの送信にプロキシを不正中継ホストとして利用している。

　例として、CONNECTメソッドを使ってSMTPを中継させる通信を以下に紹介しよう。

　SMTPを中継する場合、CONNECTの後の「中継先ホスト」にメール送信先のメールサーバ、「中継先ポート」に25（SMTP）を指定するだけでよい。あとは、HTTPプロキシがこの要求を許可すれば、それ以降は接続元と中継先メールサーバとのSMTPによる通信がやりとりされることになる。

　この例では、まずproxy.example.com（80/tcp）にHTTP接続し、その後にCONNECTメソッドを用いてmail.example.net とSMTP（25/tcp）の通信をやりとりしている。

　CONNECTメソッドがHTTPプロキシによって許可されたことは、8行目のHTTPステータスコードの「HTTP/1.0 200 Connection Established」からうかがえる。

　許可された後、10行目以降は接続元と中継先メールサーバとのSMTPの通信となり、HTTPプロキシは、単にSMTPの通信をそのまま中継（トンネリング）するだけとなる。最終的にこの通信が成立すると、foobar@example.netあてにメールが届く。

　なお、CONNECTメソッド自体は不正なものではないため、攻撃と判断するにはそのほかの要素を参照する必要がある。判断については後述する。

1/3

Index
脆弱なホストを狙った不正中継を見抜く
	Page1 不正中継、踏み台といった脆弱なホストの悪用 被害者が加害者になり得る不正中継の怖さ HTTPプロキシを利用した不正中継 HTTP CONNECTを利用した不正中継
	Page2 SMTPメールサーバの不正中継 不正中継の実例――脆弱なホストを探し、踏み台にする
	Page3 どのように判断すべきか この機会にもう一度サーバを見直してみよう

インシデントの見抜きかた 連載インデックス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード