モーグルとカバとパウダーの日記 このページをアンテナに追加 RSSフィード Twitter

モーグルやカバ(EXカービングスキー)、山スキー(BC)の山行記録などがメインの日記です。
いろんな条件のいろんなところを、その時々の条件にあった滑り方で楽しむ、フリースキーをして遊んでいます。

検索で来られた方は、上の検索窓から再度検索していただくか、右サイドバーのカテゴリーやトピックスの項目で絞り込んでみてください。
仕事柄、コンピュータ系のネタも多いので、スキー関連ネタだけ読みたい方は[ski]、コンピュータ関連ネタは[pc]、スパム関連ネタは[spam]で絞り込んでください。

2006-07-06 (Thu)

[][]Starpitでほぼ誤検出無く98%のスパムを排除 (S25R+tarpittingによるスパム対策) Starpitでほぼ誤検出無く98%のスパムを排除 (S25R+tarpittingによるスパム対策)を含むブックマーク Starpitでほぼ誤検出無く98%のスパムを排除 (S25R+tarpittingによるスパム対策)のブックマークコメント

(追記)

このStarpitの課題点を改善したtaRgreyというものを提案しています。

こちらのほうがいろいろな点でよりベターなものになっていますので、こちらのエントリーをご覧いただいた後は、このエントリーもご確認下さい。

taRgrey - S25R + tarpitting + greylisting (tarpit + greylist policy server)

モーグルとカバとパウダーの日記 - taRgrey - S25R + tarpitting + greylisting


(修正 2009/05/19)

現時点でのスパムに対応するように遅延時間を85秒に変更しました。またS25RのパターンをIPv6での誤検出が無いように変更されたのを、今更ながら反映しました。


Starpitというスパム対策方法を提案します。*1

これはMTAで「ほぼ誤検出無く」93%程度のスパムを排除できる手法です。さらに特定業者フィルタと組み合わせて98%強の排除率にすることが出来ます。(2006/7 時点で)


S25Rという接続元IPFQDNから動的IPを見分けるパターンにマッチするものだけ、tarpitting*2という「返答の遅延」を掛けることで、スパム送信側が時間を待ちきれずに勝手に接続を切る*3、というものです。

ですから正確には、スパムを拒否しているのではなくて、スパム送信側が勝手に送信をやめているということになります。

同様な手法でRgreyという、S25Rにマッチするものだけgreylisting(一度再送要求を出し、再送してきた場合は受け取る)を掛ける、という手法を提案していますが、それのtarpitting版と考えても良いでしょう。


S25Rにマッチするような動的なIPから送ろうとしているメールで、かつ通常のMTAではタイムアウトが5分と設定されている*4ところを、例えば1分以内で送信するのをやめてしまうようなメールサーバの場合、ほぼスパムと断定出来ると考えられます。

自宅サーバなど動的IPからの送信の場合でも、通常のMTAを利用している場合はtarpittingタイムアウトしないため、問題なく送信することが出来ます。

弊社のメールサーバではこの設定で半年以上の運用実績がありますが、今のところまだ誤検出での問い合わせはありません。

また、もっと大規模(数万アカウント)な環境での5ヶ月ほどの運用では、数件の問い合わせ(しかもほぼDNSの設定ミスによるもの)でした。


Starpitはスパムの排除率ではなく、誤検出や副作用が少なくなることを目標として、まず間違いなくスパムだというものを排除するための1次フィルタとして利用することを想定しているため、単体ではそれほどの排除率は高くありません。

S25R単体での排除率は98%強ほどですが、S25R+tarpittingとすることで93%程度にまで排除率が落ちます。

しかし、他のフィルタ設定を併用することで、排除率も上げることが出来ます。

Starpit+Rgreyという構成では96%強の排除率でした。

Starpit+特定業者フィルタでは誤検出を増すことなく98%程の排除率でした。

f:id:stealthinu:20060707141927p:image:small tarpittingを掛ける時間や他のフィルタを併用した場合の、スパム排除率等のグラフ (小さくて見にくいですが、紫の線が最終的なスパムの検出率で、一番右の結果が、Starpit90s+特定業者フィルタのものになります。)

さらに排除率を上げるために、後段に検出手法が全く異なるベイジアンフィルタなどのコンテンツフィルタを利用することも効果的で、コンテンツフィルタの負荷低減や人間の誤検出確認の負荷*5にも効果が有ります。


また、Starpitではsmtpdプロセス数の増加が起るため、非常に負荷の高いメールサーバには向かない場合もあります。

その場合は、StarpitではなくRgreyのみで運用したほうが良いかもしれません。

そのサーバの状況や運用ポリシーに合わせて、どういう組み合わせで利用するかを決定すると良いでしょう。(参考 RgreyとStarpitの比較)



良い点、悪い点

