Moja strona przekierowuje na inną stronę — przyczyny i rozwiązanie

„Dzień dobry, wchodzę na państwa stronę z telefonu i wyskakuje mi, że wygrałem iPhone’a” — tak zwykle zaczyna się ta historia. Właściciel wchodzi na stronę z komputera: wszystko w porządku. Wchodzi drugi raz: w porządku. Dzwoni do informatyka, ten też nic nie widzi. A klienci dalej lądują na stronach z hazardem, „nagrodami”, fałszywymi aktualizacjami przeglądarki albo w sklepach z podróbkami. Złośliwe przekierowanie to dziś jeden z dwóch najczęstszych objawów włamania na stronę WordPress (drugi to japoński spam w wynikach Google). Poniżej wyjaśniamy, dlaczego go nie widzisz, gdzie siedzi i co zrobić.

Najpierw wyklucz niewinne przyczyny

Zanim założysz włamanie, sprawdź trzy rzeczy, które też dają „przekierowanie na inną stronę”, ale są zwykłą pomyłką w konfiguracji:

• Wygasła domena lub hosting. Strona pokazuje wtedy parking domeny z reklamami. Sprawdź datę ważności domeny u rejestratora i stan konta hostingowego.
• Błędny adres strony w ustawieniach WordPressa. Po przenosinach albo zmianie na HTTPS pola „Adres WordPressa” i „Adres witryny” (Ustawienia → Ogólne) wskazują stary adres — strona przekierowuje na niego. To jednak zawsze Twoja własna domena, nie obca.
• Wtyczka przekierowań lub pętla HTTPS. Reguła w wtyczce do przekierowań 301 albo konflikt między wtyczką SSL a ustawieniem hostingu. Objaw: przekierowanie na własną domenę, często z błędem „za dużo przekierowań”.

Jeśli natomiast przekierowanie prowadzi na obcą domenę z treścią, której nie zamawiałeś — hazard, loterie, „bezpieczeństwo Twojego urządzenia”, pornografia, podróbki, „aktualizacja Chrome” — to włamanie. Dalsza część tekstu jest o tym.

Dlaczego Ty nie widzisz przekierowania, a klienci tak

Bo kod przekierowujący jest warunkowy. Włamywacz chce, żeby infekcja żyła jak najdłużej, więc wyklucza z niej właśnie Ciebie. Typowe warunki:

• Tylko telefony — rozpoznawane po przeglądarce; Ty pracujesz na komputerze.
• Tylko wejścia z wyszukiwarki lub mediów społecznościowych — rozpoznawane po adresie strony, z której przyszedł odwiedzający; Ty wpisujesz adres ręcznie albo masz go w zakładkach.
• Tylko raz na dobę na osobę — po pierwszym przekierowaniu przeglądarka dostaje ciasteczko i przy kolejnych wejściach widzi czystą stronę; przypadkiem „sprawdzasz” już po tym pierwszym razie.
• Nie dla zalogowanych — kod sprawdza ciasteczko logowania do panelu WordPressa; administrator nigdy nie trafia w przekierowanie.
• Nie dla Twojego adresu IP — po kilku wejściach z biura kod zapamiętuje Twój adres.
• Nie dla robota Google — żeby Google nie oznaczył strony zbyt szybko (to element cloakingu, który opisujemy w tekście Co to jest cloaking).

Żeby zobaczyć przekierowanie na własne oczy: weź telefon, wyłącz Wi-Fi, otwórz tryb incognito, wyszukaj firmę w Google i kliknij w wynik. Więcej takich testów w tekście 7 prostych testów.

Gdzie siedzi złośliwe przekierowanie

Tu jest sedno sprawy — i powód, dla którego „usunęliśmy podejrzany plik, a przekierowanie wróciło” zdarza się tak często. Kod przekierowujący bywa w kilku miejscach jednocześnie, a każde z nich potrafi odtworzyć pozostałe.

1. Pliki motywu i wtyczek

Najczęściej doklejony fragment JavaScriptu lub PHP na początku albo końcu plików functions.php, header.php, footer.php motywu, w plikach aktywnych wtyczek, a także w plikach rdzenia WordPressa (index.php, wp-settings.php, pliki w wp-includes). Kod jest zwykle zaciemniony (długie ciągi znaków, eval, base64), żeby nie rzucał się w oczy przy przeglądaniu.

2. Baza danych

