Bezpieczeństwo WordPressa: hardening, który naprawdę działa

Według rocznych raportów firm zajmujących się bezpieczeństwem WordPressa zdecydowana większość nowych podatności dotyczy wtyczek i motywów, nie rdzenia.

• aktualizuj rdzeń, wtyczki i motywy regularnie (drobne wersje rdzenia — automatycznie),
• usuń (nie tylko wyłącz) nieużywane wtyczki i motywy,
• instaluj wyłącznie rozszerzenia aktywnie rozwijane, z repozytorium WordPress.org lub od zaufanego producenta — nigdy „nulled”,
• używaj wspieranej wersji PHP (8.2 lub nowszej) — starsze wersje nie dostają poprawek bezpieczeństwa,
• subskrybuj powiadomienia o podatnościach (np. Patchstack, Wordfence Intelligence, WPScan).

Ataki brute force i wypełnianie danymi z wycieków (credential stuffing) to codzienność każdej strony.

• wymuś uwierzytelnianie dwuskładnikowe dla administratorów i redaktorów (aplikacja TOTP lub passkeys / klucze sprzętowe),
• ogranicz liczbę prób logowania i blokuj podejrzane adresy IP,
• nie używaj loginu „admin” i nie wyświetlaj nazw użytkowników jako autorów w adresach URL,
• wyłącz xmlrpc.php, jeśli nie korzystasz z aplikacji mobilnej ani Jetpacka,
• loguj się zawsze przez HTTPS, a sesje administratora skracaj.

Każde konto to potencjalne wejście. Nadawaj tylko te uprawnienia, które są niezbędne:

Na serwerze: pliki z uprawnieniami 644, katalogi 755, wp-config.php — 600 lub 640. Użytkownik bazy danych powinien mieć dostęp wyłącznie do jednej bazy.

Kilka linijek w wp-config.php znacząco utrudnia atak po przejęciu konta:

define( 'DISALLOW_FILE_EDIT', true );   // brak edytora plików w panelu
define( 'WP_DEBUG', false );            // na produkcji bez komunikatów błędów
define( 'FORCE_SSL_ADMIN', true );
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

• używaj unikalnych kluczy i soli (generator na api.wordpress.org),
• zablokuj wykonywanie PHP w katalogu wp-content/uploads,
• wyłącz listowanie katalogów,
• dodaj nagłówki bezpieczeństwa: Strict-Transport-Security, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy i — po testach — Content-Security-Policy.

WAF filtruje złośliwy ruch, zanim dotrze do WordPressa. Najlepiej działa na poziomie DNS/CDN (np. Cloudflare) lub serwera; wtyczka bezpieczeństwa to druga linia obrony.

• włącz reguły zarządzane i ochronę przed botami,
• ogranicz dostęp do /wp-admin i wp-login.php (np. wyzwanie dla podejrzanego ruchu, limit żądań),
• skanuj pliki pod kątem zmian i złośliwego kodu,
• włącz dziennik aktywności (kto, co i kiedy zmienił),
• ustaw powiadomienia o logowaniach administratorów i o zmianach plików rdzenia.

Kopia, której nigdy nie przywracałeś, jest tylko nadzieją. Stosuj zasadę 3-2-1:

• 3 kopie danych,
• na 2 różnych nośnikach lub usługach,
• 1 poza serwerem i kontem hostingu (np. zewnętrzna chmura z wersjonowaniem).

Kopiuj pliki i bazę danych — sklep codziennie lub częściej, stronę firmową co najmniej raz w tygodniu i przed każdą aktualizacją. Raz na kwartał przetestuj przywrócenie na kopii roboczej.

Plan na wypadek włamania: odetnij dostęp (tryb serwisowy), zmień wszystkie hasła i klucze, przywróć czystą kopię, zaktualizuj wszystko, znajdź przyczynę w logach, poproś Google o ponowne sprawdzenie w Search Console.