Elementy zabezpieczenia WordPress, które musisz znać


Zabezpieczenie aplikacji WordPress, pomimo tego co sądzi większość użytkowników, nie musi być trudne. Zadbanie o podstawowy poziom zabezpieczenia jest prosty, jednak przy każdych zmianach należy zachować czujność i zdrowy rozsądek. Swoimi wskazówkami w tym zakresie dzieli się Paweł Otlewski.


Podstawy

Długo się zastanawiałem, czy w ogóle ten temat poruszyć… jednakże codzienne obserwacje zachęcają do uwzględnienia podstaw. Choć specjaliści ds. bezpieczeństwa kierują uwagę użytkowników na ten problem, wielu wciąż upiera się przy stosowaniu łatwej kombinacji loginów i haseł (np. login: admin, hasło: Kolega12).

Niemal każdy z nas, chociaż raz w życiu posiadał proste hasło: jedno lub dwa słowa, bez znaków specjalnych. To normalne, że staramy się mieć hasło, które łatwo nam zapamiętać, ale… Skoro jest ono łatwe dla nas, z pewnością będzie proste do odgadnięcia także dla potencjalnego hakera. Ktoś inny jest w stanie zapamiętać nasze zabezpieczenia w bardzo prozaiczny sposób, np. podglądając nas zza ramienia, albo przy wykorzystaniu Brute-Force. Dana osoba może próbować odgadnąć hasło i w rezultacie trafi.

Hasła i szyfrowanie połączeń

Tylko oryginalne nazwy użytkownika i mocne hasła są w stanie podnieść poziom bezpieczeństwa. Nazwy typu: admin, administrator, webmaster, postmaster, <tutaj_nazwa_strony>, czy user powinien zostać wykluczone. Zadbajmy o to, bo inaczej ktoś szybko wykorzysta nasze niedopatrzenie. Dodatkowo przypominam o szyfrowaniu połączeń. W czasach, gdy koszt certyfikatu to kilkanaście złotych, nie warto oszczędzać na sprawdzonych rozwiązaniach. SSL jest uwiarygodnieniem dla serwisu i zabezpieczeniem strony przed atakiem Man in the middle

Bogate i jednocześnie słabe wsparcie

Zacznijmy od początku… Jaki jest najczęstszy powód infekcji, które się pojawiają na WordPress’ie i na każdym popularnym systemie CMS (takim jak np.: Joomla)? Brak aktualizacji oraz korzystanie z dodatków (wtyczek), które zostały porzucone przez twórców.

W celu zobrazowania sytuacji, przyjrzyjmy się wtyczce: “Steam Widget”. Jak widać – wtyczka jest aktualna po instalacji. Zabezpieczenie, które WordPress’a rozumiane jako aktualizowanie wtyczek – jest spełnione, niby wszystko ok, trzeba jednak zwrócić uwagę na datę ostatniej aktualizacji:

Wtyczka została ostatni raz zaktualizowana ponad 3 lata temu. Dodatkowo na stronie wtyczki pojawia się wielki banner:

Jak widać – sam WordPress informuje, że wtyczka może być porzucona i nie wspierana. Twórca wtyczki nawet pewnie nie ukrywa faktu, że ta została porzucona. Mimo to nie została ona usunięta z bazy wtyczek, dodatkowo jest instalowana przez właścicieli wielu aplikacji – a to jedna z wielu dróg możliwego zainfekowania. Jak widać na powyższym przykładzie, by zabezpieczyć WordPress, nie wystarczy jedynie bieżąca aktualizacja. Istotny jest również rozważny dobór wtyczek.

Ok, pilnujemy wtyczek – o czym jeszcze musimy pamiętać?

Automatyczne aktualizacje

Zalecam zautomatyzować wszystko. Na początek może uruchomimy aktualizacje samego WordPress’a? Jest to bardzo proste, gdyż wystarczy w pliku wp-config.php dodać wpis:

 define( ‚WP_AUTO_UPDATE_CORE’, true ); 

Można go dodać praktycznie w każdym miejscu, więc nie powinno to sprawiać problemu. Od teraz aktualizacje WordPress będą prowadzone automatycznie. Jedna czynność została już zautomatyzowana. Teraz zajmijmy się aktualizacjami wtyczek, stylów oraz tłumaczeń.

W folderze wp-content/mu-plugins/ tworzymy plik (może się nazywać np.: aktualizacja.php) i wrzucamy tam następujący wpis:

<?php
add_filter(‚auto_update_plugin’, ‚__return_true’ );
add_filter(‚auto_update_theme’, ‚__return_true’ );
add_filter(‚auto_update_translation’, ‚__return_true’ );

