Jak zabezpieczyć stronę na WordPress bez użycia wtyczek?

Jak zabezpieczyć stronę na WordPress bez użycia wtyczek?

Zabezpieczenie strony internetowej na WordPressie jest niezbędne dla każdego właściciela witryny. Wielu z nas automatycznie sięga po różnorodne wtyczki bezpieczeństwa, które, choć często faktycznie skuteczne, mogą obciążać stronę i skomplikować jej działanie. Dobra wiadomość jest taka, że wiele zabezpieczeń da się wprowadzić bez użycia wtyczek. Dlatego w niniejszym artykule skupię się na praktycznych i efektywnych metodach zabezpieczania Twojej strony WordPress, które można zastosować bezpośrednio, bez konieczności instalowania dodatkowych rozszerzeń.

1. Zabezpieczenie pliku wp-config.php

Dodaj następujący kod do pliku .htaccess w głównym katalogu WordPressa, najlepiej w pierwszej linijce:

# ZABLOKOWANIE DOSTĘPU DO WP-CONFIG
<files wp-config.php>
order allow,deny
deny from all
</files>

Dodatkowo, aby zwiększyć bezpieczeństwo możesz przenieś plik wp-config.php jeden poziom wyżej niż główny katalog WordPressa.

Dlaczego warto zabezpieczyć w ten sposób wp-config?

Większość serwerów hostingowych i konfiguracji WordPressa jest zabezpieczona tak, aby uniemożliwić bezpośredni dostęp do pliku wp-config.php, przez przeglądarkę. Dyrektywy w .htaccess dla wp-config.php, są dodatkowym środkiem bezpieczeństwa. Służą one jako warstwa ochrony w przypadku, gdyby standardowe zabezpieczenia zawiodły lub były niewłaściwie skonfigurowane.

WordPress nadal będzie miał dostęp do pliku wp-config.php, nawet po zastosowaniu powyższych dyrektyw w pliku .htaccess. Blokują one dostęp do pliku wp-config.php tylko przez przeglądarkę internetową, a nie z poziomu serwera, na którym działa WordPress. Oznacza to, że WordPress, nadal będzie mógł czytać i używać wp-config.php do normalnej pracy, ponieważ jego procesy uzyskują dostęp do plików na serwerze lokalnie, a nie przez HTTP, na który wpływają ustawienia .htaccess.

Przeniesienie wp-config.php poza katalog publicznie dostępny (np. public_html lub www) to kolejne zabezpieczenie. Dzięki niemu, nawet gdyby doszło do błędu konfiguracyjnego serwera lub innych nieprzewidzianych problemów, plik jest mniej narażony na ataki, ponieważ nie może być bezpośrednio dostępny z poziomu przeglądarki internetowej. Na przykład, jeśli twoja struktura katalogów wygląda tak: /home/user/public_html/wp-config.php, możesz przenieść plik do /home/user/wp-config.php.

Jest to bezpieczne i proste do wdrożenia, ponieważ wordPress automatycznie wyszukuje plik wp-config.php w jego standardowej lokalizacji (domyślnie znajduje się on w głównym katalogu Twojej instalacji WordPress. Jest to ten sam katalog, gdzie znajdują się foldery wp-content, wp-includes i wp-admin), a jeśli go tam nie znajdzie, po prostu sprawdza katalog nadrzędny i tam szuka pliku wp-config.

Alternatywnie, jeśli nie chcesz przenosić pliku wp-config wyżej w drzewie katalogów, możesz skopiować plik wp-config.php do innego katalogu. Następnie wystarczy usunąć zawartość oryginalnego pliku wp-config.php i wkleić poniższy kod:

<?php
define('ABSPATH'
, dirname(__FILE__) . '/');
require_once(ABSPATH . 'swpcsec/wp-config.php');
?>

Oczywiście w miejsce swpcsec należy wkleić nazwę katalogu do którego skopiowany został plik wp-config.php oraz upewnić się, że ścieżka jest poprawna.

2. Wyłączenie edycji plików w panelu administratora

Dodaj następującą linię do pliku wp-config.php, najlepiej przed linią, która mówi: /* That's all, stop editing! Happy blogging. */:

define('DISALLOW_FILE_EDIT', true);

