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.JPのBlack 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」など日本人の名前だったことから、日本語のスパムだったと推測される。以前は、息子宛に着信したスパムは英語のものばかりだった。外国人スパマーがオンラインショッピングのサーバを侵害して盗んだメールアドレスが日本人スパマーにまで流れたようである。

半月後の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割ということになる。

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アドレスブラックリスト方式の効果はしょせんそんなものだろう。データベースの維持にコストがかかっているだろうに。

April fool

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

OptPlus売れていないんじゃないの？

　「バウンシングバック認証」でググると、私のブログ記事が1位と2位を独占している。2007年5月29日「「バウンシングバック認証」で検索上位」を書いて以来、順位は落ちていない。「OptPlus」でも1位と2位に私のブログ記事がヒットする。「Opt Plus」では7位と8位だが、「Opt Plus ASP」だと、なんとOpt Plus ASPの本家サイトを抜いて私のブログ記事が1位である。
　OptPlusやバウンシングバック認証方式について調査しようとすると、痛烈な批判記事がいやでも目に付いてしまう。こんな状況の中で、OptPlusはどのくらい売れているのだろうか。
　いろいろ検索してみても、ユーザーの声はマスコミサイトのヨイショ記事にしか見当たらない（そのユーザーは、OptPlusのベンダーのビジネスパートナーである）。S25R方式については、「効果抜群でびっくりした」、「これほど効果があるとは予想していなかった」などの声がたくさん見つかるが、OptPlusについては見つからない。バウンシングバック認証要求メールを実際に受けたという話題も見つからない。
　2007年5月にたくさんのマスコミサイトがヨイショ記事を発表してから2年近くになるが、Opt Plus ASPやベンダーのSYSMATE社のコンテンツは代わり映えしない。私の指摘でユーザーが抱くであろう疑問（たとえば「やぎさんゆうびん問題は起こらないのか」など）に答えるコンテンツが追加されてもいないし、獲得ユーザー数やユーザーからの賞賛の声を誇示するコンテンツもない。売る気ないんじゃないだろうか。
　OptPlusが売れていないと思われるのは、おそらく、私のバウンシングバック認証方式反対キャンペーンによるものではない。もちろん、私のブログ記事を読んで、たくさんのマスコミサイトのヨイショ記事を鵜呑みにせずに済んだ人はいるかもしれない。しかし、私がキャンペーンを張らなくても、おそらくOptPlusは売れなかった。
　OptPlusを導入したASPやベンダーの失敗の原因は、日本人のニーズを正しく理解していなかったことである。たいていの日本人は、スパムを受けなくて済むことよりも、正当なメールを確実に受信できることの方を重視するのである。送信者が認証手続きをしなかったら正当なメールも受信されないというバウンシングバック認証方式には、おそらく多くの日本人は見向きもしなかったのである。メーラーに付いているベイジアンフィルタで80～90%のスパムをごみ箱に振り分けることができればそれでおおむね満足で、“スパムの阻止率100%”のために金を払おうと思う人などほとんどいないのである。
　失敗の原因のもう一つは、S25R方式を知らなかったことである。S25R方式を発表したのは2004年。「スパム 対策」のGoogle検索で1位か2位にヒットする状況が2005年以来ずっと続いている。なのに、2007年になってOptPlusを「現在のスパム対策ソリューションの中で最も投資対効果が高い」などと言っている。ちょっと調べれば、スパムの阻止率97～99%、高スキルの技術者でなくても実装できる、しかも無料というS25R方式には勝てないということはすぐにわかったはずである。
　日本人の心と日本人の発明に目を向けなかった事業者の失敗である。

（4月6日追記）
　「OptPlus」と「Opt Plus ASP」での検索順位が少し下がった。しかし、トップ10には入っているので、アピール度は十分である。

（OptPlusとバウンシングバック認証方式に関するすべての記事へのリンクはこちらの記事にあります。）

OptPlusの認証画面の脅し文句

　「OptPlus」でググると、7位に面白いページがヒットする。

OptPlus メール 注 意: このシステムはそちらの接続環境(66.249.67.207)で認証したことを自動的に記録いたします。認証後、迷惑メールと判断されるメールを送られてきた場合、法的な処置をとる場合がございますので、翌ﾟご了承下さい。 ... mail.yungjin.co.kr:8886/mmpmgr/user/auth_view.php?msgid=498146C84719&lang=jp - 6k -

