トラブルと言っても軽微な物から洒落にならない物まで色々有ります。当方の管理者としての対応方針をその分類によってまとめてみたいと思います。

　先日Oblivion関連ファイルのアップローダであるshy.jsphr.netさんの所にウイルスがUPされるという事件が発生しました。この記事はそれに触発されて書いたものです。

　項目ごとにその性質を個人的な観点から3段階で分類しています。
事前対策難易度：事前に予防的に対応できるか
事後対応難易度：事後に対策が取れるか
迷惑度：利用者に対する迷惑
危険度：利用者へのSecurityの上での危険性

荒らし
　基本的に『荒らす』ことが目的な事例です。愉快犯や個人的なフラストレーションの発散を行なう者による物をここに含めます。

【迷惑度：2】
　荒らしに於いてはSiteの大事なコンテンツである記事の削除や改竄を行なう為、迷惑極まりない物です。利用者側としては当然ですが、管理者にとっても事後対応(復旧や通報)が必要になるので当然のように迷惑です。

【事前対策難易度：2】
　現在のそういう輩は基本的に技術が高いわけではないのでWeb Program(BBSやWiki)のシステムの枠組みの中でしか行動しません/出来ません。つまり、致命的な悪さをされることは無いのですが、逆にシステムの中で許容できる行動を行なっているので事前に予防する事は困難です。確かに連続投稿規制やNG Word等は可能ですが、大抵はそれが善意の利用者に不便をもたらします。よってこれを予防したいならばSite運営の方針を考えた方が効果的と思います((『Siteの質(管理運営方針、若しくはSiteの雰囲気)と利用者の質はかなり相関性がある』ものだと当方は思っています。『恨みを買わない事』『恨みを買うような不誠実な管理を行なわない事』『きめ細かな管理をしている(様に思わせる)姿勢』が低コストありながらも効果が一番高いと思います))。

【事後対応難易度：1】
　逆に事後対応は簡単です。きちんとログを取ってさえ居れば荒らしを行った者の特定は容易です。そういった人の多くは『スキル』が低い為IPの偽装も行なわず/行なえずに悪さをして自分で尻尾を出しています¹。あとはISPに通報するだけです。ISPの対応が不誠実な事も多いと思いますが大昔に比べればずいぶんマシになったものです。それでも効果がない場合はISPごと投稿禁止にしてしまうしかありません。そこまでダメダメなISP、若しくは骨のある荒らしに遭遇した事は有りませんが。
　荒らされた内容の復旧は大抵は比較的容易です。これは荒らしがシステムを利用した行動しかしない/出来ない事に尽きます。Web Programによってはバックアップをきちんととるものも多く、そこから巻き戻すだけで復旧できてしまいます。そうでなくとも管理者側で定期的にログをバックアップしていさえすれば復旧は困難では有りません。面倒なだけです。
　因みに、当方管理下のSiteへの荒らしは例外なくISPへの対応依頼を行なっています。厳しいかもしれませんが自身のやった事の責任を取る事は当然の事ですしそういう姿勢を見せる事は抑制力にも繋がるからです。対応依頼用のメールのテンプレートや作業手順をある程度定型化そういう輩は大抵それを知らずにやる事が多いでしょうが。

【危険度：1】
　こういった輩は上述の通り『スキル』が低いのでSecurity上の危険性は殆どないに等しいです。せいぜい、ブラウザクラッシャーやウイルスのアドレスを張る位しか出来ないでしょう。大して脅威ではありません。寧ろ、通報時に強い対応を要求できる良い理由です。

【補足】
　現在発生する物の殆どは『低スキル』な者が行なう事が多いので大した重大性は有りません。攻撃者がScript kiddie位までレベルが上がると多少厄介ですが、『DUKE』の類が流行った時代に比べればISPの対応や法制度が幾らかはマシになっているので気にするほどではないでしょう。ただ、『荒らし』の行動者は大抵人間の手作業(若しくは手作業での攻撃対象への対応)である為、後述のspamのように機械的に弾く事は困難です。人間の目で見れば明らかに不適切な物であってもProgramでは簡単に識別できないという好例です。結局、予防の為の対策よりも事後対応の方に重点が置かれてしまう事はやむをえない事でしょう²。

