Dodatkowe zabezpieczenie WordPressa: uprawnienia, wp-config i .htaccess

Aktualizacje, silne hasło i weryfikacja dwuetapowa to podstawa bezpiecznej witryny WordPress. Wzmacnianie zabezpieczeń (hardening) idzie o krok dalej: konfigurują Państwo witrynę tak, aby luka lub przejęte konto mogły wyrządzić mniej szkód. Poniżej opisujemy, o jakie ustawienia chodzi i jak wprowadzić je na Państwa pakiecie hostingowym.

Co już dzieje się na serwerze

Część zabezpieczeń jest już skonfigurowana na naszych serwerach. Dostęp do xmlrpc.php jest domyślnie zablokowany (WordPress: brak dostępu do xmlrpc.php), niebezpieczne funkcje PHP są wyłączone (Zabezpieczenia PHP: wyłączone funkcje), a dodatkowo działają zapora dla ruchu sieciowego oraz skaner złośliwego oprogramowania. Więcej informacji: Web Application Firewall oraz Imunify360: skanowanie witryny w poszukiwaniu złośliwego oprogramowania. Poniższe kroki wykonują Państwo samodzielnie, we własnej witrynie.

Wszystkie pliki można edytować w DirectAdmin za pomocą Menedżera plików (File Manager). Pliki zaczynające się od kropki, takie jak .htaccess, są widoczne dopiero po włączeniu wyświetlania plików ukrytych: zobacz Wyświetlanie i edycja plików ukrytych, takich jak .htaccess. Przed zmianą każdego pliku prosimy najpierw wykonać jego kopię i umieścić ją poza katalogiem public_html.

1. Brak edycji kodu z poziomu panelu administracyjnego

Prosimy otworzyć plik wp-config.php w katalogu domains/example.com/public_html i dodać poniższy wiersz nad wierszem z komunikatem o zakończeniu edycji (That's all, stop editing!):

define( 'DISALLOW_FILE_EDIT', true );

Edytory plików motywów i wtyczek znikną wtedy z panelu administracyjnego. Osoba, która przejmie konto administratora, nie będzie mogła kilkoma kliknięciami umieścić złośliwego kodu w Państwa motywie. Instalowanie i aktualizowanie wtyczek nadal działa normalnie. W tym samym pliku prosimy ustawić WP_DEBUG na false, aby komunikaty o błędach nigdy nie wyświetlały się odwiedzającym.

2. Brak PHP w katalogu uploads

W katalogu wp-content/uploads powinny znajdować się obrazy i dokumenty, a nie pliki PHP. Włamywacz, który dzięki luce może przesłać plik, próbuje właśnie tam umieścić plik PHP i go wywołać. Prosimy utworzyć w katalogu wp-content/uploads plik .htaccess o następującej treści:

<Files *.php>
Require all denied
</Files>

Następnie prosimy sprawdzić, czy witryna, formularze i biblioteka mediów nadal działają.

3. Brak listy katalogów

Jeśli w katalogu nie ma pliku index.php ani index.html, serwer WWW może wyświetlić listę wszystkich plików. Prosimy dodać na początku pliku .htaccess w katalogu public_html:

Options -Indexes

Aby to sprawdzić, prosimy otworzyć katalog bez pliku indeksu, na przykład https://example.com/wp-content/uploads/. Powinna pojawić się strona błędu (403 lub 404), a nie lista plików.

4. Uprawnienia plików i katalogów

Prosimy nigdy nie używać 777: wtedy każdy na serwerze może zapisywać w tym katalogu. Jeśli instrukcja twierdzi, że jest to konieczne do działania przesyłania plików, przyczyna problemu leży gdzie indziej. Zmiana uprawnień: zobacz Uprawnienia plików i katalogów (chmod).

5. Brak pozostałości w katalogu WWW

Wszystko, co znajduje się w public_html, można pobrać przez internet. Dlatego prosimy usunąć:

• kopie pliku wp-config.php, takie jak wp-config.php.bak lub wp-config.old. Zawierają one hasło do bazy danych i są wysyłane jako zwykły tekst;
• kopie zapasowe, takie jak backup.zip lub database.sql;
• katalog .git pozostawiony przez programistę;
• wp-content/debug.log;
• pliki testowe, takie jak info.php z phpinfo().

Aby zablokować dostęp do pojedynczego pliku, zobacz Blokowanie plików za pomocą .htaccess.

6. Nagłówki i logowanie

• Nagłówki bezpieczeństwa informują przeglądarkę, jak ma obsługiwać Państwa witrynę. Zobacz HSTS i nagłówki bezpieczeństwa dla witryny.
• Dostęp do strony logowania można ograniczyć do własnego adresu IP: zobacz Zabezpieczanie pliku wp-login.php w WordPress.
• Weryfikacja dwuetapowa dla administratorów: zobacz Konfiguracja weryfikacji dwuetapowej w WordPress.

Ukrywanie wersji WordPress to porządkowanie, a nie zabezpieczenie: programy atakujące po prostu próbują wykorzystać lukę. Tylko aktualizacja ją usuwa.

A wtyczka bezpieczeństwa?

Wtyczka bezpieczeństwa często łączy zaporę, skaner i ochronę logowania. Zapora we wtyczce działa dopiero wtedy, gdy WordPress jest już uruchomiony; zapora na serwerze zatrzymuje żądania wcześniej. Wtyczka jest więc uzupełnieniem, przede wszystkim w zakresie weryfikacji dwuetapowej i ograniczania prób logowania. Prosimy używać najwyżej jednej: dwie wtyczki bezpieczeństwa działające jednocześnie często wchodzą ze sobą w konflikt.

Dalsza lektura

• Hardening WordPress (developer.wordpress.org, w języku angielskim)

Chcą Państwo dowiedzieć się więcej? Zapraszamy na bezpłatny kurs WordPress, lekcja 7.4 Wzmacnianie zabezpieczeń witryny: uprawnienia, nagłówki i wtyczki bezpieczeństwa.