脆弱なホストを狙った不正中継を見抜く：インシデントの見抜きかた（3）（2/3 ページ）
猛威をふるったBlasterワーム。これが大流行したのは2003年でしたが、いまだにこのワームの痕跡はインターネット上に残っています。その理由の1つは、いまだにセキュリティパッチが適用されていないホストが残っていることにもあります。今回は脆弱なホストや設定ミスによって発生する「穴」への攻撃を見抜く方法を解説します（編集部）
SMTPメールサーバの不正中継
第三者のSMTPサーバを介してメールを送る行為は、スパムメールの送信に用いられることが多い。
スパムメールのような大量のあて先へのメール送信の場合、送信元のサーバに多大な負荷が掛かってしまう。なぜならSMTPメールを送信する際には、そのあて先に応じてDNSの名前解決を行い、あて先ごとのSMTPサーバにメール送信を行う処理が発生するからである。
スパムメールの多くは、不正中継によって、そういった処理を自分ではなく第三者のSMTPサーバに肩代わりさせている。
SMTPサーバに対する最も単純な不正中継の手法は、単にメールの送信先（RCPT TO）に、組織外の第三者のメールアドレスを指定するだけである。
RCPT TO: user@example.com
仮にSMTPサーバの受け取るべきメールアドレスのドメイン名がexample.netだったとしよう。このSMTPサーバが、組織外のあて先（例:example.com）へ中継できるのは、本来であれば許可された接続元（組織内）からのみで、組織外からは拒否するのが通常だが、設定ミスにより中継を許可してしまい、知らぬうちに攻撃者の片棒を担いでいることになる。
また、これ以外にも、RFC 1123のソースルーティングを悪用した手法もオープンリレーではよく用いられる。この手法は、メールアドレスに少し手を加えることにより、先に説明した制限をすり抜けるといったものである。
詳細を次の実例で紹介しよう。
不正中継の実例――脆弱なホストを探し、踏み台にする
では、「脆弱なホストを探す通信」の実例を紹介する。以下はHTTPプロキシに対する通信の例である。
通信元 address:port 192.168.1.1:6904 通信先 address:port 10.10.10.1 (gate.example.net):8080 GET http://www.example.com/index.html HTTP/1.0
送信先ポート番号の8080はHTTPプロキシでよく利用されるポート番号である。そのほか、よく知られたものとして3128、8090、1080などもよく観察される。
GET部分に注目してほしい、http://の次にwww.example.comが入力されているが、送信先のドメインはgate.example.netである。正常なHTTPリクエストであれば、このような差異は発生しない。ポート番号と上記の特徴からこの通信はHTTPプロキシを狙っていると考えられる。
もう1つ紹介する。
通信元 address:port 172.19.8.7:32034 通信先 address:port 10.10.10.2 (www.example.net):80 POST http://www.example.com/index.php HTTP/1.1 User-Agent: Opera/9.0 (Windows NT 5.1; U; en) Host: www.example.com Pragma: no-cache Accept: */* Referer: http://www.example.com/query.htm Proxy-Connection: Keep-Alive Content-Length: 999 Content-Type: application/x-www-form-urlencoded option=com_content&do_pdf=1&id=1index2.php?_REQUEST[option] =com_content&_REQUEST[Itemid]=1&GLOBALS= &mosConfig_absolute_path=http://www.example.org
上記の例は送信先ポート番号が80（HTTP）である。
一見、正常なHTTPリクエストに見えるが、前例と同様にPOSTの後にhttp://があり、続くドメインが送信先のものと異なるため、HTTPプロキシを狙ったものと考えることができる。だが、80/tcpあての通信は通常、Webサーバソフトウェアが応答する。
では、この通信が狙っているものは何か。例えば、プロキシ機能を有効にしたApacheが該当する。これも踏み台にできるサーバを探すための通信なのだ。
次はSMTPのソースルーティングを悪用した通信の例である。
RCPT TO: @example.net:user@example.com RCPT TO: example.com!user RCPT TO: user%example.com@example.net
説明のため行番号を付与した
これら3つの例は、SMTPサーバ側でソースルーティングが有効な場合、最終的にはいずれもuser@example.comあてにメールが届くことになる。
1行目は、“:”で区切った左側の@example.netにそのSMTPサーバが受信するドメイン名（リレー可能ドメイン名）を指定し、右側に実際の送信先であるuser@example.comを指定しているのが分かる。
@リレー可能ドメイン名 : ローカルパート@ドメイン名
2行目は、UUCPによるメール配送時に用いられる表記である。“!”の左側がリレー可能ドメイン（サイト）のexample.com、右側がローカルパート（ユーザー）となるuserを指定している。
リレー可能ドメイン名（サイト名） ! ローカルパート（ユーザー名）
Copyright © ITmedia, Inc. All Rights Reserved.