Zasadniczo moja „prywatna” instancja mediawiki była tak samo bezpieczna jak skarbonka dla małych dzieci. Zaostrzyłem to teraz, ale pozostało mi około stu nowych stron i poprawek wygenerowanych przez setki losowo generowanych użytkowników.

Pytanie 2-częściowe; Czy istnieje sposób na usunięcie wszystkich osieroconych stron? Czy mogę powiedzieć, aby wycofać wszystkie wersje NIE wykonane przez konkretnego użytkownika (mnie)?

Jeśli nie chcesz używać metody eksportowania i ponownej instalacji sugerowanej przez danlefree , może okazać się przydatne rozszerzenie Nuke . Po zainstalowaniu, odwiedzając specjalną stronę Special: Nuke jako administrator, otrzymasz następujący formularz:

Istnieje również kilka wbudowanych skryptów konserwacyjnych MediaWiki, które mogą być przydatne, w tym:

• cleanupSpam.php , którego można użyć do wycofania i / lub usunięcia wszystkich wersji zawierających link do konkretnej nazwy hosta,

• deleteBatch.php , którego można użyć do usunięcia wszystkich stron wymienionych w pliku, oraz

• rollbackEdits.php (który obecnie nie wydaje się mieć odpowiedniej dokumentacji na wiki), którego można użyć do wycofania wszystkich edycji określonego użytkownika.

Czyszczenie spamu przy użyciu bezpośredniego dostępu do bazy danych

Możliwe jest również robienie tego, co chcesz, bezpośrednio manipulując bazą danych. Szczegóły mogą się nieco różnić w zależności od sytuacji, ale podstawowe kroki wyglądałyby mniej więcej tak:

1. Ustaw wiki na tryb tylko do odczytu . Zdajesz nie chce ktoś spróbować edycję wiki gdy jesteś aprowizacji z bazy danych.

2. Utwórz kopię zapasową swojej wiki. (Jest to wysoce zalecane przed każdym nieodwracalnym usunięciem masy.)

3. Usuń wszystkie konta użytkowników utworzone przez spamerów. Jeśli, jak w powyższym pytaniu, byłeś jedynym prawidłowym użytkownikiem, możesz po prostu:

   DELETE FROM user WHERE user_id != YOUR_USER_ID;

   Alternatywnie, jeśli nie zostały utworzone nowe ważne konta po odkryciu wiki przez spamerów, możesz znaleźć najwyższy prawidłowy numer identyfikacyjny użytkownika i wykonać:

   DELETE FROM user WHERE user_id > LAST_VALID_USER_ID;

   Możesz też użyć narzędzia administracyjnego, takiego jak phpMyAdmin, aby ręcznie wybrać prawidłowe konta i usunąć resztę.

4. Wyczyść dodatkowe dane związane z usuniętymi kontami. Nie jest to absolutnie konieczne, ale te osierocone rekordy są bezużyteczne i po prostu zaśmiecą bazę danych, jeśli ich nie usuniesz:

   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. Usuń wszelkie poprawki, które nie zostały wykonane przez prawidłowego użytkownika:

   To jest wielki krok; wszystko przed przygotowaniem, wszystko po sprzątaniu. Po usunięciu wszystkich kont spamowych możesz po prostu:

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

   Jeśli Twoja wiki ma wyłączoną anonimową edycję (którą zdecydowanie polecam dla prywatnych / testowych stron wiki), powyższe zapytanie powinno wystarczyć, aby pozbyć się wszystkich wersji spamu. Jeśli jednak włączyłeś edycję anonową, będziesz musiał osobno usunąć anonimowy spam .

   Jeśli masz pewność, że wszystkie edycje anon na twojej wiki są spamem, jedynymi edycjami dokonanymi przez UID 0, które mogą być konieczne do zachowania, są te dokonane przez samą MediaWiki (takie jak strony importowane spoza wiki). W takim przypadku powinno działać coś takiego jak następujące zapytanie:

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

   Spowoduje to usunięcie wszelkich poprawek przez identyfikator UID 0, w których nazwa użytkownika wygląda (niejasno) jak adres IPv4; oznacza to, że zaczyna się cyfrą od 1 do 9.

   Jeśli Twoja wiki ma kilka prawdziwych poprawek anonowych, być może będziesz musiał być bardziej kreatywny. Jeśli liczba adresów IP wykorzystywanych przez legalnych niezarejestrowanych redaktorów jest ograniczona, możesz po prostu dodać klauzulę podobną AND rev_user_text NOT IN ('1.2.3.4', '5.6.7.8', '9.10.11.12')do powyższego zapytania, aby wykluczyć wkłady tych adresów IP z usuwania. Możesz również dodać warunki, na przykład, AND rev_user_text NOT LIKE '192.168.%'aby zapisać wszystkie zmiany z adresów IP zaczynające się od określonego prefiksu.

