最近トラックバックスパムをあまり受信しなくなった。というか、Junkとして排除できるようになった。
なぜかと言えば、SpamLookupのKeyword Filterの「スパムにするキーワード」におクスリ系キーワードをガッツリ登録したからだ。
/adderall|ambien|amoxicillin|cialis|ephedra|ephedrine|famvir|fioricet|hoodia|hydrocodone|meridia|oxycodone|paxil|percocet|pharmacy|phemntermine|phentermine|ritalin|soma|tramadol|tylenol|ultram|valium|vicodin|xanax|zoloft/i 4
これで一日あたり4000件くらい排除できている。
2007-12-04追記:
このあたりも追加しといた方が良いかも。
/adipex|lexapro|lipitor|oxycontin|propecia|prozac|wellbutrin/i 4
CAPTCHA™テストを使った簡単なアンチコメントスパムプラグイン(Ogawa::Buzz: Captcha Plugin公開)をアップデートしました。
Captcha_Plugin - ogawa - CAPTCHA(TM)テストによる簡単なアンチコメントスパムを実現するプラグイン。 - Google Code
最初に公開した時点ではプロトタイプ的なものでしかありませんでしたが、今回はなるべく柔軟に使用できるように以下の拡張をしました。
4. のsecret keyの設定機能に関して補足しておきます。
Kazuho@Cybozu Labs: Captcha Plugin/ja についてでも指摘されている通り、このプラグインで使用されているAuthen-Captchaはbrute force attackに弱い性質がありました。
CAPTCHAテストの生成時と検証時に共有鍵を使用する方式に改めればこの問題は大幅に緩和でき、実際下記のようなパッチも提案されています(FreeBSD portsでp5-Authen-Captchaをインストールするとパッチが当たったものがインストールされます)。
#7664: improve Authen::Captcha security
Captcha Pluginのsecret keyの設定機能は、このパッチが当たっているAuthen-Captchaがインストールされている場合のみ有効になります。この機能を使用するためには、おそらくほとんどのユーザは、手でこのパッチを当てる必要がありますのでご注意ください。
Authen-Captchaはもう保守されていないっぽい。Authen-PluggableCaptchaというのもあるけど。本当はGoogleあたりがCaptcha部分だけ外部サービスとして提供してくれれば良いのにね。
2006-10-08追記: CAPTCHA表示用のテンプレートをプラグインの設定画面から変更できるようにした0.12を公開してあります。
2006-10-17追記: CAPTCHAを使用しない設定にしたブログで、正常にコメントポストできない問題を修正した(0.13)。
CAPTCHA™テストを使った簡単なアンチコメントスパムプラグインを作ったので公開しておきます。
Captcha_Plugin - ogawa - CAPTCHA(TM)テストによる簡単なアンチコメントスパムを実現するプラグイン。 - Google Code
このプラグインは、以下のように、コメント時に大抵の人間には容易に解答できるがプログラムでは簡単に解けないようなテストを課すことで(この場合はSecure Codeを入力させることで)、spambotを排除するという仕組みを実現します。
Movable Typeで同様の機能を実現する方法としては、SCode - Movalog Plugins - TracやCAPTCHA によるコメントスパム対策 - Open MagicVox.netが知られています。
Captcha Pluginがこれらと異なるのは、セッションごとに(つまりはコメントフォームが表示されるごとに)Javascriptを使って新しいCAPTCHAテストを生成するということと、各CAPTCHAテストに有効期限が設定されていることです。ですから、単純なbot攻撃に加えて、「人間が解いて、botが攻撃する」タイプのbot攻撃にも有効ではないかと思われます。
また、セッションごとに新しいテストを生成するということは、テストの生成が十分に軽量に行える保証が必要です。このため、テスト生成を行うCGIスクリプトcaptcha_js.cgiは簡単なものに留めて、あえてMTアプリケーションにしていません。MTアプリとして作ると、プラグインの設定画面での設定内容を処理に利用できるとか、中間ストレージにMTのフレームワークを利用できるとか可用性の点で大いにメリットがある反面、ブートストラップやDBアクセスのオーバーヘッドが無視できないものとなります。
ちなみにSCode Pluginは、テスト画像を作るCGIプログラムをMTアプリとして実現しており、その上毎セッションまったく同じ画像を返すにも関わらず、GDモジュールを使って毎回画像を生成していてキャッシュすらしません。それもなんだかなあ…。
Ogawa::Buzz: AutoIPBan Plugin公開
とか作っておきながらなんですが、どうもねえ…。
昨日の時点で約7000件のトラックバックスパムがやってきて、うち約6000件はリジェクト、250件はスロットリングされ、残りの700件強がやはりJunk Folderに溜まっていくご様子…。結果として9割方リジェクトできているのだからいいじゃないかとはちょっと思えませんね。なんかくじけそうです。
対SPAM最終兵器“Junk slowdown”!! : 亜細亜ノ蛾 - Weblog
やっぱりこっちの方が素直で有効っぽいです。スクリプトの途中でスリープさせるのはあまり意味がないかと思いますが。そのままだと芸がないので私はCで超簡単なマルチスレッドプログラムを書いて済ませてみました。
さて、ここからが本題。
教えてエロいえらいひと
コメント・トラックバックCGIのリネームとMT.cfg・.htaccessの変更を、同時に行ってくれるスクリプトがあれば、週一くらいで実行すると万全なのですが。
ってことなのですが、基本的に「スクリプトで」mt-config.cgiを更新するのはあまりお勧めしません。代わりと言ってはなんですが、定期的にmt-config.cgiのCommentScriptとTrackbackScriptを変更し、再構築するだけで済むようにするには以下のようにするとよいです。
まず、mt-comments.cgi, mt-tb.cgiは予想しにくいでたらめな名前に変更しておきます。ここでは、仮にmt-comment-detarame.cgi, mt-tb-detarame.cgiとします。
次にmt-config.cgiのCommentScript, TrackbackScriptにスクリプト名を設定します。ここで設定する名前は、mt-comment-detarame.cgiなどにリライトされるので、ファイルとして実際に存在している必要はありません。また、mt-comment-detarame.cgiなどとは異なった名前の方がよいでしょう。例えば、mt-comments-nospam.cgi, mt-tb-nospam.cgiとか日付を使った名前とか。
最後に、以下のようなテンプレートを作り、出力するファイル名にはフルパスでMTがインストールされているディレクトリの.htaccessを指定します(例: /home/hoge/.../mt/.htaccess)。また、インデックス・テンプレートと同時に再構築されるようにしておくとよいでしょう(このテンプレートは絶対にダイナミックパブリッシングにしてはいけません)。
RewriteEngine on
RewriteRule ^<$MTCommentScript$>(.*)$ mt-comments-detarame.cgi$1 [L]
RewriteRule ^<$MTTrackbackScript$>(.*)$ mt-tb-detarame.cgi$1 [L]
RewriteRule ^(mt-comments|...)\.cgi$ /hoge/sand-trap.php [L]すでに.htaccessに何かを指定しているのであればその内容も含めます。また、Movable TypeからMTディレクトリに書き込めるようにパーミッションを設定しておく必要があります。それが済んだらこのテンプレートを再構築して正しく.htaccessが生成できることを確認してください。
確認できたらすべてのアーカイブ、インデックスを再構築して終わりです。以降は、定期的にmt-config.cgiのCommentScriptとTrackbackScriptを変更し、再構築するだけで済みます。
…というのは全部実際には試さずに書いています。
あまりのトラックバックスパムの多さに堪えかねて、Movable TypeのIPBanListをもっともっと活用するためのプラグインを作ったので公開しておきます。このプラグインでは、トラックバックスロットリングの対象となったIPアドレスを自動的にIPBanListに追加したり、Junk Folderのトラックバックの送信元IPアドレスを一括してIPBanListに追加したりすることができます。
また、IPBanListの情報にテンプレートからアクセスする手段も提供しているので、.htaccessをMovable Typeで生成してIPBanListに含まれるホストからは一切トラックバックやコメントできないようにすることも可能です。
詳しくは以下参照。
AutoIPBan_Plugin - ogawa - Google Code
スパマーはいい感じにばらけたIPアドレスを使ってトラックバックを打ってくるので、効果のほどはいまいちかもしれません。OneHourMaxPings, OneDayMaxPingsを小さめに設定しておけばより高い効果が得られます。が、正常なトラックバックがIPBanList入りする恐れが多少増します。
2006-05-14追記:
SpamLookupの振り分け結果を活用できるようにコメント・トラックバック一覧から簡単にスパマーのIPアドレスをIPBanListに追加できるようにしました。
また、テンプレートからIPBanListにアクセスできるようにMTIPBanListコンテナタグ、MTIPBanListIPタグを追加しました。以下のようなテンプレートを使って.htaccessを生成しておくと、スパムIPアドレスをアクセス禁止にできるでしょう。
Order allow,deny allow from all <MTIPBanList> deny from <$MTIPBanListIP$> </MTIPBanList>
なんだかここのところ、トラックバックスパムが異常に多い。
一日平均250件くらいずつSpamLookupにはじかれて、Junk Folderに溜まっていっているご様子。
一方でMovable Type 3.2には同一IPアドレスからのトラックバックの受信をスロットリングする機能もある。一時間あたりOneHourMaxPingsの値(デフォルトでは10)以上の同一IPアドレスからのトラックバック、一日あたりOneDayMaxPingsの値(デフォルトでは50)以上の同一IPアドレスからのトラックバックはリジェクトされ、SpamLookupの対象にすらならない。
いったいどれくらいリジェクトされているのかと思ってログを吐くように細工しておいたら、約一日で750件を超えていることが判明。
合わせて約1000件か……おまいらの情熱はどこからくるのか、と。
ちなみにOneHourMaxPingsでリジェクトされたのが約100件に対し、OneDayMaxPingsでリジェクトされたのが約650件。後者の値を絞るのが効果がありそう。
ThrottleSeconds, OneHourMaxPings, OneDayMaxPingsはすべてmt-config.cgiで設定できるよ。
MT SpamLookup Best Practices: blog.bulknews.net
ちと思ったことがあります。SpamLookupのKeyword Filterの「未公開キーワード」ないし「迷惑キーワード」に以下のように追加しさえすれば、MT BanASCIIはイラネエンジャアアルメエカ、と。
/^[\x00-\xFF]+$/
そう思って実際試してみると、有効に機能しない模様。なるほど、BanASCIIではEncode::decodeしてから/^[\x00-\xFF]+$/と比較しています。decodeしていない(EUC_JP/UTF-8の)文字列との比較なら/^[\x00-\x7F]+$/と比較する必要がありますが、それだとLatin-1の後半にマッチしないという道理なわけですね。
しかし、Latin-1の後半を検出したり、特定の文字集合を検査したりするのにいちいちプラグインを用意するのでは手間もかかるし、効率も悪くなります。もっと手軽に、より多くのユーザーがPerl 5.8の持っている真っ当なマルチバイト文字サポートの恩恵に浴することができてしかるべきだと私は考えます。
というわけで、MT 3.2に付属のSpamLookup 2.0に対するパッチを用意してみました。
このパッチを当てると、Keyword Filterの「未公開キーワード」ないし「迷惑キーワード」に、マルチバイト文字やUNICODEプロパティ・スクリプト・ブロックを使った正規表現が書けるようになります。
以下はExampleです。
Keyword Filterの「未公開キーワード」ないし「迷惑キーワード」に以下のように追加します。
/^[\x00-\xFF]+$/
あるいは\p{Latin}などを使って可読性の良い方法でも書けるでしょう。
Keyword Filterの「未公開キーワード」ないし「迷惑キーワード」に以下のように追加します。
/^[^あ-ん]+$/
ないし
/^\P{Hiragana}+$/
このバリエーションで句読点を必須にしたり、ひらがなの他にカタカナを必須にするルールも同様に書けるでしょう。
コメントスパム受信時、トラックバックスパム受信時のリアクションを複数サポートする、スパムフィルタプラグインを公開します。
QuasiSpamFilter_Plugin - ogawa - Google Code
コメントスパム受信時、トラックバックスパム受信時のリアクションを複数サポートする、スパムフィルタプラグインです。実用にも堪えると思います(私自身も使っています)が、スパムフィルタのリファレンス実装を目的としています。このプラグインでは、自作のスパムフィルタを作りたい、もしくは作っているという方にも利用いただけるようなBuilding Blocksを提供できればと考えています。
「コメントスパム対策」と言うとき、それは複合的な意味を持ちます。コメントスパムがブログ内に表示されるのを避けたいのか、管理画面の「コメント一覧」に表示されるのすら避けたいのか、あるいはコメント投稿によって発生する再構築の負荷を低減したいのか？
このエントリーでは私がやっているコメントスパム対策について述べます。
番組の途中ですが緊急速報です。mt-comments.cgiに極めて重大な欠陥が見つかったようです。スパムメールの踏み台にされるという、とんでもない欠陥です。対策が発表されたら全員がすぐに適用する必要があります。
MT-Blacklist -> Hijacked comments.cgi
というわけで対策出ました。必ずパッチ適用をしましょう。
Movable Type Publishing Platform: Movable Type 3.15 released
Movable Type 日本語版サイト: 【重要】 Movable Typeの脆弱性と対策について
STEP 1: 「TypeKey + 承認付き」にする
単に「コメントスパムがブログ内に表示されるのを避けたい」のであれば、TypeKeyを用いた投稿だけを許すか、それに加えて「承認(事前確認)付き」でのコメント投稿を許すようにすればよいだけです。承認付きであるだけで、スパマーのスパミングに対するインセンティブは非常に小さなものになります。
STEP 2: 特定の文字列を含むコメントをdenyする
ときどき見かけるのは、ASCIIのみのコメントをdenyするパッチやプラグインです。私自身も以前同じ目的のプラグインを作りました(単純にアプリケーションレベル・コールバックの機能を試したかっただけですが)。
Ogawa::Buzz: Application-level Callbacks in MT3.1
しかし、個人的にはASCIIのみのコメントをdenyしたくはありません。そもそも英語のブログを書いているのならdenyすべきではありませんし、この日本語ブログに英語やポルトガル語のコメントが付くこともあります。投稿者の端末の都合も考慮したいところです。最近は非ASCII文字を混ぜてくるSpambotもあるらしいので実効性にやや疑問を感じます。
私がやっているのは、コメントスパムに現れる特定の文字列に着目して、それを含むコメントをdenyするという方法です。上記のエントリーのものを若干変更して以下のようなプラグインを使っています(下記はプラグインのコア部分だけ)。
use strict;
MT->add_callback('CommentFilter', 10, 'Reject Spam Comments', sub {
my ($eh, $app, $comment) = @_;
return ($comment->text !~ /PATTERN/i);
});
1;
「PATTERN」の部分を明示していませんが、この部分には例えばコメントスパムに含まれがちな特定のタグを書いておくと非常に効果があります。以下のエントリに具体例を含むプラグインを公開しています。
Ogawa::Buzz: Quasi-Spam Filter Plugin
STEP 3: 再構築の負荷を低減する
「TypeKey + 承認付き」にしている場合、MT 3.121までのバージョンでは承認付きコメントが投稿されたときにも再構築が発生します。したがって、STEP 2の方法でdenyできない限り、DoSとしてのコメントスパムは依然有効です。また、スパムでなかったとしても承認時点で再構築されるのが望ましいでしょう。MT 3.14では再構築が発生しませんが、「コメントが登録されたら(メールで)通知する」ように設定していても、承認付きコメントに対して通知されなくなります。
まとめると承認付きコメント投稿時の動作は、バージョンによって以下のように異なります。
| バージョン | 再構築の有無 | 通知の有無 |
|---|---|---|
| 3.121まで | あり | あり |
| 3.14 | なし | なし |
| 望ましい動作? | なし | あり |
3.14の動作でもよいのかもしれませんが、私自身は再構築「なし」、通知「あり」というのが好みなので、以下のようなパッチを当てています。このパッチはMT 3.121用です。
--- lib/MT/App/Comments.pm.bak 2004-11-24 18:43:21.000000000 +0900
+++ lib/MT/App/Comments.pm 2005-01-22 17:12:13.000000000 +0900
@@ -346,29 +346,25 @@
$blog->touch;
$blog->save;
- # Rebuild the entry synchronously so that if the user gets
- # redirected to the indiv. page it will be up-to-date.
- $app->rebuild_entry( Entry => $entry )
- or return $app->error($app->translate(
- "Rebuild failed: [_1]", $app->errstr));
- # Index rebuilds and notifications are done in the background.
- MT::Util::start_background_task(sub {
- $app->rebuild_indexes( Blog => $blog )
+ if ($comment->visible) {
+ # Rebuild the entry synchronously so that if the user gets
+ # redirected to the indiv. page it will be up-to-date.
+ $app->rebuild_entry( Entry => $entry )
or return $app->error($app->translate(
"Rebuild failed: [_1]", $app->errstr));
- my $send_notfn_email = 0;
- if (!$commenter) {
- $send_notfn_email = !$comment->visible();
- } else {
- $send_notfn_email = !$commenter_has_comment
- && !$comment->visible();
- }
- if ($blog->email_new_comments || $send_notfn_email)
- {
+ # Index rebuilds and notifications are done in the background.
+ MT::Util::start_background_task(sub {
+ $app->rebuild_indexes( Blog => $blog )
+ or return $app->error($app->translate(
+ "Rebuild failed: [_1]", $app->errstr));
+ });
+ }
+ if ($blog->email_new_comments) {
+ MT::Util::start_background_task(sub {
$app->_send_comment_notification($comment, $comment_link,
$entry, $blog);
- }
- });
+ });
+ }
}
}
MT::Util::start_background_task(
Movable Type 3.1(日本語版じゃなくて英語版)は現在beta testフェーズにあります。このバージョンで追加された機能はこの辺り(Movable Type 日本語版サイト: Movable Type 3.1の主な新機能について)で確認できますが、私にとってはアプリケーション・レベルのコールバック機能の追加が一番重要な変更で、それ以外は枝葉末節でしかありません。
ではこの機能がどのようなことに使えるかというと、例えば今流行っている「日本語を含まないコメントはSpamとしてRejectする」などの改造は、以下のようなごく簡単なプラグインとして実現できてしまいます(自分でこのプラグインを使うつもりはありませんけれど…)。このプラグインを拡張してルールを追加・変更するのも簡単でしょう。
また、Ogawa::Buzz: Trackbackの脆弱性で話題になっていたような改造も以下のようなごく簡単なプラグインとして実現できてしまいます。この種の脆弱性は時々刻々と発見され、対処する必要がある性質のものですから、プラグインの形でincrementalに対策できるメリットは大きいと思われます。
サンプルプラグインを作ってみて分かったのは、結構強力な機能だということです。もちろん、CommentFilterやTBPingThrottleFilterなどと言った有用なコールバック用のフックがアプリケーション側でちゃんと定義されていることが肝なのですが。
念のため断っておきますと、Movable Type 3.01以前のバージョンでは動作しません。まだ公開されていない3.1以上のバージョンが必須です。ベータテストに参加していない方は、3.1公開まで素直に待ちましょう。
私のメール受信環境(postfix + Courier-IMAP)では、bogofilterを使ってSpam/Ham(No-Spam)判定を行っている。「Spam」と判定されたものはIMAPのSpamフォルダに、「Ham」と判定されたものはIMAPのHamフォルダと標準の受信フォルダ(つまりはHamを複製している)に振り分けている。
普段は、POP3で標準の受信フォルダの中身のみを受信する。これで概ねハッピーなのだが、ときどきSpamを受け取ることもあるし、誤ってSpamと判定されたメールを読み落とす危険性もある。そこで、ときどきはメールサーバにIMAPで接続して、判定ミスしたメッセージに関しては、HamフォルダからSpamフォルダへ、あるいはその逆方向にメッセージを移動しておく。もちろん、該当メッセージをbogofilterの学習に使った上で、誤ってSpamと判定されたHamに関しては標準の受信フォルダにコピーしておきたいわけだ。
Maildir形式では移動されたメッセージをファイル名からごく簡単に識別することができる(STとかいうフラグがファイル名に付加される)ので、適当なスクリプトを書いてcronで定期的に呼び出してやれば、これを簡単に実現することができる。POP3が不要なのであればもう少し話は単純だが。
これはこれで使い勝手が良いのだが、最近Norton Internet Security 2004やMicrosoft Outlook 2004にもAnti-Spam機能が付いてきていて悩んでいる。どちらもかなり評判が良い。
ところが、Norton Internet Security 2004に付属してくるNorton AntiSpamのMicrosoft Outlook、OutlookExpress、Eudoraに対するプラグインモジュールはオフにできない。
Norton AntiSpam のツールバーを表示しないようにする方法
ふざけんじゃないわよって感じだが、もっと良くないことがある。このプラグインモジュールの導入がOutlookExpressではうまくいかない、少なくともうまくいかないケースがある。具体的にはOutlook Expressを起動すると、Norton AntiSpam用のフォルダを作ろうと試みて失敗し、Outlook Expressを強制終了し、また再度立ち上げる、の無限ループに陥る(ことがある)。
というわけでNorton AntiSpamには若干懐疑的。
メールサーバの管理はもう絶対にしないという意志を確固としたものにするために、この2月からすべてのメールは産総研のサービスするメールサーバから取ってくるようにしている。したがって、産総研がすごくナイスなSpamフィルタを導入してくれるというごく稀なケースを除けば、こういうActiveな方法によるSpam対策はできなくなった。
そこで、私は「PassiveなSpam対策」を考えてみたい。
PassiveなSpam対策とはどういうものかというと、例えば、メーリングリストに投稿するときのメールアドレスを「h-ogawa-nospam@aist.go.jp」のようなものにすることである。もちろん、signatureにメールアドレスを書くのはご法度だ。
Webページを公開する際にも、headerには
<link rev="made" href="mailto:h-ogawa-nospam@aist.go.jp">
と書かねばならないし、間違っても自分のメールアドレスを文書中に含めてはならない。どうしても含めたいという衝動に駆られた場合にも、Illustratorを起動してこんな(
)画像をわざわざ作った上で貼り付けるだけの時間的余裕と冷静さが要求されることになる。
問題なのは労力に対する効果の大小で、今のところ定量的な効果の報告を聞いた例はない。
もし、非常に効果があるのであれば、真っ先にやってみたいことは、h-ogawa-nospam@aist.go.jp宛てのメールを読むということである。
ちなみに私もActive Filterの設定はしている。こんだけね。
PATH="/usr/local/courier/bin:/usr/bin:/usr/local/bin"
MAILDIR="${HOME}/Maildir"
DEFAULT="${MAILDIR}/"
logfile "${MAILDIR}/log.maildrop"
xfilter "/home/sakae/bin/bogofilter -e -p -l"
if (/^X-Bogosity: Yes, tests=bogofilter/)
{
to $MAILDIR/.Spam/
}
cc "!user@aist.go.jp"