Hardening WordPress w pliku .htaccess – dodatkowe zamki dla strony

Dobrze ustawiony plik .htaccess działa jak dodatkowe zamki w drzwiach: zatrzymuje wiele typowych prób włamania, zanim w ogóle dotrą do Twojej strony. Wyjaśniamy, o co chodzi, i pokazujemy przykładowe reguły, które stosujemy przy zabezpieczaniu stron.

W MAQ Enterprise hardening opieramy m.in. na regułach w pliku .htaccess, dopasowanych do konkretnej strony i serwera. Poniżej kilka przykładów wraz z wyjaśnieniem „po ludzku”. Traktuj je jako ilustrację, a nie gotowy zestaw do wklejenia na każdą stronę. Dla osób nietechnicznych: ten kod wprowadza zwykle osoba zajmująca się stroną, a Ty możesz po prostu wiedzieć, co robi.

1. Wymuszenie HTTPS

Po ludzku: każdy, kto wpisze adres bez szyfrowania, zostanie automatycznie przeniesiony na bezpieczną wersję strony (tę z „kłódką”). Najpierw trzeba poprawnie zainstalować certyfikat SSL.

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteCond %{HTTP:X-Forwarded-Proto} !https
  RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

2. Wyłączenie podglądu zawartości katalogów

Po ludzku: gdy ktoś wejdzie do folderu na serwerze, w którym nie ma strony startowej, nie zobaczy listy wszystkich plików.

Options -Indexes

3. Ochrona plików z ustawieniami

Po ludzku: plik wp-config.php zawiera dane dostępowe do bazy danych strony. To jak sejf z kluczami, więc nie może być dostępny z przeglądarki. Tak samo zabezpieczamy pliki, które zdradzają, z jakiej wersji programu korzysta strona.

<Files wp-config.php>
  Require all denied
</Files>
<FilesMatch "^(\.htaccess|\.htpasswd|readme\.html|license\.txt)$">
  Require all denied
</FilesMatch>

4. Blokada skryptów w katalogu ze zdjęciami

Po ludzku: w folderze wp-content/uploads mają leżeć zdjęcia i dokumenty, a nie programy. Gdyby włamywacz wgrał tam złośliwy plik, ta reguła nie pozwoli go uruchomić. Wstawia się ją do osobnego pliku wp-content/uploads/.htaccess.

<FilesMatch "\.(php|phtml|php[0-9]|phar)$">
  Require all denied
</FilesMatch>

5. Blokada plików, które nie powinny być publiczne

Po ludzku: kopie zapasowe, zrzuty bazy, logi i pliki tymczasowe pozostawione na serwerze to częsta przyczyna wycieków. Ta reguła chowa je przed wścibskimi oczami.

<FilesMatch "\.(bak|old|orig|sql|log|swp|sh)$">
  Require all denied
</FilesMatch>

6. Nagłówki bezpieczeństwa

Po ludzku: to krótkie polecenia dla przeglądarki odwiedzającego, które zmniejszają ryzyko niektórych ataków, np. podszycia się pod Twoją stronę w obcym oknie albo wykorzystania kamery czy lokalizacji. Wymagają włączonego modułu mod_headers.

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
</IfModule>

Istnieją też mocniejsze nagłówki (Strict-Transport-Security i Content-Security-Policy), ale ich błędne ustawienie potrafi „zepsuć” stronę lub zablokować do niej dostęp, więc wdrażamy je ostrożnie i po testach.

7. Ograniczenie dostępu do xmlrpc.php i logowania

Po ludzku: plik xmlrpc.php to stara „boczna furtka” WordPressa, którą często atakują roboty. Jeśli nie korzystasz z aplikacji mobilnej WordPress ani innych usług, które jej wymagają, można ją zamknąć:

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

Jeśli do panelu loguje się tylko kilka osób ze stałych adresów internetowych (IP), można też ograniczyć dostęp do strony logowania. Poniżej adres przykładowy, wstaw własny:

<Files wp-login.php>
  Require ip 203.0.113.10
</Files>

Uwaga: jeśli Twój adres IP się zmienia, możesz zablokować dostęp samemu sobie. Zawsze miej plan awaryjny, np. dostęp do plików przez bezpieczne połączenie SFTP.

8. Ukrycie nazw użytkowników

Po ludzku: wpisanie w przeglądarce adresu w stylu /?author=1 ujawnia nazwę użytkownika autora. Znając ją, włamywacz musi zgadnąć już tylko hasło. Poniższa reguła blokuje takie próby, nie przeszkadzając w pracy w panelu.

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{REQUEST_URI} !^/wp-admin/ [NC]
  RewriteCond %{QUERY_STRING} (^|&)author=\d+ [NC]
  RewriteRule ^ - [F,L]
</IfModule>

Ważne zastrzeżenia

• Reguły dla Apache 2.4 (Require ...) nie zadziałają na serwerze Nginx. Tam konfiguracja wygląda inaczej i leży po stronie serwera.
• Niektóre hostingi mają własne zasady lub już stosują część tych zabezpieczeń. Zawsze sprawdzamy to przed wdrożeniem.
• Reguły mogą kolidować z wtyczkami (np. od przyspieszania strony, bezpieczeństwa czy SEO). Po wdrożeniu testujemy logowanie, formularze, mapę strony i pliki statyczne.
• Hardening to tylko jedna warstwa. Nie zastępuje aktualizacji, silnych haseł, dodatkowego potwierdzenia logowania, kopii zapasowych i monitoringu.
• Nie istnieje konfiguracja, która daje pewność, że do włamania nie dojdzie. Celem jest zmniejszenie ryzyka i utrudnienie ataku.

Chcesz, żebyśmy przejrzeli konfigurację Twojej strony i dobrali zabezpieczenia do hostingu oraz wtyczek? Zobacz usługę zabezpieczania stron WWW lub napisz do nas.

O autorze artykułu

Autor artykułu Paweł Makulski Od 2012 roku zajmuje się bezpieczeństwem stron WordPress i SEO. Posiada certyfikat bezpieczeństwa Google. Na co dzień pomaga firmom tak prowadzić strony internetowe, by były szybkie, bezpieczne i dobrze widoczne w wyszukiwarkach, a trudne zagadnienia techniczne tłumaczy zwykłym językiem.