Większość właścicieli stron kończy zabezpieczanie WordPressa na instalacji popularnej wtyczki „all-in-one”. Z perspektywy inżynierii systemów, prawdziwa odporność – określana jako hardening (utwardzanie) – zaczyna się znacznie głębiej: na poziomie konfiguracji serwera i architektury plików.
Dlaczego WordPress jest tak częstym celem ataków? Prosta matematyka: napędza ponad 40% wszystkich witryn w Internecie. Dla autorów złośliwego oprogramowania oznacza to jeden skrypt, który działa na milionach potencjalnych celów jednocześnie. Popularność platformy przekłada się bezpośrednio na wielkość powierzchni ataku.
Wdrożenie poniższych procedur drastycznie podnosi odporność witryny na zautomatyzowane ataki, jednocześnie nie obciążając bazy danych i nie spowalniając Core Web Vitals (Podstawowych Wskaźników Wydajności Strony).
1. Relokacja pliku konfiguracyjnego (wp-config.php)
Plik wp-config.php zawiera dane uwierzytelniające do bazy danych oraz klucze szyfrujące. Jego standardowa lokalizacja w folderze głównym (public_html) jest pierwszym punktem styku dla skryptów atakujących.
- Zabieg: Przeniesienie pliku o jeden poziom wyżej względem katalogu głównego serwera.
- Logika: WordPress jest zaprojektowany tak, by automatycznie szukać konfiguracji w katalogu nadrzędnym, jeśli nie znajdzie jej w głównym. Dzięki temu plik staje się fizycznie nieosiągalny dla skanerów z zewnątrz. To jak przeniesienie klucza do sejfu z haczyka w przedpokoju do ukrytej skrytki, o której wiedzą tylko domownicy.
- Podwójny rygiel (redundancja): Jako dodatkową warstwę ochrony warto zaimplementować blokadę dostępu w głównym pliku .htaccess. Nawet jeśli plik konfiguracyjny z jakiegoś powodu pozostałby w folderze głównym (np. po błędnej migracji), serwer odrzuci każdą próbę wywołania go przez protokół HTTP/HTTPS.
Kod Apache do ochrony pliku wp-config.php w pliku .htaccess:
<files wp-config.php>
order allow,deny
deny from all
</files>JAK SPRAWDZIĆ CZY WDROŻONO: Połącz się ze swoją stroną przez FTP. Jeśli widzisz plik wp-config.php bezpośrednio obok folderów wp-admin i wp-content – Twoja strona wymaga utwardzenia.
2. Blokada wykonania PHP w katalogu /uploads/
Folder /wp-content/uploads/ musi mieć uprawnienia do zapisu, co czyni go najczęstszym wektorem ataku. Hakerzy próbują tam przemycić złośliwy kod, np. w plikach PHP udających zdjęcia.
- Zabieg: Implementacja pliku .htaccess wewnątrz folderu /uploads/ z poniższą dyrektywą.
Kod Apache do wdrożenia w pliku .htaccess:
<files *.php>
deny from all
</files>JAK SPRAWDZIĆ CZY WDROŻONO: Wejdź w folder /wp-content/uploads/. Jeśli nie widzisz tam pliku .htaccess z powyższym kodem, masz krytyczną lukę zwiększającą podatność na ataki.
3. Blokada protokołu XML-RPC
XML-RPC (Extensible Markup Language Remote Procedure Call) to przestarzały protokół umożliwiający zdalną komunikację między aplikacjami a WordPress-em. Choć kiedyś był niezbędny do mobilnego publikowania postów, dziś stanowi głównie zagrożenie. Służy do przeprowadzania ataków typu Brute Force (automatyczne próby zgadywania hasła) oraz ataków DDoS (Distributed Denial of Service).
Atak DDoS polega na rozproszonym bombardowaniu serwera gigantyczną liczbą zapytań w ułamku sekundy, co prowadzi do jego przeciążenia i całkowitego zablokowania Twojej strony. XML-RPC pozwala napastnikowi na tzw. amplifikację – jedno zapytanie do tego pliku może wygenerować setki prób logowania, co „męczy” serwer znacznie szybciej niż standardowe logowanie.
- Zabieg: Całkowita blokada dostępu do pliku xmlrpc.php na poziomie serwera.
Kod Apache do wdrożenia w pliku .htaccess:
<files xmlrpc.php>
order deny,allow
deny from all
</files>Kod do wdrożenia dla serwerów Nginx:
location = /xmlrpc.php {
deny all;
}JAK SPRAWDZIĆ CZY WDROŻONO: Wpisz w przeglądarce: twojadomena.pl/xmlrpc.php. Jeśli zobaczysz komunikat „XML-RPC server accepts POST requests only” – Twoja strona jest otwarta na ataki botów. Prawidłowo utwardzona witryna powinna zwrócić błąd 403 Forbidden.
4. Restrykcje uprawnień systemu plików (Chmod)
Stosujemy zasadę minimalnych uprawnień. Większość infekcji wynika ze zbyt „luźnych” ustawień, które pozwalają skryptom na dowolną modyfikację plików systemowych. Służy do tego systemowa komenda Chmod (Change Mode).
Chmod to standard uprawnień w systemach Linux, na których działa większość serwerów. Cyfry (np. 644 czy 755) to matematyczny zapis uprawnień do odczytu, zapisu i wykonywania plików dla różnych grup użytkowników.
Analiza porównawcza uprawnień dla wp-config.php:
| Chmod | Poziom ochrony | Opis |
| 644 | Słaby | Standardowy. Pozwala właścicielowi na edycję. Ryzykowny na serwerach współdzielonych. |
| 600 | Dobry | Izolacja. Tylko proces właściciela strony może czytać i edytować plik. |
| 400 | Maksymalny | Nieprzebijalny mur. Tylko odczyt przez właściciela. Nawet proces PHP nie może nadpisać pliku. |
Standard dla reszty struktury:
- Katalogi: 755 (właściciel: pełne, reszta: tylko odczyt i uruchamianie).
- Pliki: 644 (właściciel: edycja, reszta: tylko odczyt).
JAK SPRAWDZIĆ CZY WDROŻONO: Sprawdź kolumnę Permissions w swoim kliencie FTP. Jeśli przy folderach widzisz uprawnienia 777, a przy pliku wp-config.php wartość inną niż 600 lub 400 – katalogi i kluczowy plik konfiguracyjny Twojej strony nie są wystarczająco dobrze chronione.
5. Wyłączenie edytora plików wewnątrz kokpitu
Domyślnie WordPress pozwala na edycję kodu motywu i wtyczek bezpośrednio z poziomu przeglądarki. To poważne ryzyko – przejęcie hasła administratora umożliwia wówczas włamywaczowi potajemne wprowadzanie zmian i modyfikacji rozbrajających inne zabezpieczenia oraz tworzenie dodatkowych luk bezpieczeństwa (tzw. backdoors).
- Zabieg: Wyłączenie edytora poprzez wpis w pliku konfiguracyjnym.
Kod PHP do wdrożenia w pliku wp-config.php:
define( 'DISALLOW_FILE_EDIT', true );JAK SPRAWDZIĆ CZY WDROŻONO: Zaloguj się do panelu WordPress, wejdź w zakładkę Wygląd. Jeśli widzisz tam opcję Edytor plików motywu – bezpiecznik nie jest aktywny.
6. Nagłówki bezpieczeństwa HTTP
Nagłówki HTTP (Hypertext Transfer Protocol – Protokół Przesyłania Hipertekstu) to dodatkowa warstwa ochrony działająca na poziomie komunikacji między serwerem a przeglądarką użytkownika. Skutecznie blokują ataki XSS (Cross-Site Scripting – Wstrzykiwanie Złośliwych Skryptów) i clickjacking. Dzięki nim przeglądarka wie, że ma nie ufać potencjalnie złośliwym skryptom, które mogłyby próbować podszyć się pod elementy Twojej strony.
Część z nich pełni rolę „instrukcji obsługi” dla przeglądarki – mówią jej, z jakich źródeł wolno ładować skrypty i style (w ramach Content-Security-Policy – Polityki Bezpieczeństwa Treści) oraz że komunikacja z witryną ma odbywać się wyłącznie po szyfrowanym połączeniu HTTPS (Hypertext Transfer Protocol Secure – Bezpieczny Protokół Przesyłania Hipertekstu) w ramach Strict-Transport-Security – Wymuszonego Bezpiecznego Połączenia. To różnica między pojedynczym zamkiem a pełnym systemem alarmowym – każdy nagłówek zabezpiecza inny punkt wejścia.
- Zabieg: Implementacja nagłówków w pliku .htaccess w głównym katalogu witryny.
Kod Apache do wdrożenia w pliku .htaccess:
<ifmodule mod_headers.c>
header set x-content-type-options "nosniff"
header set x-frame-options "sameorigin"
header set x-xss-protection "1; mode=block"
header set referrer-policy "strict-origin-when-cross-origin"
header set permissions-policy "geolocation=(), microphone=(), camera=()"
header set strict-transport-security "max-age=31536000; includesubdomains"
header set content-security-policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https:; style-src 'self' 'unsafe-inline' https:; img-src 'self' data: https:; font-src 'self' data: https:; connect-src 'self' https:;"
</ifmodule>JAK SPRAWDZIĆ CZY WDROŻONO: Wejdź na securityheaders.com i wpisz adres swojej domeny. Prawidłowo skonfigurowana witryna powinna uzyskać ocenę A lub A+.
Podsumowanie: Protokół T.A.R.C.Z.A.
Jeśli choć jeden z powyższych punktów diagnostycznych wykazał nieprawidłowości, Twój WordPress nie jest w pełni utwardzony. Aby ułatwić zarządzanie bezpieczeństwem, wszystkie te działania spinam w autorski protokół T.A.R.C.Z.A., który definiuje odporność nowoczesnej witryny.
Ten mnemonik pomoże Ci pamiętać o kluczowych czynnościach pomagających zabezpieczyć Twoją witrynę WordPress – stronę, portal lub sklep:
- T – Transfer i blokada plików wrażliwych: Izolacja pliku wp-config.php poza zasięg publiczny oraz wdrożenie dodatkowego rygla w pliku .htaccess.
- A – Apache Headers: Wdrożenie nagłówków HTTP chroniących przeglądarki użytkowników.
- R – Restrykcje XML-RPC: Wyeliminowanie przestarzałych protokołów podatnych na ataki DDoS.
- C – Chmod Control: Restrykcyjna polityka uprawnień do plików i katalogów na serwerze.
- Z – Zakaz edycji w kokpicie: Uniemożliwienie potajemnej modyfikacji kodu z poziomu panelu.
- A – Absolutna blokada PHP: Blokada właściwości folderu /uploads/ stanowiących krytyczny wektor infekcji.
Bonus – Krok poza protokołem: Unikalny prefiks bazy danych
Zautomatyzowane skrypty atakujące w pierwszej kolejności szukają domyślnego prefiksu tabel (wp_). Jego zmiana na unikalny ciąg znaków (np. tarcza_) skutecznie je myli i utrudnia ataki typu SQL Injection.
- Zabieg: Zmiana wartości $table_prefix w pliku wp-config.php oraz jednoczesna zmiana nazw wszystkich tabel w bazie danych SQL.
- Uwaga: Jest to operacja wysokiego ryzyka. Wymaga wykonania pełnej kopii zapasowej przed wdrożeniem.
JAK SPRAWDZIĆ CZY WDROŻONO: Otwórz plik wp-config.php. Jeśli w linii $table_prefix widnieje standardowe 'wp_’ – Twoja baza danych używa powszechnie znanych nazw tabel.
Żaden z opisanych zabiegów nie wymaga specjalistycznych narzędzi, a ich wdrożenie to fundament stabilnego funkcjonowania witryny. Jeśli wolisz mieć pewność, że system Twojej strony został utwardzony zgodnie z najwyższymi standardami inżynierskimi – chętnie przeprowadzę audyt i wdrożę protokół za Ciebie w ramach stałej opieki technicznej.
Twoja strona sprawia kłopoty?
Jeśli wolisz, żeby ktoś się tym zajął zamiast Ciebie – opisz swój projekt albo po prostu napisz. Odpowiadam konkretnie i bez zobowiązań.