良い点

  • ほぼ誤検出がない(たぶんRgreyと比較してもより少なそう)
  • ほとんどメールの遅延などの副作用がない(Rgreyの場合、S25Rにマッチすると再送待ちまで遅延が起る)
  • ほぼメンテナンスの必要がない
  • メールサーバの負荷増がほぼない(スパム処理分が減るので逆に負荷が軽くなる可能性もある)
  • ウイルスメールも排除できる
  • qsv系など、qmailpostfixを送信に使っていてgreylistingでも抜けてくるスパムも排除できる*6
  • Postfix2.3以降なら設定だけで利用出来る*7
  • ネットワークサービス事業者でも利用出来る可能性が高い(後述)

悪い点


設定内容

設定の核となる部分は以下の内容になります。

/etc/postfix/main.cf 一部抜粋

smtpd_recipient_restrictions =
	...
	check_client_access    regexp:/etc/postfix/tarpit_client
	....

/etc/postfix/tarpit_client 一部抜粋

(2009/5/19修正 S25Rパターン更新と現時点のスパム遅延待ち時間に対応)

# *** S25R ***
/^unknown$/                                     sleep 85
/^[^.]*[0-9][^0-9.]+[0-9].*\./                  sleep 85
/^[^.]*[0-9]{5}/                                sleep 85
/^([^.]+\.)?[0-9][^.]*\.[^.]+\..+\.[a-z]/       sleep 85
/^[^.]*[0-9]\.[^.]*[0-9]-[0-9]/                 sleep 85
/^[^.]*[0-9]\.[^.]*[0-9]\.[^.]+\..+\./          sleep 85
/^(dhcp|dialup|ppp|[achrsvx]?dsl)[^.]*[0-9]/    sleep 85

# *** S25R ***
/^unknown$/                                   sleep 65
/^[^\.]*[0-9][^0-9\.]+[0-9]/                  sleep 65
/^[^\.]*[0-9]{5}/                             sleep 65
/^([^\.]+\.)?[0-9][^\.]*\.[^\.]+\..+\.[a-z]/  sleep 65
/^[^\.]*[0-9]\.[^\.]*[0-9]-[0-9]/             sleep 65
/^[^\.]*[0-9]\.[^\.]*[0-9]\.[^\.]+\..+\./     sleep 65
/^(dhcp|dialup|ppp|adsl)[^\.]*[0-9]/          sleep 65

これだけです。

これで動的IPからと思われる接続からは、65秒の遅延が掛かるようになります。(RCPTを受け取った後に65秒遅延が掛かります。)*9

「sleep」という指定をするために、通常はPostfix2.3以降のバージョンが必要となります。

実運用時にはこれに、S25Rに引っかからない動的IPのリストや、S25Rに引っかかるけれども正しいメールサーバホワイトリストを組み合わせて使います。


遅延時間

tarpittingの設定では、どの段階でどれだけの時間遅延を掛けるかで、スパムの排除率が変ってきます。

10秒や20秒程度でも有る程度の効果が認められます。

他のチェックが全くない場合、遅延時間を変えて試してみたところ、30秒で40%程、60秒で60%程、90秒で80%程のスパムが排除されました。

遅延で排除できるスパムのうち、80%弱が35秒以内に、95%程度が65秒以内に接続を切っています。Postfix-2.3でsleep中に切断されたらすぐに終了するパッチのエントリーで確認出来ます。


RFC2821 #4.5.3.2 Timeoutsでは「RCPT Command: 5 minutes」と規定されています。

そのため、例えば65秒程度の遅延を掛けても、一般的なMTAと標準の設定では問題になりません。


ログを残す

tarpittingは、sendmailではgreet pauseという機能で呼ばれており、同じく返答を遅延させることでスパムを排除するものです。

greet pauseの場合、この名の通り接続した最初のgreeting message(接続時に出てくる挨拶)表示をゆっくり行う、というものですが、ここで行うtarpittingは遅延を掛けるタイミングが違い、送信者と受信者のメールアドレスを受け取ってから遅延するようにしています。

これは、greet pauseでは接続元IPしかログに情報が残せないため、もし誤検出があった場合に調査が難しくなるためです。

接続元IPと送信元メールアドレス、送信先メールアドレスなどの情報をログを残したい場合、下記のように設定を追加してやります。

/etc/postfix/main.cf 一部抜粋

smtpd_recipient_restrictions =
	...
	check_client_access    regexp:/etc/postfix/warn_client
	...
	check_client_access    regexp:/etc/postfix/tarpit_client
	....

/etc/postfix/warn_client 一部抜粋

# *** S25R ***
/^unknown$/                                     WARN
/^[^.]*[0-9][^0-9.]+[0-9].*\./                  WARN
/^[^.]*[0-9]{5}/                                WARN
/^([^.]+\.)?[0-9][^.]*\.[^.]+\..+\.[a-z]/       WARN
/^[^.]*[0-9]\.[^.]*[0-9]-[0-9]/                 WARN
/^[^.]*[0-9]\.[^.]*[0-9]\.[^.]+\..+\./          WARN
/^(dhcp|dialup|ppp|[achrsvx]?dsl)[^.]*[0-9]/    WARN

ネットワークサービス事業者の場合

電気通信事業者の場合、利用者の同意無くメールの発信者情報に基づいてメールを遅延させることは、電気通信事業法に抵触する可能性があり、Starpitもこれに該当します。