Ten kod dezaktywuje możliwość edycji plików wtyczek i motywów z poziomu panelu administratora. Teraz jeśli spróbujesz uzyskać dostęp do edytora plików, przechodząc w panelu WordPressa do Wygląd > Edytor lub Wtyczki > Edytor, opcje edycji plików nie będą już dostępne.

Wyłączenie edycji plików w panelu administratora zapobiega ryzyku, że ktoś z nieautoryzowanym dostępem do panelu administracyjnego może bezpośrednio modyfikować pliki tematów lub wtyczek, co mogłoby prowadzić do poważnych problemów z bezpieczeństwem. Od teraz wszelkie zmiany w wtyczkach lub motywach będą musiały być przeprowadzane przez bezpośrednią edycję plików na serwerze (np. za pomocą FTP) lub poprzez aktualizacje oferowane przez dostawców tych wtyczek i motywów.

3. Dostęp do strony logowania tylko z wybranych adresów IP

Możesz użyć pliku .htaccess do ograniczenia dostępu do wp-login.php tylko do określonych adresów IP. Na Przykład:

<files wp-login.php>
order deny,allow
Deny from all
Allow from XXX.XXX.XXX.XXX
</files>

Oczywiście zastąp XXX.XXX.XXX.XXX Twoim adresem IP. Jeśli nie wiesz jaki jest Twój adress IP możesz go sprawdzić np. na https://whatismyipaddress.com. Jeśli chcesz dodać więcej adresów IP (bo np. logujesz się do panelu administracyjnego Twojej strony z różnych lokalizacji) możesz zmodyfikować powyższy kod w ten sposób:

<files wp-login.php>
order deny,allow
Deny from all
Allow from XXX.XXX.XXX.XXX
Allow from YYY.YYY.YYY.YYY
Allow from ZZZ.ZZZ.ZZZ.ZZZ
</files>

Niestety problemem tego rodzaju zabezpieczeń jest to, że Twoje IP musi być stałe. W przypadku dynamicznych adresów IP, które zmieniają się regularnie (co jest typowe dla wielu dostawców internetu), taka metoda zabezpieczeń będzie niestety niepraktyczna.

Jeśli jednak masz zmienne IP i logujesz się często do panelu administracyjnego Twojej strony i chcesz korzystać z takiego zabezpieczenia, możesz uzyskać dedykowany adres IP poprzez użycie VPN. Alternatywnie możesz również upewnić się czy Twój usługodawca Internetu nie oferuje możliwości uzyskania stałego adresu IP. Czasami jest to możliwe, więc warto dopytać.

4. Dodatkowe okienko uwierzytelniania przed formularzem logowania do panelu WordPressa

Jeśli nie jesteś w stanie uzyskać stałego adresu IP (lub chcesz dodać kolejną warstwę zabezpieczeń) możesz zabezpieczyć wejście do panelu administracyjnego dodatkowym loginem i hasłem, które będzie trzeba wprowadzić przed wyświetleniem formularza logowania WordPressa. Aby zastosować takie dwuetapowe uwierzytelnianie, musisz skorzystać z poniższego kodu, który należy wkleić do pliku .htaccess.

<Files wp-login.php>
AuthName "Dostep zabroniony. Podaj dodatkowy login i hasło."
AuthType Basic
AuthUserFile /home/username/.htpasswd
Require valid-user
</Files>

W praktyce, będzie to działać tak, że każdy, kto próbuje uzyskać dostęp do strony logowania WordPressa, zostanie najpierw poproszony o podanie nazwy użytkownika i hasła zdefiniowanych w pliku .htpasswd. Zanim zobaczymy formularz logowania do WordPressa, wyświetli się więc dodatkowe okienko, w które będziemy musieli każdorazowo wprowadzać dodatkowe hasło, aby móc uzyskać dostęp do panelu logowania do WordPressa. Inaczej zobaczenie panelu logowania nie będzie możliwe.

W takim razie jak to dokładnie działa i co jeszcze musimy zrobić?

Linijka AuthUserFile /home/username/.htpasswd wskazuje na lokalizację pliku .htpasswd (nazwa tego pliku może być inna, ale musi mieć jednak kropkę na początku), który zawierać będzie nazwy użytkowników i zaszyfrowane hasła, których będziemy używali do uwierzytelniania.

