Strona na WordPressie jest tak silna, jak jej najsłabsza wtyczka, konto lub kopia zapasowa. Rdzeń WordPressa regularnie otrzymuje wydania bezpieczeństwa; to, co Państwo do niego dodają i jak go utrzymują, zależy od Państwa. Ta lista kontrolna obejmuje najważniejsze zabezpieczenia, mniej więcej w kolejności, w jakiej sami byśmy je wdrażali.
1. Aktualizować rdzeń, wtyczki i motywy
Automatyczne aktualizacje rdzenia w tle istnieją od WordPressa 3.7 i domyślnie obejmują wydania poboczne (minor). Od WordPressa 5.5 można też włączyć automatyczne aktualizacje dla poszczególnych wtyczek i motywów z poziomu panelu administracyjnego.
- Włączyć automatyczne aktualizacje wtyczek od renomowanych twórców, a pozostałe przeglądać co tydzień.
- Automatyczne aktualizacje zależą od WP-Cron. Warto sprawdzać błędy w Narzędzia > Zdrowie witryny (Tools > Site Health), ponieważ niedziałający cron oznacza, że aktualizacje po cichu przestają się wykonywać.
- Zanim zacznie się polegać na automatycznych aktualizacjach, należy upewnić się, że da się je wycofać. Zaleca to również dokumentacja WordPressa.
2. Usunąć porzucone i nieużywane wtyczki
Przewodnik WordPressa dotyczący zabezpieczania (hardening) mówi wprost: wtyczki należy aktualizować, a nieużywane usuwać. Dezaktywacja nie wystarcza, ponieważ kod pozostaje na serwerze.
Katalog wtyczek WordPress.org daje dwa sygnały ostrzegawcze:
- Żółty komunikat informujący, że wtyczka „nie została przetestowana z 3 ostatnimi głównymi wydaniami WordPressa”.
- Czerwony komunikat informujący, że wtyczka została zamknięta i nie jest już dostępna do pobrania. Po 60 dniach wyświetlany jest powód, a jednym z wymienionych powodów jest „problem z bezpieczeństwem”.
Zamknięta wtyczka nie będzie otrzymywać aktualizacji przez WordPress.org. Należy ją zastąpić. Nigdy nie należy instalować „nulled”, czyli nielegalnie odblokowanych kopii wtyczek premium, a wtyczki instalować wyłącznie z WordPress.org lub od zaufanych dostawców.
3. Przejrzeć konta administratorów
Należy sporządzić listę wszystkich kont z rolą Administrator i usunąć te, których istnienia nikt nie potrafi wyjaśnić. Za pomocą WP-CLI:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registeredKażda osoba powinna mieć własne imienne konto, nigdy wspólny login admin. Należy przydzielać najniższą rolę, która wystarcza do pracy: większość redaktorów treści nie potrzebuje roli Administrator. Trzeba wymagać silnych, unikalnych haseł, najlepiej przechowywanych w menedżerze haseł.
4. Włączyć uwierzytelnianie dwuskładnikowe
2FA należy włączyć dla każdego administratora. Rdzeń WordPressa nie zawiera 2FA, więc potrzebna jest wtyczka lub dostawca jednokrotnego logowania, który je wymusza. Jeśli wtyczka to obsługuje, warto wybierać metody takie jak klucze bezpieczeństwa lub klucze dostępu (passkeys), a kody odzyskiwania przechowywać w bezpiecznym miejscu.
5. Ograniczyć próby logowania i zdecydować o XML-RPC
Dokumentacja WordPressa wskazuje wp-login.php i xmlrpc.php jako częste cele ataków siłowych (brute force). Zaleca ograniczanie liczby prób logowania na brzegu sieci (WAF lub CDN) albo na serwerze WWW. Wtyczka bezpieczeństwa również może spowalniać logowania, ale działa w PHP, więc rozwiązanie na poziomie serwera lepiej radzi sobie przy dużym ruchu.
Jeśli XML-RPC nie jest używany, należy go wyłączyć. Niektóre aplikacje mobilne i usługi, takie jak Jetpack, go potrzebują, więc najpierw warto to sprawdzić. Filtr xmlrpc_enabled wyłącza tylko metody wymagające uwierzytelnienia. Pingbacki i inne metody bez uwierzytelniania nadal działają. Aby całkowicie wyłączyć XML-RPC, należy zablokować plik na serwerze WWW. Dla nginx:
location = /xmlrpc.php {
deny all;
}6. Wyłączyć wbudowany edytor plików
Edytor motywów i wtyczek w kokpicie pozwala każdemu, kto ma sesję administratora, zmieniać kod PHP. Należy go wyłączyć w wp-config.php:
define( 'DISALLOW_FILE_EDIT', true );Według dokumentacji wp-config.php DISALLOW_FILE_MODS idzie dalej i blokuje również instalowanie i aktualizowanie wtyczek oraz motywów z kokpitu. Należy go używać tylko wtedy, gdy zmiany wdraża się w inny sposób, np. przez Git lub WP-CLI.
7. Przechowywać kopie zapasowe poza serwerem i poza katalogiem głównym strony
Przewodnik dotyczący zabezpieczania zaleca regularne kopie zapasowe zarówno plików, jak i bazy danych, kilka migawek i zaufane miejsce przechowywania. Ich integralność należy chronić szyfrowaniem, zapisanymi skrótami lub nośnikami tylko do odczytu.
Wynikają z tego dwie praktyczne zasady. Kopię zapasową w katalogu głównym strony, np. plik zip w wp-content, może pobrać każdy, kto odgadnie jej nazwę. Kopię na tym samym serwerze może usunąć ten sam atakujący. Co najmniej jedną kopię należy przechowywać w miejscu niedostępnym dla danych logowania strony i przetestować pełne przywracanie.
8. Sprawdzać integralność plików
WP-CLI potrafi porównać pliki z oficjalnymi sumami kontrolnymi WordPress.org bez ładowania WordPressa:
wp core verify-checksums --include-root
wp plugin verify-checksums --allPierwsze polecenie wskazuje zmodyfikowane pliki rdzenia, a --include-root ostrzega o nieoczekiwanych plikach w katalogu głównym. Drugie porównuje wtyczki z sumami kontrolnymi WordPress.org, więc pomaga tylko w przypadku wtyczek tam hostowanych. Warto też szukać plików PHP w wp-content/uploads, gdzie normalnie powinny znajdować się wyłącznie pliki multimedialne.
9. Używać użytkownika bazy danych z minimalnymi uprawnieniami
Każda strona powinna mieć własną bazę danych i własnego użytkownika bazy danych z uprawnieniami wyłącznie do tej bazy. Nigdy nie należy łączyć się jako użytkownik root bazy danych.
Przewodnik dotyczący zabezpieczania zauważa, że do codziennej pracy wystarczą SELECT, INSERT, UPDATE i DELETE. Nie zaleca jednak odbierania DROP, ALTER i GRANT, ponieważ wtyczki i duże aktualizacje mogą wymagać zmiany schematu. Jeśli mimo to zostaną odebrane, trzeba mieć przetestowane kopie zapasowe.
10. Ustawić uprawnienia plików
Punktem wyjścia według przewodnika jest 755 dla katalogów i 644 dla plików. Pliki rdzenia, wp-admin i wp-includes powinny być zapisywalne tylko przez Państwa konto użytkownika, a nie przez serwer WWW. Wyjątkiem jest wp-content: serwer WWW musi mieć tam prawo zapisu na potrzeby przesyłanych plików. Dla wp-config.php przewodnik sugeruje 400 lub 440.
find /var/www/example -type d -exec chmod 755 {} \;
find /var/www/example -type f -exec chmod 644 {} \;
chmod 440 /var/www/example/wp-config.phpPrzed uruchomieniem tych poleceń należy dostosować ścieżki i właściciela plików do konfiguracji hostingu.
11. Wysyłać nagłówki bezpieczeństwa
Nagłówki takie jak Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options i Referrer-Policy dodają ochronę po stronie przeglądarki. W miarę możliwości warto ustawiać je na serwerze WWW lub w CDN, a nie przez wtyczkę. Najlepiej zacząć od polityki Content Security Policy w trybie report-only, ponieważ motywy i kreatory stron mogą korzystać ze skryptów inline.
12. Postawić przed stroną WAF
Dokumentacja WordPressa opisuje trzy poziomy: wtyczki bezpieczeństwa filtrujące żądania wewnątrz WordPressa, zaporę na poziomie serwera, taką jak ModSecurity, oraz usługi reverse proxy, które filtrują ruch, zanim dotrze on do serwera. Im dalej od aplikacji odbywa się filtrowanie, tym mniejsze obciążenie trafia do PHP. WAF nie zastępuje aktualizacji. Daje czas między ujawnieniem podatności a wdrożeniem poprawki.
Wersja skrócona
| Obszar | Minimum |
|---|---|
| Aktualizacje | Automatyczne aktualizacje poboczne rdzenia włączone, wtyczki przeglądane co tydzień |
| Wtyczki | Brak zainstalowanych wtyczek zamkniętych, porzuconych lub nieużywanych |
| Konta | Konta imienne, niewielu administratorów, 2FA dla nich wszystkich |
| Logowanie | Ograniczanie prób na serwerze lub na brzegu sieci, XML-RPC zablokowany, jeśli nieużywany |
| Zmiany kodu | Ustawione DISALLOW_FILE_EDIT |
| Kopie zapasowe | Poza serwerem, poza katalogiem głównym strony, przywracanie przetestowane |
| Integralność | Sumy kontrolne zweryfikowane, brak plików PHP w katalogu uploads |
| Baza danych | Jeden użytkownik na stronę, z uprawnieniami tylko do własnej bazy |
| Przeglądarka | HSTS i przetestowana CSP |
| Brzeg sieci | WAF lub reverse proxy przed stroną |
Od czego zacząć
Warto zacząć od pierwszych czterech punktów. Zajmują niewiele czasu i nie wymagają zmian w hostingu. Następnie warto sprawdzić obecne nagłówki naszym skanerem nagłówków bezpieczeństwa.
Jeśli chcą Państwo, aby ktoś sprawdził to za Państwa, SecAudit skanuje WordPressa w poszukiwaniu złośliwego oprogramowania i web shelli, weryfikuje integralność plików względem oficjalnych sum kontrolnych i przypisuje zainstalowane wtyczki do znanych podatności.
