基本的に、私の「プライベート」メディアウィキインスタンスは、幼児の貯金箱と同じくらい安全でした。私は今それを強化しましたが、ランダムに生成された数百のユーザーによって生成された約100ほどの新しいページとリビジョンが残っています。

2部の質問。孤立したページをすべて削除する方法はありますか？特定のユーザー（私）によって作成されていないすべてのリビジョンをロールバックするように言うことはできますか？

danlefreeによって提案されたエクスポートと再インストールの方法を使用したくない場合は、Nuke拡張機能も便利です。インストールしたら、特別ページSpecial：Nukeに管理者としてアクセスすると、次のようなフォームが表示されます。

また、次のような便利な組み込みMediaWiki メンテナンススクリプトがいくつかあります。

• 特定のホスト名へのリンクを含むすべてのリビジョンをロールバックまたは削除するために使用できるcleanupSpam.php

• ファイルにリストされているすべてのページを削除するために使用できるdeleteBatch.php

• rollbackEdits.php（現在のところ、適切なオンウィキドキュメントはないようです）。これを使用して、指定したユーザーのすべての編集をロールバックできます。

データベースへの直接アクセスを使用したスパムのクリーンアップ

データベースを直接操作することで、必要なことを実行することもできます。状況によって詳細は少し異なりますが、基本的な手順は次のようになります。

1. wikiを読み取り専用モードに設定します。データベースをいじっている間に、誰かにwikiを編集してもらいたくないでしょう。

2. ウィキのバックアップを作成します。（いずれにしても、不可逆的な大量削除の前にこれを強くお勧めします。）

3. スパマーによって作成されたすべてのユーザーアカウントを削除します。上記の質問のように、あなたが唯一の有効なユーザーだった場合は、次のようにできます。

   DELETE FROM user WHERE user_id != YOUR_USER_ID;

   あるいは、スパマーがウィキを発見した後に新しい有効なアカウントが作成されなかった場合、最も高い有効なユーザーID番号を見つけて実行できます。

   DELETE FROM user WHERE user_id > LAST_VALID_USER_ID;

   または、phpMyAdminなどの管理ツールを使用して、有効なアカウントを手動で選択し、残りを削除できます。

4. 削除されたアカウントに関連付けられている余分なデータをクリーンアップします。これは厳密に必要というわけではありませんが、これらの孤立したレコードは使い道がなく、削除しないとデータベースが乱雑になります。

   DELETE FROM user_groups WHERE ug_user NOT IN (SELECT user_id FROM user);
   DELETE FROM user_properties WHERE up_user NOT IN (SELECT user_id FROM user);
   DELETE FROM user_newtalk WHERE user_id NOT IN (SELECT user_id FROM user);

5. 有効なユーザーによって作成されていないリビジョンを削除します。

   これは大きなステップです。準備前のすべて、クリーンアップ後のすべて。すべてのスパムアカウントを削除したら、次のことができます。

   DELETE FROM revision WHERE rev_user > 0 AND rev_user NOT IN (SELECT user_id FROM user);

   Wikiで匿名編集が無効になっている場合（プライベート/テストWikiに強くお勧めします）、上記のクエリですべてのスパムリビジョンを削除することができます。ただし、匿名編集を有効にしている場合は、匿名スパムを個別に破棄する必要があります。

   wikiのすべての anon編集がスパムであることが確実な場合、UID 0によって行われる保存が必要な唯一の編集は、MediaWiki自体（wikiの外部からインポートされたページなど）によって行われます。その場合、次のクエリのようなものが機能するはずです。

   DELETE FROM revision WHERE rev_user = 0 AND rev_user_text BETWEEN '1' AND '999';

   これにより、ユーザー名が（あいまいに）IPv4アドレスのように見えるUID 0によるリビジョンが削除されます。つまり、1〜9の数字で始まります。

   ウィキに実際の正当なアノンの編集がある場合は、もう少し創造的になる必要があるかもしれません。正規の未登録エディターが使用するIPアドレスの数が制限されている場合、AND rev_user_text NOT IN ('1.2.3.4', '5.6.7.8', '9.10.11.12')上記のクエリのような句を追加して、それらのIPによる貢献を削除から除外できます。たとえば、AND rev_user_text NOT LIKE '192.168.%'特定のプレフィックスで始まるIPアドレスからのすべての編集を保存するなどの条件を追加することもできます。

6. 上記のクエリはスパムリビジョンを削除します（ただし、そのコンテンツは引き続きtextテーブルに残ります）が、page_latest影響を受けるページのフィールドは存在しないリビジョンを指します。これにより混乱が生じる可能性があるため、修正することをお勧めします。

   まず、page_latestすべてのページの列を消去する必要があります。

   UPDATE page SET page_latest = 0;

7. 次に、attachLatest.phpメンテナンススクリプト（推奨。--fixスクリプトが実際にデータベースを変更するようにパラメーターを使用すること）を実行するか、手動のSQLクエリを使用して、列を再構築します。

   UPDATE page SET page_latest =
       (SELECT MAX(rev_id) FROM revision WHERE rev_page = page_id);