悪意の改竄者
　これは『荒らし』とは異なり、攻撃者が利益を得る為にSite利用者に明確な害を与える物です。具体的には個人情報を奪取するウイルスをSiteに潜り込ませる等です。他人の作によるウイルスやブラウザクラッシャーのアドレスをSiteに投稿する行為はどちらかというと荒らしに含まれるのでここではふれません。

【迷惑度：3】
　盗む情報はNet上のサービスのID&Passwordやクレジットカードの情報が多いようです。それらのアカウント等を持ってない人にはなんら被害は発生しませんが、そうでない場合は極めて危険です。

【事前対策難易度：2】
　改竄の手法は2パターン有ります。1つ目は『通常の投稿に危険なMalwareのアドレスを潜ませる』で、もう一つは『ServerやWeb Program自体のセキュリティホールを利用してMalwareを埋め込む/Malwareに誘導する』ものです。
　前者の手法も多く見られます。それは恐らくMalwareのアドレスをばら撒くだけなら技術も不要故人海戦術を採用できるからなのでしょう。即ち前者は大抵は『低スキル』なので拒絶する事はかなり容易です。投稿されるMalwareのアドレスは大抵個性が有りますし、攻撃者が外国人であることはそれが即ち投稿情報に現れる事が多いからです³。ただ、Malware置き場として改竄されたWeb Serviceを利用する事も多く、これは管理上の悩みの種となっております。たとえばFC2 blogですが、ここはたびたびそのような悪意の攻撃者によりMalware置き場として利用されています。FC2 blogが大手である事(しかし、管理側の対応が甘すぎる事)を逆手に取った物でしょう。当方の管理Site群ではそのドメインを含むアドレスは投稿できないようにして有ります。FC2 blogはかなりの方が利用している為、当方のSite利用者にとっては不便((参考アドレスとして紹介する等が出来ない))なのですが、Site利用者の安全を考えるとどうしても解除をする気にはなりません⁴。
　このバリエーションとしてアップローダやWikiの添付ファイルにMalware等をUPするという事例も有ります。これはファイル自体の危険性は人間がチェックしなければ判断できないものであり、事前予防は簡単では有りません。Malware等であればサーバ側にアンチウイルスプログラムを走らせる事で対応できなくもありませんが、共用サーバでは利用できるものではありません。更にMalwareではない不正なファイルをファイル交換目的でUPする事例もあり、その場合は更に対策が厳しくなります⁵。当Siteではファイル添付等の設定を絞る事でこれへの対策を行なっています⁶。
　後者の『ServerやWeb Program自体のセキュリティホールを利用してMalwareを埋め込む/Malwareに誘導する』に関しては当方側ではあまり対策は出来ません。共用サーバを利用している関係上、サーバ側の脆弱性に関してはレンタルサーバ管理会社を信用するしか有りませんし、Web Programに関してはその開発サイトのアナウンスに注目し最新のものに出来るだけ早く更新する事しか出来ません。とはいえ、利用しているレンタルサーバ会社のさくらさんはそう信用に足る所だと思っていますし、多くの攻撃者は機知のセキュリティホールを狙う為、大抵は既に対策パッチやバージョン更新が行なわれているものです。よって対策はそう難しいものでは有りません。

【事後対応難易度：3】
　これは犯行者の多くが海外の者である為、ISP通報が余り意味を成しません。欧米ならまだしも中国等の場合は期待するだけ無駄です。

【危険度：3】
　当然の事ながら利用者にとっては危険きわまり有りません。

【補足】
　この類は近年とみに増加しています。良くある事例はネットゲームのアカウントを盗み、キャラやアイテムをリアルマネーで売り飛ばして利を得るという形態です。しかも犯人は大抵海外⁷である事や、不十分な法制度⁸の為、本質的解決は絶望的です。
　結局Site管理側では一定の対応しか取れない為、Site利用者側できちんとセキュリティ対策を行なう事が重要です。Microsoft Updateは当然の事ながら、AntiVirusプログラム、Personal Firewallの導入、各種プログラムの更新⁹。

