Klient dzwoni, że po wejściu na stronę firmy trafił do obcego sklepu. Przeglądarka pokazuje czerwony ekran z ostrzeżeniem, a w skrzynce leży wiadomość od hostingu o zablokowanym koncie. Tak najczęściej wygląda chwila, w której właściciel dowiaduje się, że jego WordPress został zainfekowany.
Ta instrukcja jest przeznaczona dla właścicieli firm i osób, które same opiekują się stroną. Potrzebny jest dostęp do panelu WordPressa, do panelu hostingu i do plików przez SFTP lub menedżer plików, a do części dotyczącej Google także dostęp do Search Console. Opisane czynności dotyczą wyłącznie własnej witryny i opierają się na oficjalnej dokumentacji WordPressa oraz pomocy Google.
Po lekturze czytelnik będzie umiał rozpoznać objawy włamania, zatrzymać szkody w pierwszej godzinie, oczyścić pliki i bazę albo przywrócić czystą kopię, zdjąć ostrzeżenie w Google i ocenić, kiedy lepiej oddać sprawę komuś, kto robi to zawodowo.
Po czym poznać, że strona na WordPressie została zainfekowana?
Infekcja rzadko ujawnia się wprost właścicielowi. Złośliwy kod często rozpoznaje zalogowanego administratora i pokazuje mu stronę bez zmian, a szkodliwe treści wyświetla tylko osobom wchodzącym z wyszukiwarki albo z telefonu. Dlatego pierwsze sygnały przychodzą zwykle z zewnątrz: od klienta, od hostingu albo od Google.
Najczęstsze objawy to:
- przekierowania na obce strony, zwłaszcza po wejściu z wyników Google lub na telefonie,
- obce treści w wynikach wyszukiwania: tytuły w innym języku, nazwy leków, zakładów lub sklepów, których firma nie prowadzi,
- ostrzeżenie przeglądarki na całym ekranie albo etykieta ostrzegawcza przy wyniku w Google,
- nieznani użytkownicy z rolą „Administrator” na liście kont,
- komunikat od hostingu o wykrytych złośliwych plikach, wysyłce spamu lub wyłączeniu witryny,
- wtyczki, motywy lub pliki, których nikt z zespołu nie instalował, oraz wyraźne spowolnienie strony.
Jak sprawdzić objawy samodzielnie?
Stronę należy otworzyć w oknie prywatnym przeglądarki, bez logowania, najlepiej także na telefonie korzystającym z sieci komórkowej. Drugi test to wejście przez wynik wyszukiwania, a nie przez wpisanie adresu, bo wiele przekierowań uruchamia się tylko dla ruchu z Google.
Trzeci test wykonuje się w wyszukiwarce: wpisanie site:nazwadomeny.pl pokazuje adresy, które Google zna w danej domenie. Jeżeli na liście są podstrony, których firma nigdy nie tworzyła, ktoś dopisał je do witryny. Sposób czytania takich wyników opisałem we wpisie o tym, jak sprawdzić, czy strona jest zaindeksowana w Google.
Skąd bierze się infekcja i dlaczego trzeba znaleźć jej źródło?
Włamanie na WordPressa ma zwykle jedną z kilku przyczyn. Strona wyczyszczona bez zamknięcia drogi wejścia zostaje najczęściej zainfekowana ponownie tą samą metodą, dlatego przyczynę trzeba ustalić. Pomagają w tym daty zmian podejrzanych plików, dziennik dostępu serwera z tego samego okresu i lista wtyczek z wersjami.
- Nieaktualna wtyczka, motyw albo sam WordPress ze znaną luką. Poznaje się to po długiej liście oczekujących aktualizacji i po wtyczkach, które od dawna nie są rozwijane.
- Wtyczka lub motyw pobrane z nieoficjalnego źródła. Takie paczki bywają rozpowszechniane z dopisanym kodem.
- Słabe albo powtarzane hasło do panelu, FTP lub hostingu. Wskazują na to logowania z nieznanych adresów i nowe konta administratorów.
- Zainfekowany komputer osoby, która loguje się do strony. Dokumentacja WordPressa przypomina, że programy szpiegujące potrafią przechwytywać dane do FTP i do panelu.
- Inna zainfekowana witryna na tym samym koncie hostingowym. Jeżeli w jednym koncie działa kilka stron, infekcja przenosi się między katalogami.
Pierwsza godzina: co zrobić po kolei?
W pierwszej godzinie nie chodzi o pełne oczyszczenie strony. Cel jest skromniejszy: zatrzymać szkody, zachować ślady i odebrać intruzowi dostęp. Dokumentacja WordPressa zaczyna od zalecenia zachowania spokoju, ponieważ najwięcej strat powodują pochopne ruchy.
- Zapisanie tego, co widać: objawy, godzina ich zauważenia, ostatnie zmiany na stronie (nowa wtyczka, zmiana motywu, nowy widżet), treść wiadomości od hostingu. Przydają się zrzuty ekranu.
- Ograniczenie dostępu do witryny dla odwiedzających, tak aby szkodliwe treści przestały do nich trafiać.
- Wykonanie kopii obecnego, zainfekowanego stanu: plików i bazy danych.
- Zmiana wszystkich haseł: panel WordPressa, hosting, FTP lub SFTP, baza danych, skrzynki pocztowe.
- Przegląd listy użytkowników i usunięcie kont, których nikt z zespołu nie zakładał.
- Kontakt z pomocą techniczną hostingu z pytaniem o zakres infekcji i o dostępne kopie zapasowe.
Jak ograniczyć dostęp do strony?
Są dwie drogi. Pierwsza to tryb konserwacji włączany wtyczką albo w panelu hostingu. Jest szybki, lecz działa wewnątrz zainfekowanej instalacji, więc nie daje pewności, że złośliwe pliki przestaną być dostępne pod własnymi adresami.
Druga droga jest pewniejsza: ograniczenie dostępu na poziomie serwera. W panelu hostingu można zwykle ustawić hasło na katalog strony albo poprosić pomoc techniczną o tymczasowe wyłączenie witryny z komunikatem o przerwie. Wytyczne Google dla zaatakowanych witryn zalecają, aby na czas naprawy witryna przestała podawać treści użytkownikom, a serwer odpowiadał kodem 503, który oznacza przerwę tymczasową. Najlepiej, gdy taka odpowiedź pochodzi spoza zainfekowanej instalacji.
Te same wytyczne ostrzegają przed jednym skrótem: wpis blokujący w pliku robots.txt nie wystarcza, ponieważ zatrzymuje wyłącznie roboty wyszukiwarek, a zwykli użytkownicy nadal trafiają na szkodliwe treści. Przerwa powinna być krótka. Kod 503 utrzymywany tygodniami zaczyna szkodzić widoczności strony.
Po co kopia zainfekowanej strony?
Brzmi to dziwnie, ale dokumentacja WordPressa zaleca wprost: przed czyszczeniem należy wykonać jeszcze jedną kopię środowiska, nawet zainfekowanego. Gdy czyszczenie pójdzie źle, taka kopia pozwala wrócić do punktu wyjścia. Jest też materiałem do ustalenia, którędy doszło do włamania.
Kopia składa się z dwóch części: wszystkich plików z katalogu strony oraz eksportu bazy danych, który wykonuje się w panelu hostingu lub w narzędziu phpMyAdmin. Archiwum należy wyraźnie opisać jako zainfekowane, przechowywać poza serwerem i nigdy nie przywracać go na działającą stronę.
Które hasła trzeba zmienić i w jakiej kolejności?
Dokumentacja WordPressa wymienia wszystkie punkty dostępu: FTP lub SFTP, panel administracyjny WordPressa, panel hostingu oraz bazę danych MySQL. Hasła mają być długie, złożone i niepowtarzalne, najlepiej wygenerowane przez menedżer haseł.
Radzę zacząć od skrzynki pocztowej przypisanej do konta administratora i od panelu hostingu, ponieważ przez nie da się odzyskać wszystkie pozostałe dostępy. Następne są konta FTP, baza danych i na końcu użytkownicy WordPressa. Zmiany należy wykonywać z komputera, który przeszedł pełne skanowanie programem antywirusowym.
Po zmianie hasła do bazy strona przestanie działać, dopóki nowe hasło nie zostanie wpisane w pliku wp-config.php, w wierszu DB_PASSWORD. To zachowanie prawidłowe, nie kolejna awaria.
Jak przejrzeć użytkowników?
W panelu WordPressa należy otworzyć „Użytkownicy”, a następnie „Wszyscy użytkownicy” i nad tabelą wybrać filtr „Administrator”. Każde konto na tej liście musi mieć znanego właściciela. Nieznane konta trzeba usunąć, a przy usuwaniu wskazać, komu przypisać ich treści, jeśli jakieś mają.
Przy okazji trzeba otworzyć profil każdego administratora i sprawdzić sekcję „Hasła aplikacji”. Nieznane pozycje należy unieważnić, bo dają dostęp do strony z pominięciem zwykłego logowania. W „Ustawienia”, „Ogólne” należy też sprawdzić, czy pole „Członkostwo” nie pozwala każdemu na rejestrację i czy „Domyślna rola nowych użytkowników” nie została zmieniona na administratora.
Gdy intruz przejął konto i logowanie nie jest możliwe, dokumentacja WordPressa podaje dwie drogi: zwykłe odzyskiwanie hasła albo zmianę danych konta bezpośrednio w tabeli wp_users przez phpMyAdmin udostępniany przez hosting. Prostszy wariant to zmiana w tej tabeli adresu e-mail konta na własny i skorzystanie z odzyskiwania hasła na ekranie logowania.
Kto na tym etapie woli nie zajmować się tym samodzielnie, może po prostu zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl. Chętnie przejmę sprawę: oczyszczę zainfekowaną stronę, zgłoszę ją do ponownego sprawdzenia w Google i zabezpieczę na przyszłość.
Czy przywrócenie czystej kopii zapasowej wystarczy?
Jeżeli istnieje kopia zapasowa sprzed włamania, jej przywrócenie jest najszybszą drogą do działającej strony. Wytyczne Google stawiają jeden warunek: trzeba się upewnić, że kopia powstała przed atakiem. Infekcja bywa uśpiona przez wiele dni, więc kopia z poprzedniego tygodnia może już zawierać złośliwe pliki.
Datę włamania ustala się po datach zmian podejrzanych plików, po dacie utworzenia obcych kont i po dziennikach serwera. Kopię wybiera się z zapasem, czyli wcześniejszą niż najstarszy ślad. O zasady przechowywania kopii należy zapytać hosting, co zaleca także dokumentacja WordPressa.
Przywrócenie kopii nie kończy sprawy, ponieważ przywraca także lukę, przez którą doszło do włamania. Zaraz po nim trzeba:
- Zainstalować wszystkie aktualizacje WordPressa, wtyczek i motywów.
- Usunąć wtyczki i motywy, z których strona nie korzysta.
- Zmienić ponownie wszystkie hasła i klucze bezpieczeństwa w
wp-config.php. - Przejrzeć użytkowników, bo obce konto mogło powstać wcześniej niż widoczne objawy.
- Odtworzyć treści dodane po dacie kopii: wpisy, zamówienia, zgłoszenia z formularzy. Przenosi się wyłącznie treść, nigdy pliki PHP z zainfekowanej wersji.
Ryzyko tej drogi to utrata danych z okresu między kopią a włamaniem. W sklepie internetowym oznacza to zamówienia i konta klientów, dlatego przed przywróceniem należy wyeksportować je z zainfekowanej bazy do osobnego pliku. Jeżeli czystej kopii nie ma, pozostaje czyszczenie opisane niżej.
Jak wyczyścić witrynę według dokumentacji WordPressa?
Dokumentacja WordPressa dla zhakowanej witryny odradza kasowanie wszystkiego i budowanie strony od zera, o ile nie jest to naprawdę konieczne. Zaleca ponowną instalację wybranych części witryny czystymi plikami z oficjalnego źródła. Kolejność jest następująca: skan, podmiana plików systemu, wtyczek i motywów, przegląd plików konfiguracyjnych i katalogu z mediami, wymiana kluczy, przegląd bazy, a na końcu aktualizacja do najnowszych wersji.
Czym przeskanować stronę?
Dokumentacja wymienia dwa rodzaje narzędzi. Pierwszy to skanery działające jako wtyczki wewnątrz WordPressa, między innymi Wordfence, Sucuri, Quttera i GOTMLS. Drugi to skanery zdalne, które oglądają stronę z zewnątrz, takie jak VirusTotal i Sitecheck.
Oba rodzaje się uzupełniają. Skaner zdalny widzi to, co widzi odwiedzający, więc wykrywa przekierowania i wstrzyknięty kod na stronie, ale nie zajrzy do plików na serwerze. Wtyczka porównuje pliki z oryginałami i wskazuje te zmienione lub dopisane. Wynik skanu jest listą miejsc do sprawdzenia, a nie dowodem czystości.
Jak podmienić pliki systemu WordPress?
Najpierw trzeba ustalić wersję WordPressa. Widać ją w panelu, na ekranie „Kokpit”, „Aktualizacje”, a gdy panel nie działa, w pliku wp-includes/version.php. Dokumentacja jest tu stanowcza: do podmiany używa się tej samej wersji, która działa na stronie, ponieważ starsza lub nowsza może witrynę unieruchomić.
Dokumentacja odradza też przycisk ponownej instalacji na ekranie „Aktualizacje”. Instalator nadpisuje zazwyczaj tylko istniejące pliki, a włamanie często polega na dodaniu nowych. Właściwa droga to połączenie przez SFTP, usunięcie katalogów wp-admin i wp-includes w całości i wgranie ich na nowo z paczki pobranej z wordpress.org.
Co zrobić z wtyczkami i motywami?
Katalog wp-content dokumentacja każe przejrzeć uważniej, bo zawiera wtyczki i motywy, a więc kod spoza samego systemu. Najpewniejsza metoda to spisanie listy wtyczek, usunięcie ich katalogów i wgranie świeżych paczek z oficjalnego repozytorium albo z konta u producenta. Ustawienia wtyczek są zapisane w bazie danych, więc w większości przypadków pozostają na miejscu.
W motywie dokumentacja wskazuje pliki, które padają ofiarą najczęściej: index.php, header.php, footer.php i plik funkcji motywu. Pliki motywu potomnego trzeba przejrzeć ręcznie, bo nie ma dla nich czystego oryginału.
Na co patrzeć w wp-config.php i .htaccess?
Plik wp-config.php porównuje się z plikiem wp-config-sample.php z czystej paczki. Powinien zawierać dane bazy, klucze bezpieczeństwa, przedrostek tabel i kilka ustawień. Podejrzane są wiersze z include lub require wskazujące nieznane pliki, bardzo długie ciągi nieczytelnych znaków oraz funkcje eval i base64_decode.
Plik .htaccess jest według dokumentacji często zmieniany w złych zamiarach i może występować w wielu katalogach, nie tylko w głównym. To on zwykle odpowiada za przekierowania zależne od tego, skąd przyszedł odwiedzający. W typowej instalacji z przyjaznymi adresami część należąca do WordPressa wygląda tak:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressDodatkowe wpisy mogą pochodzić od wtyczki pamięci podręcznej lub zabezpieczającej i zwykle są opisane jej nazwą. Reguły z obcymi domenami albo warunkami odwołującymi się do wyszukiwarek należy usunąć. WordPress potrafi odtworzyć swoją część pliku: wystarczy w panelu otworzyć „Ustawienia”, „Bezpośrednie odnośniki” i kliknąć „Zapisz zmiany”.
Jak przejrzeć katalog uploads?
Katalog wp-content/uploads przechowuje zdjęcia i dokumenty, dlatego nie da się go podmienić czystą paczką. Z mojej praktyki wynika, że właśnie tam najczęściej zostaje ukryte wejście, przez które intruz wraca po czyszczeniu. Dokumentacja WordPressa nie omawia go osobno, więc to moje zalecenie.
W katalogu z mediami nie powinno być plików wykonywalnych. Należy wyszukać w nim pliki z rozszerzeniami .php, .phtml i .ico o nietypowych nazwach oraz pliki .htaccess. Wyjątkiem bywa pusty plik index.php, który ma tylko ukryć listę plików. Każdy plik PHP z dłuższą zawartością należy uznać za podejrzany.
Jak wymienić klucze bezpieczeństwa?
Klucze bezpieczeństwa to osiem wierszy w wp-config.php, od AUTH_KEY do NONCE_SALT. Dokumentacja zaleca wygenerowanie nowego zestawu w oficjalnym generatorze kluczy WordPressa pod adresem api.wordpress.org/secret-key/1.1/salt/ i nadpisanie nim dotychczasowych wartości. Skutek jest natychmiastowy: każda zalogowana osoba, także intruz, zostaje wylogowana. Po potwierdzeniu, że strona jest czysta, dokumentacja zaleca jeszcze raz zmienić hasła, także hasło użytkownika bazy danych.
Czy trzeba czyścić bazę danych?
Tak, ponieważ podmiana plików nie usuwa tego, co zostało zapisane w bazie. W tabeli wp_options należy sprawdzić wiersze siteurl i home, które muszą wskazywać własną domenę. Te same wartości widać w panelu, w „Ustawienia”, „Ogólne”, w polach „Adres WordPressa (URL)” i „Adres witryny (URL)”.
W treści wpisów i stron trzeba poszukać znaczników <script> i <iframe> z obcymi adresami oraz ukrytych linków. Przed każdą zmianą w bazie obowiązuje jej eksport, bo błędne polecenie potrafi usunąć treści bezpowrotnie.
Po czym poznać, że czyszczenie zadziałało?
Strona jest czysta dopiero wtedy, gdy kilka niezależnych sprawdzeń daje ten sam wynik. Jedno czyste skanowanie to za mało.
- Ponowny skan wtyczką i skanerem zdalnym nie pokazuje zmienionych plików ani ostrzeżeń.
- Strona otwierana w oknie prywatnym, na telefonie i z wyniku Google nie przekierowuje na obce adresy.
- Adres wymyślony, na przykład z przypadkowym ciągiem znaków, zwraca stronę błędu 404, a nie obcą treść.
- Na liście użytkowników są wyłącznie znane konta.
- W kolejnych dniach w katalogach nie pojawiają się nowe pliki PHP, a daty zmian plików systemu pozostają bez zmian.
Co zrobić, gdy infekcja wraca?
Powrót złośliwych plików po dobie lub dwóch oznacza, że pozostało ukryte wejście albo droga włamania jest nadal otwarta. Trzeba wtedy sprawdzić cztery miejsca: pozostałe witryny na tym samym koncie hostingowym, zadania harmonogramu w panelu hostingu, katalog wp-content/mu-plugins, z którego kod uruchamia się bez włączania w panelu, oraz komputery osób z dostępem. Przy drugim nawrocie radzę przerwać samodzielne próby i przekazać sprawę specjaliście.
Co pokazuje raport „Problemy dotyczące bezpieczeństwa” w Search Console?
Gdy Google stwierdzi, że witrynę zaatakowano albo że działa ona w sposób szkodliwy dla użytkowników, umieszcza informację w raporcie „Problemy dotyczące bezpieczeństwa”. W menu Search Console raport znajduje się w grupie „Bezpieczeństwo i ręczne działania”. Jeżeli problemów nie ma, widać zielony znacznik i odpowiedni komunikat. Jeżeli są, ich liczba pojawia się w górnej części raportu.
Problemy należą do trzech kategorii: „Treści zmodyfikowane przez hakerów”, „Złośliwe i niechciane oprogramowanie” oraz „Inżynieria społeczna”. Od kategorii zależy, czy przy wyniku w Google pojawia się etykieta ostrzegawcza, czy przeglądarka wyświetla ostrzeżenie na całym ekranie.
Po rozwinięciu opisu problemu widać dzień jego pierwszego wykrycia, krótki opis i przykładowe adresy. Pomoc Google zastrzega, że lista przykładów nie musi być kompletna, a czasem nie ma ich wcale, co nie oznacza, że problem nie dotyczy żadnej strony. Naprawa ma objąć całą witrynę, bo usunięcie problemu tylko na części stron nie zmienia jej oceny.
Jak poprosić Google o sprawdzenie?
- Otwarcie raportu „Problemy dotyczące bezpieczeństwa” i rozwinięcie opisu każdego problemu.
- Przeczytanie opisu i kliknięcie linku „Więcej informacji”, który prowadzi do czynności naprawczych dla danego rodzaju problemu.
- Usunięcie wszystkich problemów z listy na wszystkich stronach witryny i sprawdzenie poprawek.
- Przywrócenie dostępu do witryny. Strona nie może być zablokowana hasłem, plikiem robots.txt ani dyrektywą noindex, bo Google nie będzie w stanie jej obejrzeć.
- Kliknięcie w raporcie przycisku „Poproś o sprawdzenie” i opisanie wykonanych poprawek.
Według pomocy Google dobra prośba spełnia trzy warunki: dokładnie omawia problem, opisuje działania podjęte w celu jego usunięcia i dokumentuje wyniki tych działań. Przykładowa treść do dostosowania:
Witryna została zaatakowana przez nieuprawnioną osobę, która dodała obce strony i kod przekierowujący. Wykonano: podmianę plików systemu WordPress, wtyczek i motywu na czyste, usunięcie obcych plików i nieznanych kont administratorów, zmianę haseł i kluczy bezpieczeństwa, aktualizację oprogramowania. Obce adresy zwracają kod 404. Ponowny skan nie wykazuje zmienionych plików.
Ile trwa sprawdzanie i co potem?
Pomoc Google podaje, że w przypadku większości próśb sprawdzanie może potrwać kilka dni lub tygodni. Wytyczne Google dla zaatakowanych witryn doprecyzowują, że sprawy dotyczące wyłudzania informacji rozpatruje się w około jeden dzień, złośliwego oprogramowania w kilka dni, a spamu dodanego przez intruza nawet w kilka tygodni. Po uznaniu witryny za czystą ostrzeżenia w przeglądarkach i wynikach wyszukiwania znikają w ciągu 72 godzin.
O postępach Google informuje wiadomością e-mail. Do czasu ostatecznej decyzji nie wolno wysyłać prośby ponownie. Pomoc Google ostrzega, że prośba złożona przed usunięciem problemu wydłuża rozpatrzenie następnej i może skończyć się statusem sprawcy wielokrotnych naruszeń.
Jak usunąć obce adresy z wyników Google?
Po ataku w wynikach wyszukiwania zostają adresy utworzone przez intruza, często w obcym języku. Znikną same, gdy Google odwiedzi je ponownie i otrzyma kod 404, ale trwa to tygodniami. Proces przyspiesza narzędzie „Usunięcia” w Search Console, w grupie „Indeksowanie”.
- Upewnienie się, że obce adresy zostały usunięte z witryny i zwracają kod 404 lub 410.
- Otwarcie narzędzia „Usunięcia” i wybranie karty „Tymczasowe usunięcia”.
- Kliknięcie „Nowa prośba”, a następnie „Tymczasowe usunięcie adresu URL”.
- Wpisanie adresu i wskazanie zakresu: „Usuń tylko ten URL” albo „Usuń wszystkie URL-e z tym prefiksem”.
- Kliknięcie „Dalej” i potwierdzenie prośby.
Opcja z prefiksem przydaje się, gdy intruz utworzył setki adresów we wspólnym katalogu. Zbyt krótki prefiks ukryje jednak także własne podstrony. Przetwarzanie prośby może według pomocy Google potrwać cały dzień, a zablokowany adres nie pojawia się w wynikach przez około 6 miesięcy. To blokada tymczasowa, dlatego warunkiem trwałego skutku jest kod 404 lub 410 po stronie serwera.
Wytyczne Google zaznaczają, że narzędzie służy wyłącznie do stron, które nigdy nie mają wracać do wyników. Własnych podstron, które intruz tylko uszkodził, nie zgłasza się do usunięcia. Po oczyszczeniu należy poprosić o ich ponowne zaindeksowanie w narzędziu do sprawdzania adresów URL. Wpływ ataku na to, co widać po wpisaniu nazwy firmy, opisałem we wpisie o tym, jak wyglądają wyniki Google na nazwę firmy.
Jak zabezpieczyć WordPressa na przyszłość?
Dokumentacja WordPressa kończy listę czynności dwoma punktami: aktualizacją do najnowszej wersji, ponieważ starsze są bardziej podatne na ataki, oraz wdrożeniem zaleceń z dokumentu o wzmacnianiu zabezpieczeń. Z tych zaleceń największe znaczenie dla małej firmy mają:
- Aktualizacje WordPressa, wtyczek i motywów instalowane na bieżąco oraz usuwanie wszystkiego, co nie jest używane.
- Pobieranie oprogramowania wyłącznie z wordpress.org i od producentów.
- Weryfikacja dwuetapowa dla kont administratorów i długie, niepowtarzalne hasła.
- Połączenie SFTP zamiast FTP, aby dane logowania nie były przesyłane otwartym tekstem.
- Uprawnienia 755 dla katalogów i 644 dla plików oraz zaostrzone uprawnienia pliku
wp-config.php. - Regularne, datowane kopie plików i bazy przechowywane poza serwerem strony.
- Dzienniki dostępu i błędów zachowywane tak długo, jak pozwala hosting.
Dokumentacja podaje też gotowy wiersz do pliku wp-config.php, który wyłącza edytor plików motywów i wtyczek w panelu:
define( 'DISALLOW_FILE_EDIT', true );Dokumentacja zastrzega, że to ustawienie nie powstrzyma wgrania złośliwych plików inną drogą. Od siebie dodam dwie zasady: każda osoba ma własne konto z najniższą wystarczającą rolą, a kopię zapasową raz na jakiś czas przywraca się próbnie. Stan aktualizacji i wtyczek trzeba przeglądać regularnie, na przykład przy okazji przeglądu opisanego we wpisie o tym, co sprawdzić w audycie SEO strony.
Jakich błędów unikać podczas ratowania strony?
Większość poważnych strat po włamaniu nie wynika z samego ataku, lecz z pośpiechu przy naprawie. Najczęstsze błędy to:
- kasowanie plików bez wykonania kopii zainfekowanego stanu,
- przywrócenie kopii zapasowej bez sprawdzenia jej daty i bez aktualizacji oprogramowania,
- zmiana haseł na komputerze, który nie został przeskanowany,
- wysłanie prośby o sprawdzenie do Google przed zakończeniem czyszczenia,
- blokowanie strony w pliku robots.txt w przekonaniu, że to chroni odwiedzających.
Osobną sprawą jest milczenie wobec klientów. Jeżeli strona przez kilka dni kierowała ludzi na obce adresy, krótka i rzeczowa informacja o zdarzeniu oraz o podjętych działaniach chroni zaufanie lepiej niż udawanie, że nic się nie stało. Zasady takiej komunikacji opisałem we wpisie o tym, jak przejść przez kryzys wizerunkowy w internecie w pierwszej dobie.
Kiedy oddać sprawę specjaliście?
Samodzielne czyszczenie ma sens przy prostej stronie firmowej, gdy istnieje kopia zapasowa albo infekcja ogranicza się do kilku plików. Radzę nie próbować samemu, gdy chodzi o sklep internetowy lub stronę z kontami klientów, gdy brakuje czystej kopii przy rozległych zmianach, gdy infekcja wróciła po czyszczeniu albo gdy na jednym koncie hostingowym działa kilka witryn.
Jeżeli strona przetwarza dane osobowe, a intruz mógł uzyskać do nich dostęp, administrator danych powinien ocenić, czy doszło do naruszenia ochrony danych. RODO przewiduje zgłoszenie takiego naruszenia organowi nadzorczemu bez zbędnej zwłoki, w miarę możliwości nie później niż w ciągu 72 godzin od jego stwierdzenia, chyba że jest mało prawdopodobne, by skutkowało ono ryzykiem dla praw i wolności osób. Ocenę warto oprzeć na opinii prawnika lub inspektora ochrony danych.
Najczęstsze pytania
Czy wystarczy zainstalować wtyczkę zabezpieczającą i uruchomić skan?
Nie. Skaner wskazuje podejrzane pliki, ale nie daje pewności, że znalazł wszystkie, a ukryte wejścia bywają pisane tak, aby go ominąć. Dokumentacja WordPressa łączy skan z podmianą plików systemu, przeglądem katalogu wp-content, zmianą haseł i wymianą kluczy bezpieczeństwa. Dopiero komplet tych czynności daje rozsądną pewność.
Czy zainfekowana strona traci pozycje w Google?
Może je tracić z kilku powodów naraz: ostrzeżenie odstrasza odwiedzających, obce treści zmieniają tematykę witryny w oczach wyszukiwarki, a przekierowania odcinają ruch. Po oczyszczeniu i pozytywnym wyniku sprawdzenia etykiety znikają, a widoczność zwykle wraca stopniowo, wraz z ponownym odwiedzaniem stron przez robota. Żadnego terminu nie da się tu uczciwie obiecać.
Hosting wyłączył stronę. Co wtedy?
Należy poprosić pomoc techniczną o listę wykrytych plików, o dostęp do plików przez SFTP mimo blokady oraz o informację, jakie kopie zapasowe są dostępne. Po oczyszczeniu zgłasza się hostingowi wykonane czynności z prośbą o ponowny skan i odblokowanie. Dokumentacja WordPressa zaleca kontakt z hostingiem również dlatego, że na serwerze współdzielonym problem może dotyczyć nie tylko jednej witryny.
Czy trzeba powiadomić klientów o włamaniu?
Zależy to od tego, czy ucierpiały dane osobowe. Gdy naruszenie może powodować wysokie ryzyko dla osób, których dane dotyczą, RODO wymaga zawiadomienia ich bez zbędnej zwłoki, a ocena tej sytuacji należy do administratora danych.
Czy przywrócenie kopii usuwa obce adresy z Google?
Nie. Przywrócenie kopii usuwa obce strony z serwera, ale wyszukiwarka pamięta je do czasu ponownego odwiedzenia. Należy upewnić się, że te adresy zwracają kod 404, i w razie potrzeby zgłosić je w narzędziu „Usunięcia”.
Ostrzeżenie w przeglądarce nie znika mimo czyszczenia. Dlaczego?
Najczęściej dlatego, że prośba o sprawdzenie nie została wysłana albo czeka na rozpatrzenie. Ostrzeżenie nie znika samo w chwili usunięcia plików, a po pozytywnej decyzji Google potrzebuje jeszcze do 72 godzin. Jeżeli decyzja była odmowna, w raporcie „Problemy dotyczące bezpieczeństwa” pojawiają się kolejne przykładowe adresy do naprawy.
Brak czasu albo ochoty, żeby zająć się tym samodzielnie?
To zupełnie zrozumiałe. Opisane czynności wymagają spokoju i kilku wolnych godzin, a w firmie zwykle brakuje jednego i drugiego. Chętnie zrobię to od początku do końca: oczyszczę zainfekowaną stronę, zgłoszę ją do ponownego sprawdzenia w Google i zabezpieczę na przyszłość.
Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i w kilku zdaniach opisać sprawę. Odpowiadam osobiście i od razu mówię, co da się zrobić.
