1  spam blog の増加と対策

最近の話でもないんだろうが、spam はメールだけでなくWebでも増加しているようだ。

ニフティは3月26日、国内のブログ記事の4割が「迷惑ブログ」に分類されるという独自調査の結果を公表した。アフィリエイト広告収入や特定サイトへの誘導が目的で、同社では「無意味なコンテンツ」と定義している。ブログの4割は「迷惑ブログ」――ニフティ調査 - ITmedia エンタープライズ

こうした spam blog はコピー元にされたblogや検索者にも迷惑だが、一番困るのは検索エンジン各社だろう。現在でも当然ながら個別のblogに対して blacklist を作ったりなにかしらのロジックで回避するような対応策を考えているんだろうが、今のところその手の blog が検索で引っかかるのは事実だし、spam blog 自体が AdWords 広告を出していたりするのも鬱陶しい。

いっそ迷惑blogが目立つblogサービスでは、ドメインやIPアドレスブロックごと、いわゆる Google八分 を仕掛けるルールにしてしまうのはどうだろう。サービス提供側も真面目に対応せざるを得なくなると思うんだが、規約に盛り込めるような悪行と見なせるかどうかが難しいところか。コンテンツ的にはリンク集やニュースサイトや Planet と大差ないんだし。

そう言えばRSSを全文コピー掲載されることへの対策として、各記事本文に元記事へのリンクを入れると言う方法がRSS FooterでWordPressのRSSに情報を入れてコピーブログを防ぐ | 秋元 や フィードの各記事に署名を入れました - F.Ko-Jiの「一秒後は未来」 で紹介されていたので、うちでも近いうちに入れてみようかなと思っているが、鬱陶しくならないかがちょっと心配。

メールでの SPF/SenderID や DomainKeys/DKIM のような本家送信元証明手段が blog にもあるといいのだけど、うまい方法はちょっと思いつかない。

1  SMTPレベルでのspam送信機能改善

数年前から MTA レベルの spam フィルタ技術として tarpitting + greylist 等を適用しているが、最近どうも効きが悪い感じがしたので、すり抜けてくる spam について少し調査をしてみた。結論としては spam 送信ソフトの実装レベルがかなり上がってきた事が伺える。

SMTP的な挙動が正常なMTAと区別が付かないspammerの増加

Greylist (わざと再送要求する) や Tarpit (応答コード送信を遅延させる) といった手法に普通の MTA と同じようにきちんと対応してくる spammer が増えてきている。元々 spam 送信者のソフトウェアが真面目に実装されていない事を利用した手法なので、真面目に実装した方が spam 送信率が高くなると認識された時点で対応されるのはある意味当然ではあるのだが、思ったより早く対応が進んでいる。
その他でも、HELO/EHLO できちんと FQDN を送信してきたり、セカンダリMXを参照して再送をかけてきたりと、全般的にSMTP的な振る舞いは正しいMTAと区別できないレベルのものが確実に増えてきている。特に英語spamに顕著。

ISPの真っ当なメールサーバを中継してくるspammerの増加

正当なISPのメールサーバから正当なFromで送りつけてくる spammer が最近は多少目立つようになってきた。ほぼ同じ内容のspamが複数の送信者・ISP経由から来ているのを見るに、恐らくはウィルス感染PCのbotnetから広く浅く送ってきているのだろう。これをやられるともうSMTPレベルではフィルタのしようがなく、本文の文章解析に頼るしかない。

2  From / To / Subject / Body の工夫

SMTPレベル以外でも、From / To や Subject, 本文自体にも色々と工夫が見られる。

From が自分自身 (To と同一) であったりランダムであったりする

SpamAssassin では blacklist_from と言う From 固定フィルタがあるが、これが使えなくなる。From が自分自身と言うケースに付いては SPF のような送信サーバ認証を使う手はあり、SpamAssassin 等でも whitelist_from_spf と言った SPF 認証された From のみを Whitelist として扱う設定がある。
個人的な問題は私の主メールアドレスのドメインを登録している NSI が未だに TXT レコードの編集に対応していないという所だが、SPF 対応サーバ自体は去年のドコモの PSF フィルタ開始から増加している。