spam
　皆さんおなじみ？のspam。Wikiや掲示板への宣伝spamがここに含まれます。尚、用語としてのspamは大文字ではなく小文字で書く事が望ましいようです¹⁰。

【迷惑度：3】
　最近ではspamへの対策が弱い掲示板やWiki・blogのコメント欄はすぐさまspamで埋め尽くされてしまいます。しかも自動プログラムによって行なわれるので人間の手での復旧作業は人間側が消耗するだけになってしまいます。

【事前対策難易度：1】
　自動プログラムが行なう物であるため、対策は容易な部類に入ります。海外のIPならば一気に範囲で規制してしまえばよいですし、NG Wordも効果が有ります。日本のものは少なく海外のものが多いので投稿内容に日本語が含まれない事も投稿拒絶条件に出来ます。また自動プログラムである関係上、攻撃側が吐く環境変数もかなり特徴的で網に掛けやすいものです。更に、大抵のプログラムはFormを解析後に『textarea』に投稿内容を入れて送信してきますので通常のブラウザからは見えないダミーの『textarea』を作成し、そこに入力があった場合はspamプログラムの投稿であると断定できたりもします。
　日本のspammerの場合は多少対策が厄介になりますが¹¹、公開Proxy規制を導入する事でISP通報が出来る可能性が高くなります。ただ、CSRFを利用したspamの場合はIP規制は意味が有りません。リファラー等を調べる事で利用されている攻撃ページを特定し、そこを管理するところに通報するのがベストでしょう。
　また、spammerはユーザーの多いProgramを良く狙います。大抵のWeb ProgramはそのURIにそれに特徴的な文字列が出るものです¹²。その特徴的な文字列でWeb検索するだけでそのProgramを使用している場所をリストアップできちゃいます。それらは大抵デフォルトで設置されているので一度それへの自動投稿設定を作ってしまえば後は使いまわすだけで楽勝という方法があります。これへの対策も特に面倒では有りません。要は特徴的な文字列が出ないようにすればよいのです。即ちWeb Programの名前やディレクトリ名を没個性的にしてしまえば良い訳です。単純でありながらもきわめて効果的な方法である事を強調しておきます。
　攻撃側は対策が取れている場所に固執するより山ほどあるそうでないSiteにspamを打ち込む方が手っ取り早いでしょうから一定の対策をとるだけで十分でしょう。手動でspamを行う輩はそんなに大したことないのであまり考慮しなくてもOKだったりします。

【事後対応難易度：2】
　海外のものの場合は、対応が面倒であればIP範囲ごとアクセス禁止/投稿禁止にしてしまえばよいでしょう。国内であればログをまとめてISPに通報すれば大抵は対応してもらえます。
　当方の管理Siteではspamと判定した投稿は全てログを取ってあり、NG WordやNG Domainの充実、禁止IP範囲の特定に利用しています。

【危険度：1】
　セキュリティ的な問題はほぼ有りません。

【補足】
　IP規制が誤爆する事も有るのでそれへの対応はまめに行なう必要が有ります。

利用者同士の争い
　歩み寄る為の議論ではなく、ただの口喧嘩がこれです。或いはWikiでの編集合戦等がここに含まれます。

【迷惑度：3】
　空気が悪くなりますので極めて迷惑です。

【事前対策難易度：2】
　Programで対策できるものではありません。明確な対応策も殆ど有りません。数少ない事前に出来る事は『管理者の運営姿勢を明確にしておく』『Siteの空気を良くしておく事』位でしょう。

【事後対応難易度：2】
　混乱が発生した場合は出来る限り公正中立に対応する事としか書くべき事は有りません。

【危険度：1】
　セキュリティ的な問題はほぼ有りません。