6. Powyższe zapytania pozwolą pozbyć się wersji spamu (chociaż ich zawartość nadal pozostanie w texttabeli), ale pozostawi page_latestpole stron, których dotyczy problem, wskazując na nieistniejącą wersję. Może to powodować zamieszanie, więc lepiej to naprawmy.

   Najpierw musimy wyczyścić page_latestkolumnę dla wszystkich stron:

   UPDATE page SET page_latest = 0;

7. Następnie przebudujemy kolumnę, uruchamiając skrypt konserwacyjny attachLatest.php (zalecane; pamiętaj, aby użyć --fixparametru, aby skrypt faktycznie zmienił bazę danych) lub ręcznie zapytać SQL:

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

8. Na koniec usuniemy wszystkie strony, dla których nie można znaleźć prawidłowych poprawek (ponieważ zostały utworzone przez spamerów i nigdy nie zawierały żadnej prawidłowej treści):

   DELETE FROM page WHERE page_latest = 0;

9. Dla ostatecznego efektu odbuduj łącza, indeks tekstowy i tabele ostatnich zmian, uruchamiając skrypt konserwacyjny rebuildall.php . Możesz również usunąć zawartość usuniętych wersji spamu z bazy danych, aby nie zajmowały one tam niepotrzebnego miejsca, uruchamiając skrypt konserwacyjny purgeOldText.php .

Gdy to wszystko zrobisz, sprawdź, czy wszystko wygląda dobrze, a jeśli tak, wyłącz tryb tylko do odczytu - mam nadzieję, że po zainstalowaniu niektórych funkcji antyspamowych zapobiegnie to ponownemu wystąpieniu problemu.

W przypadku małych stron wiki bardzo polecam rozszerzenie QuestyCaptcha , które pozwala skonfigurować prosty niestandardowy tekstowy CAPTCHA. Sztuka polega na tym, że przy każdej wiki posiadającej własny zestaw pytań zaprogramowanie spambota, aby poprawnie na nie odpowiedział, byłoby bardzo pracochłonne i przynosiło niewielkie korzyści. Zainstalowałem go na mojej wiki po tym, jak kilka razy zostałem trafiony przez XRumer i od tamtej pory nie widziałem spamu.

Ps. Skorzystałem z tych instrukcji, aby zbadać około 35 000 wersji spamu stworzonych przez równie wielu użytkowników z małej wiki . Wszystko poszło dobrze. W tym szczególnym przypadku wiki (na szczęście!) Nie pozwoliła na anonimową edycję, a prawie wszyscy legalni użytkownicy zostali stworzeni, zanim spamerzy znaleźli wiki, więc mogłem dość łatwo najpierw usunąć wszystkie konta spamowe, a następnie wszystkie poprawki stworzyli. (Na początku przypadkowo usunąłem jedno uzasadnione konto, więc musiałem przywrócić dane z kopii zapasowej i ponownie wykonać proces ostrożniej.) Zaktualizowałem powyższe instrukcje, aby lepiej odzwierciedlić to, co właściwie skończyłem, i żeby być nieco bardziej ogólnym .

