Zabezpieczenie wp-config.php: 10 ustawień do sprawdzenia

W pliku wp-config.php znajdują się hasło do bazy danych, klucze podpisujące każde ciasteczko logowania oraz przełączniki decydujące, czy błędy zobaczą odwiedzający. Większość właścicieli stron nigdy go nie otwierała. Ten poradnik to audyt tego jednego pliku w 10 punktach, czyli praktyczne zabezpieczenie wp-config.php. Przy każdej kontroli podajemy dokładną linijkę, wartość produkcyjną, sposób weryfikacji oraz to, przed czym dane ustawienie nie chroni.

Za co odpowiada wp-config.php i jak go edytować bez białego ekranu

W pliku są trzy rodzaje danych. Po pierwsze, dane dostępowe do bazy. Po drugie, osiem kluczy i soli bezpieczeństwa. Po trzecie, stałe zmieniające zachowanie WordPressa. Kto może odczytać ten plik, może zalogować się do Państwa bazy danych. Kto może go zapisać, może uruchamiać kod przy każdym wczytaniu strony.

To także najłatwiejszy plik do uszkodzenia. Jeden brakujący średnik oznacza biały ekran lub błąd krytyczny dla każdego odwiedzającego. Za każdym razem warto trzymać się tej procedury:

1. Pobierz na swój komputer kopię aktualnego pliku.
2. Edytuj przez SFTP lub SSH, a nie w przeglądarkowym menedżerze plików ani we wtyczce.
3. Jeśli masz dostęp do powłoki, uruchom php -l wp-config.php. Powinien pojawić się komunikat „No syntax errors detected”.
4. Odśwież stronę główną i /wp-admin/ w oknie prywatnym.
5. Jeśli coś przestanie działać, wgraj kopię ponownie. Dopiero potem spokojnie popraw zmianę.
6. Jeśli wszystko działa, usuń z serwera tymczasowe kopie (na przykład wp-config.php.bak). Kopię na własnym komputerze zachowaj.

Ważne jest miejsce wpisu. Pod koniec pliku znajduje się komentarz /* That's all, stop editing! Happy publishing. */, a po nim require_once ABSPATH . 'wp-settings.php';. Stałe zdefiniowane za tą linijką są dla większości ustawień zdefiniowane za późno. Każde nowe define() umieszczaj nad komentarzem. Oficjalny opis znajdą Państwo na stronie wp-config.php w dokumentacji dla deweloperów WordPressa.

Sekrety: dane dostępowe do bazy oraz unikalne klucze i sole

Kontrola 1: dane dostępowe do bazy. DB_USER powinien być użytkownikiem bazy utworzonym wyłącznie dla tej jednej witryny, z długim, losowym hasłem. Jeśli trzy witryny współdzielą jednego użytkownika bazy, wyciek z jednej naraża wszystkie trzy. Nie używaj tu nigdy hasła do panelu hostingu. Ta kontrola nie pomoże, jeśli atakujący już wykonuje kod na serwerze, bo i tak odczyta plik.

Kontrola 2: klucze i sole. Jest ich osiem: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY oraz cztery odpowiadające im stałe _SALT. Muszą być długie, losowe i unikalne dla tej witryny. Jeśli którakolwiek z nich nadal brzmi put your unique phrase here, popraw to jeszcze dziś. Nowy zestaw wygenerują Państwo pod adresem api.wordpress.org/secret-key/1.1/salt/ i wkleją w miejsce starego bloku. W WP-CLI wystarczy jedno polecenie:

wp config shuffle-salts

Sole warto zmienić po włamaniu, po odejściu administratora lub agencji mającej dostęp do plików, a także wtedy, gdy plik kiedykolwiek był publicznie dostępny.

Po włamaniu wymiana tych sekretów to tylko jeden z kroków większego sprzątania. Pełną kolejność opisuje artykuł usuwanie malware z WordPressa.

Ustawienia debugowania na produkcji: WP_DEBUG, WP_DEBUG_DISPLAY i WP_DEBUG_LOG

Kontrola 3: WP_DEBUG. Na działającej stronie powinno być false. Wyświetlane błędy ujawniają ścieżki na serwerze, nazwy wtyczek, a czasem fragmenty zapytań. Atakujący może na tej podstawie wybrać cel.

