Spam SEO w WordPressie: ukryte linki do kasyn i leków

Jeśli Google wyświetla dla Państwa domeny nieoczekiwane wyniki o kasynach, lekach albo po japońsku, a w przeglądarce witryna wygląda normalnie, trzeba sprawdzić, czy nie chodzi o spam SEO w WordPressie. Takie wyniki mogą świadczyć o trwającym włamaniu albo o spamie, który po czyszczeniu nadal tkwi w indeksie. Spam jest ukryty w kodzie strony albo serwowany wyłącznie Google i osobom wchodzącym z wyszukiwarki. Poniżej: jak zobaczyć witrynę tak, jak widzi ją Google, gdzie ten spam się ukrywa i jak usunąć go z indeksu.

Jak wygląda spam SEO w WordPressie i dlaczego go nie widać

Nie widać go, bo nie jest przeznaczony dla Państwa. Atakującym zależy na reputacji domeny, nie na uwadze odwiedzających. Wstrzyknięty kod często pomija zalogowanych użytkowników oraz osoby wpisujące adres bezpośrednio w przeglądarce.

Najczęściej spotyka się trzy odmiany:

• Ukryte linki (hacklinks). Do stron podrzucane są linki do kasyn, sklepów z lekami lub pożyczek. Zwykle siedzą w bloku display:none, są przesunięte poza ekran albo trafiają do stopki, której nikt nie czyta.
• Japoński spam słów kluczowych (Japanese keyword hack). Tysiące automatycznie generowanych stron z japońskim tekstem i linkami do sklepów. Często mają własną mapę witryny, żeby Google szybko je znalazł.
• Warunkowe przekierowania i cloaking. Kod sprawdza user agenta, adres IP lub referrer. Googlebot dostaje treści spamowe. Odwiedzający, który kliknął wynik w Google, zostaje przekierowany. Właściciel widzi normalną stronę.

Szkody są realne, choć niewidoczne. Pozycje mogą spaść, odwiedzający tracą zaufanie, a Google może marnować zasoby indeksowania na strony ze spamem zamiast na Państwa właściwe podstrony. Jeśli nie ma pewności, czy w ogóle doszło do włamania, warto zacząć od artykułu 12 oznak, że witryna WordPress została zhakowana.

Zobaczyć witrynę oczami Google

Zaczynamy w samym Google. Należy wyszukać site:example.com, przejrzeć wyniki, a potem zawęzić zapytanie:

site:example.com casino
site:example.com viagra OR cialis
site:example.com 激安
site:example.com inurl:.html

Wyniki w języku, w którym Państwo nie publikują, albo wzorce adresów URL, jakich witryna nie używa, to mocny dowód.

Dodatkowym sprawdzeniem jest Sprawdzanie adresu URL (URL Inspection) w Google Search Console. Wystarczy wkleić podejrzany adres (lub stronę główną), kliknąć Przetestuj opublikowany adres URL (Test live URL), a potem Wyświetl przetestowaną stronę (View tested page). Karta HTML pokazuje kod, który otrzymał robot Google, a zrzut ekranu – to, co z niego wyrenderował. W tym kodzie warto wyszukać casino, href i display:none. Test na żywo korzysta z robota inspekcyjnego Google, który atakujący mogą traktować inaczej niż robota indeksującego. Może on ujawnić cloaking, ale czysty wynik go nie wyklucza.

Zgrubne porównanie można wykonać z własnego komputera za pomocą curl:

curl -s https://example.com/ -o normal.html
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/ -o googlebot.html
diff normal.html googlebot.html
curl -sS -D - -o /dev/null -e "https://www.google.com/" https://example.com/

Ostatnie polecenie wysyła żądanie GET z referrerem Google i wypisuje nagłówki odpowiedzi. Nagłówek Location: może zdradzić przekierowanie HTTP, ale w ten sposób nie wykryje się przekierowań w JavaScripcie ani nie odtworzy każdej sesji przeglądarki. Jest jeszcze jedno ograniczenie. Jeśli wstrzyknięty kod sprawdza zakresy adresów IP Google, curl z laptopa zobaczy czystą stronę. Czysty wynik curl nie oznacza czystej witryny.

Na koniec warto otworzyć w Search Console Indeksowanie > Strony (Indexing > Pages). Nagły skok liczby zaindeksowanych lub wykrytych adresów URL, których Państwo nie publikowali, zwykle wskazuje na wygenerowane strony ze spamem.

Gdzie spam SEO ukrywa się w WordPressie

Przed rozpoczęciem analizy należy zachować kopię zapasową plików i bazy danych. Kopię trzeba chronić, bo może zawierać dane osobowe i sekrety. Najlepiej pracować na odizolowanej kopii z ograniczonym dostępem do sieci i uruchamiać poniższe polecenia z katalogu głównego WordPressa: wiele poleceń WP-CLI ładuje WordPressa i może wykonać zainfekowany kod. Dodanie --skip-plugins --skip-themes zmniejsza to ryzyko, ale mu-plugins i zmodyfikowany wp-config.php nadal się uruchomią. Jeśli bezpiecznej izolacji nie da się zapewnić, analizę warto zlecić hostingodawcy lub zespołowi reagowania na incydenty.

