* [spam] URI spamフィルタ (Part 1) とブロック機構: 概要 [#wb00d081]
- ページ: [[BugTrack2]]
- 投稿者: [[henoheno]]
- 優先順位: 重要
- 状態: 提案
- カテゴリー: 本体新機能
- 投稿日: 2006-11-18 (土) 23:48:10
- バージョン:
#contents
** 関連: [#dc60ad85]
- [[BugTrack/772]] [SPAM] Wiki SPAMming
- [[開発日記/2006-11-04]] (official/dev) 内容ベースのspamフィルタ と 新規postについて
- [[開発日記/2006-11-12]] spam.php: 冒険者向け: 現状の組み込み手順
- [[BugTrack2/207]]: [spam] badhost: A list of URI redirection or masking services
- [[BugTrack2/208]]: [spam] badhost: list of Jacked sites, and Spam domains
** 修正 [#pd14f285]
- [[cvs:lib/spam.php]]
- [[cvs:lib/spam_pickup.php]]
- [[cvs:spam.ini.php]]
//- [[cvs:domain.ini.php]]
spamフィルタのコンセプト実装について、実現している部分を中心に概要をまとめます。
+ ''URIの計測機構'' - URI追加型スパム(下記)の「ハイパーリンクを生成させようとする欲求の強さ(理不尽さ)」を計測します。
-- URIの直書きによる外部リンク生成要求の個数 (記法を問わない)
-- HTML Anchor タグ、phpBB BBCode ないしその派生記法による外部リンク生成要求の個数
+ ''上記フィルタを利用したブロック機構''
-- (comment、pcomment、bugtrack、trackerなど、特定のシチュエーションで)新規に追加されるメッセージを調べ、特定の条件でブロックする
-- ブロックされた側には、改行コード一つのみが送信されます。
+ ''ブロック内容の通知機構'' - ブロックした投稿内容については、ブロックした事がわかる形で管理者にメールされます。管理者は誤判定などが無いかどうか、ブロック通知をチェックすべきです。メールクライアントのフィルタ機構によって、普段とは別のフォルダへ振り分けることができます。
Subjectの例 ('[blocked]' が挿入される):
[PukiWiki] [blocked] 自作プラグイン/csv2newpage.inc.php
** 概要: URI追加型スパム [#a9766872]
他のWebアプリケーション(特に、第三者でも投稿できるHTMLフォームを持っているWebアプリケーション)に、URIを自動的に追加させようとするスパムを、ここでは「URI追加型スパム」と呼ぶ事にします。
このスパム行為の発信者には、ある程度明確な傾向があります。総じて、発信者は「(1)低コストで (2)大きな効果(※金銭的な)」をもたらすために、「(3)任意の外部へのリンク(HTMLのAnchorタグ)を (4)ある程度の期間 (5)対象のサイトに出現させる/消させない」という事に強いモチベーションを持っています。
*** URIに関する工夫 [#l00a18d6]
単純な(文字列比較や、正規表現による)フィルタを回避できるように、URIには、防御側が想定しないであろうバリエーションを持たせる事があります。例えば語句のゆれを作成するために無駄な要素を追加したり、通常存在するべき要素を削ったり、大文字/小文字やpercent-encode の有無を変化させることがあります。
単純な例: メッセージとURI
buy foobar http://example.org/buy/foobar
buy foobar http://example.org#buy_foobar
buy http://victim.example.org/go?http%3A%2F%2Fnasty.example.org
order foobar HTTP://EXAMPLE.ORG/BUY/FOOBAR
URIに使用されるドメイン名にはいくつかの傾向があります。
- 既存のサイトの一部 (サブドメイン・ディレクトリ) を借用したもの
- レンタルWebスペースやブログレンタルサイトのようなサービス(サブドメイン・ディレクトリ)を借用したもの -- もちろん複数アカウントによって複数個が利用される
- 独自にスパム用のドメインを取得したもの -- ドメイン名は数字や文字の羅列である場合がある
いずれも、取得したドメインについては、(開設されてから閉鎖、ないし放置されるまで)ある程度の生存期間が存在します。
*** メッセージに関する工夫 [#d2d1dd0b]
ひな型と、その時追加したいURIを組み合わせ、生成したデータを投稿します。生成したテキストデータを投稿する場合と、ターゲットに選んだサイトから得た情報(例: どのようなフォームを持っているか)からひな型を作り、そこからデータを生成する場合があります。
特定の記法を解釈するWebアプリケーションを狙って、何らかの記法を利用する事があります。
例: URIを(同時に)単一の方法で羅列
[ url=http://example.org/buy/foobar]Buy Foobar[/url]
[ url=http://example.org/buy/foobar]Buy Foobar[/url]
[ url=http://example.org/buy/foobar]Buy Foobar[/url]
また、複数のWebアプリケーションでも(羅列したURIの)どれかが外部リンクとして成立する様に、複数の記法をミックスさせる事があります。
例: 同じURIを(同時に)複数の方法で羅列
Nice site! Check about foobar
http://example.org/buy/foobar
<a href=" http://example.org/buy/foobar ">buy foobar</a>
[ url=http://example.org/buy/foobar]Buy Foobar[/url]
AnchorタグやBBCodeなどの記法を用いたuri spamの特徴としては、「記法に関してはほぼ正確である」という点があります。この点については、それぞれの記法を解釈できるサイトについて、間違いなく記法を解釈させるためであると考えることができます。
<a href= http://example.org >buy example</a> <= "</a>"で閉じている
<a href="http://nasty.example.com">visit http://nasty.example.com/</a>
<a href=\'http://nasty.example.com/\' >discount foobar</a>
[ url]http://nasty.example.com/[/url]
[ url=http://nasty.example.com]visit http://nasty.example.com/[/url]
ターゲットとしたサイトごとに適切な記法を使わない点については、投稿側のスパム作成コストや、スパム対象一覧の蓄積方法・流通方法などに原因があるのではないかと推測する事ができます。もしそれに見合うのならば、適切な内容が使用されるでしょう。
*** 自動投稿に関する工夫 (対象、頻度、分量に関する工夫) [#t71f3a46]
着実な積み重ねによって、ターゲットとしたサイトを侵食する事を目標とします。結果的に、管理側が長期間にわたり管理を放棄した状態となるのが理想的です。
例えば:
- プログラムを使ってスパムを投稿させます。
-- 投稿対象として認識したサイトは次回以降も活用します。
-- ターゲットのサイトの大元(ネットワークプロバイダ)や、発信側のネットワークプロバイダ等から締め出されるほどの頻度や量では活動しません。しかし人間にとっては充分に高頻度(数分～数時間等)に、かつ長期間に渡り、昼夜休まず投稿を行います。
- 管理側へ対策として:
-- データの量や頻度を非常に大きくする事があります。
-- 管理側に気付かれないようにURIを追加する方法があるならば、それを試みます。
-- 複数のIPアドレスから投稿を行わせます。
--- 異なるIPアドレスからのリトライ、ないし多重投稿を行わせる事で、フィルタの貫通性能を高める事があります。
--- 一度利用したIPアドレスは数日～数週間後に再利用する事があります。(※送信側のコストの都合による)
-- 投稿した内容が掲載されているかを確認し、異常があれば確認します。例えば、投稿用のIPアドレスの一つから、URIを含まないデータが追加可能かどうかを確認します。
** URI追加型スパムのブロックについて [#d04277c7]
上記のような特徴をもっている自動スパムに対して、従来型の機械的なフィルタは、(1)ユーザーの利便性を損なわずに (2)管理者のメンテナンス負担を減らせるか、といった点のバランスに問題があります。
- IPアドレスによるブロック:
-- (静的) ホスト単位の拒否: 次からは異なるIPアドレスで投稿があるため、効果が薄い(例えば二週間後にやっと役に立つかもしれない)。またメンテナンスの負荷や頻度が高い。メンテナンス負荷を下げるための仕組みを導入すると、パフォーマンスが犠牲になりがち。
-- (静的) ネットワーク単位の拒否: 強いが、反動も大きい (利便性低下)
-- (動的) リアルタイムブロックリスト(RBL)の利用 -- 有効性と利便性の検証が必要。実行時にコストがかかる
- NGワードによるブロック:
-- 内容と、機能の柔軟性次第。また更新が必要 (メンテナンス負担増加)。単純すぎるNGワードは利便性を損なうか、損なうために追加できない。NGワードを追加しすぎるとメンテナンスコストは高まり、パフォーマンスが低下する。メンテナンス負荷を下げるための仕組みを導入すると、パフォーマンスが犠牲になりがち。
「URI追加型スパム」は、(投稿テストを除き)基本的に必ずURIをコンテンツに追加させようとします。そこで、投稿されるコンテンツに含まれるURIを検証し、その質や量で自動的にブロックを判定する機構があれば、IPアドレスが合致するかどうかや、NGワードを含んでいるかどうかに限定せずにスパムをブロックする事が可能になります。
--------
* コメント: URIが既に含まれている場合の挙動 [#m138a078]
- 今最新のCVSでspam.php関連を評価させて頂いていますが、適用後に既存コンテンツに紛れていたSPAMを削除出来なくなりますね。editのPOST時に不可視のoriginalの内容も評価してしまうのが原因と思いますが、何とかなりませんでしょうか。 -- [[nobunobu]] &new{2007-01-01 (月) 22:10:41};
-- こんにちは :) 仰る通りで、現状は融通の利かない防御壁しかありません。既存のコンテンツにブロック対象があると、コンテンツがロックアウトされてしまうでしょう。特に badhost は強烈です(該当するURLが事前にあってはならない)。次に、HTML anchor = 0 なども同様です(該当パターンにマッチする会話があってはならない)。現状の基本的な回避策は、そのようなコンテンツがあったら、一旦条件を緩和して、(1)それが不必要なら削除する (2)それがパターンに合致しないように少し書き換える (3) それが問題にならない程度に今後もしきい値を緩和する 以外ないでしょう。 -- [[henoheno]] &new{2007-01-01 (月) 23:47:58};
--- 例えばそれが本当に不要なスパムの場合、仮にそのようなページがあれば、ユーザーにそのページを教えてもらって、管理者が個別にクリンナップをかけることができると思います。事前にそのパターンで既存コンテンツを検索しても構いません。一旦そのようなクリンナップが完了したならば、後は幸せになるでしょう -- [[henoheno]] &new{2007-01-01 (月) 23:53:50};
-- 回避用のハックとしては、例えば、「とある IPアドレスからの編集についてはチェックしない」、といった事ができるでしょう。 -- [[henoheno]] &new{2007-01-01 (月) 23:53:10};
-- edit 周りの解決策としてはご指摘されている様に、現状のeditの機構そのものを見直す作業になると思います。originalの存在理由や、存在しなくても動いてしまう理由を問い詰めたり、修正内容の中から「追加される行」「削除される行」それぞれを取り出して評価する様な方向があると思います。ただ現段階のものは、過去バージョンのPukiWikiにも簡単に組み込ませられるような状況に持っていきたいと考えています。 -- [[henoheno]] &new{2007-01-01 (月) 23:56:54};
-- originalのcheckよけとして、function check_uri_spamの&br;foreach($target as $str) {&br;を&br;foreach($target as $key=>$str) {&br; if ($method['_comment']=='edit' && $key=='original') continue;&br;に変更するのはどうでしょうか？これならbadhostなURLを編集画面にて削除出来ると思いますが。 -- [[nobunobu]] &new{2007-01-02 (火) 00:04:31};
--- 'original' をチェック対象から外してしまう、というのはとても興味深いアイデアです :) 仮に実現するならどこでするかですが、lib/spam.php はあくまでも「一つの事をうまくやる関数」の集合体ですから、そこの check_uri_spam() に外部由来の例外処理を組み込むと、見通しが効かなくなると思われます。 spam.php に渡すデータを用意している段階 (lib/pukiwiki.php にある) でそれを行うのがよろしいかと思います。具体的には、$vars から 'original' を除いたものを作ってやればいいのだろうと思われます -- [[henoheno]] &new{2007-01-03 (水) 00:42:53};
--- ($varsの改変なんてやらないで)POSTされた内容として全てを保存したい(メールさせたい)場合は、$method を拡張する形で 「指定した array() の中にある $key と合致するものを検索対象から外す」機構を加える様にすると(original以外の用途にも使えるようになって広がりが生まれるので)良いのでしょう。 -- [[henoheno]] &new{2007-01-03 (水) 00:51:49};
--- 最大の問題は、'original' の有効性/無効性について確証を得ていない所ですね (^^; -- [[henoheno]] &new{2007-01-03 (水) 00:55:03};
--- いろいろとコメントありがとうございます。&br;とりあえず当方のサイトでは現状のCVSスナップショットに上記修正と別途RBL参照及びご認識よけホワイトリストを追加したもので、運用をはじめました。&br;適用数時間ですでに数件のBlockに成功しました＾＾&br;ほとんどが、#commentへのarea_anchorですけど・・&br;今暫定的に#comment機能を殺していますが、これであれば再開放しても良いかもしれません。 -- [[nobunobu]] &new{2007-01-03 (水) 01:35:02};
- 具体的に困るのは、むしろ対策後で、たとえばspam.ini.phpを更新したあとで、書き換えられたURLを元に戻す作業をするときもspam.ini.phpが反応してしまいURLを書き直すときにいちいち、spam.ini.phpを無効化しなければならないということです。spam.ini.phpに登録されていないトラップドメインに、数十ページ書き換えられたときのことを考えてみてください。-- [[Logue]] &new{2007-06-23 (土) 16:35:06};
- 'original' については、ほぼ現状のデータ構造に依存した無駄な部分なのだろうと見切りをつけた((気分になった))ので、edit時に限り 'original' を対象にしない修正を加えました。これで、既存のNGリンクを除去できる様になったはずです。同時に、'original'の存在を見越して閾値を甘めにつける必要がなくなりましたので、設定のデフォルトも調整しました。 -- [[henoheno]] &new{2007-08-28 (火) 00:16:49};
-- [[cvs:lib/pukiwiki.php]] (1.21)
-- [[cvs:pukiwiki.ini.php]] (1.149)
- official に「edit時に限り 'original' を対象にしない修正」を導入するのはいつでしょうか？[[official:続・質問箱/35]] や[[official:自作スキン/ by YEAR OF THE CAT]] が修正できなくなっています。デフォルトのedit プラグインなら、更新の衝突時にしか'original' を使わないとおもうのですが。 -- &new{2009-01-23 (金) 22:55:56};
-- [[official:WebTrack]] に記述したほうがいい？ -- &new{2009-02-17 (火) 16:59:05};
-- [[official:WebTrack/84]] -- &new{2009-03-07 (土) 15:14:30};
//#comment
--------
* コメント: ブロック結果とそのバリエーション [#k68b8f3f]
- 追加のアイデアとしてもう一つ。発信者がスパムを登録する際、実際はblockされるんですけど、その後に、あたかも登録が成功したかのように振舞う仕組みを入れたほうが良いと思います。 -- [[teanan]] &new{2006-11-21 (火) 06:55:03};
- spam-botが登録後にリロードしてくるようになるだけの気もしますが、騙されるbotがいる事は期待できるかも。ただ表示内容を工夫しないと、万一誤判定が発生した際に分かりづらくなるかも。 -- [[にぶんのに]] &new{2006-11-21 (火) 23:48:49};
- 本当は一定時間維持できたら良いんですけど・・・。ますます誤判定したときに分かりづらくなりますが (^^; -- [[teanan]] &new{2006-11-22 (水) 02:12:04};
- 結果のあしらい方は内部の処理と独立しているので、表現方法は元々複数あると思います。他の方法も検討したりして、内部処理の話題とは個別に考えると話が進むと思います。このページは多分上の話でもっと長くなるので X) しばらくしたらページを分けるのが良いでしょう・・・・ -- [[henoheno]] &new{2006-11-23 (木) 00:46:06};
- 他の例: (1)即座に exit() する(最初こうでした)。 (2)即座に \n を返す(多分人間に優しいんじゃないかと思って・・・)。 (3) 人間にも機械にも判別できるメッセージを返す。(あなたbanされましたよ!) (4) とにかくでたらめな何かを返す(予測不可能にするのだけが目的。でも他のIPから確認すればバレる)。 -- [[henoheno]] &new{2006-11-23 (木) 01:01:24};
- N秒動作を停止する。攻撃側の足をひっぱるのかと思いきや、サーバー側のコネクション数などのリソースを浪費しかねないと思うのでご利用は計画的に。 -- [[henoheno]] &new{2006-11-23 (木) 12:11:33};
//#comment
--------
* コメント: goodhostに対する処理 (無視したい対象に対する無視の仕方) [#ea98e579]
- うちで動かしているwikiでMenuBarやtopページのリンクがごっそり同じurlのスパムサイトに変更されていたので、同じurlを一定回以上書いたらblockという手法を実装しようとcheck_uri_spam関数の中に自作してみたのですが、既存ページでwikipediaへのリンクが(InterWikiを使わずに)多数ありこれが引っかかってしまいます。なにかいい対処法はないでしょうか？ -- &new{2007-08-13 (月) 13:01:44};
-- ホワイトリストであらかじめ問題のないサイトを列挙しておいてはどうでしょうか。 -- [[teanan]] &new{2007-08-13 (月) 14:50:12};
-- 具体的にはnon_uniquriのチェック直前に、$pickupsをuri_pickup_implodeでurl文字列に戻して連想配列を使ってカウントアップし最大のものが閾値を超えたらblockとしようとしているんですが、見たところ日本語のwikipediaへのリンクがja.wikipedia.org/wiki/の後の%エンコードされてる部分がごっそり削られてたため同じurlと認識されているようです。uri_pickupの正規表現を読んでもこれが削られるようには思えないんですが。ブラックリストに追加するのが手間なので手を抜こうとしての改造なのでホワイトリスト作成というのも本末転倒に思えまして (^^; -- &new{2007-08-13 (月) 21:14:39};
-- こんにちは :) 現時点のspam_uri_pickup() は前処理として percent-encode をdecode したりしていますので、その((まな板の上に乗せるhostを少しでも増やすために、あまり綺麗にuriをpickupしていない点の))副作用の一つだろうと思います。綺麗にそれらを((uriの中に別のuriや別のhostが隠れているかもしれないが、まとめて全部、系統立てて))pickupするのは、もう二ひねり位しなければならなそうなので、手をつける前にちょっと考えています。例えばHTMLのAタグの範囲なども考慮させるともう少し大変です。spam_uri_pickup() の前提となっている uri_pickup() は、理想的な状態を前提に置いているけれども、現実にはもっと雑多なシチュエーションで動いてくれないと困るので、最終的には使われなくなるでしょう。 -- [[henoheno]] &new{2007-08-13 (月) 23:26:56};
-- さて、wikipediaについては '.wikipedia.org' を goodhost に一行加えるだけで済むように思います。PHPいじるよりは楽なはず・・・ -- [[henoheno]] &new{2007-08-13 (月) 23:24:51};
-- 既存のspam排除ルールの場合、MenuBarの全リンクをeditで外部に付け替えられるのを防ぐには、non_uniquriかnon_uniqhostで切るか、badhostに登録するかしか無いと思います(使い方の問題だったらごめんなさい)。で、badhost登録もさぼりたいとすればnon_uniquriかnon_uniqhostになるので、goodhost登録してもURL直書きリンクな日本語wikipediaは逃げられないと思うのですが(これこそ勘違いだったらごめんなさい) -- &new{2007-08-14 (火) 00:10:44};
-- 実現/維持のためのコストを案じておられ、wikipedia のURIが大量にある事について困っておられるという事でしたで (実際にはjaに限定しない) wikipedia のURIを一切カウントしないルールを提示したつもりです。ご理解いただいている通り、non_uniqXXX と組み合わせて下さい。一行追加すれば、この点ではbadhostのメンテナンスは不要であるはずなので、もしよろしければお試しいただいて、その現場において何がどう駄目/足りないのかをお教えいただけませんでしょうか。(さすがにwikipediaのページを利用したspamなどはここでは考慮しません) -- [[henoheno]] &new{2007-08-14 (火) 00:28:42};
-- blocklist(spam.ini.php)に書かれているgoodhostのルール適用は、lib/spam.phpのソースを見る限りでは最後のbadhostチェック時だけだと思うのですが。ためしにplugin/spamを使ってgoodhostにwikipedia.orgを追加しnon_uniquri=3チェックをすると日本語の方だけ赤字になります＞(実例へのリンクがありました) -- &new{2007-08-14 (火) 01:45:34};
-- 実例の提示をありがとうございます。goodhost については、こちらの意図とも実装が合っていないので、直させて下さい。Wiki本文も拝見しましたが、こうしたアクションとは別に、Wikipediaに対するInterWiki化はやっていいのではないかと思いました。 -- [[henoheno]] &new{2007-08-16 (木) 00:57:03};
-- goodhostについては了解です。InterWiki化はのんびりと進めることにします (^^; -- &new{2007-08-16 (木) 01:24:13};
-- [[CVS版]] を対象に、この件のフォローを盛り込みました。他のチェックを行うより前に blocklist の処理を行わせる工程(pre)を追加し、goodhost はデフォルトでそちらに加えるようにしました。結果的に、goodhostで指定された項目は一切チェック対象になりません。よろしければ(まずは本番環境でないところで)お試し下さい。lib/spam.php と spam.ini.php の両方を差し替える必要があります。 -- [[henoheno]] &new{2007-08-19 (日) 00:00:27};
--- [[cvs:lib/spam.php]] (r1.32)
--- [[cvs:spam.ini.php]] (r1.76)
-- この処理を追加したせいで後続の処理におかしい所が出たとしたら、それはそれで直します -- [[henoheno]] &new{2007-08-19 (日) 00:05:42};
-- ところでInterWikiのつけ方の案ですが、こんな感じはどうだろうかと思いました -- [[henoheno]] &new{2007-08-19 (日) 00:21:51};
現在: CV:[[塩沢兼人:http://ja.wikipedia.org/wiki/%E5%A1%A9%E6%B2%A2%E5%85%BC%E4%BA%BA]]
案1 : CV:[[塩沢兼人>Wikipedia:塩沢兼人]] -- 汎用的だがまだ冗長
案2 : [[CV:塩沢兼人]] -- 最短。意外と問題ないのでは?
//#comment
--------
* コメント [#pd172587]
- JavaScriptにある乱数を生成させて、PHP側でも同じアルゴリズムで乱数を生成して、その２つを照合するみたいな。結局はAjaxになるんでしょうけど、未だにJavaScriptを解析できるBotは無いですし。 -- [[Logue]] &new{2007-01-16 (火) 22:50:01};
-- ありますよ。 -- &new{2007-01-17 (水) 09:45:38};
-- 別のアイデアの提案ですね。 JavaScriptで駆動できるということは、少なくとも数列の種となるデータをインターネット経由でクライアントに渡していますね。そしてその種があればPHPで数列を生成できると。誤解していなければ・・・PHPを使った自動攻略アプリケーションが実装できませんか -- [[henoheno]] &new{2007-01-17 (水) 23:21:36};
-- このアイデアのポイントはおそらくJavaScriptの方ではなくて数列の方で、その進化系は challenge and response の機構ではないでしょうか。 このアイデアは昔からあって、[[cvs:lib/mail.php]] にもresponseを生成する部分が実装されています(APOPがchallenge and response を使っているから)。また[[HTTPのdigest認証>http://www.ietf.org/rfc/rfc2617.txt]]もchallenge and responseの仕組みを使っています。-- [[henoheno]] &new{2007-01-17 (水) 23:24:00};
-- response や digest を生成する部分を、JavaScriptやflashなどでクライアント側に実装するというのは、(PukiWikiの管理者パスワードを含め)パスワードを平文で送らねばならない、現状のWebアプリケーション全般に有効でしょう。しかし欠点はご想像の通りです。 -- [[henoheno]] &new{2007-01-17 (水) 23:30:30};
--- なるほど。秘匿性の面で不安が残ると言うことですか。 -- [[Logue]] &new{2007-01-18 (木) 20:13:52};
- [[BugTrack2/200]] の現状の感触。「URIの計測およびパターンの検出」だけでも結構な量がさらえています。ただし、それらは前時代的なspamばかりであって、ある種の攻撃者を防ぐためにはblocklistの併用は必須。しかしblocklistでも「完全に新規の(使い捨ての)ホスト」は防げない、といった所ですね。足場をしっかり固めた後に、いずれは次の段階・・・つまり攻撃側の状況を記録しながらカウンターを打つ柔軟かつ動的な仕組み((使い捨ての攻撃はそれでも防げませんが、密度が高まるでしょう))や、攻撃側へカウンターを打つ((spamの源を断つ方向の))状況を目指さねばならないでしょう。 -- [[henoheno]] &new{2007-03-11 (日) 23:58:27};
- 最近のラグナロク系Wikiのスパムを見ると''URL改変型''が多いですね。知らないうちにリンクがごっそりスパムサイトに変えられてましたよ。最低限、「タイムスタンプを更新しない」オプションは無効化すべきでしょうね。 -- [[Logue]] &new{2007-06-20 (水) 19:39:26};
-- お疲れ様です。しかし [[BugTrack2/53]] に書いたのと同じ疑問があります。スパム対策系の話題には大小さまざまな切り口のものがありますが、どれから試みるか、という認識の点で少し損(削られていく運用の時間という形で)をされていませんか。 オンラインゲーム系サイトのアレコレの苦労も考慮された案も複数出てきているはずですが、Logueさんはなぜか未だにそれらの外で苦しんでいるように見えます。今度余裕があったら事情を教えて下さい -- [[henoheno]] &new{2007-06-21 (木) 00:03:28};
-- うーん。私の場合[[RO>http://ro.logue.be/]]と[[FF11>http://ffxi.logue.be/]]のWikiを両方運営しているんですけど、明らかにスパムの手口とかが違うんですよ。問題になるのはラグナロク系で、spam.ini.phpで対策しても、次から次へと間際らしいドメインを作っては、アドレスを書き換えていくってパターンが多いんです。まぁ、CHINANETからの更新を弾いていれば７０％は防げそうですけど。FF11は古典的なURL投稿スパムばかりですね。 -- [[Logue]] &new{2007-06-23 (土) 16:57:25};
#comment
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