Subject や本文にスペルミスを入れてくる

英語spamでの話になるが、固定文字列フィルタをすり抜けるためにわざとキーワードをスペルミスしてくる。よくあるのは Viagra を Viagara や Viarga と言ったようなもの。

今のところはまだこうしたインテリジェントなspammerは大多数ではないため、既存の手法もそれなりの割合では効いているが、出来のいいツールが出回るようになると現行の手法では対処が難しくなるだろう。まめにメンテナンスされた DNSRBLs 、ドメイン認証、フロー制御、あとはコンテンツレベルでのより賢いフィルタリング等の重要性が増していくだろうが、より CPU リソースを消費する方向に進んでいると言うのはかなり憂鬱な話ではある。

どちらにせよ大量のサンプルと申告者を持っているサービスは有利になるので、個人レベルならば例えば「Gmailへフォワード→POP3で取得」などという方法を使うのも手かもしれない。

1  クライアントサイドでのSPF対応

MTA である postfix レベルで SPF による受信拒否をするのは現状やりすぎだが、 spam filter のレベルで判定基準の一つにする手はある。 特に「本当ならばSPFレコードが提供されているドメインで、SPFレコードのIPアドレスと送信元サーバのIPアドレスがマッチしない」と言うケースであればほぼ黒といえる。 また逆に、SPF を通ったのであれば spam スコアを軽減できる可能性もある。 後者は spammer が SPF 対応してくることを考えると微妙だが。

Spamassassin で SPF を使うには、単に /etc/spamassassin/init.pre にて

loadplugin Mail::SpamAssassin::Plugin::SPF

として SPF verification test Plugin を呼ぶ。 最新版では最初から有効になっているが、 Debian で使うには libmail-spf-query-perl を入れるか、Mail::SPF を別途入れる必要がある。 前者は Recommends には入っている。 個々の設定で

whitelist_from_spf *@docomo.ne.jp

のようにして、whitelist に登録した from アドレスの送信サーバが詐称されていないことを確認することも出来るようだ。

もちろんこの先 spammer が SPF に対応してくる可能性もあるが、その場合は spam と送信元の紐付けが SPF で一意に出来るので IPアドレスレベルでフィルタしやすくなるわけで、SPF 自体が無意味になるものではない。

1  スラッシュドット ジャパン | NTTドコモがSPFによるメール着信拒否機能を提供

ユーザの選択によるものだそうだが、メールマガジンなど一律で送信するようなサービスでは対処が必須になりそうだ。au では既に同様の機能が提供されているようなので対処が終わっている所が多いのかもしれないが。

SPFは、基本的には DNS サーバの TXT レコードに送信メールサーバを規定のフォーマット、例えば docomo.ne.jp の場合は

v=spf1 +ip4:203.138.203.0/24 ~all

のように書き込めばいいので対処は難しくはない。 とは言え先日 TXT レコードを登録できるDNSサービスは意外と多い? で書いたように、増えてきたとはいえ未対応の業者も多く、実際問題として init.org を登録している NSI のDNSサービスは TXTレコード登録・編集に対応していない。 ドコモや au のような取り組みが NSI 等にもプレッシャーになってくれればありがたいのだが。

1  tdiary につっこみspam到来のため、フィルタを設置

コメント投稿元IPアドレスが 8,184、POST数 10万を越える完全な DDoS 攻撃。あまりそうした攻撃を受けていなかったので油断して防御策を弄していなかったため、ちょっと狼狽した。この blog ですら月間 2万〜4万 spam 程度なのだが。こう多いと POST のフロー制御をする dso でも書こうかという気になる。