（ごみ文字が入っている）

　このサイトは韓国の製薬会社。OptPlusの認証画面である。
　66.249.67.207は、逆引きするとわかるが、GoogleのロボットのIPアドレスである。Googleはどうやってこのページを見つけたのだろうか。この会社にメールを送ってバウンシングバック認証要求メールを受けた人しか知り得ないURLのはずである。誰かが公表したのかと思ったが、検索しても見つからなかった。
　アクセスしてみると、警告文のIPアドレスの部分は自分のIPアドレスになることがわかる。サーバ側でアクセス元のIPアドレスを検出して表示して見せることができるのは当然のことだが、インターネットの仕組みに詳しくないユーザーは不気味に感じることがある。何かを問い合わせようと思ってメールを送った人は、自分のIPアドレスの表示と「法的な処置をとる」という脅し文句に恐れおののいて、認証手続きをせずにあきらめてしまうかもしれない。
　お客様への気配りの心をわきまえた日本人は、こんなことをしてはいけない。

XMailCFG (for Windows)をリンク

　S25Rの目次ページに、XMailCFG (for Windows)へのリンクを掲載した。ホワイトリスト情報をお寄せくださった方から教えていただいたものである。
　XMailは、UNIXとWindowsで動作する、オープンソースのFINGER/SMTP/POPサーバ。XMailCFGは、XMailの設定やメンテナンスを行うソフトウェアであり、XMailにS25Rを組み込むことができる。
　XMailとXMailCFGのおかげで、S25Rを組み込んだメールサーバをWindows上でも実現できるようになった。しかも、両ソフトウェアともフリーである。「S25RをWindowsサーバで実現できませんか」という質問を受けたら、これを紹介してあげることにしよう。

掲示板のスパム対策

　協力者からのホワイトリスト情報は、メールよりも掲示板で寄せられることの方が圧倒的に多い。掲示板は、メールとは違って、個人情報を明かさずに投稿できることと、自分の貢献が公になることから、協力者にも好まれるようである。掲示板がなければこれほど多くのホワイトリスト情報は集まらなかったかもしれない。
　掲示板のスパム投稿も問題になっている。スパム投稿のために掲示板を維持できなくなり、閉鎖した人もいる。
　私の掲示板は、他の多くの掲示板に比べてスパム投稿を受けにくかった。トップ画面に投稿フォームがなく、投稿画面へ移るのにワンクリック必要であることが幸いしたようである。また、トップ画面は記事タイトルのスレッド表示で、記事の内容の表示にもワンクリック必要であることから、スパム投稿の宣伝効果に欠けると敬遠されたことも幸いしたかもしれない。
　それでも、私の掲示板にもスパム投稿が来るようになった。そこで、スクリプトに手を加えて、投稿画面のURLを変更してみた。これにより、投稿画面をダイレクトに狙うアクセスをエラーに落とすことができる。しかし、これも破られていたちごっこになった。
　そこで、掲示板スクリプトのファイル名を変えるという方法をとった。「raib.cgi」というファイル名は「raib_3036.cgi」として、また攻撃が来たら数字の部分を変更してかわすことにする。そして、元の名前の「raib.cgi」は、掲示板へジャンプさせるHTMLを吐くシェルスクリプトにする。これが吐くHTMLは、METAタグで掲示板へジャンプさせるようになっている。Aタグは書かず、また、METAタグ中のURLは相対パスにしてフルパスをわかりにくくする。これにより、ブラウザでアクセスする人は手間なく掲示板に到達できるが、スパマーが使う自動プログラムでは掲示板に到達しにくくなる。この方法をとってからは、スパム投稿は根絶した。
　私は無精なので、スパム投稿対策機能を持つ新しい掲示板スクリプトを導入するのでなく、使い慣れたスクリプトを使い続けたかった。これでスパム投稿を排除できたのは幸いだった。投稿してくださるゲストにとっても、CAPTCHA認証の手間を強いられないのは楽だろう。
　掲示板の内容が検索エンジンに拾われなくなるが、そのくらいはやむを得ない。むしろ、ロボットによってPerlスクリプトが連続で動かされてサーバのCPU負荷が上がるよりはよいだろう。
　対策をとったのは2007年だが、今なお、投稿画面の古いURLへのアクセスが日に数回来ている。アホなボットである。