【補足】
　当方は基本的に『管理人は黒子であり、利用者の環境を良好に保全するのが仕事』という方針で行動しています。ですが全くの放任という訳ではありません。常日頃で発言していますが『Wikiや掲示板は設置するだけ育っていくものではない。仮に育ったとしても大抵はそのエントロピーの増大は著しいものになる。よって或る程度の管理者の方針と管理が極めて重要』だと思っています。これもどこかで書きましたが、『Wikiや掲示板の管理は園芸みたいなもの』でしょう¹³。
　加えて、管理者の個性も出来る限り抑え無色透明である事を是としています。個性を出すという事は利用者ウケという点で諸刃の剣であり、その匙加減はとても難しいのです。しかしながらそうでありつつも利用者と管理者の距離を出来る限りなくすような運営方針は重要だと思います。管理者の存在感が希薄すぎるのも良くない事だと思います。どこかで書きましたが、管理者は孤独です。特にWikiや掲示板の管理者はそうです。何か有ったとしても、物が分かった方々は管理者を慮って敢えて言わない、普通の方々は面倒くさいから言わない、物を知らない人は好き勝手にどうでも良い事を言う、そんな状況は良くある事です。孤独感は管理のモチベーションにも影響するものです。よってその為にも距離感をなくす事は重要だと思います。お互いに意思疎通がしやすくなればSite全体の発展にもつながります。勿論、これは上で書いた『個性を抑える』事と微妙に矛盾しますので簡単な事ではないのですけれども¹⁴。

管理者の行方不明
　利用者だけではなく広い範囲に迷惑を及ぼすものです。

【迷惑度：3】
　利用者にとっては極めて迷惑です。引継ぎが成されれば良いのですが、大抵はそうではないので後継Siteが現れるまでは利用者に多大な不便を強いることになります。また、後継Siteが現れたとしても基本的にログの移行は困難なので¹⁵後継管理者にも多大な苦労を強いる事になります。加えて、サーバやドメインが有効期限切れでアクセスできなくなる場合はログのサルベージが極めて困難に成ります。
　利用者以外にも害を成します。最近では管理されてないWiki/掲示板/blogはspammerの格好の餌食であり、spamによるWeb上の貴重な情報の埋没は一般のNetユーザーにも不利益を与えます。また、ただのspamなら良いのですが個人情報奪取のトロイ等のアドレスのspam行為も少なくありません。更にWeb Programのセキュリティホールの修正も成されないため有害なクラックが行われる可能性も有ります。