Oczywiście musimy plik .htpasswd stworzyć i wgrać na serwer, oraz zaszyfrować w nim nasze dodatkowe hasło. Aby to zrobić możemy skorzystać z dowolnego generatora takich haseł np. https://wtools.io/generate-htpasswd-online. Będzie to wyglądać mniej więcej tak:

.htpasswd generator

Oczywiście należy wprowadzić własną nazwę użytkownika i hasło, kliknąć „generate”, a następnie skopiować wygenerowany rezultat do pliku .htpasswd, który należy zapisać na serwerze w lokalizacji zgodnej z linijką AuthUserFile /home/username/.htpasswd w pliku .htaccess.

Jeśli chcesz upewnić się czy ścieżka do pliku .htpasswd jest prawidłowa, możesz stworzyć plik np. o nazwie getpath.php o poniższej treści i wgrać go do katalogu swojego WordPressa:

<?php echo getcwd(); ?>

Teraz wystarczy, że wpiszesz adres swojej strony internetowej w pasek przeglądarki i dodasz po ukośniku getpath.php np. https://jdportfolio.pl/getfilepath.php.

Wykonanie powyższego kodu z pliku getfilepath.php wyświetli na ekranie ścieżkę do katalogu w którym aktualnie znajduje się twoja instalacja WordPressa np. /home/johndoe/websites/johndoeportfolio. Jeśli umieściłeś plik .htpasswd w katalogu o poziom wyższym, ścieżka do tego pliku będzie następująca: /home/johndoe/websites/.htpasswd

Pamiętaj, aby zabezpieczyć plik .htpasswd, upewniając się, że znajduje się on w miejscu niedostępnym przez przeglądarkę internetową i ma ustawione odpowiednie uprawnienia dostępu.

  • Ważne jest, aby ten plik był umieszczony w miejscu na serwerze, które nie jest dostępne publicznie przez przeglądarkę internetową. Innymi słowy, plik ten nie powinien znajdować się w katalogu, z którego serwowane są pliki strony internetowej. Zazwyczaj plik .htpasswd umieszcza się w katalogu nadrzędnym względem katalogu strony www lub w innym bezpiecznym miejscu, gdzie tylko skrypty serwera i administratorzy mają do niego dostęp.
  • Ustaw odpowiednie uprawnienia dostępu do pliku .htpasswd, aby tylko uprawnieni użytkownicy (np. administrator serwera) mieli do niego dostęp. Na serwerach Unix/Linux często stosuje się uprawnienia takie jak 640 lub bardziej restrykcyjne 600 (zalecane w tym wypadku). Najłatwiej zmienić te uprawnienia łącząc się z serwerem przez klienta FTP np. FileZilla. Wystarczy wtedy kliknąć prawym przyciskiem myszy na plik .htpasswd i wybrać opcję „Prawa pliku”, a następnie wpisać 600 w okienku „wartość numeryczna”.

5. Zmiana domyślnego prefiksu tabel WordPressa

Zmiana domyślnego prefiksu tabel w bazie danych WordPressa z „wp_” na coś bardziej unikalnego to kolejny krok w zabezpieczaniu Twojej strony. Jest to jedna z metod zapobiegania atakom typu SQL Injection, ponieważ utrudnia potencjalnym atakującym odgadnięcie nazw tabel w bazie danych.

Najlepiej zrobić to przed instalacją strony, ponieważ WordPress pyta przy swojej instalacji jakiego prefiksu tabel użyć. Jeśli jednak posiadamy już stronę na WordPressie zrobioną wcześniej, możemy zmienić prefiks tabel edytując bazę danych.

Przede wszystkim przed przystąpieniem do jakichkolwiek zmian w bazie danych zrób jej kopię zapasową, aby w przypadku jakichkolwiek problemów móc przywrócić stan pierwotny. Jeśli masz już ściągnięty backup bazy danych na dysk, możesz przystąpić do kolejnych kroków.

Zaloguj się na swój serwer przy pomocy FTP i zablokuj tymczasowo dostęp do Twojej strony na czas wprowadzania poniższych zmian. W tym celu dodaj do pliku .htaccess następujący kod, oczywiście podmieniając XXX.XXX.XXX.XXX na swoje IP:

# ZABLOKOWANIE DOSTĘPU DO STRONY
<Limit GET POST PUT>
order deny,allow
deny from all
allow from XXX.XXX.XXX.XXX
</Limit>

