日曜日, 5月 31, 2009

ホワイトリスト情報の報告がまた増えた

 2月28日に、ホワイトリスト情報の報告が減ったことを述べた。2009年に入ってから公開ホワイトリストに追加した項目は、1月に1件、2月にはなし、その後、3月に4件、4月に3件と少なかった。ところが、5月に入って34件とまた増えた。
 これは多分こういうことだろう。
 これまでは、ホワイトリスト情報は主に小規模サイトから寄せられていた。大規模サイトでは、自動救済をしていることが多いだろうし、偽陽性判定が頻発するので報告が大変だから、あまり報告されなかったのだろう。
 2008年終わりから2009年初めにかけて報告が少なくなったころ、公開ホワイトリストは小規模サイトにはほぼ十分なものになった。大規模サイトでは、それでもなお偽陽性判定は起こるが、頻度は少なくなり、報告が大変でなくなった。そのため、大規模サイトからホワイトリスト情報が寄せられるようになった。
 5月下旬に掲示板で多くのホワイトリスト情報をお寄せくださったhoutokuさんのサイトは、メールアカウント数が約600とのこと。taRgreyで自動救済されたホストのうち、素性が明らかで正当なメールサーバだと確認されたものを、無期限に許可するためにホワイトリスト登録していた。このホワイトリストはサイトローカルなものにしておくのでなく公開した方がよいと思い立って、私に登録を申請してくださるようになった。そして、私がどのような正規表現にするのがよいかを判断して公開ホワイトリストに掲載したら、それをダウンロードして自サイトのホワイトリストとして利用されている。
 つまり、公開ホワイトリストにブレークスルーが起こり、より大規模なサイトでも偽陽性判定を減らすことができるものへ成長し始めたということである。houtokuさんら常連ゲストの方々からの報告が減るころには、数百人規模のサイトでも偽陽性判定をめったに起こさないホワイトリストになるだろう。もしかしたら、さらにその後、数千人規模のサイトからホワイトリスト情報が寄せられるようになるかもしれない。

土曜日, 5月 30, 2009

SPAMCOPの併用の効果

 4月29日にSPAMCOPの併用を開始した。4月26日から5月30日22時までのログから拒絶ログソーティングスクリプトでカウントした推定メッセージ数は偽陽性判定を除いて1582、この期間に着信したスパムは8通。したがって阻止率は99.5%となった。
 S25Rをすり抜けてSPAMCOPでブロックされたスパムは5通あった。これらが着信していたとすると、阻止率は99.2%である。これもけっこう高い値だが、SPAMCOPの併用でさらに0.3%上がったことになる。SPAMCOPによる偽陽性判定は起こっていない。
 S25Rでブロックされたホストの中には、論文に示していない追加の一般規則とブラックリストで引っかかったものがあった。そのうち以下に○で示したものはSPAMCOPに登録されていた。

router.shtorm.com [195.62.14.1]
pursuant.age.volia.net [77.122.227.132]
smatteringness-warmth.volia.net [77.123.102.225]
devoted-parlayer.volia.net [93.74.8.151]

つまり、追加の一般規則とブラックリストがなかったとしても、4通のうち3通はSPAMCOPでブロックできたということである。
 SPAMCOPの併用はかなり役に立つ。一方、今までにスパムアクセスをしてきたホストをRBL.JPBlack list DB checkで調べたところでは、RBL.JPに登録されていたことは数えるほどしかなく、spamhausに登録されていたのを見たことは一度もない。

金曜日, 5月 15, 2009

スパム送信サーバが13時間リトライ

 次のようなリトライアクセスがあった。