8. 最後に、有効なリビジョンが見つからなかったすべてのページを削除します（スパマーによって作成され、有効なコンテンツがなかったため）。

   DELETE FROM page WHERE page_latest = 0;

9. 最後に、rebuildall.phpメンテナンススクリプトを実行して、リンク、テキストインデックス、および最近の変更テーブルを再構築します。また、purgeOldText.phpメンテナンススクリプトを実行して、削除されたスパムリビジョンのコンテンツをデータベースから削除し、不要なスペースを占有しないようにすることもできます。

それがすべて完了したら、すべてが正常に見えることを確認し、そうである場合は、読み取り専用モードをオフにします。問題が再発しないように、スパム対策機能をインストールした後に願っています。

小さなウィキの場合、QuestyCaptcha拡張機能を強くお勧めします。これにより、シンプルなカスタムテキストベースのCAPTCHAを構成できます。トリックは、すべてのウィキに独自の質問があるため、スパムボットがそれらに正しく回答するようにプログラミングすることは、ほとんど利益を得ずに多くの作業になることです。数回XRumerに見舞われた後、自分のwikiにインストールしましたが、それ以来スパムは見られませんでした。

追伸 私はこれらの手順を使用して、小さなWikiから同様に多くのユーザーによって作成された約35,000のスパムリビジョンを削除しました。すべてがうまくいきました。この特定のケースでは、ウィキ（残念ながら！）が匿名編集を許可せず、スパマーがウィキを見つける前にほとんどすべての正当なユーザーが作成されたため、最初にすべてのスパムアカウントを削除してから、すべてのリビジョンを削除できました彼らが作成しました。（最初に1つの正当なアカウントを誤って削除したため、バックアップから復元し、プロセスをより慎重にやり直さなければなりませんでした。）実際に実行した結果をよりよく反映し、もう少し汎用的にするには、上記の手順を更新しました。

この状況を処理する最も簡単な方法は（nuke'n'paveを気にしない場合）、ユーザー名で作成または編集されたすべてのWikiページをエクスポートし、Wikiを再インストールして、生成したエクスポートファイルをインポートすることです。

このコンテキストでの「再インストール」とは、次のことを意味します。

1. 自分で作成した記事をエクスポートします（おそらくWikiSysopユーザーまたは同様のユーザーとしてログインしています）
2. MWデータベースを削除する
3. 空のMWデータベースを作成する
4. LocalSettings.phpファイルを安全な場所にコピーします
5. /config/ディレクトリを再アップロードします
6. 新しいMWデータベースでインストールプロセスを実行します（古い管理ユーザーを再作成することに注意してください）
7. /config/ディレクトリを削除し、古いLocalSettings.phpファイルをMWルートに戻します
8. 手順1で作成したファイルをインポートします

編集：このプロセスで問題が発生した場合や、スパムを削除する別の方法を試してみたい場合は、データベースバックアップ（スパムリビジョンを含む）をプルダウンすることをお勧めします。

理論的には、MediaWiki拡張機能を記述して、MediaWikiインスタンスに対して好きなことを実行できます。

それと、danlefreeによって提案された「nuke'n'pave」の短い場合は、User Merge and Delete拡張機能が便利だと思うかもしれません。簡単に。

この状況を処理する最も簡単な方法は、拡張機能DeleteBatchをインストールすることです。WikiでSpecial：AllPagesを使用して、削除するページ名のスクリプトファイルを取得し、Special：DeleteBatchにロードします。

スパムページが100ページしかない場合は、それほどひどくはしていません。数千のスパムページがあるウィキをクリーンアップする必要がありました。このページでUser：Halzによるいくつかの良いヒントに出会いました：https ://www.mediawiki.org/wiki/User:Halz/Mass_despammingにはさまざまなツールの制限の内訳が含まれています。

一番下には、少し遅くなりますが、スパムの可能性が高いページを見つけるのに役立つSQLクエリがあります。特に、スパマーがウィキを乗っ取った期間を特定できる場合に役立ちます。Halzには、Extension：Nukeのハッキングされたバージョンもあり、大量の削除を容易にするために、こうした種類のクエリ可能なパラメーターを提供します。彼は私に使用するコピーをくれましたが、私は彼がそれを公開したとは思いません。

MediaWikiのSQLを台無しにしないことを強くお勧めします！MediaWikiは、ウィキペディア用に最適化された複雑な獣です。SQLには奇妙なことが起こっており、単純に行を削除すると、一貫性が失われる可能性があります。

プログラミングスキルがある場合は、APIを使用してください。Pywikibotは良い選択です。

それ以外の場合は、maintenance/ディレクトリ内のツールを確認してください。私自身のツールであるmewshを試してみてください（そして、「スパム対策ツール」をtodoとして追加しました）。

私はインストールを引き継ぎ、userテーブルに47,000を超えるスパムエントリとほぼ900,000のスパムを発見しましたexternallinks。Sequel Proを使用して、各テーブルにアクセスし、本物のユーザーが作成したものではないエントリを削除しました。私はスパムを発見しましたexternallinks、page、searchindex、user、watchlist。それはかなり時間効率的でした。私の時間の大半は、削除クエリの実行を待っていました。本物の編集のほとんどは物事の順序の早い段階で行われたため、私は幸運でした。