Dodanie tego kodu spowoduje, że z Twoją stroną będziesz mógł/a łączyć się tylko Ty. Może to być przydatne w sytuacji, gdy chcesz zezwolić na dostęp do strony tylko z określonych lokalizacji (np. tylko z Twojego biura lub domu). Jest to również przydatne, gdy strona jest w trakcie budowy lub konserwacji i chcesz zapobiec dostępowi publicznemu. Czyli dokładnie tak jak teraz.

Następnie w pliku wp-config Twojego wordpressa musisz odnaleźć linijkę:

$table_prefix = 'wp_';

Następnie musisz ją zmienić na nowy prefix np:

$table_prefix = 'wpjd2g_';

Jeśli teraz odwiedzisz stronę pokaże się instalator WordPressa. Nie martw się jednak, że ktokolwiek zobaczy ten instalator. Zobaczysz go tylko Ty. Dlatego właśnie modyfikowaliśmy tymczasowo plik .htaccess, umożliwiając dostęp do strony wyłącznie z Twojego IP. Nie przejmuj się jednak tym instalatorem. WordPress nie widzi po prostu tabel w bazie danych, bo zmieniony został ich prefiks w pliku wp-config. Dlatego próbuje ponownie się zainstalować. Niebawem wszystko wróci do normy, kiedy wykonasz kolejne kroki.

Teraz zaloguj się do phpmyadmin do bazy danych swojej strony www. Jeśli nie pamiętasz nazwy bazy danych Twojej strony www oraz hasła do niej, te dane znajdują się w pliku wp-config.php.

W menu po lewej wybierz swoją bazę danych, zaznacz wszystkie tabele i wybierz „Zamień przedrostek tabeli” tak jak na screenie poniżej.

phpmyadmin - zmiana prefixu tabel w WordPress

Teraz pojawi się okienko „Zastąp tabelę prefiksem”. W polu Od wpisz stary prefiks (wp_), a polu Do wpisz nowy prefiks (wpjd2g_).

Zmiana prefiksu tabel w WordPress

To jeszcze nie wszystko. Co prawda teraz Twoja strona powinna się już wyświetlać, ale w bazie danych wciąż znajdują się pozostałości starego prefiksu, które uniemożliwią chociażby zalogowanie się do panelu administracyjnego. Aby zakończyć zmianę prefiksu, musisz wykonać jeszcze jeden krok.

Kliknij na zakładkę SQL w menu na górze ekranu w phpmyadmin. Skopiuj i wklej następujące polecenia i kliknij „wykonaj”. Oczywiście wpjd2g_ to nowy prefiks tabel. Jeśli Twój nowy prefiks jest inny, podmień ten fragment na właściwy.

update wpjd2g_usermeta set meta_key = 'wpjd2g_capabilities' where meta_key = 'wp_capabilities';
update wpjd2g_usermeta set meta_key = 'wpjd2g_user_level' where meta_key = 'wp_user_level';
update wpjd2g_usermeta set meta_key = 'wpjd2g_autosave_draft_ids' where meta_key = 'wp_autosave_draft_ids';
update wpjd2g_options set option_name = 'wpjd2g_user_roles' where option_name = 'wp_user_roles';

Wyglądać to będzie tak:

Zmiana prefiksu tabel w bazie danych WordPress

Teraz możesz usunąć niepotrzebne linijki z pliku .htaccess umożliwiające dostęp do strony tylko z Twojego IP. Nie zapomnij również dobrze przetestować strony internetowej. Upewnij się, że wszystko działo poprawnie po zmianie prefiksu tabel, zwłaszcza jeśli strona korzysta z wielu wtyczek.

6. Zabezpieczanie przed atakami typu XML-RPC

XML-RPC to protokół umożliwiający zdalne wywoływanie procedur (RPC) przy użyciu XML, który umożliwia interakcję pomiędzy różnymi systemami. W ramach WordPressa, XML-RPC służy do zdalnego zarządzania treścią, umożliwiając takie działania jak publikacja postów czy moderacja komentarzy przez aplikacje zewnętrzne. Zabezpieczanie WordPressa przed atakami typu XML-RPC jest bardzo ważne, ponieważ interfejs XML-RPC może być wykorzystywany do przeprowadzania ataków typu brute-force oraz innych niepożądanych działań.

