ホーム > アーカイブ > 2009年3月のアーカイブ

2009年3月のアーカイブ

ホワイトリストでスパム投稿対策

[`evernote` not found]
[`grow` not found]
[`livedoor` not found]
[`yahoo` not found]
Delicious にシェア
このエントリーをはてなブックマークに追加

スパム投稿ロボットが、フォームページに付随するファイル
(画像やJavascriptなど)をまったく収集してないことをヒントに
ホワイトリストによるスパム投稿対策を考えてみました。

要点は、まずフォームのページにIMGタグで
ダミーファイルのリクエスト埋め込んでおきます。
このダミーファイルでは
アクセス元のIPやリクエストヘッダなどをログに記録します。

普通のブラウザでアクセスしていればログに残りますが
スパム投稿ロボットは付随するファイルをリクエストしてこないので
当然ログに残りません。
投稿があった時このログと照合して投稿の可否を決めます。

これななら COOKIE も SESSION も JavaScript も
無関係なので携帯端末にも応用できます。
ただし、記録したリクエストの有効期限とか
携帯端末IDの利用とかいくつか工夫がいりそうです。

久しぶりに書きたいテーマに出会いました。
仕様をまとめたらPHPのコードにしてみようかな。
まず携帯の仕様をおさらいせねば。

スパム投稿の発信元を追跡してみる

[`evernote` not found]
[`grow` not found]
[`livedoor` not found]
[`yahoo` not found]
Delicious にシェア
このエントリーをはてなブックマークに追加

hidden + IP でスパム投稿対策 でフォームに埋めたIPは
ホントの発信元ではなくほとんどが接続を中継してる PROXYサーバーのIPです。

少しでも発信元に近づくためリクエストヘッダをログにとってみると
次のようなPROXYサーバーらしき痕跡を見つけられます。

Via: 1.1 192.168.19.1 (Mikrotik HttpProxy), 1.1 121.7.231.132 (Mikrotik HttpProxy)',
X-Forwarded-For: 72.36.182.226, 125.160.91.245, 121.7.231.132
X-Proxy-ID: 2035636757, 1382434604

標準のアクセスログにはこうした情報まで記録されないので
PHPの apache_request_headers() 関数で
リクエストヘッダを独自のログにとってみました。

このうち X-Forwarded-For はPROXYサーバーが
付加するクライアントのIPなので、より発信元に近いIPってことになります。

1件だけ眺めててもピンときませんが
フォームに埋め込んだIPが同じリクエストを
ひとつのグループとしてみると、いくつかの共通したIPが見えてきます。

72.232.10.98
72.232.81.78
72.232.220.34
72.36.182.226

whois で調べてみると、
どれも同じ US の会社が管理するIPだとわかります。
この会社はホスティングサービスなどをやってる普通の会社なので
ココのユーザーがスパムを発信してる可能性が高いです。
ただし上のIPもPROXYの可能性もあるので
断定はできませんが、かなり発信元に近づいたと思います。

ここまできたら、この会社にスパム投稿の発信元にされている旨を
ログなどの蓄積した情報を添えて相談すると。
しっかりログをとっていれば、
ネットワークの専門家でなくてもこのくらいまでの追跡は可能です。

hidden + IP でスパム投稿対策

[`evernote` not found]
[`grow` not found]
[`livedoor` not found]
[`yahoo` not found]
Delicious にシェア
このエントリーをはてなブックマークに追加

スパム投稿だけを別ログに取っていたら共通点が見えてきました。
しかも2パターンに絞られます。これは、うちに来てる
AHOな自動投稿プログラムは2種類しかないってことです。

スパム投稿パターン1 AHoo
特定のIPから、不定期に、本文が異なる内容を投稿。
フォームは集計以前に得たようで、リクエストされた痕跡は無い。
●クッキー無し
●UAがどれも同じ
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 4.3 (build 01218))
●$_POSTのうち、パスワードとワンタイムチケットはまったく同じ。
 その他の内容はバラバラ。