しかし、大量のメールによるサーバ等への負担や、利用者のメールの送受信時の支障を解消するという正当な目的に基づき、必要最小限度の方法で遅延等させる場合には、正当業務行為としてユーザの同意が無くとも許されます。


迷惑メールによるサーバ負荷増のため、メールの遅延等を起こさないようにサーバの増強等を強いられている場合、Starpitを導入出来る可能性があります。

総務省の消費者行政課(スパムフィルタ等関連の問い合わせ先部署)に相談して、現在のメールサーバの負荷状況と導入する予定のフィルタ内容を説明して、判断していただくのが良いでしょう。*10


以降で説明するgreylistingとの併用や、特定業者フィルタについては、少なくともユーザからの同意が必要になると思われます。(その場合、tarpitting等の指定の前に、RCPT TO先のユーザ名とスパムフィルタを掛けるユーザのテーブルとをマッチングして、OKしてしまうようにシステムを構築すればよい。)

ユーザからの同意がある場合でもフィルタの適用が可能かは、同様に問い合わせて確認ください。


Rgreyとの併用

誤検出や副作用を減らすことよりも、スパムの排除率を上げたい場合は、Starpit+Rgreyという構成にして運用することも出来ます。

つまり、S25Rにマッチするものに対してtarpittingを掛け、それでも通ったものに対して再度greylistingを掛けるわけです。

これにより、スパムの排除率は96%強まで上げることが出来ます。

しかしそれと同時に、greylistingによる誤検出の可能性が(S25Rにマッチしたもののみしか影響を受けないため、その可能性はとても低いですが)増えます。また誤検出までいかなくても、S25Rにマッチした場合はgreylistingによる遅延という副作用が出ます。


下記の設定でStarpitとRgreyとをどちらも掛けることが出来ます。詳しくは、Rgreyのページを参照ください。

/etc/postfix/main.cf 一部抜粋

## for Rgrey
smtpd_restriction_classes =
	greylist_client
greylist_client =
	check_policy_service inet:60000

smtpd_recipient_restrictions =
	...
	check_client_access    regexp:/etc/postfix/tarpit_client
	....
	check_client_access    regexp:/etc/postfix/greylist_client
	....

/etc/postfix/greylist_client 一部抜粋

# *** S25R ***
/^unknown$/                                     greylist_client
/^[^.]*[0-9][^0-9.]+[0-9].*\./                  greylist_client
/^[^.]*[0-9]{5}/                                greylist_client
/^([^.]+\.)?[0-9][^.]*\.[^.]+\..+\.[a-z]/       greylist_client
/^[^.]*[0-9]\.[^.]*[0-9]-[0-9]/                 greylist_client
/^[^.]*[0-9]\.[^.]*[0-9]\.[^.]+\..+\./          greylist_client
/^(dhcp|dialup|ppp|[achrsvx]?dsl)[^.]*[0-9]/    greylist_client

このセクション以降の設定については、そのままRgreyでも利用できますので、Rgreyで運用される方もご参照下さい。


特定業者フィルタ

Starpitで排除できるスパムは、弊社のメールサーバSpamAssassinの判定とログより推定すると、約93%程度となっています。

postfixqmailなどをタイムアウトの設定も変更せずに利用して送ってきているような業者の場合、Starpitを抜けてきてしまいます。

しかし、Starpitを抜けてくるスパムは特定スパム送信業者に限られてくること、またタイムアウト設定すら変更しないで送ってくるようなあまり工夫しない業者ため、その専用のフィルタを3,4件設定してやることで、98%強まで排除率を上げることが出来ます。

また、怪しいのにどうしてもそれだけでは排除できない場合、後段の2次フィルタに対して参考情報を付加してやることで、それを参考にしたポイント付けをして2次フィルタの検出率を高めることが出来ます。

(関連)

モーグルとカバとパウダーの日記 - スパマーのネームサーバでフィルタリング (qsv系スパムをNSで拒否)

モーグルとカバとパウダーの日記 - melsoho系(From:mel@〜.(com|net)で内容がSOHO関連)スパムを拒否する

モーグルとカバとパウダーの日記 - apachelivedoor系スパム(From:apache@〜.infoでlivedoorのNSを使っている業者)を拒否


具体的には以下のように設定します。

smtpd_restriction_classes =
        reject_client_s25r
        reject_client_nothotmail
        check_sender_apacheinfo
reject_client_s25r =
        check_client_access    regexp:/etc/postfix/reject_client_s25r
reject_client_nothotmail =
        check_client_access    regexp:/etc/postfix/reject_client_nothotmail
check_sender_apacheinfo =
        check_sender_access    regexp:/etc/postfix/check_sender_apacheinfo

smtpd_recipient_restrictions =
        ...
        check_helo_access      hash:/etc/postfix/reject_helo
        check_sender_ns_access hash:/etc/postfix/reject_ns
        check_sender_mx_access hash:/etc/postfix/reject_mx
        check_helo_access      regexp:/etc/postfix/check_helo
        check_sender_ns_access regexp:/etc/postfix/check_ns
        check_client_access    regexp:/etc/postfix/tarpit_client
        ...