define( 'WP_DEBUG', false );

WP_DEBUG ustawione na false nie wyłącza własnej dyrektywy PHP display_errors. Jeśli hosting ma ją włączoną, ostrzeżenia nadal mogą pojawiać się na stronie. Zapytajcie dostawcę hostingu albo sprawdźcie konfigurację PHP, jeśli prowadzicie własny serwer.

Kontrola 4: jeśli potrzebne są logi, ukryj je i przenieś. Czasem trzeba debugować produkcję. Wtedy nigdy nie wyświetlaj błędów na stronie i nie zostawiaj domyślnej lokalizacji logu. WP_DEBUG_LOG ustawione na true zapisuje do wp-content/debug.log, a ten plik bywa publicznie do pobrania. Podaj zamiast tego ścieżkę poza katalogiem głównym serwisu WWW:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/home/example/logs/wp-debug.log' );
@ini_set( 'display_errors', '0' );

Katalog musi istnieć i być zapisywalny dla użytkownika PHP. Następnie upewnij się, że żaden stary log nie jest nadal publiczny:

curl -I https://example.com/wp-content/debug.log

Oczekiwana odpowiedź to 403 lub 404. Kod 200 oznacza, że każdy może odczytać log. Usuń go.

Logi często zawierają adresy e-mail, adresy IP i dane z formularzy, czyli dane osobowe. Po zakończeniu pracy wyłącz logowanie, a stare pliki logów usuń lub rotuj. Opis każdej stałej znajdą Państwo w dokumentacji debugowania WordPressa.

HTTPS i środowisko: FORCE_SSL_ADMIN oraz WP_ENVIRONMENT_TYPE

Kontrola 5: FORCE_SSL_ADMIN. To ustawienie utrzymuje stronę logowania, panel i ciasteczka administratora na HTTPS:

define( 'FORCE_SSL_ADMIN', true );

Obejmuje wyłącznie panel administracyjny i logowanie. Nie zastępuje przekierowania z HTTP na HTTPS dla całej witryny po stronie serwera i nie jest nagłówkiem HSTS.

Kontrola 6: WP_ENVIRONMENT_TYPE. To ustawienie informuje WordPressa i wtyczki, w jakim środowisku działają. Dozwolone wartości to production, staging, development i local. Domyślna jest production.

define( 'WP_ENVIRONMENT_TYPE', 'production' );

Ma ono realne skutki. W rdzeniu środowisko development włącza WP_DEBUG, jeśli nie zdefiniowano go samodzielnie. Niektóre wtyczki i hostingi odczytują tę wartość, by wstrzymywać wysyłkę poczty albo zmieniać cache na stronach nieprodukcyjnych. Ważniejsze jest jednak oznaczanie. Kopia stagingowa zwykle zawiera pełne dane prawdziwych klientów i zamówień. Oznacz ją jako staging i zabezpiecz uwierzytelnianiem HTTP lub ograniczeniem adresów IP. Gdy projekt się kończy, usuń ją. Zapomniana subdomena stagingowa z ubiegłorocznym stanem bazy klientów to częste źródło wycieków.

Edytor plików i modyfikacje plików: DISALLOW_FILE_EDIT oraz DISALLOW_FILE_MODS

Kontrola 7: Dodaj tę linijkę na każdej witrynie:

define( 'DISALLOW_FILE_EDIT', true );

Usuwa ona z panelu edytory plików motywów i wtyczek. Skradzionego loginu administratora nie da się wtedy kilkoma kliknięciami zamienić w uruchomiony kod. Nie powstrzyma to jednak atakującego, który może wgrać wtyczkę.

Kontrola 8: DISALLOW_FILE_MODS idzie dalej. Blokuje też instalowanie i aktualizowanie wtyczek oraz motywów z poziomu panelu i wyłącza automatyczne aktualizacje w tle. Włączaj je dopiero wtedy, gdy masz inną ścieżkę aktualizacji, na przykład WP-CLI, pipeline wdrożeniowy lub aktualizacje prowadzone przez hosting. W przeciwnym razie zamrażasz witrynę na dzisiejszych, podatnych wersjach. Oba ustawienia i proces aktualizacji opisuje artykuł DISALLOW_FILE_EDIT: wyłączanie edytora plików w WordPressie.