Jeśli nie korzystasz z funkcji związanych z XML-RPC, takich jak zdalna publikacja czy integracja z innymi aplikacjami (a większość osób z tego nie korzysta), najlepiej jest całkowicie wyłączyć ten interfejs. Możesz to zrobić dodając następujący kod do pliku .htaccess w głównym katalogu WordPressa:

<files xmlrpc.php>
order deny,allow
deny from all
</files>

Ten kod sprawi, że dostęp do pliku xmlrpc.php będzie zablokowany dla wszystkich użytkowników. Możesz zdecydować się na bardziej selektywne podejście, pozwalając na dostęp do xmlrpc.php tylko z określonych adresów IP. Można to zrobić również poprzez modyfikację pliku .htaccess:

<Files xmlrpc.php>
order deny,allow
deny from all
allow from XXX.XXX.XXX.XXX
</Files>

7. Ustawanie nagłówków bezpieczeństwa HTTP i WordPress

Serwer odpowiada nagłówkami HTTP, kiedy ktoś odwiedza Twoją stronę za pomocą przeglądarki. Te nagłówki, głównie metadane, kierują działaniem przeglądarki.

Nagłówki ochrony HTTP to kluczowy element bezpieczeństwa witryny, chroniący przed atakami takimi jak XSS i wstrzykiwanie kodu. Są łatwe do skonfigurowania i zapewniają dodatkową warstwę ochrony. Istnieje wiele rodzajów tych nagłówków, z których każdy odpowiada za inny aspekt bezpieczeństwa.

Właściwe ustawienie nagłówków, zwłaszcza Polityki Content-Security-Policy (CSP) może się różnić w zależności od specyfiki strony internetowej, ale możesz wypróbować poniższe ustawienia.

<ifModule mod_headers.c>
Header set Strict-Transport-Security "max-age=31536000" env=HTTPS
Header set X-XSS-Protection "1; mode=block"
Header set X-Content-Type-Options nosniff
Header set X-Frame-Options DENY
Content-Security-Policy "default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';";
</ifModule>

Zanim to zrobisz upewnij się jednak, że Twój serwer korzysta z modułu mod_headers. Możesz to sprawdzić samodzielnie lub poprosić o sprawdzenie swojego dostawcę hostingu.

  • Jeśli masz dostęp do konfiguracji serwera (na przykład poprzez SSH) i wiesz, jak to zrobić, możesz samodzielnie sprawdzić obecność i aktywację modułu mod_headers. W systemach Linux, komenda apachectl -M lub httpd -M często wyświetla listę załadowanych modułów Apache, w tym mod_headers.
  • Jeśli nie jesteś pewien, jak sprawdzić to samodzielnie, lub nie masz dostępu do konfiguracji serwera, najlepiej będzie skontaktować się z dostawcą usług hostingowych. Zapytaj swojego dostawcę hostingu, czy moduł mod_headers jest dostępny i aktywny na Twoim serwerze.

Oto krótkie omówienie każdej dyrektywy:

  1. Strict-Transport-Security:
    • Header set Strict-Transport-Security "max-age=31536000" env=HTTPS zapewnia, że połączenia z Twoją stroną są realizowane wyłącznie przez HTTPS przez następny rok (31536000 sekund). Flag env=HTTPS zapewnia, że nagłówek jest dodawany tylko, gdy połączenie jest zabezpieczone (HTTPS).
  2. X-XSS-Protection:
    • Header set X-XSS-Protection "1; mode=block" włącza wbudowane filtry przeciwko atakom XSS w przeglądarkach i ustawia je w tryb blokowania.
  3. X-Content-Type-Options:
    • Header set X-Content-Type-Options nosniff zapobiega „sniffingowi” typu MIME przez przeglądarkę. Gdy ten nagłówek jest ustawiony, informuje on przeglądarkę, aby nie próbowała zgadywać („sniffować”) typu MIME zasobów, co pomaga zapobiegać pewnym rodzajom ataków, takim jak wstrzykiwanie złośliwego kodu. Typy MIME to sposób, w jaki komputery nazywają różne rodzaje plików, aby wiedzieć, jak je obsługiwać np. obrazy, filmy itp.
  4. X-Frame-Options:
    • Header set X-Frame-Options DENY blokuje możliwość osadzania strony w ramkach (iframe), co pomaga zapobiegać atakom typu „clickjacking”.
  5. Content-Security-Policy:
    • Content-Security-Policy "default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';" jest to mocno restrykcyjna polityka, która domyślnie blokuje wszystkie źródła, z wyjątkiem tych z tej samej domeny (‘self’). Pozwala to na zwiększenie bezpieczeństwa przez ograniczenie możliwości ładowania zasobów z innych witryn. Zaproponowana Polityka Content-Security-Policy (CSP) jest bardzo restrykcyjna i może zakłócić działanie niektórych funkcji strony, takich jak skrypty zewnętrzne, widgety, itp. Dostosuj ją zgodnie z potrzebami swojej witryny.