/etc/postfix/reject_helo

# *** HELO from my domain/server/IP ***
【自分のドメイン】.jp                       REJECT match HELO blacklist
mail.【自分のドメイン】.jp                  REJECT match HELO blacklist

これは自分のドメインでメールサーバが一つだけの場合など、自分自身から自分自身宛にメールをSMTP接続で送ることがあり得ない場合、スパマーがHELOで自分自身のドメイン名を騙って送ってきたときに拒否する設定です。


/etc/postfix/reject_mx

0                                               REJECT Invalid MX 0.0.0.0/8
10                                              REJECT Invalid MX 10.0.0.0/8
127                                             REJECT Invalid MX 127.0.0.0/8
…略

おかしなMX、例えばプライベートIPに指定してあるなど、の場合に拒否する設定です。

送信者アドレスの MX レコードによる判定 - MTA のアクセス制御 参照)


/etc/postfix/reject_ns

# qsv
ns1.is-name.net                                 REJECT match NS blacklist qsv
ns2.is-name.net                                 REJECT match NS blacklist qsv
ns1.kim-name.net                                REJECT match NS blacklist qsv
ns2.kim-name.net                                REJECT match NS blacklist qsv
…略
# melsoho
ns1.busiassist.net                              REJECT match NS blacklist melsoho
ns2.busiassist.net                              REJECT match NS blacklist melsoho
ns1.busiassists.com                             REJECT match NS blacklist melsoho
ns2.busiassists.com                             REJECT match NS blacklist melsoho
…略
# mynsto
dns.myns.to                                     REJECT match NS blacklist mynsto
dns2.myns.to                                    REJECT match NS blacklist mynsto

NS(ネームサーバ)でのブラックリストです。

スパマーが運営しているNSなど、そのNSがスパムドメインしか管理していない場合に、そのNSをネームサーバとしているドメインを拒否します。

qsv系やmelsoho系、mynsto系などを拒否するために使います。(qsv系は30s以上のtarpittingで排除できますが、念のため)


/etc/postfix/check_helo

/^([^\.]+\.)?hotmail\.com$/     reject_client_nothotmail
/^([^\.]+\.)?mailyes\.net$/     reject_client_s25r
/^([^\.]+\.)?mtassigns\.com$/   reject_client_s25r

/etc/postfix/reject_client_nothotmail

/\.hotmail\.com$/                    DUNNO
/^adsl-[0-9\-]+\.dsl\.irvnca\.(pacbell|sbcglobal)\.net$/    REJECT match hotmail blacklist
# *** S25R ***
/^unknown$/                                     REJECT match hotmail blacklist
/^[^.]*[0-9][^0-9.]+[0-9].*\./                  REJECT match hotmail blacklist
/^[^.]*[0-9]{5}/                                REJECT match hotmail blacklist
/^([^.]+\.)?[0-9][^.]*\.[^.]+\..+\.[a-z]/       REJECT match hotmail blacklist
/^[^.]*[0-9]\.[^.]*[0-9]-[0-9]/                 REJECT match hotmail blacklist
/^[^.]*[0-9]\.[^.]*[0-9]\.[^.]+\..+\./          REJECT match hotmail blacklist
/^(dhcp|dialup|ppp|[achrsvx]?dsl)[^.]*[0-9]/    REJECT match hotmail blacklist

/etc/postfix/reject_client_s25r

# *** BLACK LIST ***
/^[0-9\.]+\.ap\.yournet\.ne\.jp$/               REJECT match compound blacklist
/^pl[0-9]+\.nas[0-9]+\.(ichikawa|o-tokyo|kyoto|toyama)\.nttpc\.ne\.jp$/ REJECT match compound blacklist
/^adsl-[0-9\-]+\.dsl\.irvnca\.(pacbell|sbcglobal)\.net$/    REJECT match compound blacklist
…略
# *** S25R ***
/^unknown$/                                     REJECT match compound blacklist
/^[^.]*[0-9][^0-9.]+[0-9].*\./                  REJECT match compound blacklist
/^[^.]*[0-9]{5}/                                REJECT match compound blacklist
/^([^.]+\.)?[0-9][^.]*\.[^.]+\..+\.[a-z]/       REJECT match compound blacklist
/^[^.]*[0-9]\.[^.]*[0-9]-[0-9]/                 REJECT match compound blacklist
/^[^.]*[0-9]\.[^.]*[0-9]\.[^.]+\..+\./          REJECT match compound blacklist
/^(dhcp|dialup|ppp|[achrsvx]?dsl)[^.]*[0-9]/    REJECT match compound blacklist

HELOで特定のスパム業者が名乗る名前のドメイン(mailyes.net,mtassigns.com)の場合に拒否します。

またHotmailからの接続でないのに、サーバ名をhotmail.comだと言ってくる場合に拒否します。

念のため、接続元がS25Rにマッチする場合にのみ拒否します。


/etc/postfix/check_ns

/^ns[1-2]\.domain\.livedoor\.com$/      check_sender_apacheinfo

/etc/postfix/check_sender_apacheinfo

/^apache@[^\.]+\.info$/                 reject_client_s25r

