†2004年末から、とうとう日本語のWikiもSPAMボットの対象に含まれてきた様です。一度に数十単位のWikiサイトが自動修正ロボットによる書き込みを受けています。以下にその概要、動向などをまとめます。以前から単発でSPAMは来ていました。SPAM"この機能を有効化することで、文書などの書き込み時に、秒単位で処理が遅延します。IPアドレスから名前が引けなかったり、そのWikiのユーザー情報を持たないアクセスを、全く見かけが同じの別のWikiに送り、自由に荒らさせる。して、更新履歴(とクライアントのIPアドレス等)をメールで受け取る様にしましょう。removed」とでも書いたメッセージに更新する等。そのシステムには捨てアカウントを作ることができるのだろう。SPAMを探索中に同じメッセージを何度も見かけると、さすがに慣れて来ます。それでこれがまた、検索のキーにもなるんですよね。japanHiki方面には2004/10ごろから登場していたようですね。cluture,people.※直後に続くのは他の漢字文化圏のサイトへのリンク。周辺のSPAMに使われているドメインを確認したところ、いずれも所有者が同一人物の様で・・・。†これ以前のものは./old_reportへ移動しました。†devは何故かB-Wikiの所だけタイムスタンプを更新しないで定期的に書き換えられている模様。05:53:29本日14:55頃から再び攻撃中。15:10:30この不毛な戦いになんとか終止符を打たなければなりませんね。16:28:21お疲れ様です。IPやUAはWebサーバーのログを見られるのであれば解ります。なくば、PukiWikiの更新をメールで受け取る事で記録できます。21:57:10少なくとも今回の件に関しては禁止単語で対処出来そうです。casinoとhardcoreで結構弾けそう。19:44:33同一内容の複数書き込み時にリミッターをかけるとかはどうでしょうか。同じ内容を二度も三度も書き込むのはSPAMくらいな気がします。20:51:50ふむふむ。私が攻撃者なら、その対応には「ランダムな文字列を追加する」ことで回避できると確信するでしょう。決定打というよりは手法(考え方)の一つの様です。†ページを新たに生成するもの、ページの先頭に付加するもの、コメント追加するものの3種類確認。記載される内容は若干異なるものの、URLとしては、下記のひとつのみ。www.areaseo.com新たにページを生成するものは、既存のWikiNameのページを全て小文字にして生成していました。既存のページ名をモディファイして新しいページ名を生成しているのは、Wikiのかさ増し、ないし情報の埋め込みが目的のように見えますね。22:54:19今回のpostは、以下の複数のホストから来ているようでした。韓国系IP+αの様ですね。210.105.169.17259.13.242.201210.113.119.78163.180.130.202203.241.185.19661.120.143.110222.236.191.40複数のホストが二つの内容を書き込んでいて、最初はyellopagesといった言葉を使ったyellowpage誘導およびそのpagerank向上を狙ったspam。次にpagerankといった言葉を使ったpagerank目的のspam。全てがほぼ同時刻にpostしていますが、その内容は、同じ時間帯にはほぼ同一であるようでした。23:20:05おおっと、その辺は盲点でした。teananさんにも届くよう、設定を追加しました。頻繁*1にSPAM書き込みがあるので、ページの凍結を希望します。23:01:38この件、ちょっと小細工してみたいのですが良いでしょうか。具体的にはformの変数名を変えてみようかと。12:48:28お疲れ様です。officailに対するチャレンジの続きの話ですよね、どうぞどうぞ。バックアップは取りましたし、所有グループも統一しておきました。webサーバー周りを見てみて下さい。ある程度ファイルも整理してあります。23:38:05一通り終了しました。:config/plugin/trackerに「欲しいプラグイン2」を追加しました。みたく、少々分かりづらくしてあります。「~/欲しいプラグイン.orig」にリネームしました。01:33:58ちなみに、field名を日本語にしてしまおうと思ったのですが、tracker_listの改造が必要なのでやめました。07:00:25欲しいプラグインに来ていたspamは、とりあえず撃退できているようですね。凍結はあまり意味が無かったという認識でしたでしょうか。23:57:46(項目をわけました。09:36:00対策をして1ヶ月程経過しました。official:欲しいプラグインへのspamはある程度ブロックできてそうに思いますので、少しまとめておきます。09:36:00trackerへのspam攻撃の対策には、定義名(:config/plugin/tracker/hogeの設定名)変更が効果的のようです。spam書き込みは、trackerプラグインのpostで来ていると思います。trackerの設定名が変わると、postで指定された設定名が見つけられずにエラーとなります。英語圏からのspam書き込みが目立ちますので少し工夫ができます。「state」フィールドには「NY」などの単語が指定されてきていました。定義名やフィールドの定義に分かりやすい英単語を使用するのはspam送信者の理解を助けてしまいますので、避けた方が良さそうです。:)trackerによるspam書き込みのあったページを凍結するのは無意味です。(^^;コンテンツ側の設定変更でとりあえず逃げられるわけですが、当然ながら、一時凌ぎにしかなりません。trackerへのspam書き込みを抑止するためには、trackerプラグインの修正が不可欠ですので、今後の課題をあげておきます。09:53:06postされたtrackerデータを、直接新規ページに書き込んでしまうのは止めたほうが良いです。プレビュー画面を挟むだけでもspam書き込みの抑止になります*3。trackerフォームによるpostかどうか、簡単な方法でも良いので判断できるようにした方が良さそうです。trackerへのspamについては、昨今ではBugTrack2/200によってまとめて対策できています。任意のページに誘導するための任意のファイルを添付。様々な被スパムblogにその添付ファイルへのリンクを張るスパムblogサイトをGoogleなどの検索ロボットがクロールするときに、該当添付ファイルへのリンクが評価される該当添付ファイルが上位にヒットしDDos攻撃まがいのアクセス集中発生。ファイルが添付されたのは、22日で削除したのは翌日。多数のblogサイトに該当ファイルへの添付への直リンクが張り巡らせてあるため、1週間後になってからDDoS攻撃まがいのアクセスの集中が起きた。htmlファイルと読み込ませないようにmime-typeを指定してあったにもかかわらず、Googleがしっかりと添付ファイルの内容をクロールしている点が気になる。トップページを凍結していれば防げた可能性もあるが、添付ファイルに直リンクし、被リンク数が多ければ重要だろうとされるGoogleの性質を悪用してあるため、深い階層に知らないうちに添付されている添付ファイルの場合、発覚が遅れる可能性が高い。新しいタイプのspamを確認しました。これは、PukiWikiのファイル添付機能を使って何らかのHTMLを表示させ、スパム先でその添付ファイルに直リンクさせるというもののようです。これは、自分のサイトのトップページが異常に増えていたので調査したところ発覚しました。添付されていたファイルの内容は化けて実害は無いようでしたが、一応全ページにファイル添付できるwiki性質を考慮すると、今後も被害の拡大が予想されます。リファラーを解析し、調査してみた結果、すでにいくつかのPukiWikiサイトでも同様の被害にあっているようです。ファイルが添付されるページは、必ずしもトップページというわけではないようです。urlとして(脆弱な設定の)wikiを狙うというのは一つの方法として確立されているはずで、恒久対策は、第三者に対する添付ファイルを禁止することでしょう。この件は検索エンジンとは絡まないと考えているのですが、検索エンジンの関与というのはどこからそのように思われたのでしょうか。06:17:36Googleの検索結果ですが、アドレスをよく見てください。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になっていますが、明らかに添付ファイルの内容がクロールされたように思われます。変なファイルがアップされたときに、それを削除するまでに1日もたってないのに、これだけのアクセスが集中し、その検索元をみると、ページではなく添付ファイルの内容にヒットしているという事象は問題だと思います。08:04:23Logueさんの触れている話題(htmlファイルへを添付し、そこへのアクセス増が負荷に)に近そうな事例を見つけました。あるかどうかと、中身がHTMLであるかどうかは無関係でしょう。検索エンジンやWebブラウザによっては、拡張子を無視して独自に中身を判断する可能性があります。後者の具体例はIEです。18:03:45今週に入ってから異常な量のスパムを確認しました。その多くは、henohenoさんの言うように基本的なセキュリティ不足が原因となっているのはわかります。今回のスパムは、添付ファイルや設定ミスによる脆弱性が、他のWikiサイトにも被害を与えるという点で深刻なものです。他のWikiサイトをみていると、該当添付ファイルの再投稿もかなり高い頻度で再添付されているようです。Wikiで添付ファイルリストを見ると、その激しい攻防が見て取れます。22:55:38調査していたところ、IP:85.17.103.104から、070110-?-g6?.htmlという形式の名前のファイルをあちらこちらの添付可能なwikiにアップロードするロボットを確認。怖いのは発覚を遅らせるもしくは、内容を更新するため数分間隔で内容が微妙に異なる同一名のファイルを再添付している模様。被害に遭っているwikiサイトの添付ファイルのバックアップの履歴をみるとすごいことになっています!添付されたファイルの内容は、ポルノ系のワードが多く登録されていました。いくつかの亜種がありますが、このファイルを開くと任意なサイトに飛ばされます。NF1();</script>このようなソースで、かなり難解になっています。%27%29%3b'));</script>のように完全に符号化されているタイプも確認しました。本件を厄介に思われているのは良く伝わっています。問題を切り分けるテクニックが今回あまり活かされておらず、結果的に既存の話題を冗長に展開されている様に思えるのが悲しいです。私は誰がツッコミ担当になっても良いと思っています。Wikiの特性をうまく活用して下さい。前提として、セキュリティホールを埋めると言うことは、失敗する可能性をゼロにする事と同じです。11:24:34(1)「添付ファイル機能を第三者に公開する」設定となっているWebサイトを攻撃側が流用する件。するようなテクニックの(労力が低いタイプの)亜種です。添付ファイルにはまた厄介な特性がありますから、第三者に添付される可能性をゼロにするか、添付された内容を適切に検証する体制を用意できると証明できないならば、どのような対応も無意味です。した話題は以前から取り上げられているはずです。11:24:48(2)攻撃側がコンテンツにキーワードや、もし可能なら(検出のしにくい形で)JavaScriptを埋め込む件。ここではあまり話題になっていなかったかもしれませんが、1の際に使われる一般的なテクニックなので私には驚きはありません。このテクニックは一つではないので、もし興味があれば、専用のBugTrackに参考としてまとめるのが今後のためになると思います。11:25:00(3)結果的に複数のIPアドレスを発信元にする件。日常的に(結果的に)IPが偽装されている現在では(手を抜いた攻撃者以外には)残念ながらもう(永続するという意味の)決定的な情報ではありません。一定期間ないし一定の手順で自動的にアクセスを妨げるという防御側のテクニックが存在しており、部分的に効果があったり、なかったりするのは既知の通りです。listの運用やその手法自体にあります。11:25:13(4)検索エンジンのクローラーの影響を下げたいというSEO的な願望。)技術的な確証がありません。今回の根本的な原因である1の部分に穴があるのであれば、きっかけが無くなりませんから(確率的に)無意味です。11:25:28いえ、私はスクリプトに問題があるからどうにかしてくれと言ってるつもりはありません。簡単な対処法である程度被害を食い止める事ができるので注意を呼びかけて欲しいと言いたいのです。数分単位でファイルの削除と再添付を繰り返す上、直リンクを繰り返しているのでこれまでのwikiスパムと比較してサーバーへの負荷が大きいのではないでしょうか?しかし、ファイル添付に限定してCHAPTCA採用してもいい気が・・・。12:47:09こんにちは。見てなかったので、全然気づきませんでした。サーバに負荷かけてたらしく止められてやっと気付きました。すごい危険ですよね・・・。ゆーのはメンテしないといけないんだなぁ。16:25:55追加報告です。先ほどの85.17.103.104からのアクセスを弾いたところ、ファイルを添付するような行動はみられなくなりましたが、依然としてアクセスが異常に増大している点と、リンク元に被害にあったほかのWikiからの異常なアクセスが目に付きました。サーバーログを見てみると、unknown.hostforweb.comからのアクセスおよび、User-AgentがWWW-Mechanize/1.0のアクセスが異常に増大している点が見受けられました。そこで、85.17.103.104以外に、この2点を制限したところ、普段通りのアクセス数に近くなりました。攻撃者は、ファイルの多重添付以外に、別の場所に設置した単純なスクリプト(おそらく、cronで定期的に動かしていると思われる)によるリファラースパムも同時に行っていると推測できます。攻撃者は、なぜ、このスクリプトのUser-Agentを偽造しないのか疑問に思います。アクセス元解析に利用しているTrackfeedのサービスの性質(JavaScriptで環境変数を取り込む)からは、このようなwikiサイトからのリファラーは一切記録されておらず、このことから推測すると攻撃者の意図はJavaScript型アクセス解析に足跡が残らないようにするために、このような処置をした可能性があります。(反対に、PukiWikiのリンク元記録はサーバーで処理するため残る)unknown.hostforweb.comについてのwhoisをしてみても結果が奇妙です。このunknownが含まれるホストについて、少し気になったので調べてみましたが、どうやらこれは、正しいIPアドレスの逆引きホスト名が登録されていないという意味らしいです。なると、攻撃者はこのhostforweb.comの脆弱性を踏み台にしてリファラースパム行為を行っているものと推測できます。別のサーバサイドスクリプトからPukiWikiの内容に干渉できる可能性は低いと思いますが、unknown.hostforweb.comに限らず、unknownを名前に含むホストは、すべて弾いてしまったほうがいいかもしれませんね。20:50:51お疲れ様です。攻撃側が単純なツールを使っている場合、特に工夫せずともJavaScriptは実行されないでしょうから、JavaScriptについては気にされなくて良いかと思います。いうのはPOSTした相手のIPアドレスを逆引きした結果ですね。DNSサーバーがたまたまそのような答えを返しているのではないでしょうか。ついてはうまく行くかもしれませんが、他は期待外れに終わると思います。01:04:20ホストごとに異なる名前を返す例を沢山ご存知のはずです。ISPにぶらさがっている一般ユーザーのIPアドレスとか。01:06:45あー、そうでした。unknownって書いてあったのでメールの送受信におけるunknownホストと混同していたみたいです。気がかりになるのは、ここの記事で、unknownは未使用アドレスに多いとかかれているところです。01:14:43今回気になるのは「他のWikiからの異常なアクセス」という下りです。01:10:21まったくないです。2/3のリンク元のwikiは、ファイル添付された形跡や、場合によってはページすら作られた形跡がない、全く関係ないリファラーでした。先ほどJavaScriptのアクセスログには一切これは残っていません。ランダムにwikiサイトのアドレスを組み合わせているのではないでしょうか。先ほどのアクセス制限をすることで、ぴたりと止みました。パッチを当てて設定したら、htmlの添付スパムは防げました。別件のSPAMを見かけましたら、お知らせください。崩れた数字を表示させて人間かどうかチェックするというアイディアをさっくり書いて見た。21:26:03崩れた数字じゃなくて質問内容も楽しめる唐揚げ方式にしてみました。09:34:33a要素にrel="nofollow"属性を付加する事でPageRankへの反映を抑止するという対策法。14:34:31盛り込みます。10:46:48「プレビュー」は残して、サブミットボタンを複数(ダミー)にするアイデア。13:50:44事前に必ずプレビューを見させるとか、ログインを必要とするような仕掛けがあっても、SPAMが入っているところには入っているようです。23:01:45editプラグインの名前を変えたらどうでしょうか。define定義あたりで変えやすくして、気が向いた時に変更するとか...。09:52:53爆撃されています。09:13:53こちらも爆撃されています。3/5以降にBbsページを狙った爆撃が起きているようです。09:23:12またもXOOPS日本公式のWikiがやられていました。ページそのものは修正済みなので、バックアップの方にリンク貼っておきます。13:20:15あ、これってさっきorgにきたのと同じですね。16:01:36あら、消えた...。本物のSPAMという意味で書いたつもりだったのでした。こちらこそ慌てさせてすいません。17:38:31(tracker関連を別項目に分けました。対処すればいいのか、途方にくれています。まで連絡をお願いします。Wikiの様に、編集認証でブロックする(そのアカウントはユーザーと共有する)のが手早いのではないかということで、ひとまずその旨連絡しました。07:23:44台湾のcandyzさんの所も、SPAMがひどくてトップページをPukiWikiではなくした模様。同じ対応をとりあえずアドバイス。20:33:06最近BugTrackへのSPAMが多いですねぇ。パターンから見て、ご丁寧にもフォームから投稿しているっぽいですね。20:36:06そうですね。踏み込んだ(実践的な)SPAM対策がさらにいくつか必要になってきている様です。次のリリースまでの間に取り組むべき結構重たいテーマになると思います。SPAMをみんな模索している(一部の人はIPの判定やNGワードで全て解決すると思っている)状態で、ちゃんと役に立つ実装を作って、管理者が設定管理地獄に陥らないようなものじゃないといけませんから。00:33:11とりあえず、こちらでは、プロクシからの投稿のみ禁止することにしました。<limit>を入れているわけは、検索用クロウラーまで弾いてしまう可能性があることと、何も閲覧する上プロクシ使われることで迷惑なことはないと思ったためです。[F]</LimitExcept>ただ単に掲示板用のプロクシキックのスクリプトをRewriteCondで書き直しただけで、文法に間違いとかありそうですが、それなりに効果はあるかと。Torを悪用したbotの対処方法が思いつかない・・・。20:12:04日本語が読める相手以外除外してしまう方法。