Hardening WordPress: wp-config, uprawnienia plikow i blokada edycji w panelu

Wiekszos wlascicieli stron WordPress mysli o bezpieczenstwie przez pryzmat wtyczek: instalojesz Wordfence, klikasz "Scan" i czujesz sie chroniony. Problem w tym, ze wtyczka bezpieczenstwa to ostatnia linia obrony, nie pierwsza. Jesli wp-config.php jest czytelny dla kazdego procesu na serwerze, jesli edytor plikow jest wlaczony w panelu admina, a XML-RPC odpowiada na kazde pingniecie z internetu - zadna wtyczka tego w pelni nie naprawi.

Hardening WordPress na poziomie konfiguracji to praca, ktora robie przed uruchomieniem kazdego projektu. Zajmuje okolo 30 minut, nie wymaga zadnych platnych narzedzi i zamyka kilka wektorow ataku, ktore hakerzy skanuja masowo. Ponizej opisuje dokladnie co robic i dlaczego.

Dlaczego wp-config.php to najwazniejszy plik w instalacji

Plik wp-config.php zawiera dane dostepowe do bazy danych, klucze soli, prefiks tabel i szereg stalych konfiguracyjnych. Jesli atakujacy go odczyta - ma login, haslo i host bazy danych. To nie jest hipoteza: boty systematycznie probuja odczytac ten plik przez rozne techniki (path traversal, lokalne wlaczenia plikow, blednie skonfigurowane reguly serwera).

Domyslnie WordPress tworzy wp-config.php z uprawnieniami 644, co oznacza odczyt dla wszystkich uzytkownikow systemu. Na hostingu wspoldzielonym, gdzie wielu klientow dziela ten sam serwer, to realne ryzyko. Poprawne ustawienie to 400 (tylko wlasciciel moze czytac, nikt nie moze zapisywac) lub 440 gdy PHP FPM dziala na osobnym uzytkowniku i potrzebuje dostepu.

Zmiana uprawnien przez FTP (FileZilla, prawy klik na pliku, "Permissions of file") lub przez SSH:

chmod 400 wp-config.php

Zanim zmienisz, sprawdz na swoim hostingu jak dziala PHP - na niektorych konfiguracjach shared hosting 400 moze powodowac blad 500. W takim przypadku uzyj 440.

Uprawnienia plikow i katalogow - schemat, ktory dziala

WordPress ma prosta regule, ktora czesto jest lamania na instalacjach "w pospichu": katalogi potrzebuja prawa do wykonywania (traverse), pliki nie. Dlatego:

• Katalogi: 755 (wlasciciel czyta/pisze/wykonuje, grupa i swiat czytaja i wykonuja)
• Pliki: 644 (wlasciciel czyta/pisze, reszta tylko czyta)
• wp-config.php: 400 lub 440
• .htaccess: 644, a po zakonczeniu konfiguracji mozna ustawic 444 (tylko odczyt dla wszystkich) - WordPress moze go nie zapisac automatycznie, ale to akceptowalny kompromis

Najczestszy blad, ktory widze po audytach: uprawnienia 777 na calym katalogu wp-content/uploads/. To wymaganie niektorych starych wtyczek lub pospiesznie rozwiazany blad "Permission denied". Na hostingu wspoldzielonym 777 pozwala dowolnemu skryptowi na serwerze zapisac plik w Twoim katalogu.

Szybki sposob na zresetowanie uprawnien przez SSH (gdy masz dostep):

find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;
chmod 400 wp-config.php

Bez SSH - panel hosta (cPanel/DirectAdmin/Plesk) lub wtyczka jak iThemes Security robi to jednym kliknieciem.

DISALLOW_FILE_EDIT - pierwsza prawa w wp-config.php

Edytor plikow w panelu WordPress (Wyglad - Edytor lub Wtyczki - Edytor) pozwala zalogowanemu adminowi edytowac kod PHP bezposrednio w przegladarce. Z perspektywy bezpieczenstwa to funkcja, ktora powinna byc domyslnie wylaczona na produkcji.

Dlaczego? Bo jesli atakujacy przejmie konto admina - przez brute-force, przez wyciekniete haslo, przez phishing - ma natychmiastowy dostep do edytora plikow i moze wstrzyknac kod malware bez dostepu do serwera przez FTP czy SSH. Jeden wpis w wp-config.php to likwiduje:

define( 'DISALLOW_FILE_EDIT', true );

Jesli chcesz isc dalej i zablokowanie rowniez instalacji oraz aktualizacji wtyczek i motywow z poziomu panelu (przydatne gdy deployujesz przez git lub pipeline CI/CD i nie chcesz, zeby klient przypadkowo cokolwiek nadpisal):

