連載
» 2007年11月07日 10時00分 公開

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

[海老根猛,@IT]

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

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

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

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

図3 メール不正中継 図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
リスト2 【例1】HTTPプロキシに対する通信

 送信先ポート番号の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
リスト3 【例2】HTTPプロキシに対する通信

 上記の例は送信先ポート番号が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
リスト4 【例3】SMTPのソースルーティングを悪用した通信
説明のため行番号を付与した

 これら3つの例は、SMTPサーバ側でソースルーティングが有効な場合、最終的にはいずれもuser@example.comあてにメールが届くことになる。

 1行目は、“:”で区切った左側の@example.netにそのSMTPサーバが受信するドメイン名(リレー可能ドメイン名)を指定し、右側に実際の送信先であるuser@example.comを指定しているのが分かる。

@リレー可能ドメイン名 : ローカルパート@ドメイン名

 2行目は、UUCPによるメール配送時に用いられる表記である。“!”の左側がリレー可能ドメイン(サイト)のexample.com、右側がローカルパート(ユーザー)となるuserを指定している。

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

Index

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

Page1

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

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

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

HTTP CONNECTを利用した不正中継


Page2

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

不正中継の実例――脆弱なホストを探し、踏み台にする


Page3

どのように判断すべきか

この機会にもう一度サーバを見直してみよう


Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。