【事前対策難易度：2】
　簡単な様で難しいのが事前対策です。管理のモチベーションを出来る限り保てるよう工夫するのもひとつの方法です。具体的な策が取り立ててある訳ではないのは問題ですが。ただ、出来る限り自動化を導入するのはある程度有効と思います。
　当方はWikiに関してはある対策をとっています。それは一定期間管理者がログイン作業をしなかった場合、Wikiの生ログをDL出来るようにする仕組みを設置しています (例：http://wiki.oblivion.z49.org/livingcheck.php )。

【事後対応難易度：-】
　発生してからでは遅いです。

【危険度：2】
　利用者の安全を脅かす可能性は有ります。

【補足】
　Oblivion関連のWikiで2つは現在も『避難所』を付けたままです。これはこの項目で触れた事も関連します。
　それらのWikiは以前はvaglemさんという方がそれらのWiki(以降、本家と略す)を運営されていました¹⁶。しかしながら気づいたらいつのまにか管理人さんの消息が不明になってしまいました。とりあえず大きな問題が無かったものの、今後に不安を感じた為後継Wikiの立ち上げを2007年の暮れに実行、受け皿を作りました。勿論面倒な仕事である事は重々承知していましたが、元々Web関連の技術には強い関心を持っていた上にコミュニティの発展を裏方として支える事が出来るというのが決断理由でした。
　簡単に『受け皿を作った』と書きましたが、結構面倒がありました。例えば本家はPukiWiki plus!を利用していましたが、当方は無印のPukiWikiを採用しました。それは元々PukiWikiの方に習熟していたということが大きいですが、派生版よりは本家のほうを使ったほうが良いという判断もありました。何らかの問題があっても自力で修正できるという目算もありましたし。ただ、このことにより一部のWiki文法互換性の問題が発生し、ログ移植の際に手間になったことがマイナス点でした¹⁷。オリジナルのログの取得も手間が掛かりました。これは自前で書き捨てScriptを書いて何とかしました¹⁸。
　まぁ上記のように管理側ではかなりの苦労をしました。年末年始の休みを大いに潰して格闘したので初詣に行かなかった記憶があります…。
　現在でも『避難所』の文字を外すことは考えていません。本家は現在はまっさらになっておいますが、未だに検索では本家が引っかかる事がまずひとつの原因です。

Google：http://www.google.co.jp/search?hl=ja&source=hp&q=oblivion+wiki
Yahoo!：http://search.yahoo.co.jp/search?p=oblivion+wiki
Bing：http://www.bing.com/search?q=oblivion+wiki

このような状況では『避難所』の文字列を外すと混乱の元になるのは明らかです。また、本家の管理人のvaglemさんの意思表示が全く無い事も理由です。現在も本家のドメインおよびWikiが稼動している事¹⁹よりvaglemさんが生存している事はほぼ明らかなのですが。

　なんにせよ、この辺の事情と経緯は他山の石として自身への戒めとしています。

最後に
　コミュニティの発展をSite管理者として参加できる機会を頂いた事はとても幸運なことであり、有り難い事だと思います。全ての利用者の方に深く感謝致します。その為にも今回の記事に取り上げたようなトラブル対策に関しては出来る限りの事前/事後の対策を行っていく所存です。

　ここまで読んで頂いた方へのサービス？として、保管している2chの過去ログを一括でDLできるアドレスをお教えいたします。例えばこんな感じです。

　oblivion.z49.org/logs/html-logs-ob.tar.bz2

falloutその他も同じように配置してあります。falloutならhtml-logs-fallout.tar.bz2と成っています。また、他のログ置き場も識別文字列をgameもしくはpcに置き換えるとDLできます。興味がおありでしたらお試しあれ。

　こんな風にログの公開を始めようと思ったのは、検索用INDEXや保管ログの一括更新システムを作ったついで…だったりします(こんな感じ)。同じくこの副産物としてOblivionの日本語化Wikiと翻訳所のアクセスログの更新も同時にアップデートできるようになりました。

1. IP偽装といっても公開Proxy規制で弾ける程度の事しか出来ない。若しくはTrackingを回避するほどの術や知識を持たない [↩]
2. だからこそ逆に『Siteの空気の改善』は重要である [↩]
3. 具体的に言えばIPその他の環境変数 [↩]
4. FC2に於いては改竄後の管理側の対応や情報公開が極めて不十分であると感じた為、解除は不適と判断。改竄の再発もそれを後押しする [↩]
5. 国際的テロ団体が日本のアップローダでファイルをやり取りしていた事例がある [↩]
6. 特にWikiへのファイル添付。ファイルサイズ制限に加え簡易フォーマットチェックを行い画像しか添付できないようにしている [↩]
7. 特に中国 [↩]
8. アカウントはアカウント所有者ではなくアカウント発行側の財産であるという扱いなので、アカウントが盗まれたとしても被害届けが出せない。故に(えてして多く見られるが)発行側が積極的行動を行なわない体質の場合は被害者は泣き寝入りとなる事が多い [↩]
9. 特に最近はFlashやAdobe Readerの脆弱性を攻めるものが多い。巨大化しつつもセキュリティの対応が貧弱なAdobeに過去のMicrosoftの姿を見る人も多い [↩]
10. “SPAM”は商標登録された食品の名前 [↩]
11. IP規制や日本語未使用による拒否が出来ない [↩]
12. 例えば一昔前に流行ったKent WebのJoyfule Noteという掲示板なら joyful.cgi という文字列がURIに出てくる [↩]
13. この点において、Site管理は討論の議長の仕事にかなり似通っていると思います [↩]
14. 当方の実践的な方法としては、必要な場合はアナウンスを欠かさないようにする事や運営情報を色々公開する事が挙げられる。Wikiに必ず運営ページを設置することやこの管理blogの運用がその一例 [↩]
15. 管理者権限等がないと生の形でのログが取り出せない事が多い [↩]
16. vaglem.net上に残っているものがそれ [↩]
17. そのほか、デザイン周りもかなり仕組みが異なったので似せるのが面倒だった [↩]
18. 原理は簡単で、?cmd=list にアクセスしてページ一覧を取得、次にそれぞれのページの編集モードを呼び出し、生のWikiログを表示させ、あとはそこから正規表現で生のWikiログだけをローカルに保存するという感じ。添付ファイルも類似の手法で可能 [↩]
19. 両方とも有料サービスである [↩]