　この方法は私のネットフレンドにも勧めたのだが、その人の掲示板は、この方法をとっても何度か破られている。トップ画面に投稿フォームがあるので、スパマーに狙われやすいのだろう。それでも、古い掲示板スクリプトを使い続けたいならば、これ以上に運用が楽な防御方法はないと思う。

　参考までに、掲示板へジャンプさせるHTMLを吐くシェルスクリプトのコードは次のとおり。「euc-jp」の部分は、メッセージの文字コードに合わせる。シフトJISの場合は「shift_jis」にする。

#!/bin/sh echo 'Content-type: text/html' echo echo '<HTML LANG="ja">' echo '<HEAD>' echo '<META HTTP-EQUIV="Content-type" CONTENT="text/html; charset=euc-jp">' echo '<META HTTP-EQUIV="refresh" CONTENT="0; URL=./raib_3036.cgi">' echo '</HEAD>' echo '<BODY>' echo '<CENTER>掲示板への攻撃を防御するため、別URLへ移動します。</CENTER>' echo '</BODY>' echo '</HTML>'

息子宛のスパムアクセスが途絶えた

　2008年7月20日「信じられない阻止率」で、私の息子へのスパムの着信数について述べた。オンラインショッピング会社のサーバが侵害されて息子のメールアドレスがスパマーに漏洩したものと思われ、2007年9月から届き始めた。今年3月までの着信数の推移は次のとおりである。

2007年9月：	3通
10月：	2通
11月：	2通
12月：	3通
2008年1月：	6通
2月：	5通
3月：	11通
4月：	3通
5月：	2通
6月：	0通
7月：	0通
8月：	1通
9月：	0通
10月：	0通
11月：	0通
12月：	1通
2009年1月：	0通
2月：	0通
3月：	0通

　2008年12月22日を最後に着信していない。2月14日「「4xx」は迷惑か？」の中で、
「今では、息子宛のスパムアクセスは月10回ほどと少なくなっている。」
と述べた。この日時点で、過去1ヶ月のスパムアクセスがそのくらいだった。
　今日（3月21日）、ログを見たら、息子宛のスパムアクセスが2月15日以降一度もないことがわかった。ピーク時には月に着信11通、ということは月に数百回あったスパムアクセスが、1ヶ月以上にわたって途絶えている。
　わざとスパマーに拾わせたおとりのアドレス、ウェブページから拾われた間違いアドレス、それらを改変したでたらめのアドレス（2006年9月15日「宛先の正しいスパムの阻止率」参照）へのスパムアクセスは、どんなに「550」を返し続けても、何年たっても減っていない。だから、息子宛のスパムアクセスも、減ることはあっても途絶えることはないと思っていた。途絶えたのは意外だった。
　推測するに、オンラインショッピング会社のサーバを侵害するという難しい方法で盗まれたメールアドレスは、少数のスパマーにしか利用されず、その少数のスパマーのほぼ全員が、息子宛のスパムの送達率の悪さに送信をあきらめたのかもしれない。だとすれば、S25R方式の勝利である。

（3月23日追記）
　3月22日に息子宛のスパムアクセスが1回あった（逆引き失敗で蹴っていた）。根絶はしていないようである。

常軌を逸したダウンロードの犯人がわかった