Uprawnienia plików, lokalizacja i zbędne kopie wp-config.php

Kontrola 9: uprawnienia. Właściwa wartość zależy od tego, jako jaki użytkownik działa PHP:

• 400 lub 440: gdy właścicielem pliku jest inny użytkownik niż ten, na którym działa PHP. Grupa musi obejmować użytkownika PHP, który potrzebuje wtedy tylko prawa odczytu.
• 600: gdy PHP działa jako właściciel pliku, co jest częste przy osobnych pulach PHP-FPM dla każdego konta.

Unikaj 644 na hostingu współdzielonym, bo inne konta na tym samym serwerze mogą odczytać plik. Nigdy nie używaj 777.

ls -l wp-config.php
chmod 440 wp-config.php

O właścicielach i uprawnieniach w pozostałej części instalacji piszemy w artykule web shelle i uprawnienia plików.

Przeniesienie pliku o jeden katalog powyżej katalogu głównego serwisu jest dozwolone. WordPress szuka go tam automatycznie, jeśli katalog nadrzędny nie zawiera osobnej instalacji WordPressa. Korzyść jest niewielka. Ma znaczenie tylko wtedy, gdy PHP przestanie się wykonywać, a serwer zacznie wydawać pliki .php jako zwykły tekst. Jeśli to łatwe, zrób to, ale nie traktuj tego jako zabezpieczenia.

Kontrola 10: zbędne kopie. To większe i częstsze ryzyko. Pliki takie jak wp-config.php.bak, wp-config.php.old, wp-config.php.save, wp-config.php~ czy plik wymiany edytora, np. .wp-config.php.swp, nie kończą się na .php. Serwer WWW może je wydać jako zwykły tekst, razem z hasłem do bazy. Wyszukaj je:

find /var/www/example -name '*wp-config*' -type f

Powinny zostać tylko wp-config.php oraz nieszkodliwy wp-config-sample.php. Resztę usuń. Zmiana nazwy nic nie daje. Jeśli kopia była dostępna przez internet, zmień także hasło do bazy i sole.

Kontrola wp-config.php w 10 punktach: tabela

Czysty wynik tych kontroli nic nie mówi o podatnych wtyczkach, słabych hasłach administratorów ani przestarzałej wersji PHP. Do tego posłuży lista kontrolna bezpieczeństwa WordPressa.

Wtyczka Security Audit & Compliance z secaudit.eu zawiera skan utwardzenia i konfiguracji oraz sprawdza, czy nie są ujawnione sekrety i pliki, na przykład pozostawione kopie zapasowe. Ma też opcjonalny przełącznik wyłączający edytory plików w panelu → secaudit.eu

Następny krok: pobierz teraz kopię wp-config.php i uruchom polecenie find, szukając zbędnych kopii. Zajmie to dwie minuty, a obejmuje ekspozycję, którą najczęściej się pomija.

FAQ

Czy zmiana soli zepsuje moją stronę?

Nie. Treści, ustawienia i hasła pozostają bez zmian. Każdy zalogowany użytkownik zostaje wylogowany i musi zalogować się ponownie, dlatego wcześniej uprzedź redaktorów i klientów sklepu.

Czy na istniejącej stronie warto zmieniać prefiks tabel?

Zwykle nie. Własny prefiks daje niewiele realnej ochrony, a zmiana go na działającej stronie oznacza zmianę nazw tabel i aktualizację wpisów w tabelach options i usermeta. Pomyłka może zablokować dostęp wszystkim użytkownikom. Zostaw go, chyba że i tak odbudowujesz witrynę.

Czy wtyczka może zarządzać wp-config.php za mnie?

Niektóre mogą. Jednak wtyczka z prawem zapisu do wp-config.php sama jest ryzykiem, bo jej podatność zamienia się w dostęp do zapisu najwrażliwszego pliku. Lepsza jest ręczna edycja przez SFTP lub SSH i przechowywanie kopii ostatniej działającej wersji.