livedoorから〜.infoのドメインを取得して(だからNSはlivedoorが使用されている)、senderがapache@〜.infoとしてなっている業者を排除します。


ホワイトリストの設定

現在、弊社サーバで利用しているホワイトリストを公開します。

/etc/postfix/whitelist_client

実際にStarpitで必要となるホワイトリストは、最初の数件の部分だけですが、より副作用を減らすためにS25Rホワイトリストで集積されている情報もそのまま利用しています。

また今後、greylisting用のホワイトリストからS25Rにマッチするもののみ、導入する予定です。


ホワイトリストを掛ける際の注意点として、ホワイトリストは、tarpit_clientで遅延を掛けている

check_client_access    regexp:/etc/postfix/tarpit_client

よりも前のところで、別ファイルで行うようにしたほうが良いです。

理由は、regexpテーブルの適用順が、完全にその記述順ではなく、ホスト名でのマッチングの後、IPアドレスでのマッチングが行われてしまうためです。

そのため、先に「unknown」でマッチングしてしまい、IPで書かれたホワイトリストがマッチングしてきません。

この問題について詳細を、下記エントリーにて書きました。

モーグルとカバとパウダーの日記 - postfixでのregexp適用順がマニュアルの記述と違う


具体的な設定

具体的な設定について弊社で実運用している設定を、スパム対策に関する部分だけ抜き出したものを公開します。

これまで上で書いたことをまとめた設定となります。

Starpit+特定業者フィルタで運用しており、Rgreyを併用する設定はコメントアウトしていますので、必要に応じて修正してください。

http://k2net.hakuba.jp/spam/postfix.conf.tar.gz


(追記)

ネットワークセキュリティExpert5というムックで、StarpitやtaRgreyについての解説を書きました。

こちらのサポートページにも、具体的な設定例のファイルを置いてありますので、そちらも参照してもらえると参考になると思います。

モーグルとカバとパウダーの日記 - ネットワークセキュリティExpert5でpostfixのスパム対策について書きました。

ネットワークセキュリティExpert5迷惑メール対策サポートページ


2次フィルタの利用

後段にウイルスフィルタベイジアンフィルタを用いる場合の、構成例を紹介します。

弊社では、Starpit+ClamSMTP(ClamAV)+SpamPD(SpamAssassin)という構成で運用しています。

モーグルとカバとパウダーの日記 - Postfixの設定でClamSMTPとSpamAssassinを利用する

ウイルスメールは、ほぼ全てtarpittinggreylistingで排除できますが、企業のGWから出されている場合など、S25Rにマッチしないところから出ている場合は抜けてきてしまいます。そのため、ウイルスフィルタが必要になります。

SpamAssassinは日本語パッチを当てたものを利用すると、ベイジアンフィルタによる誤検出が劇的に下がりますので、SpamAssassinを導入されている場合はぜひ日本語パッチを適用しましょう。

モーグルとカバとパウダーの日記 - SpamAssassinのベイジアンフィルタ日本語対応パッチ


logcheckの追加設定

Debianなどでこの設定を使うと、logcheckが標準で設定されているため、たくさんの余計なログがメールで報告されてきてしまうようになります。

そこで、無視しても良いログのパターンを設定してやることで、余計なログは上がってこなくなります。

モーグルとカバとパウダーの日記 - Starpit設定してるときに追加した方がよいlogcheckの設定


sleep中に切断を検知して終了するパッチ

Postfix-2.3.0でtarpittingを行うために利用しているsleepという指定は、プログラム内部では単にsleepが呼ばれているため、スパマーが途中で接続を切っても、こちらのプロセスはsleepで指定した秒数だけ残り続けてしまいます。

そこで、切断を検知して終了するパッチを作りました。

プロセス数の増加が問題になる場合にはこのパッチを当てることで、Starpitにより増加したプロセス数を、遅延90sで40%程度、遅延60sで70%程度に減らすことができます。

モーグルとカバとパウダーの日記 - Postfix-2.3でsleep中に切断されたらすぐに終了するパッチ


参考ページ

スパム対策技術 (阻止率99%のスパム対策方式の研究報告 Selective SMTP Rejection (S25R)方式)

S25Rという動的IPからの接続を見分けることでスパム対策をする手法です。

このアイデアがなければStarpitは存在しませんでした。


tarpitting MTA のアクセス制御

greet pause - どさにっき

SMTPトランザクションの遅延

tarpittingについては上記ページが非常に参考になります。

ちなみに自分は、やまやさんから日記のコメントで教えていただいたのが、tarpitting知った最初だったように思います。


「メールゲートウェイにおけるspam 対策について」

大分大学の吉田和幸先生の論文です。

こちらでは、S25Rではないものの、DNSBLなどで怪しいと思われる接続先に対してのみgreet pausegreylistingを掛けて(つまりStarpit+Rgreyのような構成)排除されています。

その各フィルタ毎の率についてのレポートなどもあります。

非常に参考になりました。というかStarpitは、ここで吉田先生がされているスパム対策の、具体的な設定方法を提示しているだけ、とも言えます。


Greet Pauseを設定してみました

