真説・対spam最終兵器 CGIリネーム烈伝

シェアする

意味のない前書き

「みんな、聞いてくれ。実は……いままで紹介してきたspam対策は、まだ不完全だったんだよ!」

ΩΩΩナンダッテー(投げやり)(ぷー ←やり投げ)

スパムの無い管理画面

前回、spam対策としてIPフィルタを導入後、海外からのspamがMTの「迷惑コメント」「迷惑トラックバック」に登録されることが全く無くなりました。

──が、依然として、コメントCGIに対してspam業者タソからの熱烈なるラブコール毎日毎日……。どうやら、コメントCGIをリネームしても、スパマは数日で発見するようです。ファーックス! Fax電話!

できれば、コメントCGIにアクセスすること自体をご遠慮願いたい。アクセスログを見てげんなりすることを無くしたい。

──そこで、定期的にコメントCGIをリネームする方法を紹介します。

CGIリネーム!

たねちゃんズ12: CGIリネーム完全版に詳しい設置方法が書いてあるので、上から順に設定するだけです。これで、記事を新規投稿するたびにコメントCGIのURLが変更されます。

上記の方法を実行すると、トラックバックURLは下記のようになります。

http://example.com/mt/1234567890123tb/123

asiamoth流カスタマイズ

上記の記事ではコメントCGIのURLを<?php readfile (""); ?>で読み込むようになっています。

自分の場合はPerl版ダイナミック・パブリッシングを利用しているので、記事の追加毎に、アクセスがあったページが自動更新されます。なので、個別エントリィと各種コメントシステムのテンプレートにある

<MTEntryTrackbackLink>

の部分を、

<MTBlogURL>tb/<MTEntries lastn="1"><MTArchiveDate format="%w%S%y%M%m%H%d"></MTEntries>/<MTEntryTrackbackID>

と変更するだけにしました。コメント・トラックバックURLはこんな感じ。

http://example.com/mt/cm/1234567890123/123

http://example.com/mt/tb/1234567890123/456

“.htaccess”に書くRewriteRuleは下記の通り。

RewriteEngine on
<MTEntries lastn="1">
RewriteRule ^cm/<MTArchiveDate format="%w%S%y%M%m%H%d">/(.*)$ <MTCommentScript>$1 [L]
RewriteRule ^tb/<MTArchiveDate format="%w%S%y%M%m%H%d">/(.*)$ <MTTrackbackScript>/$1 [L]
</MTEntries>

2006-12-04T11:21:21+09:00 追記

すみません! 一部修正しました。

修正前に <MTTrackbackScript>$1 となっていたところは <MTTrackbackScript>/$1 にしないと動きません……(/ が抜けていた)。

こうしておけば、“robots.txt”へ次のように書くと──

User-Agent: *
Disallow: /mt/cm/
Disallow: /mt/tb/

──検索ロボットがコメント投稿ページに行かないようになります(──だといいな)。

ちなみに、トラックバックスパム予防プラグイン for MovableType/楽でURLをエンティティってます。念のため。

CRONを使う方法

「CGIリネーム完全版」コメント欄のやり取りで、CRONによるリネーム方法が書いてありましたが、肝心のスクリプトファイルがリンク切れになっていました(2006-11-03T19:21:40+09:00)。残念。

ref.: Cronによる定期的なCGIリネームで抜本的スパム対策 (Kazuの挑戦日記)

──ところで、ここまでするのなら<MTCommentScript>タグと<MTEntryTrackbackLink>タグが呼び出されるときに《何か》するプラグインがあってもよさげ。将来、テンプレートを変更することを考えると「プラグイン一つ入れるだけで適用される」というのは、かなり魅力的なのですが……。

sand-trap.phpに注意!

