MovableTypeと掲示板を設置していたら、毛唐から異常なほどのspamが毎日万単位で送信され、「サーバーが過負荷だからcgiを停止しました」と連絡が来ました。
そもそも、サーバーが過負荷になったのはspamテロリストどもの絨毯爆撃をくらったからであって、責任は100%、紅毛人スパマーにあります。スクリプトの更新やNG語の追加などできる限りのことはやってきましたが、それを上回る物量攻撃によって過負荷になったのです。
絨毯爆撃をくらったら、少なくともサーバーにアクセスはあります。CGIでスパム排除するとしても、CGIは動いてしまいます。
そこで質問です。何とかspam攻撃を有効に排除する方法はないのでしょうか。
.htacceessでIPで弾くのも、常時変化し続ける毛唐攻撃者のIPには対処できません。
できれば米軍には、スパマーをアルカイダ認定して空爆していただきたいところですが、スパムをCGIにたどり着かせないための専守防衛策を教えてください。
No.1
2
0
10pt
http://q.hatena.ne.jp/1164440889
URLはダミーです。
情報戦の段階で負けています。
敵に察知されて絨毯爆撃をくらうようでは
何を言っても負け犬の遠吠え。
そういうあなたにはCGIのファイル名の書き換えをすすめます。
BBSやMovableTypeであると敵に察知されないように書き換えてください。敵はプログラムですから、決まった事以外はできません。当然ですが、CGI内部でファイル名を使っているところがあればそこも書き換えてくださいね。
健闘を祈る！
No.2
160
3pt
毛唐からということで、かつ、日本語のサイトであれば、一番単純なのはIPアドレスで日本以外からのアクセス制限をかけるというのはどうですか？
http://mikeneko.creator.club.ne.jp/~lab/web/htaccess/access.html
日本のIP
台湾・香港からの有意義なアクセスも多いので、排除できません。
というか、こういう鎖国的技法は使いたくありません。
No.3
8810
3pt
海外からのアクセスを全部はじくのなら、
.htacceessを次のように設定すればよいかと。
order deny,allow
deny from all
allow from .jp
参考 http://q.hatena.ne.jp/1161772210
コメント欄で指摘されているようにパフォーマンスが落ちる可能性があります。
同上
No.4
160
3pt
もうひとつ思いつきました。
URLはダミーです。
こちらはポイント必要なしで。。
もし、SPAMが英語圏からのものであれば、恐らく２バイト文字は使用しないと思うので以下のような正規表現でマッチしなければNGというような内容をスクリプト内にはさめば、コメントは蹴れるかもしれません。
トラックバックは機能がよくわかってないので、どうかわかりませんが。。
/[^0-9a-zA-Z!"#\$%&\'\(\)=\-~\^|\\\`@{\[\+;\*:}\]<,>\.\?\/_\n\r\t\s]/
そのように「正規表現」で判断している時点で、CGIが稼働しているわけです。もちろんページ再構築しないだけマシではありますが。
ちなみに、MTのスパム判定ルーチンは現在極めて優秀で、ほとんどの迷惑コメント・トラックバックを弾いてくれています。弾いてはいるけれども、そもそもそういうspamが一日に何万とやってくること自体、サーバー負荷の原因となっています。
No.6
1844155
20pt
サービスを停止されるのが一番の痛手と
思われます。
SPAMの接続を禁止しない限りサーバリソースは
使われるので対策はＩＰリソース規制しかない。
鎖国的な方法であれサービスを守るのであれば
該当ＩＰからの接続拒否しか対策はないと思います。
接続した後では相手に情報を与えることになり対策
されるだけなので、接続された段階で負けです。
専守防衛には、接続させない以外手はない。
１．特定ＩＰからのＣＧＩで一定時間に限度超えた場合又は、
無効な投稿をした場合該当ＩＰからの投稿を
自動的に一定期間自動規制をようなCGIを作成
・.htaccess又は、IPレベルでの自動接続禁止
２．上記方法で問題のあるＩＰからの接続があった場合
処理の速度を極端に遅くする。
（早く処理できる＝相手の思う壺）
・処理優先度下げ負荷を下げ、最終的にエラーで
終わる。
３．ＣＧＩは変更しないで定期的にログを解析
して不正なアクセスサービスを動的に禁止
・.htaccess又は、IPレベルでの自動接続禁止
４．ＣＧＩの拡張子を".cgi"以外に取り合えず変える
５．正規のＣＧＩを呼び出し元(ＨＴＭＬ等)では、
CGIのパラメータ文字列をサーバ側で管理して
一定時間内のみ該当文字列での投稿を１回だけ
認めるようにする。 同時に１．～４．の対策
（データは全てＰＯＳＴで処理をする）
６．普通使われない方法で端末の認証をする。
例えば端末に表示されるHTMLに
画像(gif等)がある場合通常ファイル名のみが
指定されているがサーバで動的にパラメータを
生成することにより端末がそのＨＴＭＬを
表示した場合パラメータを指定してサーバを
呼び出すことになる。
このときのパラメータによりサーバの投稿
可能条件とする。
aaaa.gif?1234455
（４．の応用パターン）
===============================================
鎖国的な方法が使えないというのは、実は、世界中にまともな利用者がいるという問題があるからなのです。
イスパニヤ人が全員侵略者と判断できるなら鎖国に踏み切ってもいいのでしょうが、そうでないならユーザーを弾くわけにもいかない……。
ただ、１～４の対策は有効そうな気がします。
問題は、自分でスクリプトを組めるわけではないということです。
No.7
161
20pt
私もコメント・トラックバックスパムに悩まされて、以下のmagicvox.netにて
紹介されていたCAPTCHAを用いた対策の導入を検討しています。ご参考まで♪
ひみこーどタイプの対策ですね。
これが汎用で簡単に使えるとなると、応用範囲は広いと思います。
もっとも、サーバー負荷そのものは完全に解消できないわけですけど。
No.8
365
74pt
WebサーバがApacheでしたら、CGI起動のプロセスに至らないようにするためには「.htaccess」での防御が主になると思いますが、「.htaccess」で弾くことが出来る条件は「IPアドレス」だけではありません。
ご自身のサイトのApacheアクセスログを閲覧することは可能ですか？
まずは敵を知ることから始めなくてはならないと思います。
Apacheで一般的なcombinedログ形式でしたら…
…が記録されていることと思います。
万単位で押し寄せて来るような迷惑行為の場合は、殆どの場合、自動化するためのツールを用いています。アクセスログからそれらの特徴を見抜くことで、完全ではありませんが被害を減らすことは可能だと思います。
例えば、自動投稿ツールのバグなのか、ブラウザ名として「User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)」というすっとぼけた痕跡を残していくマヌケな仕様のツールによるアクセスも数多く（私のところでも1日に数百アクセス）あります。まともなブラウザなら「User-Agent」なんていう文字列はブラウザ名に含まれません。
当然ながら、そんな奴らは…
SetEnvIf User-Agent "User-Agent" spammer
Order deny,allow
deny from env=spammer
…で追い出してしまえば良いわけです。
また、トラックバックの場合、真っ当なトラックバックであればブラウザを名乗るようなアクセスはあり得ません。そういった迷惑ツールを「運用していく中でアクセスログから見出して追記」していくだけで、相当な数のトラックバックスパムをCGI起動プロセスに至る前に排除することが出来ます。
（例：mt-tb.cgiがトラックバック受信用のCGIだとしたとき）
<Files mt-tb.cgi>
<limit GET POST>
SetEnvIf User-Agent "Mozilla/4\.0 \(compatible; MSIE 6\.0; Windows NT 5\.1\)" tb_spam
SetEnvIf User-Agent "Mozilla/4\.0 \(compatible; MSIE 5\.5; Windows NT\)" tb_spam
SetEnvIf User-Agent "Mozilla/5\.0 compatible /1\.00 \(i686-pc-linux\)" tb_spam
SetEnvIf User-Agent "Microsoft URL Control - 6\.00\.8862" tb_spam
Order Allow,Deny
Allow from all
Deny from env=tb_spam
</limit>
</Files>
（※参考 http://gigazine.net/index.php?/news/comments/20060901_trackbacks...）
コンテンツが日本語メインでしたら、日本語を表示できないブラウザにはお引き取り願うという方法もアリだと思います。その際には、エラーメッセージで「日本語を表示できる環境にしてからアクセスしてね」というのを表示してあげれば、一応、来訪者側にも対処の余地があるってことで。迷惑投稿ツールは多分、画像で作成されているエラーメッセージの解釈はしないでしょう。
SetEnvIf Accept-Language "ja" Japanese_OK
Order Deny,Allow
Deny from all
Allow from env=Japanese_OK
ErrorDocument 403 /messages/HowToPost.gif #←ブラウザの言語設定の方法を説明した画像ファイル
ちなみに、SetEnvIfで弾いたアクセスが一般のアクセスログに混ざると腹立たしいので、
私は別ログに記録する形でログを分離させています。
さらに（極論ですが）、ユーザー名とパスワードを誰でも分かる場所に「公然と画像で掲示」しておいて、投稿用のスクリプトにBASIC認証をかけてしまうという方法を用いるとか。（BASIC認証はファイル単体にもかけられます。）
<Files bbspost.cgi>
<limit GET POST>
AuthType Basic
AuthName "User=hoge Password=fuga" #←ここにも認証情報を宣言しちゃう…(^_^;)
AuthUserFile /path/to/.htpasswd # ←もちろん、あらかじめ作成しておきます。
AuthGroupFile /dev/null
order deny,allow
require valid-user
</limit>
</Files>
他にも正規表現を駆使したりとか、色々なアイデアがありそうですが…。
私は頭があまり良くないせいか思い付きません…(^_^;)
User-Agent!!!!!!!!!!!!!!!!
これは、連中が気づかない間は有力な対策になりそうですね。
別サイト（spam対策されていると思われるサーバー）の直近のログを見たところ、確かにUser-Agentが含まれているようです。それにしても数百とか数千とか連続で送ってきてアホか南蛮人は。
256
233
1
2
ファイル名書き換えは済んでいます。
そもそもamezo.cgiだったりします。
敵はファイル名検出プログラムを持っています。