水曜日, 4月 29, 2009

SPAMCOPを設定してみた

 前回、S25Rをすり抜けてスパムを着信させたホスト20個のうち7個(35%)がSPAMCOPのDNSBLに登録されていたことを述べた。このことから、すり抜けスパムを減らすためにSPAMCOPがどのくらい役立つかを調べてみたいと思った。
 3月29日から4月29日18時までのログから拒絶ログソーティングスクリプトでカウントした推定メッセージ数は1274、この期間に着信したスパムは16通なので、ここから計算した阻止率は98.8%である。1.2%のすり抜けが、SPAMCOPによってその65%、すなわち1.2%×0.65≒0.8%に減れば、阻止率は99.2%に上がり、16通のすり抜けは10通程度に減る計算になる。
 話はそううまくはいかないかもしれない。DNSBLによる偽陽性判定でメールをエラーリターンさせるわけにはいかないから、拒否応答コードを「450」に設定して再送要求する必要がある。S25Rをすり抜けてDNSBLに引っかかる送信元ホストはメールサーバである確率が比較的高いので、「450」に対してリトライしてくる可能性が高い。リトライしなかったアクセスはスパムだったと断定してよいが、メールサーバの挙動でリトライしてきたら、スパムかどうかは受けてみないと確認できない。もしS25Rをすり抜けてDNSBLに引っかかるホストの多くがリトライしてくるとしたら、受信して確認するためにホワイトリスト登録する手間が増える。一方、DNSBLが引っかけてくれるホストの多くがリトライしないボットであれば、阻止率をあと少し上げるのにDNSBLが役立つと考えられる。
 ともかく、やってみることにした。

 main.cfファイルに以下の太字の行を追加する。

maps_rbl_reject_code = 450

smtpd_client_restrictions =
  permit_mynetworks,
  check_client_access hash:/etc/mail/dracd,
  check_helo_access regexp:/etc/postfix/helo_restrictions,
  reject_unauth_destination,
  reject_unlisted_recipient,
  check_client_access regexp:/etc/postfix/white-list.txt,
  check_client_access regexp:/etc/postfix/white_list,
  check_client_access regexp:/etc/postfix/rejections,
  reject_rbl_client bl.spamcop.net
(smtpd_client_restrictionsパラメータは私の実際の設定を示しているが、必須でない指定も含まれている。誰もがこのように設定すべきだという意味ではない。)

 上記のように設定する前に、まずreject_rbl_client指定をS25Rチェックの前に置いて優先させることによって、DNSBLに引っかかった時のログがどうなるかを調べた。次のような記録がとれた。

Apr 29 11:27:56 reject: RCPT from 66.239.107.130.ptr.us.xo.net[66.239.107.130]: 450 4.7.1 Service unavailable; Client host [66.239.107.130] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?66.239.107.130; from=<***@elbloque.com> to=<deo@gabacho-net.jp> proto=ESMTP helo=<66.239.107.130.ptr.us.xo.net>

このような記録が拒絶ログソーティングスクリプトで拾われるように、スクリプトを次のように手直しした。

# (2) Extract records indicating "450 Client host rejected".
#
egrep 'reject:.+ 450 .*Client host rejected:' | \

# (2) Extract records indicating "450 Client host rejected".
#
egrep 'reject:.+ 450 .*Client host (rejected:|.*blocked)' | \

 これでしばらく様子を見ることにする。

すり抜けスパムがDNSBLにどれだけ引っかかるか

 3月から4月にかけてスパムを着信させたホストがDNSBLに引っかかるかどうかを、RBL.JPBlack list DB checkで調べてみた。このCGIによって、ホストがSPAMCOP、spamhaus、RBL.JPに登録されているかどうかを調べることができる(2008年3月20日「DNSBLって効くの?」を書いた時にはもっと多くのDNSBLについて調べることができたが)。
 送信元ホストと、それを登録しているDNSBLを表で示す。

