掲示板迷惑書込み対策について    2006/5/7
これは北のITが某サイトの管理上入手した情報、実データを元にしたものです。
掲示板に対する迷惑な書込みでお困りのサイト管理者のために作成しています。
対策内容は現時点では効果的ですが残念ながら未来永劫有効とは言えません。
手口の変化に合わせた対応が必要だと考えています。新たな方式は都度ご紹介します。
誰がどのようにしてアクセスしているか
迷惑行為は必ずしも本人が行っているとは限りません。
他人のアドレスでアクセスしたり、正規にドメイン登録されていないアドレスも使用されている可能性があります。
そして、一部のアクセスは機械的にアクセス(手入力ではなく)しているケースも多々有ります。
このように迷惑な書込みには
・手書きによる書込み
  ・機械的な書込み  の2種類があることを先ず知っておく必要があります。
蛇足ですが、機械的書込みに狙われやすい掲示板があるようです(当社調べ)。
狙われたサイトの掲示板を見るとフリーウエアを使用した掲示板ばかりでした。
これは、使用するフィールド名等が類似しているため機械的に操作し易いことが原因ではないかと推測しています。
 
どこまでガードするか(ポリシー)
管理者はポリシーを明確にする必要があります。
仕掛けを面倒にしたくないので多少は許容するのか、徹底的にガードするかの違いです。
北のITは、全管理者が徹底して対応することで相乗効果をもたらすと考えています。
是非、徹底した対応をご検討下さい。
@不愉快、迷惑な文言を禁止する
 殆どの掲示板に備わった機能でしょう。
 但し、ご存知の通り際限がありません。
A特定のアドレスからのアクセスを禁止する
 これも特定文言の禁止と同様です。
BURLの羅列書込みを禁止する
 機械的書込みに多い迷惑行為で、アダルトな内容よりも多い傾向があります。
Cプロバイダーへの協力依頼
 ここは肝心なところです。
 利用しているプロバイダーが特定できて、それが国内プロバイダーの場合はプロバイダーに協力を依頼して対処をお願いすべきです。
   但し、機械的な書込みでは他人のアドレスを使用している可能性が高いので依頼時に判別が必要ですし、これを判別しないと数が多くて対応しきれないと言うことにもなります。
 また、プロバイダーの対処結果は満足のいく内容で報告されることは期待できません。
 個人情報保護を理由に書込み者の情報が得られることは皆無です。
 プロバイダーの営業姿勢によって、注意程度で止まる場合、利用停止にして頂ける場合等対処の内容も様々です。
D機械的な書込みの防止
 この手の書込みは書き込み内容の如何を問わず全て拒否したいですね。
 某サイトの実績では殆どの迷惑書込みが機械的な書込みによるものでした。
 次項では機械的な書込み防止をテーマに対策を記述します。
 
対策方法について
北のITが講じた対策を中心に説明します。
@不愉快、迷惑な文言を禁止する
 禁止語句を外部ファイル化し、追加設定を簡易化しました。
 掲示板用のログとは別に対策用のログを設け、禁止語句を使用した書込み内容、書込みアドレス等を記録します。
 書込みアドレスは必要に応じてAへ反映します。
 本文等に書かれたURLも必要に応じて禁止語句に登録します。
A特定のアドレスからのアクセスを禁止する
 @と同様の方式にしました。
 迷惑語句は必要に応じて@へ反映します。
 @、Aの結果を相互にフィードバックすることで防止効果は向上します。
BURLの羅列書込みを禁止する
 書込み本文中の http:// の文字列出現回数をチェックして一定数を超えたら拒否します。
右上へ続く
 
 これも対策用ログに記録し、@、Aへ反映させます。
 英字のみの書込みチェックも有効です5/15追記
Cプロバイダーへの協力依頼
 Dの対策で機械的な書込みの殆どは防御できていますので、実際に書かれてしまった場合はログから
 ・日時(日本時間、国際時間の区分を付記)
 ・アクセスアドレス
 ・書込み内容
 を調べてプロバイダーに連絡します。
 連絡時は連絡者の氏名・連絡先等を必ず添えます。
 プロバイダーを判別するために対策用ログに REMOTE-HOST の値を記録するとベターです。
 HOST値が得られていない場合は次項参照。
 プロバイダーでは専用窓口を設けている場合があります。一般問い合わせ窓口でも通常は受け付けて対応部署に転送してくれます。
