[postfix-jp:03911] Greylisting

[Tomoyuki Sakurai <ml-postfix-jp@xxxxxxxxxxxxxxx>]

WARNING:
ここではPostfixを使用したGreylistingの実装について書きます。「spamをMTA
で拒否するのは検閲だ」、「spam対策は受信者がやるべきだ」とか、「spam対策
は言論の自由に反する」という議論は別の場所でお願いします。また、記述が不
正確かもしれませんから、必ずリンク先やdistributionなどの原文にあたるよう
にしてください。英語が読めない人は、誰か親切な人が訳してくれるまで待ちま
しょう。

* Greylisting

最近のspamの多くはopen proxy経由で送信される。open proxyなクライアントは
再接続することが少ない。次々と踏み台を変えて再送することはあるけど。

MTAは一時拒否されても、一定時間再接続して配送しようとする。

じゃあ、一定時間が経過するまで一時拒否(4xx)して、それでも接続してきたら、
たぶんopen proxyじゃないと思われるので受け取ることにしよう。

open proxyも一定時間後に再接続するようになるかもしれない。けど、時間が経
てば経つほどopen proxyとしてDNSBLなどに登録されてしまう確率が高くなるし、
配送コストも跳ね上がるので、それはそれで好都合。

* open proxyってなに?

第三者によって使用することのできるproxyのこと。こういうproxyはずいぶん前
から存在していて、主に匿名性を求めるユーザによって悪用されてきました(掲
示板の書き込みとか)。また、CONNECTメソッドで任意のポートに対するTCP接続
が可能なopen proxyが、数年前からspammerによって悪用されるようになりまし
た。ちなみにPOSTメソッドなどでも同じことが可能です。

virusやOS/アプリケーションの脆弱性を利用してホストにopen proxyをインストー
ルして、それを踏み台にするのが最近のトレンド(?)です。Sobigなどが有名です
ね。バックドアを仕掛けるvirus/wormの目的はopen proxyだと思ってもいいかも
しれません。特定のサイトに攻撃を仕掛けるよりも、spamを配送する方がお金に、
より直接的に結びつきますから。

しかも、外部(Internet)から接続できるproxyサーバの数は限られているけど、
脆弱なWindowsホストは腐るほどあるので、大量に配送するにはもってこい。IP
アドレスも静的に割り当てられたIPアドレスではないので、追跡も困難だし。電
源が入ったらspamを配送して、しばらくすればシャットダウンされて、次に接続
されたときにはIPアドレスも違うものが割り当てられる。特定のアドレス範囲を
MTAが拒否しても、別のopen proxyを試せばいい。これは便利ですね。

こうしたことから、open proxyはspammerに大人気。正確な統計を取ったことは
ないですけど、おそらく最近のspamの大半はopen proxy経由でしょう。SBLや
SPEWSよりlist.dsbl.orgによる拒否回数の方がはるかに多いですし。

* Greylistingの仕組み

あらかじめ、接続の記録用にデータベースを用意しておく。

クライアントのIPアドレスとenvelope-fromとenvelope-toを一組のtriplet(組み
合わせ)とする。

接続してきたクライアントのtripletがデータベースにない場合、tripletと接続
の時間をデータベースに記録する。で、一時拒否。

データベースにそのtripletがあれば、現在の時間とtripletの時間を比較して、
一定時間経過していなければ、一時拒否。

一定時間が経過していれば、受け取る、もしくはさらに判定すべき条件があれば
その判定を元に受け取るか拒否(4xxもしくは5xx)する。

詳しくは
The Next Step in the Spam Control War: Greylisting By Evan Harris
http://projects.puremagic.com/greylisting/
を読んでください。

* 一時拒否ってなに?

SMTPのエラーコード4xxを返すこと。4xxなエラーコードは一時的なエラーを意味
します。MTAはメッセージを一定期間再送しようとします。

詳しくは、
RFC 1893 - Enhanced Mail System Status Codes
http://www.faqs.org/rfcs/rfc1893.html
とか
RFC 2821 - Simple Mail Transfer Protocol
http://www.faqs.org/rfcs/rfc2821.html
の
4.2.1 Reply Code Severities and Theory
を読みましょう。

* Postfix experimental releaseのインストール

INSTALLに従ってインストールします。official releaseと手順はあまり変わり
ません。smtpd-policy.plはインストーラで(確か)インストールされないので、
適切なディレクトリにコピーします。

FreeBSDならmail/postfix-currentがあります。ただし、必ずしも最新版ではあ
りません。運がよければMakefileのバージョンとかを書き換えるだけでインストー
ルできるかもしれません。TLSとかのパッチがあたらない場合は、あきらめるか
自分で何とかします。けっこう何とかなったりします。-currentをそのまま入れ
てもいいでしょう。

あまり役に立たない作業メモ
http://trombik.mine.nu/pukiwiki/pukiwiki.php?PostfixCurrent#zc4a2b17

大きな仕様変更はないのですが、細かい挙動はofficial releaseから変更されて
いるものがあります。HISTORYを読みましょう。main.cfやmaster.cfはそのまま
使えるはずです。

