utwardzanie pliku wp-config.php

Utwardzanie pliku wp-config.php (wp-config hardening) to zestaw ustawień i ograniczeń, które chronią główny plik konfiguracyjny WordPressa i przy okazji zawężają to, co może zrobić intruz po wejściu do panelu. Plik leży w katalogu głównym instalacji i przechowuje dane połączenia z bazą, klucze uwierzytelniania i ich sole oraz prefiks tabel ^[3]. Utwardzanie obejmuje trzy obszary: kto może plik odczytać, jakie sekrety w nim są i jakie funkcje panelu plik wyłącza. Jest szczególnym przypadkiem ogólnej praktyki, którą CERT Polska opisuje jako utwardzenie konfiguracji przez wyłączenie niewykorzystywanych funkcji ^[6]; zob. utwardzanie.

Co zawiera plik i dlaczego jest cenny

W wp-config.php zapisane są nazwa bazy, użytkownik, hasło i host bazy danych, a także stałe AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY i odpowiadające im sole ^[3]. Zmienna $table_prefix określa prefiks tabel, domyślnie wp_ ^[3]. Kto przeczyta plik, zna więc dane uwierzytelniające do bazy i sekrety, którymi WordPress podpisuje ciasteczka logowania.

Skalę problemu pokazał wpis Niebezpiecznika z 18 sierpnia 2015 roku. Wyszukiwanie w serwisie GitHub plików o nazwie wp-config.php zawierających DB_PASSWORD zwróciło 71 227 wyników ^[4]. Część z nich mogła być przykładowymi plikami, ale autorzy radzili blokować dostęp do serwerów baz danych z interfejsów publicznych i używać unikalnych haseł ^[4]. To przykład hasła zaszytego w kodzie, które wyciekło razem z repozytorium.

Składniki utwardzania

Poszczególne kroki i ich źródła zestawia tabela poniżej.

Uprawnienia. Dokumentacja zaleca, aby plik mógł czytać tylko właściciel konta i serwer WWW, co zwykle oznacza uprawnienia 400 albo 440 ^[1].

Blokada dostępu z sieci. Na serwerze Apache wystarczy reguła w pliku .htaccess ^[1]; zob. zabezpieczenia w .htaccess.

<Files "wp-config.php">
Require all denied
</Files>

Przeniesienie pliku. WordPress odczyta wp-config.php także z katalogu o jeden poziom wyżej niż instalacja ^[1]. Podręcznik zastrzega jednak, że korzyść jest według części osób niewielka, a nieostrożne przeniesienie może wprowadzić poważne podatności ^[1].

Klucze i sole. Według dokumentacji tajny klucz utrudnia udany atak, dodając do hasła losowe elementy; wartości mają być długie i losowe, najlepiej z generatora api.wordpress.org/secret-key/1.1/salt/ ^[2]. Zmiana kluczy unieważnia wszystkie istniejące ciasteczka, więc każdy użytkownik musi zalogować się ponownie ^[2]. Szczegóły opisuje hasło klucze bezpieczeństwa i sole.

Wyłączenie edytora. Stała DISALLOW_FILE_EDIT odpowiada odebraniu wszystkim użytkownikom uprawnień edit_themes, edit_plugins i edit_files ^[1]. Sekurak podaje ją jako jeden z kroków zabezpieczenia WordPressa ^[5]. Mocniejsza DISALLOW_FILE_MODS blokuje też instalowanie i aktualizowanie wtyczek i motywów z panelu i sama wyłącza edytor ^{[2] [3]}.

W WordPressie

Typowy przebieg utwardzania na świeżej instalacji pokazuje schemat poniżej.

RYS. 1Utwardzanie wp-config.php krok po kroku

Minimalny fragment pliku po utwardzeniu wygląda tak. Wartości kluczy są tu skrócone.

define( 'AUTH_KEY',           'długi-losowy-ciąg-z-generatora' );
define( 'DISALLOW_FILE_EDIT', true );
define( 'WP_DEBUG',           false );
define( 'FORCE_SSL_ADMIN',    true );

Stała FORCE_SSL_ADMIN wymusza bezpieczne połączenie przy logowaniu i w panelu ^[3]. WP_DEBUG steruje raportowaniem błędów, a WP_DEBUG_DISPLAY decyduje, czy błędy trafiają na ekran, czy do logu ^[3]; błędy wypisywane na ekran to tryb debugowania na produkcji, osobne hasło słownika. Edytor plików motywów i wtyczek jest osobnym hasłem, bo to on zmienia przejęte konto administratora w zdalne wykonanie kodu (RCE).

Dokumentacja dodaje uwagę o bazie: do codziennej pracy WordPress potrzebuje uprawnień SELECT, INSERT, UPDATE i DELETE, ale odbieranie pozostałych nie jest zalecane, bo aktualizacje zmieniają schemat bazy ^[1]. Zmianę domyślnego prefiksu wp_ podręcznik opisuje jako sposób na zablokowanie przynajmniej części ataków SQL injection ^[1]; w nazwie prefiksu dozwolone są tylko cyfry, litery i podkreślenia ^[2].

Zagrożenia i skutki

Odczytany wp-config.php daje atakującemu hasło do bazy. Jeśli baza przyjmuje połączenia z zewnątrz, może on zmienić hasła użytkowników albo dopisać nieautoryzowane konto administratora. Klucze i sole pozwalają z kolei podrabiać ciasteczka logowania, co prowadzi do przejęcia sesji bez znajomości hasła.

Plik najczęściej wycieka nie przez sam serwer, lecz przez kopie: repozytorium kodu, jak w opisanym przypadku z GitHuba ^[4], archiwa i pliki zapasowe w katalogu WWW. Takie publicznie dostępne pliki wrażliwe są pobierane przez automaty. Drugą drogą jest path traversal albo LFI (Local File Inclusion) we wtyczce, które pozwalają odczytać dowolny plik serwera, w tym konfigurację.

Wyłączenie edytora nie zatrzyma kogoś, kto ma już konto administratora, ale odbiera mu najprostszą drogę do wgrania kodu PHP. Dokumentacja opisuje to jako dodatkową warstwę na wypadek przejęcia konta z wysokimi uprawnieniami ^[2].

Dobre praktyki

• Hasło do bazy traktować jak każdy sekret: unikalne, długie, zmieniane po incydencie; zob. zarządzanie sekretami.
• Po każdym włamaniu wygenerować nowe klucze i sole, co wyloguje wszystkie sesje ^[2].
• Nie trzymać wp-config.php w repozytorium kodu ani w publicznym archiwum ^[4].
• Łączyć utwardzanie pliku z zasadą najmniejszych uprawnień dla kont w panelu i na serwerze.
• Pliki na serwer przesyłać przez SFTP, co podręcznik WordPressa zaleca, jeśli hosting na to pozwala ^[1].