May 13 17:44:51 unknown [81.91.67.81] from=<ohflpiciqvMeredith@***.com> to=<deo@gabacho-net.jp> helo=<81.91.67.81>
May 13 17:52:05 〃
May 13 18:12:46 〃
May 13 18:46:47 〃
May 13 19:34:07 〃
May 13 20:34:48 〃
May 13 21:48:49 〃
May 13 23:16:29 〃
May 14 00:56:51 〃
May 14 02:50:52 〃
May 14 04:58:12 〃
May 14 07:18:54 〃

 送信者アドレスのユーザーIDがでたらめっぽいのがいかにも怪しい。HELOアドレスがIPアドレスなのに「[ ]」で囲んでいないのがいかにも怪しい。私がウェブで公開しているアドレスは「webmaster」なので、私の知らない人から初めて来るメールは通常「webmaster」に宛てられるのに、「deo」宛なのも怪しい。
 スパムに違いないとにらんで放置プレイを食らわせてみたら、リトライアクセスは13時間34分で止まった。
 送信元にSMTPアクセスしてみたら、MTAが応答した。ボットでなくメールサーバだった。まともなメールサーバならば24時間やそこらであきらめたりはしないのが普通だが(Postfixやsendmailのデフォルト設定で5日間)、14時間未満でリトライが止まったのは、スパム送信用にチューンしたサーバだからだろう。
 人間の知識と経験に基づいて「怪しい」とにらむ判断は、今のところ、機械に任せるのがむずかしい。この職人芸で、長時間リトライするスパムアクセスを放置する。正当なメールサーバがリトライを1時間ほどでやめてしまうというレアケース(私が見つけているのは、メールマガジン携帯電話会社からのエラーリターンのケース)を除けば、怪しいとにらんだリトライアクセスが24時間未満で止まったらスパムだったと判断してほぼ間違いない。S25R方式を素のまま使っていると、こういうサディスティックなプレイができて面白い。

*.cust.bit-drive.ne.jpの丸ごと許可を取り消し

 前回、*.cust.bit-drive.ne.jpを丸ごと許可するようにしたことを報告したが、個別許可に戻した。掲示板のゲストのKenjiさんから、*.cust.bit-drive.ne.jpがスパム送信サーバに使われているとの報告をいただいたからである。
 以下は、Kenjiさんの記事の引用。Kenjiさんのサイトで複数のユーザーからスパムの申告があった送信元ホストだけでこれだけあるとのことである。

202.94.129.36 から yahoo.co.jp を騙ったspam
202.94.129.226 から yahoo.co.jp を騙ったspam
202.94.147.83 から 出会い系(オプトインかどうかは不明)
202.94.153.85 から yahoo.co.jp を騙ったspam
202.94.153.86 から yahoo.co.jp を騙ったspam
202.94.153.87 から yahoo.co.jp を騙ったspam
202.94.153.197 から yahoo.co.jp を騙ったspam
210.172.21.90 から yahoo.co.jp を騙ったspam
210.172.31.190 から yahoo.co.jp を騙ったspam
210.172.31.191 から yahoo.co.jp を騙ったspam
211.9.45.148 から yahoo.co.jp を騙ったspam
211.9.50.239 から 出会い系(オプトインかどうかは不明)
219.106.230.243 から 出会い系のspam
219.106.230.245 から 出会い系(オプトインかどうかは不明)
219.106.230.253 から 出会い系(オプトインかどうかは不明)
61.45.193.225 から yahoo.co.jp を騙ったspam

月曜日, 5月 11, 2009

*.cust.bit-drive.ne.jpを丸ごと許可

 今まで、210-172-21-218.cust.bit-drive.ne.jp (wserver.alliance.co.jp)をはじめ、cust.bit-drive.ne.jp配下のホストを、発見されるたびに一つ一つ公開ホワイトリストに登録していたが、掲示板のゲストのPyTaさんのご提案により、*.cust.bit-drive.ne.jpを丸ごと信用する許可条件に集約した。bit-driveは法人向けのインターネット接続サービスで、ボット化するエンドユーザーコンピュータはつながっていないだろうと思われ、実際、*.cust.bit-drive.ne.jpから不正メールアクセスが来たことはないからである。
 過去に掲載していた*.cust.bit-drive.ne.jpの許可条件は、しばらくコメントアウトで示しておくことにする。

# *** PUBLISHED S25R WHITE LIST ***
# Last update: May 11, 2009
# (*): reported by a contributor
#
# May 11, 2009: mail.ebookoff.co.jp (202-94-136-109.cust.bit-drive.ne.jp) (*)
/\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Mar 15, 2009: (revised)
# Feb 03, 2008: mag.jobengine.jp (*)
#/^219-106-251-106\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Apr 15, 2008: legacy.transcend.co.jp (*)
#/^219-118-179-4\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Mar 26, 2008: mail.dss-net.co.jp (*)
#/^218-42-147-99\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Mar 14, 2008: ns.ict-ics.com
#/^210-175-254-69\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Feb 03, 2008: mail.furuhonn.com (*)
#/^219-118-164-66\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Jan 14, 2008: ns.betterhome.co.jp (*)
#/^219-106-250-226\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Dec 14, 2007: nbn.co.jp's (*)
#/^210-251-250-78\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Dec 14, 2007: greeting-card.jp (*)
#/^210-251-251-204\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Nov 29: 2007: ig3.jp's (*)
#/^218-42-159-113\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Jun 19, 2007: mail.ifscorp.co.jp
#/^210-175-254-67\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Feb 08, 2007: tachikawa-roukikyo.or.jp (*)
#/^219-118-191-144\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Nov 24, 2004: wserver.alliance.co.jp (*)
#/^210-172-21-218\.cust\.bit-drive\.ne\.jp$/ OK

