WordPress – zabezpieczenie przed włamaniem. Praktyczne i skuteczne porady.

Wstęp

WordPress to jeden z najczęściej wybieranych systemów zarządzania treścią w internecie. Według oficjalnych statystyk, aż 455 milionów stron internetowych na świecie korzysta z tego systemu, a każdego dnia powstaje średnio 650 nowych stron.

Wykorzystywany jest on do robienia prostych stron na gotowych motywach, jak również rozbudowanych witryn opartych o dedykowane rozwiązania. WooCommerce, które jest rozszerzeniem e-commerce do tego systemu, stanowi również bardzo duży procent platform e-commerce na świecie. 

Popularność ta jednak niesie ze sobą wiele zagrożeń ze strony cyberprzestępców – tym bardziej, że WordPress jest projektem GPL na licencji OpenSource i wgląd do jego kodu ma każdy. Podobna sytuacja ma się również do wtyczek czy motywów. 

Należy pamiętać, że nawet najlepsze zabezpieczenia i dbanie o WordPressa, nigdy całkowicie nie wyklucza zagrożenia i nie zapewni Ci stuprocentowego bezpieczeństwa.

Dzisiejszy poradnik to zbiór porad zdobytych na przestrzeni lat pracy z tym systemem oraz od społeczności WordPressa. Nasz poradnik nie zawiera zestawienia wtyczek, którym magicznie zabezpieczymy naszą stronę, a idzie w zupełnie odwrotnym kierunku.

Po co atakuje się WordPressa?

Powodów jest wiele i nie ma tutaj znaczenia, czy nasza strona jest dużym portalem internetowym, czy stroną lokalnego warsztatu samochodowego.

Najczęstsze przyczyny atakowania WordPressa to:

• Spamerskie linki, dzięki którym osoba atakująca zyskuje profity.
• Przekierowania na inne strony internetowe, również w celach zyskiwania profitów.
• Wysyłka spamu w komentarzach lub na mail właściciela.
• Ataki DDoS powodujące przeciążenia i próby włamania na serwer.
• Zarażanie innych stron znajdujących się na serwerze.
• Wykorzystywanie zasobów serwera do kopania kryptowalut.
• Backdoor w celu wykradania poufnych danych.
• Złośliwość konkurencji.

Jakie może to mieć konsekwencje w praktyce?

Brak stosowania odpowiednich praktyk zabezpieczających może grozić naprawdę nieprzyjemnymi konsekwencjami. Jak w praktyce objawia się atak na naszą stronę?

• Google będzie zrzucać stronę z pozycji wyników wyszukiwania, a w najgorszym wypadku może ona zostać z nich całkowicie wykluczona. Twoja strona może atakować inne strony, co może skutkować wpisaniem jej na czarną listę domen, a proces przywracania jest długi i czasem kosztowny.
• Kampanie reklamowe Google Ads będą odrzucane, co zresztą samo Google argumentuje, że próbujemy kierować na zainfekowaną stronę.
• Pod twoją domeną będą indeksowane spamerskie linki np. witryn pornograficznych, reklamowych lub próbujących zawirusować komputer użytkownika. 
• Dodatkowo mogą zostać ustawione przekierowania na ww. strony w momencie wejścia na naszą stronę, co może negatywnie wpływać na wizerunek firmy.

Brzmi groźnie? Bo takie właśnie jest!

Bezpieczeństwo zaczyna się już na etapie wyboru serwera

Istnieje wiele czynników, które powinieneś brać pod uwagę przy wyborze hostingu, aby zapewnić sobie jak najlepsze warunki spełniania standardu bezpieczeństwa:

• Zweryfikuj opinie użytkowników korzystających z hostingu. Pozwoli to wykluczyć stosowanie przez dany hosting nieczystych praktyk typu modyfikacje plików stron, a także weryfikować opinie na temat supportu serwera i jego dostępności.
• Sprawdź, czy serwer wspiera najnowszą wersję PHP, która jest fundamentem poprawnego wsparcia i działania najnowszych wersji WordPressa.
• Upewnij się, że hosting ma system kopii zapasowych.
• Dowiedz się, czy w przypadku posiadania kilku stron na jednym serwerze jest zapewniona separacja domen.
• Sprawdź, czy hosting posiada mechanizm anty-DDoS i umożliwia połączenie SFTP / SSH.

Po tym krótkim wstępie nadeszła pora przejść do meritum, czyli profilaktyki bezpieczeństwa systemu – co robić oraz czego nie robić?