W bazie danych

wp db search 'casino' --all-tables
wp db search 'viagra' --all-tables
wp post list --post_type=any --post_status=any --orderby=date --order=DESC --fields=ID,post_type,post_status,post_date,post_title
wp option list --search='widget_*'
wp option list --search='theme_mods_*'
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

W wpisach i metadanych wpisów (post meta) szukamy linków, których nikt nie dodawał, a także świeżych wpisów lub stron z dziwnymi tytułami czy statusami. W tabeli wp_options warto sprawdzić:

• widgety tekstowe i HTML,
• theme mods, gdzie często ląduje własny kod stopki,
• opcje z autoładowaniem (autoload) o nazwach, których Państwo nie rozpoznają.

Nazwy tabel z prefiksem wp_ zakładają ustawienia domyślne; jeśli prefiks jest inny, należy sprawdzić $table_prefix w wp-config.php. Nieznani administratorzy to już sam w sobie poważny sygnał.

W plikach

wp core verify-checksums
wp plugin verify-checksums --all
ls -la wp-content/mu-plugins
find wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \)
find . -type f -name "*.php" -mtime -14
grep -rnE "base64_decode|gzinflate|str_rot13|eval\(" wp-content --include=*.php

wp core verify-checksums porównuje pliki rdzenia z wersjami z WordPress.org. wp plugin verify-checksums --all działa tylko dla wtyczek hostowanych na WordPress.org. W przypadku wtyczek premium trzeba pobrać świeżą kopię od dostawcy i porównać z nią.

Wyszukiwanie znaczników zaciemniania kodu da fałszywe alarmy, ponieważ część tych funkcji stosują także legalne wtyczki. Należy szukać długich zakodowanych ciągów i kodu, który nie ma sensu w danym kontekście.

Ręcznie warto sprawdzić również:

• functions.php, header.php i footer.php motywu,
• foldery wtyczek, których nikt nie instalował (atakujący lubią wiarygodnie brzmiące nazwy),
• wp-config.php i index.php pod kątem dodatkowych linii include,
• .htaccess pod kątem reguł RewriteCond dla HTTP_USER_AGENT lub HTTP_REFERER,
• katalog główny serwisu pod kątem plików XML z mapami witryny i plików weryfikacyjnych google*.html, których nikt nie tworzył.

Ślady atakującego w Search Console

Atakujący często weryfikują się jako właściciele Państwa usługi w Search Console. Następnie wysyłają własne mapy witryny, żeby Google szybciej zaindeksował spam. Dopóki mają ten dostęp, mogą dalej podsyłać adresy URL.

Należy otworzyć Ustawienia > Użytkownicy i uprawnienia (Settings > Users and permissions) i usunąć każdego właściciela lub użytkownika, którego Państwo nie znają. Potem trzeba usunąć także metodę weryfikacji, której użyli. Może to być plik google*.html w katalogu głównym, metatag w motywie lub ustawieniach nagłówka albo rekord DNS TXT. Pominięcie tego kroku pozwala im po prostu zweryfikować się ponownie.

W sekcji Indeksowanie > Mapy witryn (Indexing > Sitemaps) trzeba sprawdzić nieznane zgłoszenia: mogły je dodać legalne wtyczki lub inne upoważnione osoby zarządzające witryną. Mapy wysłane przez atakującego należy usunąć z Search Console, a ich źródło na stronie usunąć lub wyłączyć. Następnie warto otworzyć Bezpieczeństwo i działania ręczne (Security & Manual Actions) i przeczytać oba raporty: Problemy z bezpieczeństwem (Security issues) oraz Działania ręczne (Manual actions). Przykładowe adresy URL, które tam widnieją, pokazują, jaki spam znalazł Google, i stanowią przydatną listę kontrolną do czyszczenia.

Wyczyścić spam, a potem zamknąć furtkę

Usunięcie widocznych linków to kosmetyka. Jeśli punkt wejścia pozostaje otwarty, spam zwykle wraca, często w ciągu kilku dni.

1. Jeśli jeszcze tego nie zrobiono, trzeba wykonać kopię zainfekowanego stanu (pliki i baza) i zachować ją jako dowód.
2. Z bazy danych usuwamy spamowe wpisy, opcje, widgety i konta użytkowników.
3. Zmodyfikowane pliki rdzenia, wtyczek i motywów zastępujemy świeżymi kopiami ze sprawdzonych źródeł. Zainfekowanych plików nie poprawia się linijka po linijce.
4. Znajdujemy punkt wejścia. Najczęściej to podatna lub pirackia (nulled) wtyczka, skradzione hasło administratora albo wyciek danych dostępowych do FTP lub hostingu.
5. Naprawiamy go, a następnie zmieniamy wszystkie hasła oraz klucze (salts) w wp-config.php.

Pełną procedurę opisuje nasz plan usuwania złośliwego oprogramowania z WordPressa. Najczęstszą drogę włamania omawia artykuł Podatne wtyczki WordPressa.