水曜日, 5月 06, 2009

君子は豹変するのだ

 2006年11月24日「DNSBLの利用価値はあるか?」で「DNSBLを使う積極的な理由は見出せない」と述べてから2年5ヶ月たってそろそろ舌の根が乾いた今、SPAMCOPの併用実験を開始した。S25Rをすり抜けるスパムをDNSBLでブロックできる率について、ある程度定量的なデータが得られたからである。
 「DNSBLの利用価値はあるか?」の記事では、「S25Rの偽陽性を減らすためにDNSBLを併用すると、阻止率はかなり下がってしまうのではないか」と述べた。これは正しかった。ウェブで見つけた証言によると、SPAMCOPによる阻止率は50~60%程度。DNSBLの応用であるトレンドマイクロのEmailレピュテーション70%程度。阻止率はその程度に下がってしまい、S25R方式の高い防御力が無駄になってしまう。
 一方、「阻止率を上げるためにS25RにDNSBLを併用しても、阻止率が大きく向上することはないだろう」と述べた。確かに大きく向上するとは言えないが、98.8%の阻止率はSPAMCOPの併用で99.2%程度に上がるという見積もりが得られた。「むしろ偽陽性が増えるおそれがある」とも述べたが、それはあまり心配しなくてよさそうである。蹴る時の応答コードを「450」に設定して再送要求すれば、偽陽性からの救済はS25R方式の運用と同じ手順でできる。4月29日にSPAMCOPの併用を設定してから5月6日までに、S25Rをすり抜けたホスト4個のうち、SPAMCOPで阻止されたホストは3個。その中にリトライしたものはなく、偽陽性判定はまだ起こっていない。SPAMCOPはそこそこ役に立っていると言える。
 私の場合、S25Rをすり抜けて着信するスパムは一日平均1通もなく、スパムを捨てる手間はまったく問題になっていない。だから、スパムの受信を減らすためにこれ以上がんばる必要はない。ただ、S25R方式で99%近いスパムを阻止できてもなおスパムの受信が多い人にノウハウが役立つかもしれないと思って、SPAMCOPの併用実験をやっている。
 正当なメールをエラーリターンさせる副作用ゆえに「DNSBLを使ってはいけない」という主張もあるが、物は使いようである。多少とも効果があり、副作用を克服できるなら、使えばよいと思う。副作用を克服するには、S25Rと同じくDNSBLによるブロックでも再送要求を返し、ログを監視して、リトライするメールサーバをホワイトリストで救済すればよい。それが、S25R方式と同じく、スキルの高くない人でも容易に実装・運用できる方法である。知識だけであれこれ言うのでなく、知恵を働かせればよい。
 抗がん剤にはがん細胞だけでなく正常細胞も殺す副作用があるが、だからといって抗がん剤を使ってはいけないなどとは言っていられない。知恵を働かせて副作用を克服できるならば、治療に有効な抗がん剤は使うべきである。それと同じことである。

日曜日, 5月 03, 2009

SPAMCOPが効いた

 4月29日にSPAMCOPを設定してみた。その後、5月3日までに、S25Rをすり抜けるスパムアクセスが3通あった。www.era.gov.etからの1通(4月30日)は着信したが、adsl.eb1-pacovchamarao.edu.ptから(4月30日)、syscom4.att.net.coから(5月1日)の2通がSPAMCOPでブロックされた。いずれも、応答コード「450」に対してリトライしなかった。
 ほかに、81-208-74-142.ip.fastwebnet.itからのアクセス(5月3日)がS25Rに引っかかって8時間以上リトライしていて、多分スパムだろうと思って受信してみたら、やっぱりスパムだった。これはSPAMCOPに引っかからなかった。
 4通のうち2通をSPAMCOPでブロックでき、リトライがなかったので、今のところ、SPAMCOPを設定してよかったと言える状況である。