W większości niniejsze porady nie wymagają wiedzy technicznej, ale nie w każdym przypadku. Dlaczego? W wielu przypadkach trudno jest zabezpieczyć WordPressa bez ingerencji w warstwę serwerową, gdzie powinny zaczynać się wszelkie asekuracje.

Nie instaluj wtyczek zabezpieczających

Wtyczki bezpieczeństwa są prawdopodobnie ostatnią rzeczą, jaką powinniśmy zainstalować na stronie internetowej opartej na WordPressie.

Tego typu rozwiązania złudnie budują poczucie bezpieczeństwa i usypiają naszą czujność, a to właśnie te wtyczki stanowią 90% podatności na wszelkiego rodzaju ataki.

Dodatkowo bardzo często manipulują wynikami skanowania, aby zachęcać użytkownika do zakupu wersji PRO takiej wtyczki, która usunie to zagrożenie. W rzeczywistości takie zagrożenie może w ogóle nie istnieć.

Do najpopularniejszych wtyczek bezpieczeństwa zaliczamy: Wordfence, Securi, iThemes Security Pro, All in One WP Security.

Oczywiście tych wtyczek jest znacznie więcej, ale mimo wszystko nie instalujemy takich rozwiązań. 

Wtyczki bezpieczeństwa ze względu na swoją popularność są bardzo chętnie atakowane. Dodatkowo warto brać pod uwagę fakt, że same posiadają luki bezpieczeństwa:

Jeżeli wtyczka mająca zapewnić nam bezpieczeństwo, sama posiada luki w bezpieczeństwie, to chyba coś tu jest nie tak.

#ProTIP: wszelkiego rodzaju zabezpieczenia rób tylko i wyłącznie z poziomu serwera, a nie z poziomu panelu administracyjnego WordPressa.

Nie instaluj wtyczek optymalizujących

W przypadku wtyczek optymalizacyjnych sytuacja jest bardzo podobna do tej z wtyczkami zabezpieczającymi. Wtyczki te również są bardzo popularne i chętnie instalowane, ale również podobnie chętnie atakowane, co wtyczki zabezpieczające. 

Do takich najpopularniejszych wtyczek zaliczamy: WP Fastest Cache, W3 Total Cache, Autoptimize, WP-Optimize, WP Super Cache, WP Fastest Cache.

Dodatkowo te wtyczki są mocno niewskazane dla WooCommerce, ze względu na błędy, z którymi będą spotykać się użytkownicy sklepu i tutaj również optymalizacja powinna zostać wykonana tylko z poziomu serwera – oczywiście jeżeli wymaga tego dana strona, ale optymalizacja to temat na osobny artykuł.

Nie instaluj wtyczek ingerujących w główną warstwę serwera

Wtyczki ingerujące w warstwę serwera są bardzo łatwym sposobem na atak poprzez bezpośredni dostęp do serwera, pomijając przy tym wszelkiego rodzaju zabezpieczenia serwerowe.

Bardzo często z tego typu wtyczek używa się z racji braku danych dostępowych lub umiejętności do korzystania z połączenia FTP.

Do najpopularniejszych wtyczek zaliczamy wszelkiego rodzaju wtyczki typu File Manager (wtyczki dające dostęp do warstwy serwera z plikami strony z poziomu CMSa, zastępując przy tym programy FTP) czy wtyczki do zarządzania bazą danych np. WP phpMyAdmin.

Warto ponownie tutaj zaznaczyć wszystkie wtyczki optymalizujące oraz zabezpieczające, ponieważ ich fundamentem są również ingerencje do warstwy serwerowej.

Nie instaluj wtyczek nieznanego pochodzenia

Jest to chyba bardzo oczywiste, ale mimo wszystko wciąż można zauważyć tendencje do zakupu wtyczek z nieoficjalnych źródeł, np. paczki wtyczek do WP na Allegro po cenach niższych, niż w przypadku zakupu każdej wtyczki osobno. 

Wiążą się z tym dwa zagrożenia: pierwsze jest takie, że nigdy nie mamy pewności czy do takiej wtyczki nie zostało dodane coś „ekstra”. Po drugie – kupując wtyczkę od producenta masz pewność aktualizacji i suportu, czego nie otrzymujesz kupując wtyczki z innego źródła.

A co z wtyczkami lub motywami, które normalnie kosztują kilkanaście dolarów, a są dostępne za darmo np. na forach? Od razu mówimy – instalacja takiej wtyczki to świadomy strzał w kolano dla naszej strony internetowej. 

