脆弱なホストを狙った不正中継を見抜く：インシデントの見抜きかた（3）（2/3 ページ）

SMTPメールサーバの不正中継

　第三者のSMTPサーバを介してメールを送る行為は、スパムメールの送信に用いられることが多い。

　スパムメールのような大量のあて先へのメール送信の場合、送信元のサーバに多大な負荷が掛かってしまう。なぜならSMTPメールを送信する際には、そのあて先に応じてDNSの名前解決を行い、あて先ごとのSMTPサーバにメール送信を行う処理が発生するからである。

　スパムメールの多くは、不正中継によって、そういった処理を自分ではなく第三者のSMTPサーバに肩代わりさせている。

図3　メール不正中継

　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を指定している。

リレー可能ドメイン名（サイト名） ! ローカルパート（ユーザー名）