Strona wyczyszczona. Jak zabezpieczyć ją, żeby infekcja nie wróciła
Większość stron, które czyścimy drugi raz, nie została zhakowana na nowo. Została zhakowana tą samą drogą, bo po pierwszym czyszczeniu nikt jej nie zamknął. Oto lista, którą warto przejść zaraz po usunięciu infekcji.
Najpierw: ustal, jak weszli
Bez tego reszta jest zgadywaniem. Trzy najczęstsze drogi:
- Luka we wtyczce lub rozszerzeniu (zdecydowanie najczęstsza; w 2025 ujawniono ponad 11 tys. luk w ekosystemie WordPressa, 91 % we wtyczkach).
- Przejęte hasło do panelu CMS, FTP lub hostingu — często przez wyciek z innego serwisu, gdzie użyto tego samego hasła.
- Inna strona na tym samym koncie hostingowym. Jedno konto, dziesięć stron: infekcja jednej to dostęp do wszystkich.
Logi dostępu hostingu (access_log) z okresu przed infekcją pokażą podejrzane żądania POST do plików wtyczek albo logowania z nietypowych adresów.
12 kroków, które zamykają drzwi
1. Zmień wszystkie hasła, naprawdę wszystkie
Panel CMS (każdy użytkownik z uprawnieniami edytora i wyżej), baza danych (i wpis w wp-config.php / configuration.php), FTP/SFTP/SSH, panel hostingu, poczta na domenie. Użyj menedżera haseł; hasła mają być różne.
2. Wyloguj wszystkie sesje i wymień klucze
W WordPressie zmień sole w wp-config.php (AUTH_KEY itd.) — to unieważnia wszystkie ciasteczka logowania. W Joomli zmień secret w configuration.php. Wygeneruj nowe klucze API wtyczek i usług zewnętrznych.
3. Usuń nieznanych użytkowników
Sprawdź listę użytkowników, zwłaszcza administratorów. Zwróć uwagę na konta z adresami e-mail w obcych domenach albo z loginem przypominającym systemowy (wpadmin, support).
4. Zaktualizuj rdzeń, wtyczki i motyw
Wszystko. Jeśli któraś wtyczka nie ma aktualizacji od ponad roku, poszukaj zamiennika.
5. Usuń to, czego nie używasz
Nieaktywna wtyczka z luką nadal jest luką — jej pliki są na serwerze i da się je wywołać. To samo dotyczy nieużywanych motywów i rozszerzeń Joomli.
6. Zablokuj wykonywanie PHP w katalogach na pliki
W wp-content/uploads (WordPress) i images (Joomla) nie powinno działać PHP. Plik .htaccess w tym katalogu:
<FilesMatch "\.(php|phtml|php5|php7|phar)$">
Require all denied
</FilesMatch>
Uwaga: to legalny .htaccess blokujący. Nielegalny jest taki, który do blokady dodaje allowlistę konkretnych nazw plików PHP.
7. Wyłącz edycję plików z panelu
WordPress: define('DISALLOW_FILE_EDIT', true); w wp-config.php. Przejęte konto administratora nie będzie mogło wkleić shella przez edytor motywu.
8. Ogranicz logowanie
Dwuskładnikowe uwierzytelnianie dla administratorów, limit prób logowania, zmiana adresu panelu logowania to bonus, nie podstawa.
9. Popraw uprawnienia
Katalogi 755, pliki 644, pliki konfiguracyjne 640 lub 600. Żadnych 777.
10. Odseparuj strony na hostingu
Jeśli na jednym koncie masz kilka stron, rozważ osobne konta albo przynajmniej osobnych użytkowników systemowych (jeśli hosting na to pozwala). Jedna zainfekowana strona nie powinna mieć dostępu do plików drugiej.
11. Włącz kopie zapasowe poza serwerem
Kopia na tym samym serwerze zginie razem z nim. Automatyczna kopia do zewnętrznego miejsca (S3, Dropbox, serwer backupowy) z retencją co najmniej 30 dni pozwoli wrócić do stanu sprzed infekcji, gdy ta zostanie zauważona po tygodniu.
12. Ustaw monitoring
Google Search Console (ostrzeżenia bezpieczeństwa), powiadomienia hostingu o skanie, prosty monitor dostępności, który sprawdzi też treść strony (czy na stronie głównej nadal jest Twoja nazwa firmy). Zmiana treści na stronie głównej to często pierwszy sygnał.
Czego się spodziewać po czyszczeniu
- Google zdejmuje ostrzeżenie po ponownym sprawdzeniu, zwykle w ciągu 1 do 3 dni od zgłoszenia w Search Console.
- Hosting zdejmuje blokadę po ponownym skanie, na Twoje zgłoszenie.
- Pozycje w wyszukiwarce wracają stopniowo, od kilku dni do kilku tygodni.
Powtórne sprawdzenie za tydzień
Zrób skan ponownie po 7 dniach. Jeśli coś wróciło, droga wejścia jest nadal otwarta i trzeba wrócić do punktu „ustal, jak weszli”. W CleanOps powtórne sprawdzenie strony nic nie kosztuje, więc warto zrobić je rutynowo.