Jeżeli chcemy instalować wtyczki – instalujemy tylko te, które dostępne są w repozytorium WordPressa. Przed instalacją jednak nawet te wtyczki warto zweryfikować pod kątem bezpieczeństwa i czy posiadają aktualne wsparcie np. weryfikując datę ostatniej aktualizacji.

#ProTIP: skąd czerpać wiedzę na temat instalowanych wtyczek? Warto na pewno zacząć od przejrzenia historii podatności na stronie wpscan.com.

Innym dobrym sposobem, choć nie zawsze skutecznym jest wpisanie w Google: „nazwa wtyczki wordpress malware” albo „nazwa wtyczki virus” i weryfikacją, co internet mówi o danej wtyczce.

Aktualizacje – fundament bezpieczeństwa

Bieżące aktualizacje core WordPressa, wtyczek i motywu są kluczową czynnością, która wzmacnia bezpieczeństwo naszego WordPressa, więc powinniśmy dbać o to na bieżąco.

Pomijając oczywisty cel aktualizacji, od strony bezpieczeństwa stare wersje są otwartymi drzwiami dla hakerów, bo jakiś fragment kodu może zostać wykorzystany do wpuszczenia złośliwego kodu lub innego niepożądanego działania.

#ProTIP: Jeżeli pojawiła się aktualizacja – instalujemy i nie czekamy. Jeżeli mamy obawy przed aktualizacją – sprawdzamy aktualizacje na wersji testowej.

Jeżeli w naszym systemie posiadamy wtyczki, których ostatnia aktualizacja została odnotowana więcej niż 6 miesięcy temu, powinniśmy poważnie zastanowić się nad usunięciem jej i poszukiwaniu alternatywy. Zdarza się, żę autorzy wtyczek porzucają ich dalszy rozwój i hakerzy bardzo chętnie wykorzystują luki w takich porzuconych wtyczkach.

Warto też nadmienić, że wiele wtyczek wymaga wykupienia wsparcia (licencji), w ramach której otrzymujemy aktualizacje.

#ProTIP: sprawdzenia dostępności aktualizacji jak i samej aktualizacji możemy dokonać z poziomu kokpitu, wybierając opcję “Aktualizacje”.

Zadbaj o zalecaną wersję PHP

PHP, czyli język programowy, na którym zbudowany jest WordPress oraz wszystkie motywy i wtyczki. W celu polepszenia działania i lepszego bezpieczeństwa zaleca się, aby na serwerze była ustawiona wersja PHP zgodna z tą, której wymaga obecna wersja WordPressa. Poza kwestiami bezpieczeństwa, nowej wersji PHP mogą również wymagać motywy lub wtyczki do zapewniania poprawnego działania.

Wymagania bieżącej wersji WordPressa można sprawdzić tutaj: https://pl.wordpress.org/about/requirements/

Jeżeli nasz WordPress wyświetla komunikat o zalecanej aktualizacji PHP to staramy się taką aktualizację zapewnić.

#ProTIP: jeżeli nie jesteś osobą techniczną, to aktualizację wersji PHP zalecamy zrobić ze specjalistą, aby można było szybko zweryfikować poprawność działania poprzez staging strony.

Regularnie zmieniaj hasła

Potwierdzoną informacją jest to, że hakerzy często udostępniają wykradzione hasła w sieci. Dlatego taką prostą czynnością, jak zmiana hasła możemy zmniejszyć potencjalną próbę włamania lub ataku.

Starajmy się raz na miesiąc (albo przynajmniej kwartał lub pół roku) zmieniać hasła dostępowe kont administracyjnych, serwera FTP oraz bazy danych. Natomiast jeżeli dowiedzieliśmy się, że jeżeli WordPress lub któraś z wtyczek lub motywów miała podatność i została ona usunięta wraz z aktualizacją, to zmianę hasła powinniśmy wykonać każdorazowo po takiej sytuacji.

Przy ustawianiu haseł dbajmy o to, aby były to hasła trudne. Nie używajmy haseł typu: admin123, Jarek123, Audi, abc123. Są to hasła bardzo proste do rozszyfrowania, a narzędzia do ataków Brute-Force w pierwszej kolejności weryfikują takie kombinacje.

#ProTIP: dobre hasło to takie składające się z ciągu losowych dużych i małych znaków wraz z cyframi. Do generowania takich haseł polecamy: https://passwordsgenerator.net/

Podwójna autentykacja