Najłatwiejszym sposobem poradzenia sobie z tą sytuacją (jeśli nie masz nic przeciwko nuke'n'pave) byłoby wyeksportowanie wszystkich stron wiki utworzonych lub edytowanych przez twoją nazwę użytkownika, przeinstalowanie wiki i zaimportowanie wygenerowanego pliku eksportu.

„Ponowna instalacja” w tym kontekście oznacza:

1. Eksportuj artykuły utworzone przez Ciebie (prawdopodobnie zalogowany jako użytkownik WikiSysop lub podobny)
2. Upuść bazę danych MW
3. Utwórz pustą bazę danych MW
4. Skopiuj LocalSettings.phpplik do bezpiecznej lokalizacji
5. Ponownie prześlij /config/katalog
6. Uruchom proces instalacji na nowej bazie danych MW (pamiętaj, że będziesz chciał ponownie utworzyć starego administratora)
7. Usuń /config/katalog i przenieś stary LocalSettings.phpplik z powrotem do katalogu głównego MW
8. Zaimportuj plik utworzony w kroku 1

Edycja: Możesz usunąć kopię zapasową bazy danych (w tym wersje spamu) na wypadek problemów z tym procesem lub chciałbyś poeksperymentować z alternatywnymi sposobami usuwania spamu.

Teoretycznie możesz napisać rozszerzenie MediaWiki, aby zrobić co tylko chcesz z instancją MediaWiki, w tym zrobić to, o czym wspomniałeś.

Poza tym i skrótem „nuke'n'pave” sugerowanym przez danlefree, przydatne może być rozszerzenie User Merge i Delete : możesz go użyć do konsolidacji wielu kont spambot w jedno konto, którego zmiany można następnie rozwiązać bardziej z łatwością.

Najłatwiejszym sposobem na poradzenie sobie z tą sytuacją jest zainstalowanie rozszerzenia DeleteBatch . Użyj Special: AllPages na swojej wiki, aby uzyskać plik skryptu z nazwami stron, które chcesz usunąć, i załaduj go do Special: DeleteBatch.

Jeśli to tylko sto stron ze spamem, nie robisz zbyt źle. Musiałem oczyścić wiki, które zawierały tysiące spamowanych stron. Na tej stronie znalazłem kilka dobrych wskazówek użytkownika: Halz: https://www.mediawiki.org/wiki/User:Halz/Mass_despamming, w tym zestawienie ograniczeń różnych narzędzi.

Na dole udostępnił przydatne zapytanie SQL, które działa nieco wolno, ale pomaga znaleźć strony, które najprawdopodobniej są spamem, szczególnie jeśli możesz określić okres, w którym wiki została przejęta przez spamerów. Halz ma również zhakowaną wersję Extension: Nuke, która przedstawia tego rodzaju parametry z możliwością zapytania w celu łatwego masowego usuwania. Dał mi kopię do wykorzystania, ale nie sądzę, żeby ją opublikował.

Zdecydowanie odradzam używanie SQL w MediaWiki! MediaWiki to złożona bestia, bardzo zoptymalizowana pod kątem Wikipedii. W SQL są dziwne rzeczy i jeśli po prostu USUŃ wiersze, rzeczy mogą stracić spójność.

Jeśli masz jakieś umiejętności programowania, przejdź przez interfejs API. Pywikibot to dobry wybór.

W przeciwnym razie sprawdź narzędzia w maintenance/katalogu. Możesz wypróbować moje własne narzędzie, mewsh, aby Ci w tym pomóc (i właśnie dodałem tam „narzędzia antyspamowe” jako todo).

Przejęłem instalację i znalazłem w usertabeli ponad 47 000 wpisów spamu i prawie 900 000 spamu externallinks. Użyłem Sequel Pro i odwiedziłem każdą tabelę i usunąłem wpisy nieprzeznaczone przez autentycznych użytkowników. Znalazłem spamu w externallinks, page, searchindex, user, watchlist. To było dość oszczędne czasowo; większość mojego czasu czekało na uruchomienie zapytań kasujących. Miałem szczęście, ponieważ większość autentycznych zmian dokonano wcześnie w kolejności rzeczy.