数週間前から自宅のサーバがフリーズすることが多くなってきた。
アクセスが集中すると処理しきれなくなってハングアップしてしまうみたい。
ルータから入った要求を、一旦プロクシサーバを通してからwebサーバに転送する構成から、1台で総て処理する構成に戻したんだけど、このプロクシの設定が間違っていて、SPAM含めてほとんどのコメントを弾いていたみたい（なぜかコメントできるひともいた）。
そして正しい設定に戻ったことで、今まで処理されてなかったスパムが完璧（笑）に処理されるようになり、そのガンガン連投で急にフリーズするようになったみたい。
MTのスパム対策は良く考えられていて、何より管理者が規制の緩急を決められる自由度がある。普通に設定すればスパムが表面上に出て来ることはない(ごみ箱の中にすごい勢いで溜まっていくけど)。
しかし今回は、サーバの処理を軽くすることが目的なので、スパムがどうかを餞別するロジックを入れるのではなく、CGIプログラムが走る前にサーバ側でスパムを弾くような設定にする方法を考える。
(※スパムコメントに限っては、「URLが入っていたら認証するまで表示しない」という処理を入れるだけで充分だと思う(スパムは自分に誘導するために必ずURL入れるけど、そもそも宣伝目的意外でコメントにURL入れるヒトは少ないから)
－－－
まず、スパムシステムの特徴を理解するために、エントリー記事ソース内に記述されているコメントを受けつけるためのCGIへのURLを変更してみた。
一番知りたかったのは、HTML上のソースを読んでスパムしてくるか知りたかったから。
隠しフォームに値が入っていないとコメントできないという処理を入れたこともあったんだけど、効果が無かった経験あり。このことからHTMLソースを解析する能力があることが推測できる。
はたして、変更して10分で、新しいURLに対してスパム攻撃が始まった。
・・・すげぇ。スパムすげーよ！
MovableType は HTML を出力して再構築するのが特長なので、10分という時間はそのまま再構築にかかった時間、リアルタイムでコメントCGIのURL変更に対応したことになる。HTMLを解析することが実証された。
ログを確認しながら、大きく3酒類のパターンに分けた。
(1)ダイレクトにコメントCGIを叩く。リファラーを擬装している。
(2)HTMLのみを一回読みこんで、その数秒後にコメントCGIを叩く処理。
(3)HTMLのみを読みこんでソースを解析。確実にコメントを入れるようにフレキシブルに高度な処理。数パターン処理を行うものもある。
↓2のパターン
189.19.3.230 – – [14/Oct/2007:18:15:16 +0900] “GET /archives/2006/07/aaa.html HTTP/1.0” 200 57881 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)” -pct.
189.19.3.230 – – [14/Oct/2007:18:15:40 +0900] “POST /mt/mt-comments.cgi HTTP/1.0” 404 1259 “http://hogehoge.jp/archives/2006/07/aaa.html” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)” -pct.
↓3のパターン
68.39.146.121 – – [14/Oct/2007:19:41:26 +0900] “GET /archives/2005/02/abc.html HTTP/1.0” 200 62491 “http://hogehoge.jp/archives/2005/02/abc.html” “Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)” -pct.
68.39.146.121 – – [14/Oct/2007:19:41:34 +0900] “POST /mt/mt-comments.cgi HTTP/1.0” 404 1259 “http://hogehoge.jp/archives/2005/02/abc.html” “Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)” -pct.
68.39.146.121 – – [14/Oct/2007:19:41:36 +0900] “POST /http://hogehoge.jp/mt/mt-comments.cgi HTTP/1.0” 404 1259 “http://hogehoge.jp/archives/2005/02/abc.html” “Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)” -pct.
—————————————————————-
218.58.136.4 – – [14/Oct/2007:15:25:01 +0900] “GET /archives/2005/02/abc.html HTTP/1.0” 200 57036 “http://hogehoge.jp/archives/2005/02/abc.html” “Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0; .NET CLR 1.0.2914)” -pct.
218.58.136.4 – – [14/Oct/2007:15:25:10 +0900] “POST /mt/mt-comments.cgi HTTP/1.0” 404 1259 “http://hogehoge.jp/archives/2005/02/abc.html” “Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0; .NET CLR 1.0.2914)” -pct.
218.58.136.4 – – [14/Oct/2007:15:25:20 +0900] “POST /http://hogehoge.jp/mt/mt-comments.cgi HTTP/1.0” 404 1259 “http://hogehoge.jp/archives/2005/02/abc.html” “Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0; .NET CLR 1.0.2914)” -pct.
とりあえず面倒くさくなって、コメントCGIをサーバ上から削除すると、404エラーがログに残るので、404を出したIPが検索ロボットのものか逆引きしながら地道に deny として登録。
でも今後の対策として、要点をまとめとく。
■スパムはHTMLを解析するものもあるので、HTMLを見れば分かるような対策はそもそも無意味。
■単発のスパムが新規投稿された記事につくことも希にあるが、スパムの基本は過去に投稿された記事に対して行なわれる。(新着記事はコメント自由、過去記事は駄目、という設定で今動いてるけど、スパムが入らない)。だから放っておくと同じ記事にばかり付く。
心理的に解析すると、新規登校はブログオーナーに発見されて削除される・記事をひっこめられる可能性が高いが、過去記事（できればSEO効果の高い記事ページ）の方が安定していて残りやすいからか？
■ログを見て気づいたけど、結局スパムは独自に持つデータベースに登録された「記事URL」をなんらかの型で処理して行なわれる。禁止ワード/禁止IPといった方法で規制するより、記事のURLを変更するか、その記事をコメント不可設定にしたほうが苦労しない。早い。
ちなみに、１回目の到来を撃退すると、連続で来ない。ログの残り方を気にするから？
■登録されちゃった「記事URL」＝リファラー、なので、業者を特定するためにログ検索する時はIPよりリファラーで探した方が早い
↓
スパム対策として新しく考えるとすると、
■リファラーではじく(笑)
■規定した画像がGETされていないIPのコメントをはじく。(HTMLだけGETしても駄目。画像タグは最初からソース上に普通にあるので、どの画像をGETすればいいのかロボットには分からない)
■コメントCGIの場所をBASIC認証内に
■コメントCGIの場所を別サーバに。怪しいIPを自動で片っ端から弾く設定にする。間違って一般のIPが登録されても「読むことはできるが書くことはできない」だけになるので、書けない人はホワイトリストに登録させる。
■あと、上に貼りつけたログを見ても分るけど、メジャーブラウザに擬装してるわけなんだけど、mod_gzip、mod_deflate といったhttp圧縮（WEB間圧縮）の比率(行の最期の pct. )圧縮結果値が空白になってるので、これを比較することでなんとかできないのかなぁ。圧縮結果を取得する方法があればなんだけど。
さて、次はトラックバックスパム対策だ！
コメント