なお、こうした spam 投稿を連続で食らうとシステム負荷も馬鹿にならないので、単純だが system の tdiary/filter/spam.rb として href と [url 、多数の http 文字列をフィルタするものを入れてみた。

module TDiary
  module Filter
    class SpamFilter < Filter
      def comment_filter(diary, comment)
        if(/\bhref/i =~ comment.body ||
           /\[url/i =~ comment.body ||
           comment.body.scan(%r|https?://|).size > 4) then
          return false
        end
        return true
      end
    end
  end
end

利用者の方はなにか不具合が出たら報告をよろしく。そのうち たださん推奨の spam filter も入れてみる予定。

2  debian の tdiary package は orphan?

ところで tdiary の deb は tdiary_2.0.2+20060303-5_all.deb 以降、セキュリティアップデートの 2.0.3, 2.0.4 が出ても更新されていないようだけど、もうメンテナンスされていないんだろうか。手元のものは手で対応しているが、MNU するには独自 patch が多くてちょっと面倒そう。

1  taRgrey - S25R + tarpitting + greylisting

以前 postfix + Rgrey での spam 対策 で参考にさせてもらった Rgrey の stealthinu さんが、postgrey の greylist に tarpitting を追加した物を公開したと、以前メールで教えていただいた。

taRgreyとは、メールサーバ上でスパムやウイルスメールを排除するためのフィルタの手法で、 S25Rとtarpittingとgreylistingというスパム判定手法を組み合わせて使うというものです。
S25Rにより、動的IPっぽいFQDNからの接続からは怪しいと判断し、tarpitting(応答の遅延)を行います。tarpittingを待ちきれずに送信元が接続を切った後、再度送ってきた場合にはgreylisting(再送のチェック)により救済します。S25Rとtarpittingとgreylistingと、全てのフィルタを抜けれなかったものだけがスパムとして排除されます。taRgrey - S25R + tarpitting + greylisting

大分前に導入しているのだが、しばらく利用しての効果をまとめておく。

Debian には postgrey パッケージがあるのでこちらの導入は簡単なのだが、targrey を使うためには postgrey に patch を当て、設定を変更する必要がある。導入手順は元サイトを参照してほしいが、流れは概ね以下の通り。

1. postgrey に patch を当てる
2. /etc/default/postgrey の POSTGREY_OPTS に tarpit, targrey 等の設定を追加
3. /etc/postfix/permit_client_nots25r を追加
4. /etc/postfix/main.cf を編集

以前 Rgrey を導入するために設定変更している状態に更に手を入れることになったので、状況を把握するのが多少手間取った。ロジックとしては smtpd_recipient_restrictions で S25R をチェックし tarpitting を適用、tarpitting で失敗した後に再送してきた相手は smtpd_data_restrictions の方で greylisting のチェックをかけている。postgrey はその辺りを db に保存して、状態遷移を管理しているようだ。

taRgrey では tarpit で失敗した分を greylist で救う形 (tarpitting || greylist) になるため、greylist や tarpitting 単体よりは条件が多少緩くなる。その分 false positive は経るだろうが false negative が増えるかもしれない。逆に厳しくしたいのならば、条件を (tarpitting && greylist) にすればよい。

2  taRgrey の効果

1月16〜31日の約2週間の効果を以下に記す。postgrey のオプションは taRgrey で推奨されている --tarpit=65 --targrey --delay=1200 --retry-count=2 をそのまま用いている。

処理	処理数	残通数
SMTP総コネクション数	79,863	79,863
header_checks での添付(.pif .scr)DISCARD	4,026	75,837
HELO Blacklist/Rule によるREJECT	5,988	70,349
S25RにマッチしてのWARN	63,940	5,909
→ RCPT Blacklist によるREJECT	15
→ その他ルールによるREJECT	10,046
→ tarpitting での lost connection	16,511
→ Gleylisted による REJECT	32,882
taRgrey通過通数		8,109

数字が合わない部分があるが、ログをラフに解析した結果なので大目に見てほしい。taRgrey 以外のルールで意外に効いたのがhelo blacklist による reject と、smtpd_recipient_restrictions の reject_unknown_sender_domain (5,234) 。user unknown での reject も 3,384 と結構多いので、virtmap や alias での catch all ( *@domain を特定アドレスに転送 ) は無い方がよさそうだ。

当サーバでは、taRgrey を抜けたメールはその後、Amavis-new + ClamAV によるフィルタを通過する。

AmavisでのBAN/BADH	2,144
Amavis通過通数		5,965

ちなみに Rgrey も適用していない去年6月の場合、amavis に到達したメール数が68,231、amavis で落ちたメール数は 24,320 、通過数が 43,911 と、どれも 10倍近い。メール本文スキャンによるサーバの負荷を考えると、かなりの負荷軽減になっていると考えられる。

最終的に各ユーザに落ちる際に、更に Procmail、SpamAssassin によるフィルタが適用される。

MAILER-DAEMONなど定型フィルタ	1,355
SpamAssassinでのフィルタ	3,787
最終的なメール数		823

最終的な spam スルー数(false negative)は2週間で5通、誤判定(false positive) はメールマガジン1通だった。false positive が低いのは、単に whitelist をきちんと書いているからかもしれない。非 spam メールのうちでは、「Virus 判定された」と From アドレス宛に返信してきているメールが結構多い。

単純に効果のほどを考えると、Debian では patch などがいらない postgrey での Rgrey だけでも十分かもしれない。もちろん taRgrey (tarpit || greylist) で false positive を減らしたい場合や、(tarpit && greylist) として厳しく受け付けたい場合などには、この組み合わせは有効だろう。

1  MXLogic Threat Center

米国の spam filtering ビジネス企業、MXLogic の Threat Center には、世界で動いている同社 spam フィルタ製品の判定情報が集計されている。それによると、「12% が普通のメール, 87.5% が spam, 0.5% が Virus」となっており、世に流れているのメールの実に 90% 弱が spam であると言う陰鬱な事実が示唆される。

同じく spam filtering サービス提供企業 Postini のPostini / Stats でも「84.8% が spam, 0.3% が Virus」と言う数字が出ており、日本に限ればまた数字が違うのかもしれないが、世界的にはこれくらいの傾向だと言うことが分かる。

さらに Postini の Directory Harvest Attacks (DHAs) という指標を見ると、世界のメールサーバの性能のうち更に 30〜50% が、spammer がサーバを乗っ取ったり情報を引き出そうという意図で仕掛けている攻撃に費やされている、と言うことも見て取れる。同社は「spammer が DHAs に成功してメールアドレスなどの情報を引き出した場合、そのアドレス宛の spam が目覚ましく増える」としており、SMTPサーバ側の情報漏洩対策 (VRFY, EXPN に応じない、安易に User Unknown を返さない等) も大事だと言うことが分かる。

メール到達後の spam filtering も相当な処理を CPU に強いている訳で、spam によって浪費されている全世界のコンピュータ資源・ネットワーク資源がどれだけあるかと思うと気が遠くなりそうだ。特に最近は Virus 感染 PC 経由での botnet からの送信も多いが、OP25B を採用する ISP が増えれば多少なりとも状況はマシになるだろうか。

1  Rgrey - S25R + greylisting

postfix に Rgrey の方法で smtp spam filtering を入れた。ささださんの真似。1日動かした時点での効果としては、amavis の bannedmail フォルダに落ちるメールが、約 1/10 に減少している。spam filter で spam フォルダに落ちるメールは 1/3〜1/4程度になった。これだけで spam を遮断することにはならないが、後段の amavis や spamassassin に比べて処理がかなり軽いので負荷軽減にもなる。

2  Greylisting + S25R

基本的な発想は Greylisting と言う方法。

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

つまり「smtp 接続に 450 (一時的な拒否) を返して再送要求すると、まともな MTA なら再送するけど spam tool や virus は再送しないから spam を遮断できる」というもの。一度再送が行われた IPアドレスと From, To の組合わせは記録され、1ヶ月間は再度の再送要求無く処理される。

しかしこれだと「でもそれってまともな MTA にも余計な負担をかけるよね」と言われるのももっともな話。「じゃあ怪しげな接続元だけにこの手を使おう」と言うことにして、S25R にあるような

有効なスパム対策は、メール中継サーバからのSMTPアクセスを受け入れる一方で、エンドユーザー用回線からのSMTPアクセスを拒絶することである。それらは、IPアドレスの逆引き名の特徴に基づいて識別できる。

に基づき、「逆引き出来ないか、逆引き結果がいかにも回線系サービス」のものに Greylisting を適用する。

こうした接続元逆引きパターンによる判別は、postfix の場合は main.cf の設定のみで対応出来る。設定内容は rgrey そのままだが、一応書いておくと

/etc/postfix/main.cf

 smtpd_recipient_restrictions = ... , regexp:/etc/postfix/check_client_fqdn
 smtpd_restriction_classes = check_greylist
 check_greylist = check_policy_service inet:60000 

/etc/postfix/check_client_fqdn

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

postgrey は Debian なら公式パッケージが用意されているので apt 一発。と言うことで導入は容易だ。check_client_fqdn の正規表現は色々試してみるのが良さそうか。

3  導入雑感

結局これは逆引き名が「怪しい」サーバに負担を強いることになるが、実際の効果がそれなりにあるのと 1度再送してもらえば当分はスルーするので許容できるレベルではなかろうか。将来的には OP25B で解決される部分ではあるが、全ての ISP がそれを行うわけでもなかろう。ちなみに現在うちの MTA では Rgrey の他にも NS による Reject や 添付ファイル(.scr|.pif)の拒否もしている。MTA での総合的な spam 対策は spam対策まとめ が詳しい。

1  RSS の CDATA 部分を微調整

LDR で h4 等の要素が無効化されて表示が崩れる問題に関して、h4 の直後とその後の本文部分の直後にそれぞれ br 要素を追加。bloglines 等のそういった無効化をしないリーダだと隙間が空いてしまうかも知れないが、とりあえず当面はこれで。またそのうち手を入れ直すかもしれない。なお手を入れたのは index.rdf のみで atom.xml はそのまま。

2  この blog の publish datetime

そう言えばこの blog の rss 講読者から「フィードが数日遅れで表示される」と言われたことがあるんだけど、済みません、dc:date が結構嘘ついてます。次の日以降に前日の日記を書くスタイルだとどうしても published と記載内容がずれるんだけど、どう解決するのが美しいのかなぁ。せめて modified は正直に出すべきか。

1  大量の comment spam 到来と対策

今日だけで 10,000回以上、ピークは 1分間に100発以上で、例によって botnet からなので IP Address では弾きにくい(600アドレス程度ある)。とりあえず全て文字列によるフィルタリングで spam 判定できていたものの、これが馬鹿なことに spam 判別しても cache をクリアして rebuild する流れにしてしまっていた。お陰で毎回重い処理が走って load average が 30 越えすると言う悲惨なことに。ここは raise して逃げるように手直ししたが、不具合が出るようでしたら教えてください。

(追記) その後の、24日には約 23,000回程度の spam が来たが、負荷はさほど上がらずに済んだようだ。攻撃パターンはほぼ一緒なので、単一の発信元なのだろう。攻撃元IPアドレスは 1,200程度で、やはり海外回線系が多い。国内ISPからの攻撃もある。

1  言及リンクのチェックによる Trackback spam 拒否の効果

4月28日に言及リンク無しトラックバックの拒否をするように設定したが、これによって拒否されたトラックバックはこの 6月 1日〜15日の期間だけでも 214件あった。見てみると Trackback spam は大抵が日本からで、アダルト系や金融(詐欺?)系が多いようだ。リンク先がサイトのトップページだったり、同じところが何度も投げてきているのも特徴か。
まぁ同期間に言及のあるトラックバックが 1件もないのは寂しい限りだし、関連の話題という意味でトラックバックしてくれた人もいたようだが、これだけ spam が多くては制限を外すのも現実的では無さそうだ。

2  同期間の spam コメント

ちなみにコメント書き込みの禁止条件に引っ掛って拒否されたコメントは同じ期間で 1,604件。こちらの殆んどは海外からの英語のもので、URL が大量に含まれているものが多い。IPアドレスは分散しているようで、幾つか見てみると海外の回線系サービスらしきものが多いので、恐らくウィルス感染したPCで構築された botnet を使っているのだろう。こちらも困りものではあるが、現状のポリシーでも概ね弾けているので良しとする。

1  Google からのメール

Google.com からこんなメールが来た。

Subject: Thank you from Google!
From: resume-thanks@google.com
Date: Thu, 20 Apr 2006 19:56:23 -0700

Dear Applicant,
We recently received your resume and would like to thank you for your interest in working at Google. After reviewing your resume, a member of our staffing team will be in touch if we find you may be a fit for the role for which you've applied. Thanks again!

Sincerely,
Google Jobs
jobs@google.com

要約すると「あなたから送られた resume (履歴書) を拝見した。適した仕事があるかどうかをこれから検討する」と言うもの。これが届いたのがしばらく前なのだが、更に今度は

Subject: Thank you
From: resume-thanks@google.com
Date: Fri, 28 Apr 2006 08:09:44 -0700

We received your resume and would like to thank you for your interest in Google. After carefully reviewing your experience and qualifications, we have determined that we do not have a position available which is a strong match at this time.

Thanks again for considering Google. We wish you well in your endeavors and hope you might consider us again in the future.

Sincerely,
Google Staffing

と言うのが届いた。今回は「残念ながらあなたに適したポジションはありませんでした」というもの。なお私は Google に Resume を送ったことはありませんので念の為。初めはまたどこかのウィルスに感染しているマシンが私のアドレスで勝手にメールを出していて、それへの自動返答かと思ったんだけど、機械的な自動返答にしては 2種類来るのが不思議だし、そもそもこの 2通は To が違うアドレスに届いたものだったりする。

Envelope を見てみると、Received が *.corp.google.com からになっていて、google.com の DomainKey-Signature も付いてはいるんだけど、google.com の txt レコードに DomainKeys は登録されてないし、SPF も all になっているんだよね。

DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:date:message-id:from:to:subject:mime-version: content-type:content-transfer-encoding; b=je5Zw6LBUG7YERRKl1scyuV7RsHSohNJ/SCl6AbUZEIHQp+wLrwoCnuRPG/Hf0qJX 6StyBw7DBHobk6Bl25K5g==

結局は単なる悪戯メールなんだろうか。

1  言及リンク無し Trackback の拒否

元々私の Blog には大した数の Trackback は来ないのだが、先日にも書いた通り最近は明らかな spam ばかりきて辟易したので、今更ながらとりあえず言及リンク無し Trackback を拒否するようにした。仕組みとしては当然ながら Trackback に含まれる uri に対して fetch して内容を確認するという作業を伴うため、そちらへの HTTP アクセスがタイムアウトするなどすると失敗する可能性がある。申し訳ないがご了承頂きたい。

ところで一部の HNS での、Cookie を喰わないと日記本文が表示されないような仕組みの場合、こうした自動 fetch の仕組みがうまく動かない気がする。もちろんこちら側が Cookie を正しく処理するようになっていればいいのだろうが、そこまで作り込むのも難儀だし、正直どうしたものかいいアイディアが無いので、当面はこのままで。

1  Trackback spam の増加とその対策としての言及リンクフィルタ

最近はBlog の記事とは完全に無関係な広告目的の Trackback がかなり増えてきている。言及リンクのない Trackback の是非についての議論は過去にも散見されたが、実際に trackback spam が増加してくると、そうした spam を機械的にフィルタする手段は言及リンクの有無の確認程度しかない。

2  Trackback はこの先も通用する技術であり続けるだろうか

もちろんこれも spam 元が機械的にリンクを並べるようになったら区別出来なくなる。実際、最近だと取得した RSS を並べて広告を差し込んで Trackback を飛ばしてくる広告サイトも存在する。最終的には baysian filter なりを考えるべきなのかも知れないが、そもそも受け手側がそんな苦労をするという事自体が割に合わないと言う意味では、既に Trackback と言う仕組み自体が崩壊しつつあるのかもしれない。

これを避けるには OpenID のような Trackback 元サイトを認証する仕組みと組み合わせて、受け入れるかどうかを判断するような認証型をとる方法はあるかもしれない。ただこれだと知らない人からの Trackback は無条件で拒否されてしまうので、そうしたものは受取り保留と言う形を作るか、もしくは SNS のように「友達の友達」的な信頼リストのネットワークを使うなどを考えるといいだろうか。
どちらにせよ、現状の Trackback は spam との戦いになりつつあるのではないかと思うし、個人的には当面はそうした spam と自分の Trackback を区別するためにも言及リンクを入れておいて欲しいと思う。

1  所謂 全信協スパムクローラを避ける mod_rewrite 設定

日本の spam crawler としては老舗であろう全信協だが、1秒間に 20アクセス以上と言うふざけたアクセスをしてくる上に index.html へ連続 15回 といった無意味なアクセスも大量にしてくるのがいい加減に鬱陶しいので、今更ではあるがフィルタすることにした。

対策としては mod_rewrite による deny。全信協スパムクローラ対策 を参考に RewriteRule を書いた。OCN など特定 ISP が良く使われるという特徴の他にも

• HTTP/1.0 でのアクセス
• HTTP_REFERER が空
• USER_AGENT が Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
  (ないし Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) もあるらしいが、後者はうちではあまり見当たらない)

と言う特徴があるようで、特に HTTP/1.0 と USER_AGENT を条件にすれば、真っ当なアクセスをフィルタすると言うこともないのではなかろうか。現在のルールは以下の通り。

RewriteEngine On
RewriteCond %{HTTP_REFERER}     ^$
RewriteCond %{REMOTE_HOST}      marunouchi\.tokyo\.ocn\.ne\.jp$ [OR]
RewriteCond %{REMOTE_HOST}      tokyo-ip\.dti\.ne\.jp$ [OR]
RewriteCond %{REMOTE_HOST}      odn\.ad\.jp$ [OR]
RewriteCond %{REMOTE_HOST}      tky\.mesh\.ad\.jp$ [OR]
RewriteCond %{REMOTE_HOST}      ap\.gmo-access\.jp$
RewriteCond %{HTTP_USER_AGENT}  "^Mozilla/4\.0 \(compatible; MSIE 6\.0; Windows 98\)$"
RewriteCond %{SERVER_PROTOCOL}  ^HTTP/1\.0$
RewriteRule .* - [F,L]

ちなみに RewriteRule は下層ディレクトリにも引き継がれるが、そちらで別途 RewriteEngine On による Rewrite 設定をしている場合には

RewriteEngine On
RewriteOptions inherit

としておかないと設定がクリアされて効かなくなるらしいので注意。

1  mixi の「あしあと」spam

久しぶりにmixiのあしあとを見てみたら、あからさまな spam 踏みが結構頻繁に来ていた。多いところだと毎日のように踏みに来ている。

2006年01月31日 11:38 東海秘密倶楽部
2006年01月31日 07:25 女子大生ai@月収100万
2006年01月29日 13:36 新しいキャリアの創造

まぁこんなのはちょっとしたツールを書けば自動でなんぼでも踏めるわけだし、実際に「踏み返し」が多い mixi では有効性も他の手段より高そうだ。今まで少なかったのが不思議なくらいだとも言える。個人的にはあしあとは殆んど見ないのでどうでもいいが、mixi 運営局にたれこめば潰してくれるんだろうか。