日本の非常に良質なDNSBLである、RBL.JPの運営などされているハートコンピュータさんのレポートです。

こちらでも、greet pauseを怪しい接続先に対してのみ掛ける、と言う手法を利用されています。

ハートコンピュータさんとほぼ同じ手法に行き着いているということで、現時点ではベストな手法なのかと思っています。


ベイズフィルタ精度向上の確認試験結果

最初にSpamAssassin日本語パッチを書かれたサードウェア久保さんのレポート

SpamAssassin関連実験場

現在SpamAssassin日本語化パッチを公開されている滝澤さんのページ


Rgrey - S25R + greylisting

自分が提唱しているS25R+greylistingという組み合わせで、誤検出や副作用がほとんどないスパム対策手法です。


長野で働く専務のblog:SPAM対策まとめ - livedoor Blog(ブログ)

高村さんのところにStarpit導入していただいた際のまとめ。好評いただいて良かったです。

実際の導入の感じなどがつかめると思います。


MTA のアクセス制御

MTAでのスパム対策等について、最もまとまっていて参考になるページでしょう。

スパム対策等されている方で、まだ読まれていない方は必読です。

*1:Postfix2.3の正式版が出てから書こうと思ってたんですが、実は何度か日記やコメントにちょろっと書いてたんで、少しずつStarpitとその関連の情報をまとめることにしました。

*2:throttlingやgreet pauseなどとも呼ばれる

*3スパムは時間内になるべく大量にメールを送りたいため、反応の遅いメールサーバには送信をあきらめるように設定されている

*4RFC2821 #4.5.3.2 Timeoutsでは「RCPT Command: 5 minutes」と規定されている

*5:100通のスパム候補から1通の誤検出を検出するのは手間ですが、10通の中からならだいぶ楽です

*6:ちなみにqsv系はパラメータ変えて試したところ30sでタイムアウトさせている模様

*7Postfix2.3は現在まだベータですが、RC6となっていてもうすぐstableになると思われます2006/7/13現在でstableになりました!

*8:make makefiles CCARGS="... -DSNAPSHOT" として Makefile を作成してからコンパイル

*9スパマータイムアウト時間の計測より、遅延時間設定を90秒から65秒へ短縮しました。

*10:歯切れの悪い書き方ですみません。

白馬のガイドさん白馬のガイドさん 2006/07/06 18:47 WalkEZ=微妙な重さでした。
例えるとですね・・・ビーコン1.5台分といった感じ。
折りたたむと小さくなるので、ザックに忍ばせておけば携帯しても問題無さそうです。
ただ、意外と高かったです。
9,000円くらいだったかなあ。

stealthinustealthinu 2006/07/07 09:38 情報ありがとうございます。
もっと重いかと思っていたんで、それなら携帯性はそこそこ良いかなという印象です。
確かに9,000円はちょい高いですね。5,000円くらいなら買いかなあ…

いわもとこういちいわもとこういち 2006/07/09 01:12 > 「Initial 220 Message: 5 minutes」
こまかい点ですけれど、RCPTコマンドの応答に遅延を入れているので、対応するタイムアウトの規定は「RCPT Command: 5 minutes」ではないかと。
結局は同じ値なんですけれど。

stealthinustealthinu 2006/07/09 16:30 そう言えば以前Postfix-MLで、ClamSMTPとSpamAssassinをどっちもフィルタで利用したい、という件でお世話になりました _o_

確かにこの場合、Greetingで遅延させているわけではないんで、そちらですね。
ご指摘ありがとうございます。修正しておきます。

いわもとこういちいわもとこういち 2006/07/11 13:43 RCPTコマンドの応答に90秒の遅延を入れた場合、例えば1通のメールの宛先が10あると
合計で15分待たされる事になりますよね。
その間送信側のsmtpのプロセスを占有するので、まともな送信者の場合にちょっと気が引けるかも。

DATAコマンドの応答に遅延を入れるようにすれば宛先の数に関係なく一律に遅延を入れられますが、
・DATAコマンドへの遅延が、RCPTコマンドへの遅延と同程度の効果があるか不明
・DATAコマンドのタイムアウトの規定は2分で、他に比べて短い
あたりが気になります。

stealthinustealthinu 2006/07/11 14:38 なるほど。確かにそうですね。
結局、一度の接続に対して一度だけ遅延を掛けたいわけで、RCPTコマンドは複数入力される可能性がある、というところが問題なのだと思います。
Postfixではデフォルトだと、HELOで遅延を掛ける設定にしてもRCPTのタイミングで遅延を掛けるようになっているので、smtpd_helo_restrictions で掛けてみたのですが、やっぱりRCPTごとに遅延しますね…
うーむむ、遅延をpostfixで掛けるのでなく、postgreyみたいなfilterかましてそっちでやったほうが良いのかなあ。それだと一度tarpitting抜けたものはホワイトリストに入れて遅延させなくしたり、抜けなかったところをブラックリストに入れて、遅延させずに再送要求で切断することも出来るので。

