web-dev-qa-db-ja.com

Mediawikiでのスパムリビジョンの大量削除

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

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

spammediawiki
15
Andrew Bolster

Export-and-reinstallメソッド danlefreeで推奨 を使用したくない場合は、 Nuke 拡張機能も便利です。インストール後、特別ページSpecial：Nukeに管理者としてアクセスすると、次のようなフォームが表示されます。

Screenshot of MediaWiki Nuke extension interface

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

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

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

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

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

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

  1. Wikiを 読み取り専用モード に設定します。あなたはnotあなたがデータベースをいじっている間に誰かにwikiを編集してみてほしいと思います。

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

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

    DELETE FROM user WHERE user_id != YOUR_USER_ID;

    あるいは、スパマーがwikiを発見した後に新しい有効なアカウントが作成されなかった場合、最も高い有効なユーザー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のall匿名編集がスパムであることが確実な場合、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 メンテナンススクリプトを実行することで、削除されたスパムリビジョンのコンテンツをデータベースから削除して、そこに不要なスペースを占有しないようにすることもできます。

それがすべて完了したら、すべてが正常に見えることを確認し、そうであれば、読み取り専用モードをオフにします-できれば anti-spam features をインストールした後、問題が再発しないようにします。

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

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

19
Ilmari Karonen

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

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

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

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

5
danlefree

理論的には、MediaWiki拡張機能を記述して、あなたが言及したことを行うなど、MediaWikiインスタンスに対して好きなことを行うことができます。

それと、danlefreeによって提案された「nuke'n'pave」の短い場合、 ser Merge and Delete 拡張機能が便利です。これを使用して、複数のspambotアカウントを単一のアカウントに統合できます。その編集はより簡単に対処できます。

2
sampablokuper

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

2
Rob Kam

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

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

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

1
guaka

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

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

1
Harry Wood

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

0
ow3n