Ta sama luka mogła też ujawnić dane klientów, na przykład wpisy z formularzy lub konta użytkowników. Wówczas mogą mieć zastosowanie obowiązki wynikające z RODO w razie naruszenia ochrony danych; zob. zgłoszenie naruszenia RODO w ciągu 72 godzin.

Usunąć spam z Google: kody 410, usunięcia i prośba o weryfikację

Gdy wygenerowane strony wyłącznie ze spamem znikną, ich adresy powinny zwracać kod 404 (Not Found) lub 410 (Gone); oba się nadają. Jeśli zmodyfikowano prawdziwe strony, należy je przywrócić, a nie usuwać ich adresów. Adresów ze spamem nie wolno przekierowywać na stronę główną. Google może uznać to za soft 404 i dalej je indeksować.

Jeśli adresy ze spamem mają wspólny wzorzec, którego nie używa żadna prawdziwa podstrona, można odpowiadać kodem 410 na poziomie serwera:

RedirectMatch 410 "^/spam-pattern/"

location ~ ^/spam-pattern/ { return 410; }

W pilnych przypadkach, na przykład gdy spam pojawia się przy nazwie marki, można użyć narzędzia Usunięcia (Removals) w Search Console. Ukrywa ono adresy w wynikach tylko tymczasowo i nie jest metodą trwałego usuwania. Adresy wyłącznie ze spamem powinny nadal zwracać 404/410, a Google musi móc te odpowiedzi pobrać; nie należy ich blokować w robots.txt, bo Google musi zobaczyć status usunięcia. Zob. wskazówki Google dotyczące narzędzia Usunięcia. Warto ponownie przesłać prawdziwą mapę witryny, aby Google odświeżył ważne strony.

To, czy potrzebna jest prośba o weryfikację, zależy od raportów:

• Jeśli raport Problemy z bezpieczeństwem lub Działania ręczne wymienia nierozwiązany problem, po naprawieniu wszystkich objętych nim stron należy skorzystać z opcji weryfikacji. Wniosek ma być krótki i rzeczowy: co znaleziono, co usunięto, jak atakujący dostał się do witryny i co zmieniono, żeby zamknąć tę lukę.
• Jeśli żaden raport nie wskazuje problemu, nie ma o co prosić. Google musi po prostu ponownie przeskanować oczyszczoną witrynę.

Oczekiwania trzeba trzymać na ziemi. Weryfikacje trwają, adresy ze spamem znikają stopniowo, a pozycje mogą wracać powoli albo nie wrócić w pełni. Nikt nie obieca terminu.

Wykrywać kolejne wstrzyknięcia na wczesnym etapie

Spam SEO jest projektowany tak, by pozostać niezauważonym, dlatego potrzebne są kontrole niezależne od oglądania strony:

• Warto utrzymywać wzorzec integralności plików i badać każdą zmianę, której nikt nie wprowadził.
• Raz w miesiącu trzeba wykonać wyszukiwanie site: dla swojej domeny.
• Należy włączyć powiadomienia e-mail w Search Console, aby problemy z bezpieczeństwem i działania ręczne docierały do właściwych osób.
• Bazę danych trzeba regularnie skanować pod kątem wzorców linków takich jak powyższe.
• Każde nowe konto administratora, którego nikt nie założył, należy traktować jak incydent.

Wtyczka Security Audit & Compliance z secaudit.eu skanuje witrynę pod kątem ukrytego spamu SEO i hacklinków, spamu w bazie danych, ukrytych administratorów i innych wskaźników włamania. Porównuje też pliki ze wzorcem. Wykrywa i raportuje. Nie czyści witryny automatycznie, a punkt wejścia nadal musi naprawić człowiek. → secaudit.eu

FAQ

Dlaczego nie widzę spamu, gdy wchodzę na własną stronę?

To wstrzyknięty kod decyduje, kto co zobaczy. Zwykle pomija zalogowanych użytkowników i sprawdza user agenta, adres IP oraz referrer. Część ataków celuje w Googlebota lub osoby przychodzące z wyszukiwarki; inne pokazują spam także zwykłym odwiedzającym albo ukrywają linki w kodzie serwowanym wszystkim. Test na żywo w Sprawdzaniu adresu URL to jedna z kontroli, ale trzeba pamiętać, że atakujący mogą pokazywać jego robotowi inspekcyjnemu inną treść niż robotowi indeksującemu.

Czy Google ukarze moją witrynę na stałe?

W żadną stronę nie ma gwarancji. Należy dokładnie wyczyścić witrynę, zamknąć punkt wejścia i odebrać atakującemu dostęp w Search Console. Jeśli raport Problemy z bezpieczeństwem lub Działania ręczne tego wymaga, trzeba złożyć prośbę o weryfikację. Dalszy przebieg zależy od tego, kiedy Google ponownie przeskanuje witrynę, a to wymaga czasu.

Czy wtyczka bezpieczeństwa wystarczy, żeby usunąć spam SEO?

Wtyczka może pomóc znaleźć spam i zmienione pliki. Czyste usunięcie spamu i ustalenie, jak atakujący dostał się do witryny, wymaga pracy ręcznej lub pomocy specjalisty. Inaczej spam zwykle wraca.