　3月14日の記事の続編。
　公開ホワイトリストファイルへの5分間隔のアクセスを見つけた時、アクセス元ホストにSMTPアクセスをしてみたら、HELOコマンドへの応答で名乗ったFQDNは「.ne.jp」を冠していた。そのFQDNは順引きできず、また、HELOアドレスは信用できないという思い込みがあって、そのサイトドメインを疑おうとは思いもしなかった。逆引きドメイン名の登録者に通報したが、今なお返事がない。
　再度HELOアドレスを確認し、そのサイトドメイン名のMXレコードを検索してみた。すると、セカンダリMXのIPアドレスがそのホストのものと一致していた。
　逆引き名から、犯人は小規模サイトか個人サイトと推測していたが、そうではなかった。非営利の某ネットワークサービス提供団体だった。常軌を逸したダウンロードをしていたセカンダリMXは、他社の回線を借りて接続していたもので、だから逆引き名からはその団体のサーバだとはわからなかったのである。
　ログを再度調べたら、そのサイトのプライマリMXも公開ホワイトリストファイルをダウンロードしていることがわかった。こちらは一日1回である。セカンダリMXに常軌を逸したダウンロードをさせていたのは何だったのか。cronの設定ミスだったとしたらお粗末。
　手動のSMTPでpostmaster宛のメッセージを打ち込んだが頻繁なアクセスがやまないので、ルータでHTTPをブロックしていた。今日、ブロックを解除してみたら、アクセスはやんでいた。メッセージに気付いたのか、cronジョブがフェールしているのに気付いたのか。HTTPをブロックしてダウンロードを拒絶したのが制裁措置と映っただろうか。設定を直したと連絡をくれればすぐにブロックを解除したものを。
　非営利とはいえ、業務でネットワークサービスを提供しているからにはプロ。小規模サイトや個人サイトのノンプロとは違う。プロならなおのこと、自分の事業のために一個人の無償ボランティアを利用するからには常識として何を守るべきかをわきまえてほしいものである。

公開ホワイトリストファイルから冗長なスペースを削除

　これまで、公開ホワイトリストファイルでは、見栄えのために「OK」のカラム位置をそろえていたが、冗長なスペースを削除して、正規表現との間のスペースを1個だけにした。
　理由の一つは、公開ホワイトリストファイルから「OK」を削除する加工をして使う人がおられることである。加工のしやすさのためには、冗長なスペースはない方がよく、それは見栄えよりも大きな利点だと考えた。
　もう一つの理由は、ファイルサイズの削減である。これで約7KB（約20%）減った。わずかながらダウンロード時間の短縮になる。
　ただし、論文中のホワイトリストサンプルでは、見栄えのために「OK」のカラム位置をそろえたままにしている。

ちゃんとログ見てるんでしょうね

　3月14日「S25Rの採用サイトの推定数」で述べたとおり、公開ホワイトリストファイルを毎日ダウンロードしているサイトは50ほどある（気を遣ってくれる人は、ファイルのタイムスタンプを見て、更新されている時だけダウンロードするようにしてくれているが）。「定期的に取得していいですか」と事前に打診してくれた人は一人しかいない。
　まあいいです。節度をもって利用してくだされば。1回きりのアクセスは単に見ただけかもしれないが、毎日定時にアクセスがあると、どこのサイトがS25R方式を採用してくださっているかがわかって面白い。誰でも知っている某国際空港とか、超有名な某大手出版会社とか。もちろん、私から無断で公言することはしないけれども。

　それはそうと、気になったことがある。cronジョブで公開ホワイトリストを毎日ダウンロードすればホワイトリストのメンテナンスを自動化したことになるとは、まさか思っていないでしょうね。
　公開ホワイトリストを組み込めば、偽陽性判定の確率を下げることはできる。しかし、ゼロにはできない。公開ホワイトリストには、S25Rに引っかかる正当なメールサーバのうち、私と協力者がたまたま見つけたもの（S25Rに引っかかるサイトからの申告を含む）しか収録されていないのである。素のS25R方式を使っている以上、必ずログを監視して、偽陽性判定からの救済を手動で行わなければならない。偽陽性判定はめったに起こらないかもしれないが、ログの監視をサボってはならない。
　ホワイトリストのメンテナンスを自動化したいと思ったら、その方法は、公開ホワイトリストの自動取得ではない。グレイリスティングかタールピッティングの併用、あるいは自動ホワイトリスティングプログラムの組み込みである。くれぐれも勘違いしないでいただきたい。

公開ホワイトリストの棚卸し

　公開ホワイトリストを棚卸しした。逆引きができるようになっていたので許可条件をコメントアウトしたのが32件、逆引きができるようになっていたが逆引き名が一般規則に引っかかるので許可条件をFQDNに変えたのが4件である。
　なお、逆引きができるようになっていたとは、もちろん、パラノイド検査（逆引き名の順引き検証）もOKだったという意味である。ご自分で棚卸しをする際にはご注意ください。

s25rtarpitgreylistをリンク