* Postfixのアプローチ

Postfixではcheck_policy_serviceを使って実装されます。これはPostfixにおけ
る標準プロトコルとして実装されています。詳しくはSMTPD_POLICY_READMEを読
みましょう。こうすることでGreylistingに限らず、その他のポリシーによる制
限も柔軟に実装することができます。

smtpdは次のような属性(attributes)をpolicy serverに送ります。

    request=smtpd_access_policy
    protocol_state=RCPT
    protocol_name=SMTP
    helo_name=some.domain.tld
    queue_id=8045F2AB23
    sender=foo@xxxxxxx
    recipient=bar@xxxxxxx
    client_address=1.2.3.4
    client_name=another.domain.tld

policy serverは条件に応じて次のような返事を返します。

    action=450 Service temporarily unavailable

返事に従ってsmtpdは5xx/4xx/dunno/permitなどの動作をします。

ちなみに、policy serverはUNIXドメインソケットだけではなくTCPによる接続も
可能です。複数のクライアントで一つのpolicy serverに接続するとか、ラウン
ドロビンによるpolicy serverの負荷分散とかも可能ですね。詳しくは
TCP_TABLE(5)を読みましょう。

で、policy serverの例としてPerlで書かれたsmtpd-policy.plがdistributionに
含まれています。名前からわかるように、あくまでsampleです。Witseさんも
「スケーラビリティが課題だよね」とか言っていたように記憶しています。だか
らといって、実用にならないわけではないですし、改善することはそう難しいこ
とではないでしょう。プロトコルは公開されているわけですし。実際、手元では
何の問題もなく動作しています。

* 設定

smtpd-policy.plに書いてあるとおり、master.cfとmain.cfに何行か書き加える
だけ。

あまり役に立たない作業メモ
http://trombik.mine.nu/pukiwiki/pukiwiki.php?PostfixCurrent#r9db16a2

FIXME: 作業メモから解説にする

設定後にpostfix reloadが必要。

また、デフォルトですべてのメッセージが一時拒否されるので、あらかじめホワ
イトリストの作成が必須。また、ユーザに対しての説明も必要。

* 運用

Greylistingに限った話ではないですが、ログを見ましょう。

遅延しては困る相手ならホワイトリストを整備しましょう。DNSBLを併用する場
合もホワイトリストの作成が重要です。DNSBLで拒否されて困る相手ならDNSBLに
問い合わせる必要はないです。

ローカルのブラックリストの整備もパフォーマンスの向上などに役に立つでしょ
う。でも、ホワイトリストの整備の方が効果は大きいようです。

現在のsmtpd-policy.plには一定時間後にtripletを破棄(expire)させる機能がな
いので、データベースはふくらむばかりです。一定時間後にデータベースを空に
するなどの対策が必要です。

また、一時拒否されるとIPアドレス、つまりホストを次々に変えて再接続してく
るMTAがあるので、これもホワイトリストに登録するなどの、何らかの対策が必
要でしょう。

メーリングリストなどのMTAをGreylistingで判定の対象にするのは、意味がない
のでこういったホストもホワイトリストに入れましょう。

* 効果

現在のところ、open proxy経由の(MTA経由ではない)spamはこれで十分対応でき
ています。この制限を回避するには、同じIPアドレスから、同じenvelope-from
で、同じenvelope-toのメッセージを一定時間後に再送するしかありません。そ
の間に、open proxyをリストするDNSBLに登録されてしまえば、やはり拒否され
てしまいます。しかもspammerはenvelope-fromや踏み台にするopen proxyを次々
と変えて接続しますから、さらに好都合ですね。

問題はMTAを経由して配送されるspamです。MTAなら一時拒否されても一定期間、
再配送しようとします。ですからMTA経由のspamには効果がありません。でも、
今時open relayなMTAや自分でたてたMTAを使ってspamを配送するのは、あまり賢
いとは言えません。すでにそういったIPアドレス範囲やspam friendlyなISPは軒
並みDNSBLで拒否されてしまいますから。ISPのMTAを使用するのも足がつきやす
いので継続的なspamの配送には向いていません。まぁ、例外はあるのですけど。

もう一つ、Greylistingの効果としてvirus/wormの拡散もある程度防ぐことがで
きます。なぜならvirus/wormの配送方法はopen proxyを利用したそれとそっくり
だからです。今回のMyDoomでも同じIPアドレス/envelope-from/envelope-toを使
用した再接続は2回程度のようです。

* 結論

結論を書きたいところですが、きちんとした統計がとれていないので、明確な結
論を書くことができません。ですので、PostfixにおけるGreylistingの実装を試
したらその結果を報告していただけると幸いです。手元では(他の手法も併用し
て)spamを一掃することができています。
--
Tomoyuki Sakurai - Tomi -
mailto:ml-postfix-jp@xxxxxxxxxxxxxxx
local dnsbl files updated daily at
rsync://trombik.mine.nu/spf/output/