MU Plugins pozwala dodać funkcjonalności, które zawsze muszą zostać wywołane i są niezależne od stylu lub wtyczki. Od momentu dodania tego pliku, wszystkie dodatki będą aktualizowane automatycznie i nie trzeba pilnować, by te aktualizacje były wykonywane. Ważnym też jest, by usuwać wtyczki, których nie wykorzystujemy. Pomimo ich “wyłączenia” w panelu strony, w formie kodu są dalej obecne i dalej mogą stanowić niebezpieczeństwo dla naszej strony WWW.

Dodatkowo ukryjmy wersję WordPress’a. Nawet jeśli z jakiegoś powodu aktualizacja nie zostanie wykonana, atakujący nie będzie do końca tego świadom.

Zabezpieczenie na wypadek awarii na serwerze

Mamy już automatyczne aktualizacje. Czy to oznacza, że nie musimy się już niczym martwić? Nic bardziej mylnego. Jest jeszcze wiele innych miejsc, gdzie może dojść do infekcji lub wycieku danych, np. w trakcie awarii. W sytuacji, gdy pojawi się awaria interpretera PHP, pliki mogą nie być wykonywane, a zwyczajnie wyświetlone. W takiej sytuacji każdy będzie miał dostęp do kodu strony z dowolnej przeglądarki.

Dane logowania do bazy

To groźna sytuacja, choć jeszcze nie tragiczna. WordPress jak i wtyczki/style w repozytorium są dostępne dla każdego, więc w praktyce kod strony jest powszechnie znany. Jednak cenniejszym od samego kodu strony jest jej baza. Dane logowania do bazy w takiej sytuacji również mogą być dostępne dla każdego. Wtedy może dojść do wycieku, a wtedy… hasła, loginy, e-mail’e, dane klientów, koszyk, listy artykułów – wszystko będzie dostępne dla każdego.

Konieczne jest zabezpieczenie dostęp do pliku, gdzie przechowywane są wrażliwe dane dostępowe. Takim plikiem jest wp-config.php, który zawiera konfigurację WordPress’a. Dobrym rozwiązaniem będzie dodanie do pliku .htaccess wpisu:

<Files .htaccess wp-config.php>
order allow,deny
deny from all
</Files>

Powyższy wpis pozwoli na uniemożliwienie dostępu do pliku, nawet w razie awarii interpretera.

Wyłączanie edytora plików

Pilnowanie wtyczek, automatyczne aktualizacje i powoli nasza strona zaczyna być w zabezpieczona, jednak nie warto spoczywać na laurach i zadbać o dodatkowe elementy. Załóżmy hipotetyczną sytuację, że nasze hasło w jakiś sposób wyciekło i aktualnie ktoś ma dostęp do strony. W zakładce Wygląd > Edytor posiadamy interesującą funkcjonalność, która polega na możliwości edytowania stylu strony (łącznie z kodem) z poziomu samego WordPress’a. To bardzo przydatne narzędzie, ale tylko podczas tworzenia strony. Na tzw. produkcji – tej funkcjonalności lepiej nie posiadać. Bezpieczniej zatem usunąć taką funkcję, tak aby ograniczyć możliwość manipulacji. W tym celu ponownie wracamy do pliku wp-config.php i dodajemy kolejny zapis (np.: pod naszym wpisem z aktualizacjami). Jest to prosty wpis: define(‚DISALLOW_FILE_EDIT’, true);

Od tego momentu edytor jest wyłączony, bez ingerencji w główny trzon aplikacji. Nawet jeśli w przyszłości trzeba będzie coś zmienić, można za pomocą FTP edytować pliki (tutaj zalecam nie korzystać z samego FTP, ale z sFTP jeśli dostępny lub ewentualnie FTPS – szyfrowaną wersję FTP) bądź przygotować automatyczną aktualizacje stylu.

Zabezpieczanie plików

Warto również pomyśleć o zabezpieczeniu innych plików, które nie są użyteczne dla standardowego użytkownika, a pozostają świetnym źródłem informacji dla ewentualnego włamywacza. Katalogi wp-includes i wp-admin/includes posiadają w sobie pliki, które warto zablokować, a robimy to za pomocą np.: poniższego wpisu w .htaccess:

<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>

Ochrona przed przesłanymi plikami

Kolejnym katalogiem gromadzącym pliki, które będzie można wykorzystać do zainfekowania naszej strony jest katalog, gdzie umieszczane są wszystkie przesłane pliki. Bardzo częstą praktyką jest posiadanie na stronie formularza. Niezależnie, czy jest to formularz zamówień, czy kontaktowy – możemy w nim umieścić możliwość wysyłki pliku. Może to być obrazek, może nawet jakiś dokument. Tylko, co się stanie, gdy ktoś wykorzysta formularz, w celu umieszczenia skryptu na serwerze? Niestety, źle zabezpieczone formularze dopuszczają do takich sytuacji. Nawet te potencjalnie chronione – potrafią posiadać jakąś podatność. Możemy kombinować z formularzem, dodawać kolejne zabezpieczenia, weryfikację zawartości, typu MIME, skanować jakimś antywirusem, wykonywać naprawdę sporo czynności. Jednak to wymaga czasu, środków i świadomości problemu. Nawet największe firmy z branży IT mają na swoim koncie wpadki, zatem jak się skutecznie chronić?