ACTACT 2006/08/13 10:28 早速、Postfix2.3で運用してみました。
そこで気づいた点。
S25Rの箇所で/^unknown$/を入れると、IPアドレスをWHITE LIST部分で指定しても、/^unknown$/の指定が先に評価されいるようです。
IPアドレス指定のWHITE LISTが今のところ機能していません。
設定の問題かなぁ…。
まぁ、待たせてしまっても、まとまなところはところは待っているようなので実害はないのですが、ちょっと気になっています。

stealthinustealthinu 2006/08/14 11:19 情報ありがとうございます。
実はつい最近、同じ現象ではまっていました。
自分は、IPでのホワイトリストの場合、hashで対応したほうが負荷が軽いでしょうから、別に(regexpではなく)hash形式でのホワイトリストを作って、それで対応しました。
ただ、なぜこうなるのかが気になるというか、たぶんPostfixのバグの気がするので、ちょっとソース確認してみないと、と思っています。
もう少し詳しくわかったら、ブログで報告しますね。

stealthinustealthinu 2006/08/15 16:39 postfixでのregexp適用順がマニュアルの記述と違う
http://d.hatena.ne.jp/stealthinu/20060815/p1
ここに状況を書きました。Postfixかマニュアルか、どっちかのバグですね。
同じregexpテーブルで、ホスト名での比較とIPでの比較ではホスト名が先に評価されるというのは、いかにも直感的でないため、修正したほうが良いと感じます。
しかし… これは sleep のパッチよりめんどくさそうな感じ。

おぎのおぎの 2006/09/06 11:48 「具体的な設定」のところにあるリンクから設定のサンプルを
ダウンロードしましたが、main.cf.skel以外はシンボリックリンク
になっていてファイルを参照できませんでした。

stealthinustealthinu 2006/09/06 12:04 うわ、失礼しました。ご指摘ありがとうございます。
早速現在のものをダウンロードできるように修正します。

ohmohm 2006/10/15 11:35 1-2ヶ月ほど前からStarpitを仕込ませていただいて、効果絶大で大変感謝している者です。で、すりぬけがやや目立ってきたので、今回ここに書かれている「後段にpostgreyを仕込む」をやっているところなのですが、二つほど質問があります。

一つ目は、上に書かれているものほぼそのままの設定でまず試したところ、
warning: unknown smtpd restriction: ”check_greylist”
と言われてしまいました。
## for Rgrey
smtpd_restriction_classes =
greylist_client
greylist_client =
check_policy_service inet:60000
の ”greylist_client” という名前は、
check_client_access regexp:/etc/postfix/greylist_client
で参照されている greylist_client 中の各行の右辺と一致していなければならないのではないでしょうか? 上の例ではここがたとえば
/^unknown$/ check_greylist
となっていて、この check_greylist を知らないので上のようなエラーが出ているのだと思われます。
それで、main.cf の設定の方を
smtpd_restriction_classes =
check_greylist
check_greylist =
check_policy_service inet:60000
のようにしたところ、エラーが出なくなりました。

二つ目は、その状態でしばらく運用してみたのですが、tarpit_client でのチェックで、S25Rなクライアント側がタイムアウトして勝手に接続を切った場合も、クライアントが耐え切って抜けてきた場合にも、いずれの場合も greylist_client のチェックに突入してしまいます。後者は期待する動きですからいいのですが、前者の場合既にクライアントが接続を切っているにもかかわらず、postgrey が動いてしまい、db にエントリが作成されることになってしまいます。S25Rなのでpostgreyのホワイトリストに入れるというわけにもいかず、既に切れている接続に対して 450 のエラーが postgrey から返され、
notify_classes = bounce,2bounce,delay,policy,protocol,resource,software
などとしているために、いちいちメールが飛んできて大変うざったくなってしまいました(^^;)(しかもそのメールを見ても、当該クライアントが tarpit を抜けてきたのかどうかが判別できない、、、)
それはともかく、本来の目的である「tarpitを抜けてきたものだけpostgreyをかける」という動作をさせたいのですが、sleep中に接続を切られた場合はその時点でrestrictionの評価を終了するということは難しいでしょうか?

stealthinustealthinu 2006/10/16 22:59 すみません。昔の自分の設定が混じってしまっていて、それでおかしくなっています。
元記事のほうも修正しておきますが、
smtpd_restriction_classes = greylist_client
で指定した名前「greylist_client」を
/^unknown$/ greylist_client
のように呼び出せばよいので、ohmさんの修正でも全く問題ありません。
check_client_accessで指定する名前とは一致している必要はありません。
タイムアウトした場合はチェックしないようにしたい、とのことですが、これはそのままではうまくいかないですね…
sleepパッチ当てた場合でもダメでしょうか?