スパム投稿パターン1’ AHoo’
不特定のIPからの投稿である以外は、スパム投稿パターン1と同じ。
パスワードとワンタイムチケットがスパム投稿パターンAと同じなので
ネタ元が同じ。

スパム投稿パターン2  AHoo+C
先ずフォームのリクエストがあって、その2、3秒後に初投稿。
その後短い間隔(5~20秒おき)で、国が異なる別ホストより、
POSTとCOOKIEが全て同じ内容の投稿が1~3回程度続く。
フォームを収集したIPと初投稿のIPは同じ。
●クッキー有り
●UAがまたく同じ
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

【考え中】
AHoo と AHoo’ は、
一度収集したフォームをず~っと使いまわしのワンパターン。
hidden でフォームに埋め込んだ値まで一緒なので
この値の整合性をチェックすれば完全にハネることが出来ます。
AHoo の方はIPチェックで完全にシャットアウトでもいいくらい。

これに比べると AHoo+C は、
フォームを収集しながらリアルタイムで投稿してきます。
クッキーも備えブラウザに見せかけている巧妙なヤツです。
2度目以降投稿については、AHoo同様
hidden でフォームに埋め込んだ値の整合性をチェックすれば
完全にハネることができます。

【対策】
フォームの出力の際、
リモートホストのIPアドレス を hidden で埋め込んでおく。
投稿された際、
$_POSTのIPと$_SERVER[‘REMOTE_ADDR’]を比較。
一致しなければスパムボットと判定。

ただし、IPアドレスをそのまま埋めると、
プログラムでIPの書き換えを可能にしてしまうので
複合可能な方法で暗号化した値をにするなどの工夫が必要です。
あわせて、似たようなダミーの値をフォームに複数個
埋めておけば、プログラムでの解析をさらに困難にできます。
これなら COOKIE も SESSION も関係なくひろ~く応用できます。
もちろん、AHoo+C の初投稿はスルーなので
IPや投稿内容をチェックしてハネるあわせ技は必須です。

hidden で埋め込む値を IPアドレス にしたのは、
収集したフォームこそが投稿業者の資本であり、
フォーム収集元が明らかになることを一番嫌うと考えたからです。

フォーム収集時のIPでなければ投稿できないけど、
そのIPで投稿すると肝心なフォーム収集元が絞り込まれる。
収集しても使えないフォーム。
業者にしてみればホント嫌なことでしょう。
これがこの対策の一番の狙い。
スパムをハネるだけでなく投稿そのものを減らす対策になります。

この対策を施している旨をサイトに書いとくとさらにいいかも。

ワンタイムチケットでスパム投稿対策

[`evernote` not found]
[`grow` not found]
[`livedoor` not found]
[`yahoo` not found]
Delicious にシェア
このエントリーをはてなブックマークに追加

JavaScript でスパム投稿対策に「100%排除」って書いたけど
サーバー側の対策との合わせ技で100%達成してるので
そのスパム投稿対策も紹介しておきます。

1.ワンタイムチケット
フォーム出力の際、サーバー側で一度きりのユニークなIDを生成し
セッションに保存、同じIDをフォームにも埋め込んで出力します。
投稿された際このIDを照合すれば、
正規のフォームから投稿されたものだと判断できます。

尚、比較後すぐにセッション側のIDを破棄すれば
リロード(二重投稿)防止対策にもなります。

2.COOKIEにIPアドレス
フォーム出力の際、リモートホストのIPアドレス を COOKIEで送信します。
投稿された際、COOKIEのIPと実際投稿してきたホストの
IP を比較し、おなじなら同一ホストと判断できます。

スパム投稿では、一度得たフォームやCOOKIEを使いまわししてるようなので
これが違う場合は、自動投稿ロボットの可能性が高いです。
ただIPがコロコロかわる携帯端末などでは使えません。

【デメリット】
どちらも COOKIE必須 。
また1の場合はセッションの寿命が残ってる間に
投稿を完了しないと受け付けられないことです。

