コメントスパムよけに成功したと思って安心したのもつかの間、今度はトラックバックスパムがやってくるようになりました。SEO対策などのためでしょうが、くだらない、オンラインカジノやアダルトサイトに無償協力してやる義理などありませんので、スパッと排除したいところです。
もちろん、数少ない貴重な本当のトラックバックは、変わらずに受け入れる方向で実装しなければなりません。
2005/03/24に、対策の穴をついて、再びトラックバックスパムが送られてきました。前回の対策は、URIをチェックして、mt-tb.cgiの後ろになにもついていないものはスパムという判断をしたのですが、今回は、ちゃんとお尻にそれらしい文字列をつけてきていました。
そこで、そのアクセスパターンから、新しい対策を追記します。
当サイトで実施している方法です。アクセスログを見ていると、トラックバックスパムと正規のトラックバックとの間には小さな違いがあります。それはアクセスするURIにあります。
コメントスパムは、
http://www.wildtree.jp/~araki/mt/mt-tb.cgi
へアクセスするのに対して、正規のものは
http://www.wildtree.jp/~araki/mt/mt-tb.cgi/1234
のように、トラックバック先の記事番号を伴った形でアクセスしてきます。従って、そのようでないものは排除するようにします。例によって .htaccess を修正します。
RewriteEngine on
RewriteCond %{REQUEST_URI} mt-tb\.cgi$
RewriteRule ^.*$ - [F,L]
シンプル・イズ・ベストということで、単純に書きました。将来的にこの方法をかいくぐるようなのが出てきた場合、例えば、REQUEST_METHODをチェックするとか、或いは、許可する場合のパターンを列記するとか、別の対策を講じる必要がありますが、現状はこれでゴミは排除できます。
mod_rewrite は、その凶悪さから、インストールされていない場合も多々あるでしょう。そういう環境でも、大抵、mod_setenvifは導入されていると思います。
当サイトは、記述の通り、mod_rewirte でよけていますので、SetEnvIfに関する記述は、論理的には正確なはずですが、検証していません。
狙いとしては上と同じです。URIがmt-tb.cgiで終わっていたら蹴るというものです。
SetEnvIf Request_URI "mt-tb\.cgi$" spam <FilesMatch "mt-tb\.cgi$"> <Limit POST> order allow,deny allow from all deny from env=spam </Limit> </FilesMatch>
最低限、POSTだけ、蹴ればスパムは防げますので、POSTのみにLimitしていますが、別に制限しないでもいいはずです。
66-208-225-36.ubr01a.mlvind01.mi.hfc.comcastbusiness.net - - [24/Mar/2005:02:28:20 +0900] "POST /%7Earaki/mt/mt-tb.cgi/601 HTTP/1.0" 200 79 "http://www.wildtree.jp/~araki/mt/mt-tb.cgi/601" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" (実際は一行)
これが、問題のアクセスです。見てのとおり、アクセスURIは '/%7Earaki/mt/mt-tb.cgi/601' のように一見すると正しいトラックバックのように見えます。少なくとも前回の対策ではすり抜けられてしまいます1)。
さて、ここで正常なトラックバックのアクセスとの違いを探して見ましょう。
paprika - - [24/Mar/2005:15:08:06 +0900] "POST /~araki/mt/mt-tb.cgi/1126 HTTP/1.1" 200 91 "-" "MovableType/3.151-ja" (実際は一行)
端的な違いは、HTTPのプロトコルバージョン……ではなくて、Refererの有無でしょう。他のブログからのトラックバックのパターンを見ても、正常なトラックバックが、Refererを持っていることはありません。僕の知る範囲では……ですが。ですので、この情報を使った対策を講じようと思います。
RewriteCond %{REQUEST_URI} mt-tb\.cgi/
RewriteCond %{HTTP_REFERER} !^$
RewriteRule ^.*$ - [F,L]
これを先ほどの対策の下に追記してやれば再び穴をふさげます。
SetEnvIfの場合には、
SetEnvIf Referer !^$ spam
を、Limitの前に追加してやればいいと思います。Refererがあるものか、mt-tb\.cgi$ へのリクエストのものは、mt-tb\.cgiへのアクセスを拒否するというものですので、うまく機能するでしょう2)。
今回の対策は、間抜けなスパム業者が、何でもかんでもつければいいだろう的に、Refererを設定してきたために可能となったのですが、いずれ、ここも空にするようなケースも考えられます。その場合にはまた新たな対策が必要となるでしょう。しかしとりあえず、この状態で、ブロックし続けられることを願ってやみません。
MovableTypeに関してへ戻る。