左下へ続く
 
D機械的な書込みの防止
 色々なサイトで対策方法が紹介されていますのでそれらも参考にして下さい。
 ここでは北のITが実施した結果を説明します。
 幾つか試して見ましたが現在のところトークンを使用する方法のみが対策になりえると結論付けています。
 トークンについては次項参照。
 冒頭にも書きましたがこの方式が未来永劫有効と言う保障はありませんので予めご承知置き下さい。

<基本的な考え方>
・表示時にトークンをHIDDENフィールドに書く。
・書込み時にトークンを検証して判別する。
・トークンはアクセスアドレス対応に管理する。

<実施例>
 トークンはアクセスの都度値が変化すればOKですが、今回は乱数を用い且つ前回と同じ値になった場合は異なる値になるまで乱数を求めます。
 
 HIDDENフィールドの名称は独自の名称を付けるよう心がけます。名称が同じだと将来迷惑行為のターゲットになりやすいと考えます。
 蛇足ですが、今ご使用の掲示板もフィールド名及び処理モード等の識別値を独自の値へ変更することをお勧めします。特定サイトのみではすぐに捕捉されてしまいますが全てのサイトが独自名称、独自の値を持てばそれなりの効果は望めます。
 トークンはアクセスされたアドレスと対応させて管理ファイルで管理します。
 放置すると管理データが増加の一途を辿るので一定時間経過したトークンは都度自動消去する方式を取ります。
 因みに某サイトでは24Hrの設定にしていますが実際上はもう少し短時間でも良いでしょう。
 トークン不一致=機械的な書込みのデータは、他人のアドレスを使用している可能性があるのでAに反映させてはいけません。
 北のITが作成したCGIの扱いは末尾に記載。
 
ご参考(掲載内容は順不同)
<エラー(拒否)表示について>
@、A、B、Dでの表示は全て同じ表示で揃える方が、相手に理由が見えないので有利です。

<トークンについて>
a.画面表示時にサーバーが送信(CGIが付与)したトークン(暗号)を受け取ります。
b.掲示板書込み時にはこのトークンをHIDDENでサーバーに返送します。
 機械的動作では未だこの部分の対応が出来ていないようです。
c.サーバーは特定のアドレスに対して付与したトークンが書込みデータとして送られてくるハズであり、且つその値は付与したものと同一であることを踏まえて正しいアクセスが為された結果であるか否かを判定できます。
トークンはやり取りする都度変更して用います。

<HOSTが不明の場合>
ログにHOST名を残していない場合は下記手順で調べることが出来ます。
a.コマンドプロンプトを開く
b.NSLOOKUPと入力して起動する
c.調査対象のアドレスを入力する
 HOST入力では対応アドレスが判る
d.HOST名またはUNKNOWNが表示される
e.NSLOOKUPの終了はEXIT
  <JEAGについて>
JEAG(Japan E-mail Anti-Abuse Group)があり活動しています。
これは、国内の主要インターネットサービスプロバイダや携帯通信事業者各社等が、迷惑メール対策を業界全体で取り組むべき問題と位置付け、技術的な見地から対策を検討・実施しているワーキンググループです。
ABUSE@xxxxxxと言う専用窓口を設け迷惑行為に対処しているプロバイダーも数多くあります。
このような業界としての取り組みを知っておくことは有意義だと思われます。

<アドレス盗用手段について>
CSRF(Cross-Site Request Forgeries)
XSS(Cross-Site Scripting)
と呼ばれる手法が存在しているようです。
ここでの説明は省略しますので、興味のある方は上記キーワードでお調べ下さい。

<今回の対策CGIについて>
何れフリーダウンロード可能にする予定ですがREADMEが不完全なため現在は個別対応になります。
必要な方はお問い合わせページからご連絡を頂ければ無償で提供いたします。