tarpitでspamを止める

Published: 2007/10/24

ボットを利用したspam送信の特徴として以下のようなものがよく聞かれる。

一度強制切断されれば再送しようとしない
timeout時間が短い

実際はどうなのか？都市伝説なのか？ここではHoneyPotと仮想MTAシステムにより、実際のユーザーやMTAに迷惑をかけることなくspammerを欺いてbot経由のspam送信を捕捉し観測できる。そこでbotやbotnetの挙動の解析や実際のspam送信に対してさまざまな策を施してみてその挙動の変化を見ることができるのだが、その結果は以下のようなものであった。

一度強制切断されればSMTPレベルでの再送は行わない
SMTPレベルでの強制切断に反応しないものがある
timeout時間は意外と普通？

1.一度強制切断されればSMTPレベルでの再送は行わない

　bot経由で送信されるspamの大半はbotをProxyサーバーとして利用しているだけで、実際のメール送信はspammerが使用するspam送信ツール（massメーラー）で行っているだけのもの。botはMTAではなくMUA。MTA間の再送のルールに従うわけではない。実際の送信はひとつの送信先リストを用いて1～3周程度送信を行うので、一度送信に失敗したら、「設定によっては」次のルーティンでもう一度送信を試みることになる。再送とは関係なく失敗したMTAや失敗した送信先情報をリスト化して「使えないMTA」「つかえない送信先」としてspam送信のためのリストのクリーニングに用いられたりもする。またbotに自立的にメール送信する機能が導入されている場合でもMUAであり前述と同様の挙動を示す。したがって一度きりの送信行為を繰り返して実行しているだけであり、送信listの長さ、設定により再送があったり、なかったり、10分後だったり、いろいろな見え方をする。つまり「SMTP的な再送」はないといっていいと思う。

2.SMTPレベルでの強制切断に反応しないものがある

　MTAから500番台や400番台で応答しても無視。MTA側でSMTPレベルで切断されてもTCP connectionは維持されたままというメールサーバー的には非常にやっかいな状況になるものがある。spamを止めたら、いわゆるDDoS、いわゆるconnection floodを食らう状況になり、サーバーリソースが枯渇してメール送信不能になってしまう。このような問題は2006年当初からISP各社を悩ませていたりする。これはさすがに意図的ではなく、一部送信ツールの不備によるものだと思うが、どんなものでも作った側の意図によらず別の効果を生み出してしまう例が数多くあるが、これもそのひとつだろう。これに対応するためにはMTA側でSMTPレベルの切断と同時にTCPコネクションも強制切断する仕組みが必要になる。

3.timeoutは意外と普通？

　botからのsmtp通信のtimeoutが短いとよくいわれているものである。これを利用したspam対策として知られているのが「tarpit」と呼ばれる手法である。この手法の利用例は多数あり、効果を挙げているようである。筆者も2005年ごろWebサーバーへのDDoS（Request flood）への対抗策として利用したことがあり大きな効果を挙げたことがある。

これも同様に「HoneyPot+仮想MTA」システムにおける純粋に100%botによるSMTP通信に対していろいろ実験してみた。

ここでは簡易にpostfixの機能を使ってみた。/etc/postfix/main.cfに以下のような設定をいれるだけ。

 ①smtpd_helo_restrictions = sleep 60
 ②smtpd_client_restrictions = sleep 60
 ③smtpd_recipient_restrictions = sleep 60
 ④smtpd_data_restrictions = sleep 60

いろいろな場所でsleepを試したかったが①～③いづれも「RCPT TO」の後に指定した秒数だけsleepが入り、④の場合のみ「DATA」の後にsleepが入る。

「RCPT TO」にsleepが効いてしまうと、複数の宛先が指定されている場合にすべての「RCPT TO」コマンドにsleepが効いてしまう。この例では宛先を10個指定しているとメール1通送信するのに60x10=600秒かかってしまい実用上問題が起こるかもしれない。それなら実用的には「DATA」コマンド後に効いてもらったほうが良いのでここでは「DATA」コマンドに対して「sleep 180」を入れた例をあげる。

90秒以内にtimeoutしたものが全体の93%程度しめ、112秒程度でほぼ99%となる。最長は162秒。

RFC2821的には以下のようになっているのでほぼRFCどおりということになる。

 RCPT Command: 5 minutes 
 A longer timeout is required if processing of mailing lists and aliases is   
 not deferred until after the message was accepted. 
 
 DATA Initiation: 2 minutes
 This is while awaiting the "354 Start Input" reply to a DATA command.

(※実際のところ「RCPT TO」の後にsleepを入れた場合でもこの結果は同じである。その見方をすればtimeoutは短めと捉えることもできる。ここで確認できているspam送信はsleep位置に関係なく一律のtimeout値で動作しているのだろう。）

したがってMTAにて91秒程度まで、極論では121秒までsleepを入れてやれば、ここで観測されているspamの送信は抑止することができることになる。ただ実際には正常なMTAやMUAからの送信への影響はあるわけであり、またセッション保持時間が長くなる分smtpdの起動数や、TCPコネクション数にも影響を与えるので、これを安易にそのまま適用することはすすめない。

ただ効果があることは疑いようのないものなので、以下の注意点を押さえた上での適用の検討が必要。

ホワイトリストの整備、updateの継続
他の手法（greylistingなど）と併用することにより、tarpitを効かせる対象を絞る
smtpdの起動数等自分の運用する環境を把握しチューニングができること

など。

spam対策＝終わりなきホワイトリスト作成の努力

であることを忘れてはいけない。。。

[カテゴリ:spam観察日記][カテゴリ:botnet観察日記]

by jyake

tarpitでspamを止める

TOP

Contents

About cNotes

What's New