Czyli innymi słowy weryfikacja, która odbywa się jeszcze przed próbą zalogowania do panelu administracyjnego, np. token w aplikacji, token SMS. Z takimi metodami najczęściej spotykamy się korzystając z bankowości internetowej lub stronami urzędowymi, które to na telefon przesyłają nam kody do logowania.

Do popularnych rozwiązań używanych z WordPressem należą Rublon, Google Authenticator czy miniOrange’s Google Authenticator.

Jeżeli nie jesteśmy w stanie wdrożyć powyższych rozwiązań, powinniśmy zastanowić się choćby nad prostszymi sposobami autentykacji, takimi jak ustawienie Google reCAPTCHA lub ustawienie hasła za pomocą plików .htaccess i .htpasswd.

W pliku .htaccess w głównym ustawiamy regułę kierującą do naszego pliku .htpasswd:

<Files wp-login.php>
	AuthType Basic
	AuthGroupFile /dev/null
	AuthName "Komunikat"
	AuthUserFile /sciezkadoroota/.htpasswd
	require valid-user
</Files>

Nazwę użytkownika oraz hasło możemy sobie wygenerować dowolnym generatorem.

Możemy również przejść na poziom wyżej i zastosować…

Ograniczenie dostępu do panelu administracyjnego po IP

Jeżeli do wp-admina loguje się konkretna liczba użytkowników ze stałym adresami IP, bardzo dobrym zabiegiem będzie ograniczenie dostępu do panelu administracyjnego tylko dla konkretnej puli IP.

Taki dostęp możemy ustawić w pliku .htaccess wklejając:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin(\/)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin/$
RewriteCond %{REMOTE_ADDR} !^200\.200\.200\.200$
RewriteRule ^(.*)$ – [R=403,L]
</IfModule>

Dzięki temu mamy pewność, że nikt z zewnątrz nie jest w stanie zalogować się do naszego panelu administracyjnego

Wyłącz debugowanie

Błędy w kodzie pozwalają zobaczyć komunikaty błędów, które ułatwiają wykrycie potencjalnych luk w składni kodu. W pliku wp-config.php warto zamienić WP_DEBUG na:

define('WP_DEBUG', false);

if ( ! WP_DEBUG ) {
	ini_set('display_errors', 0);
}

Zablokuj dostęp edycji kodu z poziomu WordPressa

Z poziomu WordPressa mamy dostęp do dwóch miejsc, w których mamy możliwość bezpośredniej edycji kodu przy pomocy edytora motywu oraz edytor wtyczki.

To właśnie z tych edytorów bardzo chętnie korzystają hakerzy lub wtyczki / narzędzia wpuszczające do naszej strony złośliwy kod, dlatego bardzo ważnym elementem jest całkowite wyłączenie tych edytorów.

Aby wyłączyć edytor motywu, należy w pliku wp-config.php umieścić:

define( 'DISALLOW_FILE_EDIT', true );

Aby wyłączyć edytor wtyczki w tym samym pliku należy umieścić:

define( 'DISALLOW_FILE_MODS', true );

Uwaga! Wyłączenie edytora wtyczki jest równoznaczne z wyłączeniem opcji aktualizacji wtyczek. Jest to spowodowane właśnie tym, że w trakcie takiej aktualizacji kod walidowany jest z poziomu WordPressa. Dobrą praktyką jest ręczna aktualizacja wtyczek uprzednio testując poprawność działania na stagingu  lub wyłączenie tej opcji na czas przeprowadzenia aktualizacji wtyczek.

Zablokuj dostęp do listy użytkowników z REST API

W ramach zabezpieczania często ukrywa się nazwy użytkowników, jednak REST API bez problemu pozwala na sprawdzenie listy tych użytkowników. Wystarczy w przeglądarce wejść pod adres:

https://twojastrona.pl/wp-json/wp/v2/users

Możemy ograniczyć dostęp do zawartości tego pliku poprzez funkcję:

add_filter('rest_endpoints', function( $endpoints ) {
    if ( isset( $endpoints['/wp/v2/users'] ) ) {
        unset( $endpoints['/wp/v2/users'] );
    }
    if ( isset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] ) ) {
        unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
    }
    return $endpoints;
});

Obserwacja działań i zmian

Bieżąca analityka to dobra metoda na wczesne wykrycie potencjalnego zagrożenia. Mowa tutaj o analityce zarówno wejść na naszą stronę, jak również zmian zachodzących w plikach strony.