a190.watel.vt.cust.gts.sk [85.248.46.190]SPAMCOP
blu0-omc4-s29.blu0.hotmail.com [65.55.111.168]なし
gate49.cableone.ne.jp [61.7.42.49]なし
smtp.pyramide.co.ma [196.206.253.90]SPAMCOP
adsl.eb23-sjoaoponte.edu.pt [194.210.65.9]SPAMCOP
brevnov.drino.net [213.151.83.161]なし
adsl.ep-adrcisteralcobaca.edu.pt [194.210.105.124]なし
mail.gpk.lt [82.135.204.112]なし
cr-0.accnet.wireless.royell.org [208.91.182.67]なし
techfirewall.lighthouse.net [69.216.168.41]なし
unknown [211.12.212.178]なし
mail.thaibinh.gov.vn [222.252.216.155]SPAMCOP
o7.jdisonline.com [204.54.152.26]なし
mail.sistema102.net [200.50.20.150]なし
gprsinternet04.porta.net [200.25.197.97]なし
mail-fx0-f179.google.com [209.85.220.179]なし
pop.landrumshouse.com [209.194.32.242]なし
ttx01.ttx-net.sk [193.110.187.2]SPAMCOP
a2.sabnet.bj.cust.gts.sk [62.168.87.6]SPAMCOP
cerstef.b.astral.ro [83.103.177.74]SPAMCOP

 blu0-omc4-s29.blu0.hotmail.comとmail-fx0-f179.google.comはS25Rに引っかかるが、ここから着信したのは、hotmail.comとgoogle.comをホワイトリスト登録しているからである。正当なメールサーバを経由して送信されたスパムは、S25R方式ではいかんともしがたい。
 unknownのホストは、リトライの挙動からメールサーバと思われたものである。ホワイトリスト登録してみたら、着信したのはフィッシング詐欺のスパムだった。

 20個のホストのうち、SPAMCOPに登録されていたのが7個あった。ここから計算した阻止率は35%である。spamhausとRBL.JPには一つも登録されていなかった。このことから、S25Rをすり抜けるスパムをブロックするのにいくらかでも効果がありそうなDNSBLはSPAMCOPだけだと考えられる。
 また、2008年3月20日「DNSBLって効くの?」で述べたとおり、SPAMCOPだけが、S25Rで阻止されたスパム送信元ホスト10個のうち8個を登録していて、ほかのDNSBLは一つも登録していなかった。このことからも、役立ちそうなDNSBLはSPAMCOPだけだと思われる。ただし、その記事で述べたとおり、ウェブで見つけた証言によれば、そのSPAMCOPでも阻止率は50~60%程度しかないらしい。
 一方、SPAMCOPによる偽陽性判定のリスクも見て取れる。SPAMCOPに登録されていたsmtp.pyramide.co.maとmail.thaibinh.gov.vnは、名前からして明らかにボットではなくメールサーバである。第2レベルのラベルから見て、pyramide.co.maはモロッコの企業、thaibinh.gov.vnはベトナムの政府機関と推測される。これらのホストからスパムが送信されたのは確かでも、一時的にスパマーに悪用されただけかもしれない。同じホストから正当なメールも送信されるかもしれないのに、SPAMCOPは、ボットかメールサーバかを区別せずにブラックリストに登録している。ほかのDNSBLでも同じようなものだろう。DNSBLを信用して応答コード「5xx」で蹴るのがいかに危険かがわかる。
 とはいえ、蹴る時の応答コードを「4xx」にすれば、DNSBLを使っても、正当なメールをエラーリターンさせる事故を避けることができる。応答コードを変更するには、Postfixのmain.cfファイルで

maps_rbl_reject_code = 450

のように指定すればよい。この方法をとれば、SPAMCOPを利用してすり抜けスパムを減らすことができるかもしれない。
 次の記事で、SPAMCOPを利用する設定方法を説明する。

息子宛のスパムアクセスが再発した

 3月21日に、息子宛のスパムアクセスが1ヶ月以上途絶えたことを述べた。しかし、またかなりのスパムアクセスが来るようになった。4月12日から27日までの間に、アクセス回数26回。推定メッセージ数にして11通だった。やはり、一度メールアドレスがスパマーに漏洩すると、スパムアクセスが根絶することはないようである。
 スパムアクセスの中には、次のように3回トライするリトライアクセスがかなりあった。

Apr 24 20:57:16 unknown [189.79.211.229]
Apr 24 21:14:25 unknown [189.79.211.229]
Apr 24 21:41:33 unknown [189.79.211.229]

17分後に2回目、44分後に3回目のアクセスが来ている。このパターンは6シーケンスあった。グレイリスティングを併用していると突き抜けられてしまうパターンである。しかし、気付いた時には3回でアクセスが止まっていて、だまされてホワイトリスト登録することはなかったので、1通も着信しなかった。
 これらのリトライアクセスの送信者アドレスのユーザーIDは、「KichikawaMizuki」、「Fujino_Mitsuki」など日本人の名前だったことから、日本語のスパムだったと推測される。以前は、息子宛に着信したスパムは英語のものばかりだった。外国人スパマーがオンラインショッピングのサーバを侵害して盗んだメールアドレスが日本人スパマーにまで流れたようである。

土曜日, 4月 18, 2009