普通に投稿するユーザーの利便性を損ねないことはとても大切なんですが、
スパム投稿に含まれてるURLにはフィッシング詐欺のものもあるので
普通のユーザのためにもスパム投稿を見逃すわけにはいきません。
クッキー と JavaScript は ON でご協力お願いします。

JavaScript でスパム投稿対策

[`evernote` not found]
[`grow` not found]
[`livedoor` not found]
[`yahoo` not found]
Delicious にシェア
このエントリーをはてなブックマークに追加

PHPの基礎体力掲示板の話です。
最近は UA に MRA 4.3 を含んだPOSTのアクセスが目立ちます。
多い日は1日250件くらいあります。
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 4.3 (build 01218))
MRA 4.3 ってなんでしょうね。まあ
スパム投稿のUAなんで気にすることもありませんが。

正規のフォームを介すことなく、
直接ターゲットの URL に POST しているので
ロボットによる自動投稿だと思われます。

ブラックリストをつくって、IPや投稿内容でフィルタリングしてはいますが
新らしいHOSTやパターンが現れると、その度に
投稿を削除して、リストを更新してとかなり面倒です。

新規投稿以外は、Javascriptでフォームを表示してるおかげで
スパム投稿はまったくありません。
アホなロボットがJavascriptを解釈してまで
投稿してこないだろうと読んだのは正解でした。
新規投稿についてもJavascriptで対策できそうだなと思い
試したところかなり効果があったので紹介します。

要点は、フォームの action にダミーの URL を指定しておき、
送信直前に DOM で action を正しいURLに書き換えるわけです。
これで正規のフォームからの投稿だけが受け付けられます。

フォーム側はこんな感じ。加えて下のJavascriptをロードしておきます。

<form id="postForm" method="post" action="/badPost" onSubmit="return validateForm()">
    *
    * この /badPost はダミー
    *
</form>

post.js (prototype.jsを使ってます)

function validateForm()
{
    // フォームの送信先を正規のURLに変えます。
    $('postForm').action = '/post';
    return true;
}

ダミーの /badPost ですが、実際は
ブラックリストを更新するスクリプトにしておきます。

人の目で post.js を見て投稿先URLを変えられるとそれまでですが
新規投稿以外のPOSTアクセスが無いことからすると
業者もJavascript までは見てないようです。
導入して3日経ちましたが今のところ100%排除できています。

もし投稿してきたら、こちらも URL を変えるまでです。
その間にも着々とブラックリストは更新されていきます。

アクセスログの(null) を含むリクエスト

[`evernote` not found]
[`grow` not found]
[`livedoor` not found]
[`yahoo` not found]
Delicious にシェア
このエントリーをはてなブックマークに追加

Apacheのアクセスログを見てると、リクエストに
(null) が付いたアクセスが1日10件程あるのに気づきました。

例)
"GET /php/(null) HTTP/1.1"

特定のホストからというわけでもなく
日本の一般的なプロバイダさんからのアクセスです。
リクエストされてるページもバラバラです。

共通してるのは UAER_AGENTMSIE 8.0 なことと
単発のリクエストであることの2点です。

1. ヌルバイトアタック?
2. ワームによる攻撃?
3. MSIE 8.0 のバグ?
4. 単に (null) って文字を付けて遊んでるだけ?

Apacheがヌルバイトを(null)に変えて
ログに保存してるのかもしれないけど、これはなんでしょね?
正規版が公開されたばかりの MSIE 8.0 をインストールして試しましたが
(null) は付いてこなかったのでバグではなさそうです。

「2. ワームによる攻撃」の可能性が高い気がしてますが
ひとまずヌルバイトと(null)って文字の入ったリクエストを
別ログにとって様子をみたいと思います。

1 2

ホーム > アーカイブ > 2009年3月のアーカイブ

Ad
Apache
MySQL
PHP
お気に入り
ん。。。。。。広告
アーカイブ
Ad

ページの上部に戻る