Skrypt przekierowujący wstrzyknięty do treści wpisów i stron (tabela wp_posts), do ustawień motywu lub wtyczek (wp_options), do widżetów. Zdarza się też podmiana pól siteurl i home na obcy adres. Tego nie usuniesz, podmieniając pliki — trzeba przejrzeć bazę.

3. Plik .htaccess

Reguły przekierowujące odwiedzających spełniających warunek (telefon, wejście z Google) na obcą domenę. Plik może leżeć w katalogu głównym strony, ale też w podkatalogach, gdzie nikt nie zagląda, np. w wp-content/uploads.

4. Fałszywa wtyczka albo wtyczka must-use

Katalog w wp-content/plugins z nazwą udającą coś systemowego, często niewidoczny na liście wtyczek w panelu, bo kod ukrywa sam siebie. Wtyczki must-use (wp-content/mu-plugins) ładują się zawsze i nie da się ich wyłączyć z panelu — ulubione miejsce na tylne drzwi.

5. Obce konto administratora i zadanie cron

Nie przekierowują same, ale przywracają infekcję po Twoim czyszczeniu. Zadanie cron (w WordPressie albo na serwerze) co kilka godzin odtwarza usunięte pliki; obce konto pozwala wejść ponownie po zmianie hasła.

6. Zewnętrzny skrypt, który „kiedyś był dobry”

Rzadszy, ale podstępny przypadek: skrypt ładowany z obcej domeny (licznik, czat, biblioteka), którą ktoś przejął lub której właściciel zmienił zdanie. Twoje pliki są czyste, a przekierowanie i tak jest. Dlatego listę domen, z których strona ładuje skrypty, warto przejrzeć (Ctrl+U, szukaj script src).

Co zrobić — krok po kroku

1. Ogranicz szkody. Jeśli klienci trafiają na niebezpieczne treści, włącz tryb konserwacji albo poproś hosting o tymczasowe wyłączenie strony. Każda godzina to kolejni klienci na stronie oszustów i kolejne sygnały dla Google.
2. Zrób kopię stanu „po włamaniu” — pliki i baza. Nie kasuj niczego przed kopią: w śladach jest informacja, którędy weszli.
3. Zmień hasła do panelu, hostingu, FTP/SFTP i bazy. Jeśli to możliwe, z innego komputera.
4. Znajdź i usuń kod we wszystkich sześciu miejscach powyżej. W praktyce: podmiana rdzenia, wtyczek i motywu na czyste oryginały w tych samych wersjach; przegląd bazy pod kątem skryptów i obcych adresów; sprawdzenie wszystkich plików .htaccess; przegląd mu-plugins, kont i zadań cron.
5. Zamknij lukę. Ustal z logów i dat plików, przez co weszli (najczęściej konkretna przestarzała wtyczka), i zaktualizuj albo usuń ten element. Bez tego kroku krok 4 trzeba będzie powtarzać.
6. Sprawdź, czy Google już Cię oznaczył — Search Console → Problemy dotyczące bezpieczeństwa oraz raport Safe Browsing. Jeśli tak, po wyczyszczeniu złóż wniosek o ponowne sprawdzenie. Czerwony ekran w przeglądarce omawiamy w tekście „Witryna zawiera złośliwe oprogramowanie” — co robić.
7. Zabezpiecz: aktualizacje, usunięcie nieużywanych wtyczek, dwuetapowe logowanie, blokada PHP w uploads, kopie poza serwerem, monitoring zmian plików.

Jeśli nie masz w firmie osoby, która porówna pliki z oryginałami i przejrzy bazę, to właśnie ta praca: czyszczenie strony po włamaniu — pełna diagnoza, usunięcie kodu z luką, zdjęcie ostrzeżeń, raport; jedna stała kwota po analizie.

Dlaczego to wraca

Trzy powody, w kolejności częstości: (1) usunięto objaw, nie przyczynę — kod przekierowujący zniknął, luka we wtyczce została; (2) nie znaleziono wszystkich kopii kodu — zadanie cron lub plik w uploads odtworzył resztę; (3) hasła nie zostały zmienione albo zostało obce konto. Czwarty powód, o którym mówi się rzadziej: strona ma dwadzieścia wtyczek od dwudziestu autorów, z których kilku porzuciło swoje projekty — i następne włamanie to kwestia czasu, nawet po idealnym czyszczeniu. O tym, kiedy ma sens zostać na WordPressie, a kiedy zmienić fundament, piszemy w tekstach Czy WordPress jest bezpieczny? i WordPress czy dedykowany CMS.