　S25Rの目次ページに、きまぐれPCひろばのs25rtarpitgreylistへのリンクを掲載した。S25Rで送信元ホストの選別を行い、タールピッティングとグレイリスティングでスパムの排除を行う、qmail対応のPerlスクリプトである。qmailユーザーには有用なソフトウェアと思われる。

S25Rの採用サイトの推定数

　前回、常軌を逸した頻度で公開ホワイトリストファイルをダウンロードしている人は「自分と同じことを100人がやったらどうなるか」を考えてほしいと述べた。100人というのは大げさな数ではない。公開ホワイトリストファイルを自動でダウンロードしているサイトは、現在50くらいある。2007年10月8日「ホワイトリストファイルを自動取得されているサイト」を書いた時には8サイトだった。この調子では、本当に100サイトにはなるかもしれない。
　公開ホワイトリストファイルを自動取得しているのは、素のS25R方式の採用サイトだろう。Rgreyなどでホワイトリスティングを自動化していれば、自動取得は必要ないはずだからである（その場合も、公開ホワイトリストを組み込んでおくことには意味があるけれども）。
　そして、素のS25R方式の採用サイトのうち大半は、公開ホワイトリストファイルの自動取得まではしていないだろう。最初に公開ホワイトリストを組み込んであとは自分で項目を追加していくのでも十分だからである。公開ホワイトリストを定期的に組み込むにしても、時たま手動で行う人もいるだろう。Postfixのオペレーションがどうにかできるくらいのスキルレベルの人（決して少なくないと思われる）は、cronジョブを作ろうとまでは思わないだろう。自動取得しようと考える人は、根拠レスな推測だが、1割よりも少ない、20～40人に一人といったところではないかと思う。
　この乱暴な仮定に基づけば、S25R方式の採用サイトは1000～2000くらいと推定される。ホワイトリスティングの自動化を併用しているサイトや、Postfix以外のqmailやsendmailでS25R方式を実装しているサイトを合わせれば、1500～3000といったところかもしれない。
　国内に関する限り、一つのシステムでこれほど多くのユーザーがいるサーバ向けのスパム対策方式は、ほかに例がないのではないだろうか。

ホワイトリストファイルの常軌を逸したダウンロード

　公開ホワイトリストの更新は一ヶ月に1度あるかないか、多くても数回という程度である。ウィルス対策ソフトのパターンファイルじゃあるまいし、私が公開するホワイトリストファイルを寸暇を置かずに反映しなくても、セキュリティ上の問題が起こるわけでもない。私が使っているウイルスバスターでさえ、パターンファイルの更新チェックの周期はデフォルトで3時間、最短設定で1時間である。なのに、何を考えて5分間隔でダウンロードしているのか。
　そういう常軌を逸したダウンロードをしているのは1サイトだけなので、リソース負荷は問題になっていない。しかし、「自分一人くらいやっても問題ないだろう」と思うのでなく、「自分と同じことを100人がやったらどうなるか」を考えてほしい。S25R方式を採用するサイトは非常に増えているのだから。100サイトが同じことをやったら、私のサーバは34KBのファイルを3秒に一度の割合で送り出さなければならなくなるのである。
　逆引き名からは、IPアドレスの割り当て1個の小規模サイトか個人サイトと推測された。アクセス元ホストはSMTPアクセスに応答したが、「postmaster@逆引き名」にメールを送ったら「Relay access denied」で蹴られた（mydestinationパラメータに逆引き名が含まれていないらしい）。HELOコマンドへの応答で示されたFQDNは順引きできず、メールは配送エラーになった。手動のSMTPでpostmaster宛に「一日1回にしてください」とメッセージを打ち込んだ。
　その後24時間たっても5分間隔のダウンロードは止まらなかった。postmaster宛のメールをちゃんと見ていないことが考えられる。ルータでHTTPアクセスをブロックした。これで、そのサイトからは、ホワイトリストファイルはもとより、私のウェブページや掲示板にもアクセスできなくなる。しかし、私のスキルでは、気付いてもらうための策がほかに思い付かなかった。
　…と、ここまで書いたところで、whoisで逆引きドメイン名の登録者を調べて通報することを思い付いた。

（続編）
常軌を逸したダウンロードの犯人がわかった

