関連過去記事
- MovableTypeブログへのスパムコメント・トラックバック対策
- MT4のスパム対策、ほぼ落ち着いてきた。
- MTのSpamLookup - Keyword Filterプラグインですり抜けてしまうスパムたちへの対策
- MovableTypeのスパム対策でcgiリネーム
- MobableTypeのスパム対策:yournet.ne.jpに苦戦中
の続編。
そろそろ「これが最後の対策・・・!」と言いたい所。
今回の対策:リクエストプロトコル HTTP1.0を遮断
最近、Apacheの生ログとニラメッコな日が続いていましたが、ここに来てようやくスパムコメントにある共通点がある事を発見。
- MovableTypeへのスパムコメントの共通点
- OSがXP(確率99%)
- ブラウザがIE6(確率99%)
- リクエストプロトコルがHTTP1.0(確率99%)
プロトコルからの判別でほぼスパムが判別出来そうなこと発見。
先日かなり先走って、XP+IE6を悪者にした文章をアップして大いに反省しました( ̄▽ ̄;)
イマドキのブラウザならHTTP1.1で通信できますんで、
.htaccessでmt-comments.cgiをHTTP1.0から遮断してやれば良いのでは?
と思い立った次第。
(サイト全体でHTTP1.0を遮断すると、Googleさんなどのクローラーまで遮断しちゃう)
<Files"mt-comments.cgi">
#注:現在コメントCGIはリネームしてます
SetEnvIf Request_Protocol "^HTTP/1\.0" http_10
#▲通信プロトコル Http1.0禁止に(実際は下部のdenyで禁止)
order allow,deny
allow from .bbtec.net
allow from .jp
#▲一般的な国内プロバイダ許可
allow from 2iij.net
allow from mopera.net
allow from panasonic.com
allow from ibm.com
allow from as13448.com
allow from necel.com
allow from zero-isp.net
allow from bitcat.net
allow from ntt.com
#▲赤い部分は企業や特殊なプロバイダ。無くてもOK
deny from env=http_10
</Files>
▲こんなカンジにしてみた。
deny allowの解釈を良く解っていないので、このままでは穴がある気がしますが、一応40時間ほどスパムなし。
この設定で何時まで持つか・・・!?
2010/09/23追記
すげー参考になるページ発見
Apacheのアクセス制御をちゃんと理解する。 - こせきの技術日記
deny allowの順序の解説がスゲー良い。
スパム対策「CGIリネーム」その後
コメントCGI、トラックバックCGIのリネーム、変更当初はもの凄い効果を発揮していましたが、やはり1週間ほどでチラホラとスパムは集まりだし、3週間経った頃から複数のIPから20~60件/日程度の攻撃が来るようになりました。
やっぱJavascriptなどでコメントCGIのファイル名を隠しておかないと、2~3週間で元の状態に逆戻りですね('Α`)
と言う事で、最近再びスパムちゃんぷるーDNSBLやmt-ban-ascii.pl などのスパムプラグインとの併用を開始しました。
「スパム万来状態」でMTでスパムちゃんぷるーDNSBLを利用すると、サーバーのCPU使用率がハンパ無い
以前スパムちゃんぷるを利用した時には、業者にロックオンされたURLは全てコメント・トラックバック禁止に設定していました。しかし今回は全てのページでコメントオープンにして稼動させると。。。。
▲CPU使用時間が約2倍に跳ね上がり('Α`)
土日CPU稼働時間:平均2時間30分 → 4時間以上に
平日CPU稼働時間:平均1時間30分 → 2時間半以上に
コメントのスパム処理だけで、CPUが1~2時間も無駄に作動しちゃってる。
導入後、503エラーは全く出ていないので、Livedoorのデータベースからの応答を待っているだけの非常に軽い負荷なんだろうけど、これは気持ち悪い。
今後の運用で胆に銘じること
スパム対策は、
- cgiパスを見破られないように
- スパムはできるだけ.htaccessで弾く
- 残った「ターゲットにされたURL」はコメント・トラバ禁止に
- 「1.」「2.」「3.」の状態でスパムちゃんぷるを稼動
(既にターゲットにされた状態で「スパムちゃんぷる」を利用すると負荷が大きい。) - あとはmt-ban-ascii.pl が稼動している程度でOK
上記運用がベストかも。
ターゲットにされてから対策を練るより、ターゲットにされない事が重要だと改めて痛感。
おまけ
MTのコメント受付のCGI化。これからやるのでメモ。
以下はWingMemo: MT4を運営開始する前に設定しておくと良い9つの項目:からの転載です。
mt.jsに以下を追加
インデックステンプレートのmt.jsの最後に以下の記述を追加。
function mtCm() {
document.comments_form.action ="<$MTCGIPath$><$MTCommentScript$>";
}
コメント入力フォームの修正
モジュールテンプレートの「コメント入力フォーム」のactionの中の青字の部分を削除し、</form>の下に赤字の部分を追加します。
<form method="post" action="<$MTCGIPath$><$MTCommentScript$>"name="comments_form" id="comments-form" onsubmit="if(this.bakecookie.checked) rememberMe(this)">
↓
<form method="post" action="" name="comments_form"id="comments-form" onsubmit="if (this.bakecookie.checked)rememberMe(this)">
</form>
<scripttype="text/javascript">mtCm();</script>
</div>
*これはOpen MagicVoxのJavaScriptを使ってスパムによるCGIの過負荷を防ぐを参考にアレンジさせていただいたものです。参考先ではコメントCGIを分けてソースに記入していますが、ここではコメントCGIはmt.jsの中に隠してしまって、ソースの中からは完全に除去する方法をとっています。
コメント詳細の修正
MT4デフォルトではコメンターがURLを入れていた場合、コメントCGIを介して相手サイトにリダイレクトする仕様になっています。なのでここをそのままにしておくと、リダイレクトURLからコメントCGIがバレてしまうので、以下の赤字の部分を追記してコメントCGIからリダイレクトされないようにしておきます。
<$MTCommentAuthorLink default_name="Anonymous"show_email="0" no_redirect="1"$>
私の経験からでは効果は抜群です。MT4になってMT-Keystrokesが使えなくなった人にも差し当たりの代わりとして使えるかと。
転載終わり
ああ、コメント内のURL入力欄のリダイレクトからもCGIの存在がバレちゃうのか('Α`)
コレも治しておかないとダメなのか、、、