Zabezpieczanie WordPressa: kolejność, która się opłaca

Kto wpisuje w wyszukiwarkę „zabezpieczanie WordPressa”, znajduje listy z dwudziestoma punktami. Problem nie w tym, że punkty są błędne, lecz w tym, że stoją obok siebie z tą samą wagą. Pierwsze trzy dają więcej niż pozostałe siedemnaście razem.

Miejsce 1: aktualizacje, i to bez zwłoki

Większość przejętych stron nie pada ofiarą wyrafinowanego ataku, lecz znanej luki we wtyczce, na którą od tygodni istnieje aktualizacja. Zautomatyzowane masowe skany szukają właśnie tego.

W praktyce oznacza to: aktualizacje bezpieczeństwa automatycznie, aktualizacje funkcji ręcznie po krótkiej kontroli — i przed każdą aktualizacją punkt przywracania, żeby strach przed aktualizacją nie stał się powodem, by ją odkładać.

Wtyczka, która od dwóch lat nie dostała aktualizacji, jest ryzykiem, nawet jeśli działa. Przy okazji zrób porządek: to, co nie jest używane, należy usunąć, a nie dezaktywować.

Miejsce 2: logowanie

Drugie co do częstości drzwi to hasło. Cztery działania, w tej kolejności:

1. Ogranicz nieudane próby — to odbiera podstawę zautomatyzowanemu zgadywaniu haseł.
2. Wymuś siłę haseł, przynajmniej dla wszystkich, którzy mogą publikować.
3. Włącz drugi składnik uwierzytelniania, przynajmniej dla administratorów.
4. Żadnego konta z nazwą użytkownika „admin” i żadnej roli wyższej niż potrzeba.

Zmiana adresu logowania to piąty punkt, ale słabszy: trzyma z dala masowe skany i zmniejsza obciążenie, lecz nie zastępuje żadnego z czterech działań powyżej. Kto z niej korzysta, powinien zanotować nowy adres przed zapisaniem.

Miejsce 3: hardening — ustawić raz i zapomnieć

• Wyłączenie edycji plików w panelu administracyjnym — tam najchętniej umieszcza się złośliwy kod
• Wyłączenie XML-RPC, jeśli nic go nie potrzebuje
• Zablokowanie listowania katalogów
• Zablokowanie wykonywania PHP w katalogu uploads
• Ograniczenie wyliczania użytkowników przez REST API
• Ustawienie nagłówków bezpieczeństwa

Te przełączniki nic nie kosztują w działaniu i każdy z nich zamyka jeden znany skrót. To najlepszy stosunek nakładu do korzyści na całej liście.

Miejsce 4: widzieć, co się zmienia

Od tego miejsca nie chodzi już o zapobieganie, lecz o zauważanie. Opłacają się dwie rzeczy:

Porównanie rdzenia zestawia pliki WordPressa z sumami kontrolnymi z api.wordpress.org. Zmieniony plik rdzenia to bardzo wyraźny sygnał — nikt nie ma uzasadnionego powodu, by coś tam zmieniać.

Strażnik plików rejestruje stan i zgłasza odstępstwa. Jest tylko tak dobry jak moment rejestracji: stan zarejestrowany po infekcji uznaje złośliwy kod za normę.

Zarejestruj stan, dopóki da się wykazać, że strona jest czysta — najlepiej zaraz po świeżej instalacji albo po sprawdzonym przywróceniu.

Miejsce 5: firewall i skanowanie

Jedno i drugie ma sens i jedno i drugie celowo znajduje się tu na dole. Firewall w PHP działa dopiero wtedy, gdy WordPress już się uruchamia — nie zastępuje firewalla przed serwerem WWW. Skanowanie znajduje to, co przypomina jego wzorce, a nie każdy złośliwy kod.

Ważniejsze niż liczba reguł jest podejście do fałszywych alarmów. Narzędzie, którego przegląd stale świeci na czerwono, niczego już nie chroni — uczy odklikiwania. Dlatego pozwól firewallowi najpierw przez tydzień tylko zgłaszać i przejrzyj dziennik, zanim pozwolisz mu blokować.

Co często stoi na samej górze, a nie powinno

Punkt, o którym zapomina prawie każda lista

Wtyczka bezpieczeństwa zapobiega incydentom, kopia zapasowa pozwala je przetrwać. Kto musiałby wybierać między nimi, powinien wybrać kopię zapasową — to jedyne działanie, które pomaga nawet wtedy, gdy wszystkie inne zawiodły.

Najczęściej zadawane pytania