考え直してGoogleのドメイン名もホワイトリスト登録

　前回、パラノイド検査エラーになるGoogleのサーバのためにIPアドレスのホワイトリスト登録をしていることを述べた。BBSのゲストのいるかさんから報告されたGoogleのホストはルール1に引っかかるものであるが、IPアドレスのホワイトリスト登録にマッチするので、ドメイン名のホワイトリスト登録を追加する必要はない。
　しかし、考え直した結果、Googleのドメイン名も公開ホワイトリストに掲載した。というのは、いるかさんはqmail用のs25rtarpitgreylistをお使いで、公開ホワイトリストファイルをそのままPostfixで使っているわけではない。そのような人たちが公開ホワイトリストから項目を抽出して、使用システムに合わせたホワイトリストを作ることに配慮すると、Googleのドメイン名のホワイトリスト登録も示しておいた方がよいと考えたからである。
　記載は以下のとおり。

# *** PUBLISHED S25R WHITE LIST ***
# Last update: Mar 11, 2009
# (*): reported by a contributor
#
# Mar 11, 2009: mail-gx0-f21.google.com, etc. (*)
/\.google\.com$/ OK

　Googleは超メジャーなサイトなので、論文中のホワイトリストのサンプルにも掲載した。

Googleサーバのパラノイド検査エラー

　BBSのゲストのいるかさんから、以下のホストが引っかかるとの情報をいただいた。

mail-gx0-f167.google.com [209.85.217.167]
mail-gx0-f236.google.com [209.85.217.236]
mail-gx0-f72.google.com [209.85.217.72]
mail-gx0-f21.google.com [209.85.217.21]
mail-qy0-f75.google.com [209.85.221.75]

　しかし、以下のように、すでに2008年7月にIPアドレスでホワイトリスト登録していた。

# Jul 10, 2008: rv-out-0102.google.com, etc. (*)
/^209\.85\.(1(2[8-9]|[3-9][0-9])|2([0-4][0-9]|5[0-5]))\.[0-9]+$/ OK
#
# Jul 10, 2008: py-out-0102.google.com, etc. (*)
/^64\.233\.1([6-8][0-9]|9[0-1])\.[0-9]+$/ OK
#
# Jul 10, 2008: ag-out-0102.google.com, etc. (*)
/^72\.14\.(19[2-9]|2([0-4][0-9]|5[0-5]))\.[0-9]+$/ OK

　このホワイトリスト登録は、PyTaさんからの報告によるものである。たとえば209.85.198.192～209.85.198.207の16個のIPアドレスの逆引き結果はどれもrv-out-0102.google.comになり、その逆引き名を順引きすると16個のIPアドレスが順不同で列挙されてくる。Postfixは、検索された最初のIPアドレスが元のIPアドレスに一致しないとパラノイド検査エラーとして扱う。したがって、高い確率で逆引き結果が「unknown」になってしまう。
　ホスト名の初めの綴りを3種類教えていただいたので、それを手がかりに、Googleに割り当てられているIPアドレスブロックを調べて、上記のようにIPアドレスの許可条件を作った。
　いるかさんから報告されたホストは、逆引きと順引きの対応がまともになっているのでパラノイド検査エラーにはならないが、

/\.google\.com$/ OK

という許可条件を追加するまでもない。IPアドレスが1番目の許可条件にマッチするからである。

　このようなパラノイド検査エラーは、amazon.comでも起こっていた。207.171.167.25と207.171.172.6の逆引き名がともにiad-fw-global.amazon.comで、その順引き結果が二つのIPアドレスになっていた。しかし、今調べたところ、それぞれの逆引き名は207-171-167-25.amazon.comと207-171-172-6.amazon.comに変わっていて、順引きとの対応もまともになっていることがわかった。これらのホストは、すでに

# Oct 28, 2004: 207-171-180-101.amazon.com
/\.amazon\.com$/ OK

という許可条件があるので、許可される。
　逆引き名の変更で不要になった許可条件は、ホワイトリストファイルの頭の方でコメントアウトで示した。しばらくしたら削除するつもりである。

# Mar 08, 2009: (This condition has become unnecessary.)
# Jun 06, 2004: iad-fw-global.amazon.com
#/^207\.171\.(167\.25|172\.6)$/ OK