Zawsze przetestuj swoją stronę po wprowadzeniu zmian w pliku .htaccess, aby upewnić się, że wszystko działa poprawnie. Dotyczy to zwłaszcza Content-Security-Policy. Zbyt restrykcyjna polityka może powodować, że Twoja strona nie będzie działać poprawnie. Oto przykład mniej restrykcyjnej polityki CSP:

Content-Security-Policy: default-src 'self'; script-src 'self' https://zaufana-domena.com https://druga-zaufana-domena.com; img-src 'self' https:; connect-src 'self'; style-src 'self' 'unsafe-inline'; font-src 'self';

W tym przykładzie:

  • default-src 'self’: Ogranicza ładowanie większości zasobów do tych, które są częścią tej samej witryny.
  • script-src 'self’ https://zaufana-domena.com https://druga-zaufana-domena.com: Pozwala na ładowanie skryptów z tej samej witryny oraz ze wskazanych zaufanych domen.
  • img-src 'self’ https:: Pozwala na ładowanie obrazów z tej samej witryny oraz z dowolnych źródeł używających HTTPS.
  • connect-src 'self’: Ogranicza połączenia AJAX i WebSocket do tej samej witryny.
  • style-src 'self’ 'unsafe-inline’: Pozwala na używanie stylów z tej samej witryny oraz na używanie stylów inline (choć 'unsafe-inline’ może stanowić pewne ryzyko bezpieczeństwa).
  • font-src 'self’: Ogranicza źródła fontów do tych z tej samej witryny.

Ważne uwagi:

  • Polityka CSP powinna być dostosowana do konkretnych potrzeb i struktury Twojej strony.
  • Dodanie 'unsafe-inline’ do style-src jest mniej bezpieczne, ale może być potrzebne dla niektórych starszych stylów inline lub skryptów.
  • Zawsze testuj swoją witrynę po wprowadzeniu zmian w CSP, aby upewnić się, że wszystkie funkcjonalności działają poprawnie.
  • Jeśli strona nie ma zdefiniowanej polityki CSP, przeglądarki polegają na swoich standardowych mechanizmach bezpieczeństwa, takich jak blokowanie mieszanych treści (mieszanie zasobów HTTP i HTTPS) czy ograniczenia związane z polityką tego samego pochodzenia. Nie zapewni to jednak takiego samego poziomu ochrony, jak dobrze skonfigurowana polityka CSP.

8. Automatyczne przekierowanie do HTTPS

Automatyczne przekierowanie do HTTPS jest ważną praktyką zabezpieczającą, która zapewnia, że wszystkie połączenia z Twoją stroną internetową są szyfrowane. To pomaga chronić dane przesyłane między użytkownikiem a stroną przed przechwyceniem przez nieuprawnione osoby. Aby wdrożyć automatyczne przekierowanie do HTTPS, zazwyczaj modyfikuje się plik .htaccess na serwerze Apache. Aby używać HTTPS, Twoja strona musi mieć oczywiście zainstalowany ważny certyfikat SSL.

Aby przekierować ruch z HTTP na HTTPS dopisz do .htacces na samym początku pliku (zaczynając w pierwszej linijce) następujący kod:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/[0-9a-zA-Z_-]+$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Powyższy kod ma na celu przekierowanie ruchu z HTTP na HTTPS, ale uwzględnia wyjątki dla procesów weryfikacji certyfikatów SSL, co jest ważne, gdy korzystasz z automatycznych procesów odnawiania certyfikatu SSL (takich jak Let’s Encrypt). Używa również zmiennej %{HTTP_HOST}, co oznacza, że przekierowanie będzie działać niezależnie od tego, jaka jest dokładna domena (np. www.twojadomena.com, twojadomena.com, itp.).

9. Usunięcie informacji o używanej wersji WordPressa

Zastosowanie tego kodu nie jest to konieczne, jeśli stale aktualizujesz swojego WordPressa, ale faktem jest, że domyślnie WordPress udostępnia informację o aktualnie używanej wersji oprogramowania. Znacznik wersji znajduje się w sekcji <head> strony i przedstawia się mniej więcej tak:

<meta name="generator" content="WordPress 7.2.0" />

Używana przez nas wersja oprogramowania WP zazwyczaj nie jest informacją, którą chcemy dzielić się ze światem, ponieważ Twoją stronę odwiedzają nie tylko ludzie, ale również boty i roboty, które zwykle indeksują nowe podstrony. Niestety, internetowi przestępcy, wykorzystują podobne narzędzia do wyszukiwania stron podatnych na ataki. Informowanie wprost, że korzystamy (być może) z nieaktualizowanej wersji oprogramowania to po prostu proszenie się o kłopoty.

Dlatego warto ukryć informację o aktualnie używanej wersji WordPressa, przez dodanie kilku linijek do pliku functions.php, który znajduje się w katalogu głównym używanego motywu.

remove_action('wp_head', 'wp_generator');

function usun_informacje_o_versji_WP() {
   return '';
}
add_filter('the_generator', 'usun_informacje_o_versji_WP');

Dzięki temu usuniesz informację o wersji WordPressa nie tylko z <head>, ale również z kanałów RSS.

10. Wyłączenie wyświetlania błędów

Pokazywanie szczegółowych komunikatów błędów na stronie publicznej może być pomocne dla cyberprzestępców, ponieważ dostarcza im cennych informacji o strukturze i potencjalnych słabościach Twojej strony. Dlatego ważne jest, aby wyłączyć wyświetlanie błędów na stronie użytkownikom.

Całe szczęście domyślnie, wp-debugger jest wyłączony, ale jeśli Twoja strona działa nieprawidłowo, konieczne może być jego włączenie. W takiej sytuacji, wystarczy dodać następujący kod do pliku wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define ('WP_DEBUG_DISPLAY', false);

Ta konfiguracja sprawia, że błędy nie będą wyświetlane na stronie (WP_DEBUG_DISPLAY ustawione na false), ale nadal będą zapisywane do pliku logów, co pozwala na późniejsze ich przeanalizowanie i rozwiązanie problemów bez narażania bezpieczeństwa strony.

Ze względów bezpieczeństwa, zaleca się włączanie trybu debugowania (WP_DEBUG i WP_DEBUG_LOG) tylko wtedy, gdy jest to niezbędne do rozwiązywania problemów, a po zakończeniu diagnozy powinno się wyłączyć te opcje i usunąć plik debug.log z serwera.

Domyślnie plik debug.log znajduje się w katalogu wp-content WordPressa, ale od wersji 5.1 można zmienić ścieżkę do pliku logów z błędami poprzez dodanie do wp-config następującej linijki:

define( 'WP_DEBUG_LOG', '/sciezka/do/pliku/wp-errors.log' );

Oczywiście zastępując ciąg /sciezka/do/pliku/wp-errors.log własną ścieżką.

Podsumowanie

Jak widać, istnieje całkiem sporo sposobów na zabezpieczenie WordPressa bez wykorzystania wtyczek. Oczywiście nie oznacza to, że nie warto korzystać z żadnych wtyczek do bezpieczeństwa, ale już implementacja tych środków bezpieczeństwa, o których wyżej pisaliśmy, pomoże w ochronie Twojej strony WordPress przed najczęstszymi zagrożeniami i atakami.

Na koniec, warto pamiętać, że nawet najlepiej zabezpieczona strona internetowa może zostać zainfekowana. Bezpieczeństwo to proces ciągły, który wymaga stałej uwagi i dostosowania do zmieniających się zagrożeń. Dlatego niezbędne jest stosowanie silnych haseł, regularne tworzenie kopii zapasowych strony oraz stałe monitorowanie witryny pod kątem nieoczekiwanych zmian. Równie ważna jest świadomość i edukacja zarówno administratorów, jak i użytkowników strony w zakresie bezpieczeństwa cyfrowego, ponieważ błędy ludzkie bardzo często stanowią punkt wyjścia dla ataków.