脆弱なホストを狙った不正中継を見抜く：インシデントの見抜きかた（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を指定している。
リレー可能ドメイン名（サイト名） ! ローカルパート（ユーザー名）
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。