2007-07-03 (Tue)
■[pc][spam]taRgreyのtarpitting時間について

前のエントリーで書いた和歌山大学で導入されているtaRgreyの件で、和歌山大学システム情報学センターの吉田さんからメールいただき、いろいろと情報をいただいていました。
その中で、taRgreyの遅延時間について大変参考になる資料をいただきました。
これは遅延時間が3分(180秒)での切断時間のログです。
このログから、今まで推奨していた65秒の遅延では、遅延で拒否できる接続の約65%までしか拒否されず、約2分強まで掛けたほうが良い、ということがわかります。
ただ実際にはここまで漏れ(false negative)があるわけではないので、残りの分はHELOによるフィルタなどで落とされている可能性が高いと考えられます。
(追記)
Birds Of a Feather | taRgreyの遅延時間を125秒にした場合
Birds Of a Feather | taRgrey遅延時間を125秒にして丸一日の集計 より

cookie@信州FMさんのところで125秒で設定して試していただいたログでも、同様の結果が出ており、拒否されたIPを見るとやはりみなspamのようです。
自分のテスト環境ではこんな感じでした。
やはり、120秒で大きな山が出ています。
そしてこの山はpipelining(こちらが返答を返していないのにもかかわらず、待たずに残りの情報を送ってきて切断しているもの)なので、普通のメールサーバでそんなことはしませんから、それだけでほぼ間違いなくスパムであることがわかります。
これまでの65〜90秒程度までのグラフについては
モーグルとカバとパウダーの日記 - Postfix-2.3でsleep中に切断されたらすぐに終了するパッチ
のものを参照してください。
自分はStarpit、つまりgreylistingでの救済がない運用から始めているため、遅延時間を最大でも90秒程度からテストしていました。
しかしtaRgreyの場合、tarpittingで誤検出する場合でも、greylistingでの救済がありますから、tarpittingの時間を長めに取っても誤検出となる可能性は低く抑えることが出来ます。
120秒のtarpttingだと、S25Rに引っかかってtarpittingを抜けられない正しいサーバがごくまれにありますが、greylistingで救済されると考えられます。
なので逆に、tarpitting+greylistingの2重でフィルタして運用している場合は、やはり65秒程度にしておいたほうがベターだと思います。
自分は今とりあえず、125秒に設定して運用試してみています。
もしtaRgreyで65秒ぐらいで運用されている方は、false negativeが気になる場合、125秒くらいに設定試してみて、false positiveが増えたりしないか、確認いただければと思います。
もし悪影響が少ないようであれば、この値をデフォルトにしたいと思うので、レポートいただけるとありがたいです。
(関連)
モーグルとカバとパウダーの日記 - 和歌山大の情報センターでもtaRgrey導入されてる
- 424 http://k2net.hakuba.jp/targrey/
- 34 http://shinshu.fm/MHz/77.88/archives/0000197926.html
- 32 http://www.google.co.jp/search?sourceid=navclient&hl=ja&ie=UTF-8&rls=GGLJ,GGLJ:2006-31,GGLJ:ja&q=tarpitting+125
- 30 http://shinshu.fm/MHz/77.88/archives/0000198063.html
- 25 http://k2net.hakuba.jp/targrey/index.html
- 23 http://shinshu.fm/MHz/77.88/archives/0000197784.html
- 17 http://shinshu.fm/MHz/77.88/
- 15 http://shinshu.fm/MHz/77.88/a08950/
- 15 http://www.google.com/search?hl=ja&lr=lang_ja&ie=UTF-8&oe=UTF-8&q=id:stealthinu&num=50
- 13 http://search.yahoo.co.jp/search?p=モーグル+2007&ei=UTF-8&fl=0&meta=vc=&pstart=1&fr=top_v2&b=21



簡単ですが、遅延時間のヒストグラムもグラフにしておきました。
確かにこれで抜けがだいぶ減りますね。ただ、false positiveの可能性は増すので、それがどのくらい影響あるかが気になるところです。
早速、エントリーへ追記させていただきました。
グラフも描き直しましたので、こちらと差替えいただければと思います。
http://shinshu.fm/MHz/77.88/images/xc4Yx9G6.png
こちらはもっと顕著な値が出てますね。
ということは、このピークは、特定のbot群を持ってるスパム送信業者1社のみ、ということなんだと推測出来ます。
そこだけで、全スパムの約3〜4割を出してる、と。
それ以外でも、切断時間のピークが現れている箇所は、同一システムか同一ソフトを使っている可能性が高いって事かなと思っています。
しばらく前から、125秒の設定にした部分があります。
報告すればよかったかも。
(定量的な解析してないのものですから…(^^;))
結構、119秒とかが多い感じもしますし、
123〜124秒まで粘るのもありますね。
あと、sleepでに相当数を叩き落してますが
それでも抜けたものをあらためてブラックリストで
チェックをするようにもしてみました。
そうですね。90秒でのピークや、60秒でもpipeliningで切ってるのは、たぶん同一業者でしょうね。
そう考えると、スパムの7割は3,4件のスパム送信業者によって撒かれてるんじゃないかと思います。
>>ohbaさん
やっぱり遅延時間延ばされてるのですね。
とりあえず、Webのほうの表記を125秒推奨に変更することにしました。