define( 'DISALLOW_FILE_MODS', true );

Uwaga: DISALLOW_FILE_MODS wylacza takze automatyczne aktualizacje core'u WordPress. Jesli go uzywasz, upewnij sie, ze masz inny mechanizm aktualizacji.

Klucze soli - unikalne i zmieniane po incydencie

Klucze uwierzytelniania (authentication keys and salts) to sekwencje losowych znakow, ktore WordPress uzywa do szyfrowania ciasteczek sesji. Jesli ktos je zna, moze w teorii sfalsyfikowac ciasteczko logowania.

Generojesz nowy zestaw kluczy tutaj: https://api.wordpress.org/secret-key/1.1/salt/ - strona za kazdym razem zwraca inny, losowy zestaw. Skopiuj wynik i wklej w miejsce istniejacych definicji AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY itd. w wp-config.php.

Kiedy zmieniac klucze? Przy nowym projekcie (nie zostawiaj domyslnych), po podejrzanej aktywnosci (podejrzane logowania w logach), po kompromitacji konta admina, po wycieku bazy danych. Zmiana kluczy uniewa-znia wszystkie aktywne sesje - wszyscy zalogowani uzytkownicy musza sie zalogowac ponownie, wlacznie z Toba.

Blokada XML-RPC - kiedy i jak

XML-RPC to stary protokol zdalnego dostepu do WordPress, zaprojektowany jeszcze zanim REST API istnialo. Dzis korzysta z niego glownie Jetpack i oficjalna aplikacja mobilna WordPress. Jesli nie uzywasz zadnego z nich - xmlrpc.php powinien byc zablokowany.

Dlaczego to wazne? Boty automatycznie skanuja xmlrpc.php i uzywaja go do atakow brute-force na hasla. W odroznieniu od strony logowania (/wp-login.php), XML-RPC pozwala na testowanie wielu kombinacji login/haslo w jednym zapytaniu HTTP (przez metode system.multicall). Blokada logowania po N probach na wp-login.php nie chroni przed tym wektorem.

Wg danych z WebOptimo i CyberPanel, ataki przez XML-RPC stanowia znaczaca czesc masowych atakow na instalacje WordPress w 2025 roku. Patchstack raportuje 34% wzrost liczby podatnosci w ekosystemie WP miedzy 2023 a 2024 rokiem.

Blokada przez .htaccess (serwery Apache - np. LH.pl):

<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
</Files>

Alternatywnie przez funkcje w functions.php motywu lub mu-plugin:

add_filter( 'xmlrpc_enabled', '__return_false' );

Metoda PHP wylacza xmlrpc na poziomie aplikacji, ale plik nadal jest dostepny i odpowiada (tyle ze z bledem). Metoda .htaccess / nginx jest skuteczniejsza, bo blokuje na poziomie serwera.

Ukrycie wersji WordPress

WordPress domyslnie ujawnia swoja wersje w kilku miejscach: meta tag <meta name="generator" content="WordPress 6.x.x" /> w head strony, plik readme.html w glownym katalogu, parametr ?ver=6.x.x doklejany do URL-i styli i skryptow, i w kanalach RSS.

Dlaczego to problem? Boty skanuja internet w poszukiwaniu stron z konkretnymi wersjami WordPress, a nastepnie uzywaja gotowych exploitow dopasowanych do tych wersji. Ukrycie wersji nie jest absolutna ochrona (doswiadczony atakujacy znajdzie inne sposoby na identyfikacje), ale skutecznie zmniejsza skutecznosc masowego, automatycznego skanowania.

Co zrobic praktycznie:

1. Usun readme.html z serwera (lub zablokuj przez .htaccess)
2. Dodaj do functions.php motywu (lub mu-pluginu):

remove_action( 'wp_head', 'wp_generator' );
add_filter( 'the_generator', '__return_empty_string' );

3. Parametry ?ver= przy stylach/skryptach mozna usunac przez filtr script_loader_src i style_loader_src, ale to wplywa na debugowanie - zastanow sie czy tego potrzebujesz.

Hardening bez wtyczek a Wordfence - jak to laczyc

Opisy wyzej to tzw. hardening pasywny - zamykasz wektory ataku, ktore istnieja niezaleznie od ruchu na stronie. Ale nie zastepuje to narzedzi aktywnych. W kompleksowym przewodniku po konfiguracji Wordfence pisalem o tym, ze skaner malware i firewall aplikacyjny wchodza do gry juz po tym jak atakujacy dotrze do aplikacji.