半月後のE-mailレピュテーション

 前回、トレンドマイクロのE-mailレピュテーションによる推定阻止率を59%と述べたが、その後半月のデータをとったら、もう少し良い値になった。
 4月1日から16日までに受けたスパムは191通(30日あたりに換算して358通)。スパムの受信数は2月には969通、3月には1061通と増えつつあったことから、月あたりのスパム数は4月前半にはその増分の半分だけ増えた、すなわち1061+(1061-969)÷2=1107通と大雑把に仮定すると、推定阻止率は68%。トレンドマイクロの「70%くらい」という言葉は嘘ではないと言える。
 とはいえ、S25R方式による阻止率は97%以上だから、Emailレピュテーションによる見逃し率はS25R方式の10倍以上ということである。メールサーバの無駄な負荷を減らすには役立つだろうが、ユーザーをスパムの被害から救うというレベルではない。ユーザーは、メーラーのベイジアンフィルタや、Becky!によるS25Rフィルタリングなどの対策を手放すことができない。
 ちなみに、4月1日から16日までに受けたスパム191通のうち、Becky!によるS25Rフィルタリングをすり抜けたものは9通だった。すなわち、判別率は95.3%で、メールサーバでのスパム対策が行われる前には97%以上だったのに比べて低い。これは、S25Rに引っかかるホストの方が、引っかからないホストよりも高い割合でEmailレピュテーションで阻止されるということを意味する。まともなメールサーバを経由したスパムはEmailレピュテーションでも阻止されないから、これは当然の結果と考えられる。概算すると、Emailレピュテーションによる阻止率は、S25Rに引っかかるホストに対して約7割、S25Rに引っかからないホストに対して約5割ということになる。

金曜日, 4月 03, 2009

E-mailレピュテーション

 3月30日から勤務先でスパム対策が始まった。S25R方式ではない。トレンドマイクロのE-mailレピュテーションを利用したものである。社内IT部門としては、社員をスパム問題から救うというよりも、スパム問題のために何もしていないと言われないための手っ取り早い方法をとりたかったらしい。
 その後に私が受けたスパムは、3月31日には14通、4月1日には15通、4月2日には16通だった。2月には969通、3月には1061通だったことから、この3日間に月あたり1100通の割合でスパムが押し寄せていたと仮定すると、阻止率は59%ということになる。2008年3月20日「DNSBLって効くの?」で、SPAMCOPを利用した場合の阻止率は50~60%と推測されると述べた。それと同じくらいである。トレンドマイクロは70%くらいと言っていると聞いたが、それより低い。
 DNSBLのたぐいのIPアドレスブラックリスト方式の効果はしょせんそんなものだろう。データベースの維持にコストがかかっているだろうに。

水曜日, 4月 01, 2009

April fool

 韓国のヌリビジョンは、バウンシングバック認証方式で100%のスパム阻止を誇る同社のスパム対策アプライアンス「OptPlus」を機能改良したと発表した。これは、同社の日本進出後、日本のスパム対策研究者から指摘された懸念に応えたもの。
 改良点の第一は、バウンシングバック認証要求メールを返送するかどうかをユーザーが選択できるようにしたこと。OptPlusは、入ってくるメールを辞書攻撃チェック、ウィルスパターンチェック、スパムパターンチェックの3段階のフィルタにかけ、それを通過したメールのうち、バウンシングバック認証済みでないものをペンディングキューに入れる。従来は、ペンディングキューに入ったメールすべてに対してバウンシングバック認証要求メールを返送していた。正当な送信者は認証手続きをするので正当なメールは受信できるが、スパマーは認証手続きをしないのでスパムは受信せずに済むというのが「100%のスパム阻止」の仕組み。しかし、スパマーにアドレスをかたられた被害者に身に覚えのないバウンシングバック認証要求メールが届くのは迷惑になると指摘されていた。また、その被害者がバウンシングバック認証要求メールを受けて、事情がわからないまま認証手続きをすると、スパムが受信されてしまうという問題もあった。
 そこで同社は、ユーザーがペンディングキューを見て、スパムに対してはバウンシングバック認証要求メールを返送しないようにできる機能を設けた。これにより、スパマーにアドレスをかたられた被害者への迷惑が避けられる。また、その被害者が間違って認証手続きをすることによるスパムの受信も回避できる。さらに、OptPlusの導入サイト同士でバウンシングバック認証要求メールの投げ合いになって両ユーザーが互いに相手からのメールに気付かないという「やぎさんゆうびん問題」も、ユーザーがバウンシングバック認証要求メールに対してバウンシングバック認証要求メールを返送しないようにすることで解消されるという。
 改良点の第二は、ホワイトリスト登録された送信者アドレスを持つメールであっても、ペンディングキューにいったん保留し、本当にスパムでないかどうかをユーザーが判断した上で受信できるようにしたこと。これにより、ユーザーの知人などのホワイトリスト登録されたアドレスをかたったスパムが受信されてしまうという弱点が解消され、将来にわたって100%のスパム阻止を維持できるようになるという。
 同社は、日本人から寄せられた声をOptPlusに活かしたことにより、同製品の日本国内での更なる普及を目指したいとしている。