Blokada wykonywania plików PHP

WordPress jest aplikacją stworzoną w języku PHP i tak samo – po stronie serwera –  wykonywany jest kod, który ostatecznie wyświetla nam stronę. Skoro PHP jest uruchamiane, to możemy wysłać plik PHP, który również można uruchomić na serwerze. Może warto zablokować wykonywanie plików PHP po stronie serwera? Przynajmniej dla plików przesłanych przez formularz?

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

Powyższy kod zablokuje wykonywanie plików o rozszerzeniu *.php na serwerze i taki plik .htaccess należy dodać do katalogu wp-content/uploads/. Teraz nawet w przypadku przesłania pliku PHP na serwer, atakujący nie wykona kodu. Co prawda, samo przesłanie pliku nie jest zbytnio wyrafinowanym atakiem. Łatwo go wykryć i stosunkowo łatwo się przed nim zabezpieczyć. Większym wyzwaniem jest zabezpieczenie przed tzw. Code injection. Tutaj trzeba się bardziej pilnować, ale jest rada, która częściowo pozwala na zabezpieczenie strony. Polecam ponownie udać się do naszego głównego pliku .htaccess w głównym katalogu strony i do niego dodać poniższy wpis:

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]

Zabezpieczenie dostępu do panelu administracyjnego

Następne zabezpieczenie, to ochrona naszego panelu administracyjnego. Można sporo namieszać przez panel. Skoro i tak dostępu nie dajemy dla każdego, bo to nasz panel administracyjny – to po co go udostępniać na świat? Jest na to wiele sposobów, jednak dobrym pomysłem będzie zablokowanie dostępu tylko dla adresów IP z których my się łączymy. Jeśli mamy zmienne IP, zawsze możemy też dodać całą pulę adresową naszego dostawcy internetu. Przykładowy zapis:

<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>

Oczywiście, trzeba ten zapis dostosować pod siebie, więc zalecam tą opcję jedynie dla doświadczonych webmasterów.

Wtyczki zapewniające bezpieczeństwo

Na sam koniec zostawiam temat wtyczek “zapewniających” bezpieczeństwo. Popularne wtyczki, takie jak WordFence nie mogą zagwarantować 100% bezpieczeństwa. Przecież same są przykładem miejsca, gdzie można się włamać. W końcu im więcej dodatków, tym więcej możliwych dróg nieautoryzowanego dostania się do strony. Oczywiście – ich celem jest zwiększenie bezpieczeństwa – i często spełniają swoją rolę. Sam mogę polecić wtyczki takie jak Cerber, czy Sucuri. Jednak nie warto na nich polegać w 100%, jako vademecum na wszystkie problemy bezpieczeństwa.

Jednak udało się włamać, co teraz?

Nie wszystko da się przewidzieć i nie przed każdym zdarzeniem da się uchronić. Kopie bezpieczeństwa to kwestia priorytetowa. Kopia zapasowa ratuje nas, nie tylko przed konsekwencjami ewentualnej infekcji, ale również w przypadku problemów ze stroną.

Popularne powiedzenie mówi, że ludzie dzielą się na 3 grupy:

  • tacy, którzy robią kopie zapasowe,
  • co myślą, że robią kopie,
  • którzy zaczną robić kopie.

W przypadku infekcji, dzięki regularnym backupom łatwo możemy ją przywrócić do stanu sprzed ataku. Usuwamy wszystko i przywracamy z kopii. Kopie można wykonywać także samodzielnie. Własne kopie zapasowe będą dodatkowym wsparciem dla zabezpieczeń oferowanych przez firmy hostingowe.

Wspominając też o hostingach – większość z nich prowadzi kopie zapasowe, nawet 30 dni wstecz, tak jak w Linuxpl.com – dobry hosting zawsze dba też o bezpieczeństwo swoich klientów, co sporo upraszcza w temacie kopii, ale mimo wszystko – zalecam tworzyć własne kopie. Tygodniowe, miesięczne, kwartalne i trzymać w domowym zaciszu, a najlepiej na zewnętrznym, szyfrowanym dysku. Może i to czasem na wyrost, ale jednak – przezorny zawsze ubezpieczony.

Odpowiedz

Adres email nie będzie opublikowany.

*