今ごろ気がついて申し訳ないのですが……。リネーム前のコメントCGIにアクセスがあった場合に真・対spam最終兵器『IPスパムフィルタ』で紹介してように“sand-trap.php”へ飛ばすようにしていると、検索ロボットがいつまでもリネーム前のURLにアクセスしにいく──かもしれません。

  1. 検索ロボットが“mt-comments.cgi”に投稿されたコメントを収集、キャッシュ
  2. コメントCGIをリネーム
  3. 検索ロボットが“mt-comments.cgi”に投稿されたコメントのURLにアクセス
  4. 検索ロボットは“sant-trap.php”をコメント投稿画面と認識し、情報を収集、キャッシュ
  5. 以後、繰り返し……(負の連鎖)

──ガクブル!!

ということで、“sand-trap.php”のヘッダに

<meta name="ROBOTS" content="NOINDEX, NOFOLLOW" />

とでも書いておきましょう。

CGIにアクセス集中

また、少なくともGoogle botはワイルドカードを理解する仕様なので(Google ウェブマスター ツール – ウェブマスター ツールで確認)、“robots.txt”に下記を記述しておくのが吉。

QUser-agent: *
Disallow: /*.cgi*

検索ロボットがアリエナイくらいCGIにアクセスすることがありますからね……。

ref.: 404 Blog Not Found:クローラにしかとシカトしてもらう50の方法

spam対策以前の問題

あと、ネットからいろんなCGIを落としてきて遊んでいるのですが、放置している物も多数。──知らぬ間にspamコメントの温床になっていました。お、怖ろしい……。

飽きた物はディレクトリごと削除、またはパーミッションを変更して外部からアクセス不可に。──うーん、見落としが無いかな。

あと、レンタルサーバを借りている人は、パーミッションの設定で「グループ」は常に“0”にしておいた方がベスト。“644”なら“604”、“755”なら“705”ですね。

ref.: レンタルサーバにおけるセキュリティ — 適切なパーミッション設定について

「対SPAM最終兵器」のロードマップ

おそらく、これからもspamとの戦いは続くことでしょう。ここに、今後のspam対策のロードマップを記します。

──嘘を嘘と見抜けない人のために。

http://d.hatena.ne.jp/keyword/%A5%B5%A5%E0%A5%E9%A5%A4%A5%B9%A5%D4%A5%EA%A5%C3%A5%C4

コメント

  1. たねちゃん より:

    CGIリネームネタを紹介して頂き、本当にありがとうございます!
    でもこのCGIリネームって元をたどって行くと、ここがネタ元(笑)
    http://asiamoth.com/mt/archives/2006-05/06_1758.php
    この記事についてOgawaさんが記事を書いて
    http://as-is.net/blog/archives/001131.html
    私がこの2つをジィ…と見てて思い付いたのが
    http://blog.tanechan.jp/2006/05/30/000000.php
    こぉなって、現在の完全版が出来た訳ですから!
    巡り巡ってまたこちらに戻ってきた訳ですよ(笑)
    でも、この完全版でも実は1つだけ不満な点があったのですが
    それを解決出来そうな方法を書いて頂いたので、今回はそれ
    をこっそりと採用させて頂きますね!

  2. asiamoth より:

    どうもです! この素晴らしい方法が広まるといいですね。
    ネタ元がこのブログ、というのは実は気がついてましたが、ちょっと恥ずかしかったので触れずにいました。──いま見てみると、何とも原始的な方法ですからね。そりゃOgawaさんも見るに見兼ねて記事書くよ、という感じ(笑)。
    自分としては、リネーム前のURLにアクセスしに来るボット(一日20件程度)をどう料理するか──というのが悩みどころです。──スルーするのが一番かな?

  3. たねちゃん より:

    返事が遅れて申し訳ございません( つД`)
    ちとウチの事情が事情だけに大変で返事出来ませんでしたorz
    リネーム前のURLにアクセスしてくるボットですか?スパムじゃなく
    ボットなら、放っとけば問題無いかと。404エラーを出せてるなら
    いずれ拾わなくなると思いますし。
    それと前のコメントを書いた時に、こちらのブログでエラーが出た
    けど、何故か書き込みは出来てた…それとトラックバックを送ると
    受け取ってくれませんでした( つД`)