Jeżeli widzimy, że na naszej stronie mamy odwiedziny z krajów, z których raczej nie spodziewamy się wejść np. Afganistan to powinniśmy wtedy być bardziej czujni. Być może to jakiś zwykły bot, ale równie dobrze może to być haker korzystający z VPN (narzędzia do maskowania adresu IP).

Obserwacja plików strony jest również bardzo ważna, ale niestety wymaga ona dość dobrej znajomości całej struktury plików i folderów WordPressa, bo to właśnie dzięki wyłapaniu pliku, którego nie powinno być, jesteśmy w stanie skutecznie opóźnić lub całkowicie zneutralizować atak.

#ProTIP: obserwację plików możemy prowadzić również przy pomocy logów serwera dostępnych w panelu zarządzania naszym serwerem.

Separacja domen

Jeżeli posiadamy na naszym hostingu kilka stron internetowych to zdecydowanie powinniśmy zweryfikować separację domen, aby pliki stron internetowych nie były ze sobą wymieszane.

Prawidłową strukturą katalogów na serwerze przy separacji jest m.in:

• twojserwer.pl/domains/domenaA.pl/public_html/wordpress/index.php
• twojserwer.pl/domains/domenaB.pl/public_html/wordpress2/index.php

Jeżeli spotkamy się z czymś takim:

• twojserwer.pl/domains/domenaA.pl/public_html/wordpress/index.php
• twojserwer.pl/domains/domenaA.pl/public_html/wordpress/domenaB.pl/index.php

to możemy być pewni, że przy ataku na domenę A, domena B również zostanie zainfekowana. Jeżeli stron na serwerze mamy więcej bez separacji, to przywrócenie tego do działania może być dla nas bardzo kosztowne i szkodliwe dla biznesu.

Nie rób z serwera przechowywalni plików

Nie używajmy naszego serwera jako przechowywali plików osobistych czy co gorsza – plików skryptowych, rozruchowych, tekstowych czyli takich, które pozwalają na swobodne dodawanie tekstu do takiego pliku. 

Dodatkowo – jeżeli na serwerze mamy pliki motywu czy wtyczek których nie używamy, to bez zastanowienia usuwamy. Wtyczka, która jest nieaktywna nadal jest na serwerze i stanowi potencjalne drzwi do włamania.

#ProTIP: do przechowywania dokumentów czy też plików osobistych zachęcamy do korzystania z usług wirtualnych dysków typu Google Drive, Dropbox itp.

Rób kopie zapasowe strony internetowej

Kopie zapasowe są często kluczowym elementem pozwalającym na szybkie przywrócenie do działania naszej strony internetowej – w przypadku ataku czy choćby awarii spowodowanej aktualizacją, błędną modyfikacją kodu lub instalacją uszkodzonego motywu / wtyczki.

Bardzo ważne jest jednak to, aby w przypadku zainfekowania strony internetowej przywrócenie kopii nie było pierwszą rzeczą, którą robimy. Nie mamy pewności kiedy pojawiła się podatność, dlatego przywracanie kopii zapasowej na starcie nie ma sensu, bo w 99% przypadkach infekcja powróci oraz utrudniamy zlokalizowanie źródła infekcji. Bardzo często źródło infekcji znajduje się już w plikach kopii zapasowej.

Dlatego kopię możemy przywrócić, uprzednio robiąc kopię strony zainfekowanej, która będzie służyć za repozytorium do usunięcia infekcji i musimy pamiętać, że jest to rozwiązanie tymczasowe.

Pamiętajmy, aby kopii zapasowej nie robić wtyczkami. W przypadku całkowitej awarii naszej strony, gdzie nie będzie możliwy dostęp do panelu administratora, nie będziemy w stanie przywrócić naszej strony do działania. Dodatkowo nigdy nie mamy pewności czy do takiej kopii nie została dodana szkodliwa niespodzianka.

W tym miejscu zachęcamy również do naszych szkoleń z tworzenia i przywracania kopii zapasowych bez użycia wtyczek.

Częstotliwość tworzenia kopii zapasowej staramy się dostosować do częstotliwości aktualizacji treści na naszej stronie internetowej. Jeżeli posiadamy mały serwis, w którym dodajemy informacje raz na pół roku, to wystarczy jak kupię będziemy robić raz w miesiącu.

Duży portal internetowy, w którym codziennie dodawanych jest kilka newsów – archiwizujemy codziennie.

Klucze szyfrujące

Jedną z podstaw bezpieczeństwa są klucze szyfrujące – warto po instalacji zmienić je na własne. Klucze znajdują się w pliku wp-config.php, który znajduje się w głównym katalogu serwera.

