Jak najczęściej dochodzi do włamania na stronę WordPress
Sam rdzeń WordPressa jest dziś rzadkim punktem wejścia, bo luki są łatane szybko, a drobne wydania bezpieczeństwa instalują się automatycznie. Głównym problemem są wtyczki i motywy: po publikacji informacji o luce automaty zaczynają ją wykorzystywać w ciągu godzin, a strona, która aktualizuje się raz na kwartał, jest przez ten czas otwarta. Drugą drogą są dane logowania: hasła użyte w innym serwisie, który wyciekł, albo proste hasła zgadywane przez tysiące prób. Trzecią są zaniedbania na serwerze: kopie bazy w katalogu publicznym, pliki instalacyjne, stare wersje PHP, uprawnienia pozwalające zapisywać wszędzie. Każde z poniższych ustawień zamyka jedną z tych dróg.
1. Aktualizacje wtyczek i motywów na kopii testowej, co tydzień
Aktualizacja to najskuteczniejsze zabezpieczenie, ale też najczęstsza przyczyna awarii, więc bez procesu jest odkładana. Rozwiązanie to kopia testowa (staging): aktualizujesz tam rdzeń, wtyczki i motyw, sprawdzasz kluczowe podstrony, formularze i koszyk, a dopiero potem powtarzasz to na produkcji, zaraz po świeżej kopii zapasowej. Krytyczne poprawki bezpieczeństwa warto wdrażać tego samego dnia. Szczegóły procesu opisujemy na stronie aktualizacja WordPress.
2. Usunięcie nieużywanych wtyczek i motywów
Wyłączona wtyczka nadal leży na serwerze i jej pliki da się wywołać bezpośrednio. Tak samo stare motywy domyślne, których nikt nie aktualizuje. Zostaw aktywny motyw, jego motyw nadrzędny i jeden motyw domyślny jako awaryjny, a wszystko, czego nie używasz, usuń. Sprawdź też wtyczki porzucone przez autorów: jeśli wtyczka od dwóch lat nie dostała aktualizacji albo zniknęła z katalogu, poszukaj zamiennika.
3. Imienne konta i minimalne uprawnienia
Każda osoba ma własne konto, a nie wspólny login „admin". Rolę administratora dostają tylko ci, którzy naprawdę instalują wtyczki i zmieniają ustawienia. Redaktor treści potrzebuje roli Redaktor, a osoba od zamówień w sklepie roli Kierownik sklepu. Raz na kwartał przejrzyj listę kont i usuń te, które należą do byłych pracowników, dawnych wykonawców i testów. Każde zbędne konto administratora to dodatkowe hasło, które może wyciec.
4. Uwierzytelnianie dwuskładnikowe (2FA) dla administratorów
Nawet silne hasło może wyciec z innego serwisu. Drugi składnik logowania, czyli kod z aplikacji uwierzytelniającej albo klucz sprzętowy, sprawia, że samo hasło nie wystarcza do wejścia. Włącz 2FA obowiązkowo dla ról administratora i redaktora, a kody zapasowe przechowuj w menedżerze haseł, nie w mailu.
5. Limit prób logowania i ochrona wp-login.php
Automaty próbują tysięcy kombinacji haseł na wp-login.php i przez xmlrpc.php. Ogranicz liczbę nieudanych prób z jednego adresu IP i czasowo blokuj adresy, które ją przekraczają. Jeśli nie korzystasz z aplikacji mobilnej WordPressa ani z usług, które łączą się przez XML-RPC, wyłącz ten interfejs albo zablokuj go na poziomie serwera. Dostęp do panelu możesz dodatkowo ograniczyć do znanych adresów IP, jeśli zespół pracuje ze stałych lokalizacji.
6. Blokada edycji plików z panelu
WordPress domyślnie pozwala edytować pliki motywu i wtyczek z poziomu panelu. Dla włamywacza, który przejął konto administratora, to najszybsza droga do wgrania złośliwego kodu. Dodaj do wp-config.php stałą DISALLOW_FILE_EDIT ustawioną na true. Jeśli wszystkie aktualizacje robisz przez kopię testową i wdrożenie, możesz pójść dalej i ustawić DISALLOW_FILE_MODS, co blokuje też instalowanie wtyczek z panelu.
7. Poprawne uprawnienia plików i zabezpieczony wp-config.php
Katalogi powinny mieć uprawnienia 755, pliki 644, a wp-config.php 640 albo 600, czyli nigdy 777. Właścicielem plików powinien być użytkownik konta, a proces serwera WWW powinien mieć prawo zapisu tylko tam, gdzie to konieczne, zwykle w katalogu uploads. Zablokuj w konfiguracji serwera bezpośredni dostęp do wp-config.php, plików .htaccess, .git i plików z rozszerzeniami .sql, .zip, .bak i .log. Wygeneruj też własne klucze i sole w wp-config.php, jeśli strona ma je z domyślnej instalacji albo z kopii innej strony.
8. Blokada wykonywania PHP w katalogu uploads
Katalog wp-content/uploads służy do obrazów i dokumentów, a nie do skryptów. Częsty scenariusz włamania to wgranie pliku PHP przez lukę w formularzu albo wtyczce i wywołanie go z przeglądarki. Reguła serwera, która zabrania wykonywania plików PHP w uploads, sprawia, że taki plik jest bezużyteczny, nawet jeśli trafi na dysk.
9. Aktualna wersja PHP i HTTPS z nagłówkami bezpieczeństwa
Wersja PHP bez wsparcia nie dostaje już poprawek bezpieczeństwa, więc luki w samym interpreterze zostają otwarte na zawsze. Utrzymuj wersję z aktywnym wsparciem, zgodną z wtyczkami. Cała strona ma działać przez HTTPS z przekierowaniem z HTTP i nagłówkiem Strict-Transport-Security. Dodaj nagłówki X-Content-Type-Options, Referrer-Policy i ograniczenie ramek (X-Frame-Options albo frame-ancestors w Content-Security-Policy), które utrudniają ataki przez osadzanie strony i podmianę typu treści.
10. Zapora aplikacyjna (WAF)
Zapora aplikacyjna analizuje ruch, zanim dotrze do WordPressa, i odrzuca znane wzorce ataków: wstrzykiwanie SQL, próby wywołania znanych luk we wtyczkach, masowe skanowanie. Najlepiej działa zapora na poziomie serwera albo sieci dostarczania treści, bo odciąża też serwer. Zapora nie zastępuje aktualizacji, ale daje czas między publikacją luki a instalacją poprawki.
11. Kopie zapasowe poza serwerem, sprawdzane odtworzeniem
Kopia nie zapobiega włamaniu, ale decyduje o tym, ile ono kosztuje. Trzymaj kopie plików i bazy poza serwerem strony, bo włamywacz albo szyfrujący skrypt z dostępem do serwera usunie też kopie leżące obok. Zachowaj kopie z co najmniej kilkudziesięciu dni, bo infekcja bywa wykryta dopiero po tygodniach, a wtedy świeże kopie są już zarażone. Raz w miesiącu odtwórz kopię na środowisku testowym. Więcej piszemy w tekście o tym, jak działa kopia zapasowa WordPress.
12. Monitoring zmian plików, dostępności i list ostrzeżeń
Włamanie często nie psuje strony, tylko dodaje ukryte linki, przekierowania dla użytkowników z wyszukiwarki albo nowe konto administratora. Dlatego potrzebny jest monitoring, który zauważy zmianę sum kontrolnych plików rdzenia, nowe pliki PHP, nowe konta z rolą administratora, pojawienie się domeny na listach niebezpiecznych stron i spadek dostępności. Alarm musi trafić do człowieka, który wie, co z nim zrobić. Sposób działania opisujemy na stronie monitoring WordPress.
Czego nie robić, zabezpieczając WordPressa
Kilka popularnych porad daje poczucie bezpieczeństwa, a niewiele zmienia. Zmiana prefiksu tabel bazy danych po instalacji niczego nie blokuje, a źle przeprowadzona psuje stronę. Ukrywanie numeru wersji WordPressa nie zatrzyma automatów, które i tak próbują wszystkich znanych luk. Instalowanie trzech wtyczek bezpieczeństwa naraz spowalnia stronę i powoduje konflikty. Lepiej mieć jedną dobrze skonfigurowaną ochronę i dwanaście ustawień z tej listy niż stos dodatków, których nikt nie konfiguruje.
Co zrobić, jeśli strona już została zainfekowana
Jeśli widzisz przekierowania na obce strony, ostrzeżenie przeglądarki albo nieznane konta administratorów, nie zaczynaj od przywracania pierwszej lepszej kopii. Najpierw zabezpiecz dowody i odetnij dostęp: zmień hasła do panelu, bazy, FTP i hostingu, unieważnij sesje przez nowe klucze i sole. Potem ustal, od kiedy trwa infekcja, i przywróć kopię sprzed tej daty albo oczyść pliki ręcznie, porównując je z oryginalnymi wersjami. Na koniec zamknij lukę, przez którą weszło włamanie, bo inaczej wróci. Pełny proces opisujemy na stronie usuwanie wirusów ze stron internetowych.
Pytania o zabezpieczenie WordPressa
Czy wtyczka bezpieczeństwa wystarczy do ochrony przed włamaniem?
Nie. Wtyczka pomaga w ochronie logowania i skanowaniu, ale nie zaktualizuje za Ciebie innych wtyczek, nie poprawi uprawnień plików ani nie przeniesie kopii poza serwer. Ochronę daje zestaw ustawień i regularna praca, a wtyczka jest tylko jednym z narzędzi.
Jak często aktualizować WordPressa, żeby był bezpieczny?
Co najmniej raz w tygodniu, a krytyczne poprawki bezpieczeństwa tego samego dnia, w którym zostały opublikowane. Każda aktualizacja powinna przejść najpierw przez kopię testową i mieć świeżą kopię zapasową tuż przed wdrożeniem na produkcję.
Czy mała strona firmowa też jest celem ataków?
Tak. Automaty skanujące sieć nie wybierają stron według wielkości firmy, tylko według znanych luk i słabych haseł. Mała strona bywa nawet łatwiejszym celem, bo rzadziej ktoś ją aktualizuje i monitoruje.
Skąd mam wiedzieć, że moja strona została zainfekowana?
Typowe objawy to przekierowania na obce strony, zwłaszcza dla osób wchodzących z wyszukiwarki, ostrzeżenie w przeglądarce, nieznane konta administratorów, nowe pliki PHP w katalogach wtyczek albo uploads i nagły spadek ruchu. Część infekcji nie daje objawów, dlatego potrzebny jest monitoring zmian plików.
Zabezpieczenie WordPress w stałej opiece AdministracjaStron
W opiece wszystkie 12 ustawień wdrażamy przy przejęciu strony, a potem pilnujemy ich co tydzień: aktualizacje najpierw na kopii testowej, przegląd kont i wtyczek, kopie poza serwerem i monitoring. Przejęcie, pierwsza pełna kopia i przegląd bezpieczeństwa są w cenie pierwszego miesiąca. Zakres zależy od planu. Wszystkie ceny netto.
- Start, 299 zł miesięcznie: skan bezpieczeństwa co tydzień, ochrona logowania, kopie codziennie przez 30 dni, monitoring co 5 minut.
- Firma, 599 zł miesięcznie: skan codziennie, zapora aplikacyjna (WAF), usuwanie infekcji w cenie bez zużywania godzin zmian, kopie przez 60 dni.
- Biznes, 1 499 zł miesięcznie: wszystko z planu Firma oraz utwardzenie serwera i przegląd uprawnień kont, kopie przez 90 dni, reakcja w 1 godzinę od 7:00 do 22:00.
- Enterprise, 2 990 zł miesięcznie: audyt bezpieczeństwa co kwartał, rejestr incydentów, reakcja w 30 minut 24/7 i SLA w umowie.
Szczegóły znajdziesz na stronie zabezpieczenie WordPress i w cenniku opieki nad stroną WordPress. Jeśli chcesz sprawdzić, co widać z zewnątrz na Twojej stronie (wersje, wtyczki, certyfikat, nagłówki bezpieczeństwa), zacznij od jednorazowego audytu WordPress.