ohmohm 2006/10/17 11:52 早速のお返事ありがとうございます。
そう、リストの右辺を直してもいいとは思いましたが、直す行数が多いので楽なほうにしました(笑
あと main.cf の方はどうせ自分のところの都合で編集する必要があるけど greylist_client ファイルの方は stealthinu さんのところのをそのまま使わせていただく可能性が高いので、ローカルにあまり変更しないほうがベターかなと思ったということもあります。今回もしそちらも変更されたのでしたら追従しなければ、、、(笑

sleepパッチは当てております。この場合、途中で相手が接続を切ったら、ルールが NG(REJECT?) で抜けてくるようになっているはずなのでしょうか? 設定は超シンプルで、
smtpd_recipient_restrictions =
permit_mynetworks
check_client_access regexp:/.../warn_client
check_client_access regexp:/.../tarpit_client
check_client_access regexp:/.../greylist_client
reject_unauth_destination
(...は適切なパス、ってか $config_directory とかにすればいいんですね orz)なのですが、ログを見ていると、
Oct 17 11:42:19 server postfix/smtpd[8354]: connect from some-s25r-host.example.com[nnn.nnn.nnn.nnn]
Oct 17 11:42:20 server postfix/smtpd[8354]: NOQUEUE: warn: RCPT from some-s25r-host.example.com[nnn.nnn.nnn.nnn]: ; from=<faked-address@faked-example.com> to=<target-address@our-domain-example.com> proto=ESMTP helo=<hogehoge>
Oct 17 11:42:50 server postfix/smtpd[8354]: NOQUEUE: sleep: RCPT from some-s25r-host.example.com[nnn.nnn.nnn.nnn]: lost connection after 29 sec; from=<faked-address@faked-example.com> to=<target-address@our-domain-example.com> proto=ESMTP helo=<hogehoge>
Oct 17 11:42:50 server postfix/smtpd[8354]: NOQUEUE: reject: RCPT from some-s25r-host.example.com[nnn.nnn.nnn.nnn]: 450 4.7.1 <some-s25r-host.example.com[nnn.nnn.nnn.nnn]>: Client host rejected: Greylisted, see http://isg.ee.ethz.ch/tools/postgrey/help/our-domain-example.com.html; from=<faked-address@faked-example.com> to=<target-address@our-domain-example.com> proto=ESMTP helo=<hogehoge>
のようになってしまっています。(内容は適当に編集してます)
sleep パッチを当てる前の sleep 機能は少なくとも「単に寝る」だけだと思うので、寝た後は DUNNO で次に行くのだろうと想像しておりますが、sleepパッチによって、切れた場合は REJECT が返るように実装しておられるのでしょうか? (ってかソース読めって感じですね^^;)

ohmohm 2006/10/17 12:33 というわけでソースをざっくり読んでみました。status というローカル変数に検証状態を入れればよいように見えます。で、postgrey を併用していなかったときには、相手が接続を切った場合、上のようになんでもかんでも notify_classes だった場合も何もメールは飛んできていなかったのですが、それは sleep 以後のルールが reject_unauth_destination だけであり、それは spam の場合はパスするからということだったようです。
(connection は lost してしまっていますがそれに関しては何も通知してこないっぽい。)
したがって後段に postgrey を入れた場合にも同様に何も飛んでこないようにしたければ、接続が切れた場合には status = SMTPD_CHECK_OK; を無理矢理入れてしまう、というのがよさそうに思えます^^; 後段でチェックされるべきルールを一切適用しなくなるわけで、一般論としては無理があるのかもしれませんが、いずれにせよ接続は既に切れてしまっているわけなので、いくらチェックしても無駄でしょう、という理屈も成り立つように思います。(笑
とりあえずローカルで試してみます(笑

ohmohm 2006/10/17 12:44 うまくいったようです^^;
pipelining の方はよくわからなかったので放置して、lost connection の方だけ、break の直前に status = SMTPD_CHECK_OK を入れました。
公式パッチとしては無理がありそう(どちらかといえば restriction ルールとして記述できるべきかも)ですが、とりあえず個人的には幸せになった気がします:)

stealthinustealthinu 2006/10/17 13:06 あ、すでに解決されてますね。
sleepの機能自体、単に寝せてるだけで、sleepパッチはポーリングでときどき接続が切れてるか見て、切れてたらsleep終わらせてるだけです。
ただ、切れてる状況を検知してるから、後段の処理でチェック入ったらうまくいくかな?と思ってパッチ当ててらっしゃるかうかがったのですが、チェックしてないのですね。参考になりました。
確かに、接続切れてる場合には status = SMTPD_CHECK_OKを入れてしまっても良いと思います。もしくは切断、というstatusはないのかな…
pipeliningのほうは、こっちが返答返す前にどんどんコマンド送ってきた場合なので、それをOKにしちゃうと良くないですから、それで良いと思います。

あと、main.cfの修正についてはもうちょっと待っていただいたほうが良いと思います。
他のエントリーでtaRgreyというtarpittingで落ちたものをさらにgreylistingで救うためのポリシーサーバをテストしてまして、オプション指定によってtarpittingとgreylistingを2重に掛けるほうにも出来るようにしてます。
ちょっとまだぜんぜんテストが甘いので、まだ未公開ですが、近日中に公開する予定なので、その後に設定変更いただいたほうが良いかと。

statusの件も、もうちょっと調べてみて、取り入れられそうならば反映できれば、と思います。

stealthinustealthinu 2006/11/13 10:23 ohmさんの助言を参考に、
status = SMTPD_CHECK_REJECT
を入れるように修正しました。