Klucze możemy wygenerować tutaj: https://api.wordpress.org/secret-key/1.1/salt/

Wygenerowane klucze wklejamy i podmieniamy z istniejącymi.

Sanityzacja danych

Przez formularze komentarzy czy jakiekolwiek inne formularze, użytkownik może przesłać coś na naszą stronę, np. skrypt będący złośliwym kodem, który będzie wykonywać się w momencie publikacji na stronie.

Użytkownik (nawet nieświadomie) może wysłać także jakiś ciąg znaków, który uniemożliwi dalsze wykonywanie kodu strony.

WordPress posiada natywnie wbudowane funkcje do sanityzacji: https://developer.wordpress.org/?s=sanitize_

Opcja co prawda dla bardziej zaawansowanych, ale również bardzo ważna, a bardzo często zaniedbywana i nie testowana.

Odseparuj dostęp do bazy danych

Z racji tego, że większość ataków w pierwszej kolejności kierowanych jest do wyżej wspomnianego pliku wp-config, aby uzyskać dostęp do bazy danych (a ta daje nam w dostęp do środka panelu), warto nieco utrudnić ten proces, zmieniając lokalizację danych bazy danych.

W naszym pliku wp-config.php znajdziemy dane bazy danych:

define('DB_NAME', '');
define('DB_USER', '');
define('DB_PASSWORD', '');
define('DB_HOST', '');
define('DB_CHARSET', '');
define('DB_COLLATE', '');

Tworzymy w tym samym katalogu plik o innej nazwie np. wp-danedobazydanych.php i do niego wklejamy powyższe dane.

W oryginalnym pliku wp-config.php wywołujemy stworzony wcześniej plik:

require_once "wp-danedobazydanych.php"

Zablokuj dostęp do plików konfiguracyjnych

Dodaj do pliku .htaccess w głównym katalogu:

<FilesMatch "wp-config.*\.php|\.htaccess|readme\.html">
    Order allow,deny
    Deny from all
</FilesMatch>

Ukryj wersję WordPress wyświetlaną w kodzie strony

Ukrycie wersji WordPressa pozwoli na utrudnienie szybkiego wykorzystywania podatności specyficznych dla danej wersji.

W pliku functions.php należy dodać::

remove_action('wp_head', 'wp_generator');

robimy to samo również dla skryptów:

function remove_version_wp( $src ) {
global $wp_version;
$version_str = '?ver='.$wp_version;
$offset = strlen( $src ) - strlen( $version_str );
if ( $offset >= 0 && strpos($src, $version_str, $offset) !== FALSE )
return substr( $src, 0, $offset );
return $src;
}

add_filter( 'script_loader_src', 'remove_version_wp' );
add_filter( 'style_loader_src', 'remove_version_wp' );

Zablokuj wp-includes

Warto zabezpieczyć pliki, które nie są użyteczne dla użytkowników odwiedzających stronę, ale są wymagane do prawidłowego działania WordPrssa.

W pliku .htaccess w głównym katalogu WP dodajemy:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ – [F,L]
RewriteRule !^wp-includes/ – [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ – [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php – [F,L]
RewriteRule ^wp-includes/theme-compat/ – [F,L]
</IfModule>

Zablokuj wykonywanie plików PHP

Poniższy kod zablokuje wykonywanie plików o rozszerzeniu .php, które mogą być przesyłane przez np. formularze kontaktowe.

Kod dodajemy do wp-content/uploads/.htaccess:

<Files *.php>
deny from all
</Files>

a w .htaccess w katalogu głównym dodajemy:

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]

A jeżeli już złapiesz infekcję…

Działaj szybko! Im dłużej zwlekasz z usunięciem infekcji, tym więcej efektów ubocznych odczujesz, nie mówiąc również o czasie potrzebnym na posprzątanie po infekcji.

W przypadku infekcji zachęcamy do skorzystania z naszej oferty na kompleksową obsługę związaną z usunięciem infekcji lub bezpośrednio na nasz e-mail. Jeżeli nie jesteś osobą techniczną, nie należy działać na własną rękę, ponieważ w większości przypadków kończy się to powrotem infekcji lub uszkodzeniem strony.

Powtórzymy – nie należy przywracać backupu, ponieważ znacząco utrudnia to znalezienie źródła infekcji. Nie nadpisuj także plików strony internetowej czy plików CMSa – jest to równoznaczne z przywróceniem backupu.