Sens ich laczenia: hardening konfiguracyjny sprawia, ze wiele atakow nie dochodzi nawet do warstwy aplikacji. Wordfence lapie to, co mimo to przejdzie. Dodaj do tego WAF na poziomie Cloudflare i masz trzy niezalezne warstwy ochrony.

W praktyce wyglada to tak: mam klienta z WooCommerce, sklep na LH.pl, okolo 300 zamowien miesiecznie. Po wdrozeniu hardeningu (wp-config + uprawnienia + blokada XML-RPC + Cloudflare) liczba zablokowanych prob logowania w logach Wordfence spadla o ponad 70% w ciagu pierwszego miesiaca. Nie dlatego, ze atakow bylo mniej - boty po prostu przestaly dostaczac do aplikacji.

Jesli nie masz czasu na regularne pilnowanie bezpieczenstwa samodzielnie, warto rozwazyc opieke techniczna WordPress, gdzie hardening, aktualizacje i monitorowanie to czesc standardowego pakietu.

Co sprawdzic po hardeningu

Po wprowadzeniu zmian warto potwierdzic, ze wszystko dziala poprawnie:

• Zaloguj sie do panelu WordPress i sprawdz czy menu "Edytor" zniklo z Wyglad i Wtyczki (potwierdza DISALLOW_FILE_EDIT)
• Odwiedz https://twojastrona.pl/xmlrpc.php bezposrednio - powinna pojawic sie odpowiedz 403 Forbidden lub pusta strona, nie XML z metodami
• Sprawdz zrodlo strony (Ctrl+U w Chrome) i poszukaj <meta name="generator" - nie powinno byc
• Usun readme.html i sprawdz przez FTP ze plik nie istnieje (lub zwraca 404)
• Przez FileZilla sprawdz uprawnienia wp-config.php - powinna byc kolumna "400" lub "440"

Pelny audyt bezpieczenstwa, lacznie z weryfikacja naglowkow HTTP, ochrona przed SQL injection i skanowaniem plikow, to juz temat na osobny artykul - mozesz rowniez skorzystac z darmowej konsultacji jesli chcesz, zeby ktos przejrzal konfiguracje Twojego serwera.

Wiecej o tym, co wchodzi w sklad profesjonalnej opieki nad sklepem lub strona WordPress, opisalem w artykule o tym, co obejmuje opieka techniczna WordPress i ile kosztuje.

Najczęstsze pytania

Jakie uprawnienia ustawic dla wp-config.php?

Najbezpieczniejsza opcja to 400 (tylko wlasciciel moze czytac, nikt nie moze zapisywac). Na niektorych serwerach PHP musi miec dostep do pliku, wtedy uzyj 440. Nigdy nie zostawiaj 644 lub 666 - to otwarty zaproszenie dla kazdego skryptu na serwerze.

Czy blokada XML-RPC psuje Jetpacka?

Tak, Jetpack wymaga dostepu do xmlrpc.php. Jesli uzywasz Jetpacka, zablokuj XML-RPC selektywnie - przepusc tylko zadania z serwera Automattic (185.92.220.0/22). Jesli nie uzywasz Jetpacka ani aplikacji mobilnej WP, mozesz blokowac globalnie.

Co sie stanie po zmianie kluczy soli w wp-config.php?

Wszystkie aktywne sesje logowania zostana uniewa-znione - rowniez Twoja. Po zmianie musisz sie zalogowac ponownie. To celowe i pozadane zachowanie, szczegolnie po podejrzanej aktywnosci na stronie lub wycieku bazy.

Czy DISALLOW_FILE_EDIT zabezpiecza przed instalacja nowych wtyczek?

Samo DISALLOW_FILE_EDIT wylacza tylko edytor plikow (PHP/CSS) w panelu. Zeby zablokowac rowniez instalacje i aktualizacje wtyczek z panelu admina, dodaj osobno DISALLOW_FILE_MODS ustawione na true.

Jak sprawdzic aktualne uprawnienia plikow na serwerze?

Przez FTP (np. FileZilla - kolumna Permissions), przez panel hostingu (menadzer plikow), lub przez SSH komenda 'ls -la'. Na hostingu wspoldzielonym SSH nie zawsze jest dostepne, ale panel cPanel/DirectAdmin zawsze pokazuje i pozwala zmieniac uprawnienia.

Czy hardening wp-config zastepuje wtyczke bezpieczenstwa?

Nie zastepuje, ale uzupelnia. Wtyczki jak Wordfence dodaja skaner malware, firewall aplikacyjny i powiadomienia. Hardening konfiguracyjny zamyka podstawowe wektory ataku i dziala nawet gdy wtyczka jest chwilowo wylaczona lub podatna. Oba elementy powinny byc uzywane razem.