Bezpieczeństwo

Bezpieczeństwo to bardzo ważna rzecz, jednak jego głównym problemem jest to, że zaczynamy się nim interesować, dopiero kiedy jest już za późno na prewencję. Zazwyczaj przypominamy sobie o nim kiedy mamy już poważne kłopoty i bardzo dużo dodatkowej i niepotrzebnej roboty.

Tak było oczywiście i w moim wypadku… Niby robiłem wszystko zgodnie ze sztuką: częste aktualizacje, trudne hasła itp. itd. Jednak jak się okazało, czasem i to jest za mało, a ja mogłem zrobić zdecydowanie więcej.

W tekście zebrałem najczęstsze błędy i niedopatrzenia w zabezpieczeniach skutkujące wrogim przejęciem strony oraz sposoby, jak się przed tym zabezpieczyć.

Wprowadzenie, czyli coś poszło nie tak

Niczego nie podejrzewając, najspokojniej w świecie pisałem sobie kolejny artykuł w administracji WordPress. Po pewnym czasie, gdy chciałem podejrzeć swoje zmiany, przestał mi działać przycisk podglądu i wyskoczył jakiś błąd w Java Script. Zbagatelizowałem problem, myśląc: błąd jak błąd, przy skrypcie WordPressa przecież też pracują normalni developerzy, każdemu może się zdarzyć. Zapisałem projekt z przeświadczeniem, że samo przyszło, samo przejdzie i skończyłem pracę.

Na moje szczęście zainstalowałem wcześniej wtyczkę Wordfence Security i po kilku godzinach przyszedł do mnie mail o groźnym tytule: [Wordfence Alert] Problems found on stormit.pl.

Wtedy nie miałem już najmniejszych wątpliwości co się stało, lektura maila tylko to potwierdziła. Wordfence wykrył zmiany w prawie 800 plikach php!

Tego było już za wiele, czas zacząć działać!

Jak rozpoznać atak, czyli jego najczęstsze objawy

Skoro już wiedziałem, że doszło do włamania, musiałem oszacować straty. Zacząłem od sprawdzenia najczęstszych objawów tego typu ataków.

Modyfikacja plików

Tu sprawdziła się świetnie wspomniana już wcześniej wtyczka Wordfence. Plugin tworzy raport bezpieczeństwa, w którym między innymi porównuje zawartość plików na serwerze z ich pierwotnymi wersjami z głównego repozytorium. Pliki porównywane są dla kodu samego WordPressa, ale również dla zainstalowanych wtyczek. Ponieważ miałem już gotową listę zmienionych plików, sprawdziłem tylko wyrywkowo kilka z nich, szukając zmian.

Wszystkie zmodyfikowane pliki zawierały ten sam fragment kodu PHP, dodany na samym początku skryptu.

Zmieniona baza danych

Złośliwy kod często modyfikuje wpisy w bazie danych, potrafi również wygenerować nowe tabele dla swojego działania. Dlatego zawsze warto zweryfikować, czy w bazie nie pojawiło się coś, co przyciągnie naszą uwagę: dodatkowe tabele, nowe linki wychodzące w treści postów itp.

W moim przypadku, całe szczęście, nie było takich zmian. Jednak gdyby się pojawiły, trzeba by usunąć wszystkie zmodyfikowane dane lub przywrócić cały backup bazy danych.

Dodatkowe zaindeksowane strony w Google

Ataki przeprowadzane są najczęściej w bardzo konkretnym celu. Zazwyczaj jest to wyłudzenie danych lub bardziej przyziemny powód, czyli automatyczne zdobycie linków pozycjonujących z zainfekowanych stron.

Dlatego tego typu kod może generować automatycznie nowe podstrony w naszym serwisie. Żeby taki link miał sens, musi być zaindeksowany przez roboty Google. Większość zaindeksowanych stron danej domeny możemy sprawdzić, korzystać z Google Search Console lub wpisując w wyszukiwarce komendę:

site:stormit.pl

W tym wypadku dla większych stron, jeżeli wiemy, że do ataku doszło niedawno, warto ograniczyć zakres czasu dla zaindeksowanych podstron przez menu: Narzędzia i zmianę opcji z Kiedykolwiek na mniejszy zakres.

Przeglądając nowe zaindeksowane strony, szukamy wszystkiego, co może być podejrzane, jednak przede wszystkim treści w stylu: viagra, chwilówki, sex itp.

No, chyba że sami się pozycjonujemy na te słowa, to wtedy wszystko jest OK 😉

Cloaking

Czasami, żeby tego typu atak było jeszcze trudniej zauważyć, stosuje się technikę Cloackingu – czyli wyświetlania różnych treści w zależności od tego, kto daną stronę ogląda. Może to doprowadzić do tego, że przeglądając kod naszej strony, nie widzimy nic podejrzanego, a Google indeksuje spreparowane treści.

Decyzję o tym, jakie treści w danym momencie mają być serwowane, podejmuje się na podstawie nagłówka HTTP User-Agent. Każda przeglądarka oraz boty sieciowe same wysyłają ten nagłówek, niejako przedstawiając się, jednak można go zmodyfikować np. z poziomu przeglądarki korzystać z wtyczki do Google Chrome User-Agent Switcher for Chrome.

Linki wychodzące

Ponieważ zmodyfikowane treści nie muszą być jeszcze zaindeksowane w Google, trzeba dodatkowo przejrzeć źródło naszej strony, szukając przede wszystkim wszystkich wychodzących linków.

Czas posprzątać ten bajzel, czyli czyszczenie środowiska po włamaniu

Mleko się już rozlało, atak był i to skuteczny. Najwyższy czas zabrać się za sprzątanie tego bałaganu.

Tak naprawdę w procesie sprzątania możemy wyróżnić dwa główne podejścia:

1. Wyszukanie wszystkich zainfekowanych plików i usunięcie złośliwego kodu
2. Instalacja czystego systemu i delikatne przeniesienie tylko niezbędnych i sprawdzonych rzeczy z backupu

Ja zdecydowałem się na drugą opcję, ponieważ wydała mi się pewniejsza i przy okazji miałem szansę dokładnie zweryfikować, co siedzi w tym systemie.

Przebieg czyszczenia zainfekowanego systemu

1. Przygotowanie backupu

Wszelkie prace zaczynamy zawsze od zrobienia backupu bazy danych oraz wszystkich plików. To ogólna i bezpieczna zasada dotycząca nie tylko tej sytuacji.

2. Instalacja czystego WordPressa

Wgrywamy najnowsze pliki i rozpoczynamy instalację, analogicznie jak robiliśmy to przy pierwszej instalacji systemu. W ustawieniach bazy danych podajemy tę samą bazę, na której wcześniej pracował skrypt.

Po tym kroku mamy zainstalowany czysty skrypt WordPress, jednak jeszcze wiele rzeczy nie będzie działało. Przede wszystkim brakuje wtyczek i szablonów, dlatego w administracji pojawią się stosowne ostrzeżenia o tym fakcie.

3. Instalacja wszystkich niezbędnych wtyczek oraz szablonów

Najprawdopodobniej pliki szablonu i wtyczek też zawierają złośliwy kod, dlatego nie wolno ich zwyczajnie przekopiować!

Zaczynamy od instalacji wtyczek. Na podstawie backupu plików, który wcześniej zrobiliśmy, przygotowujemy listę wtyczek, które były pierwotnie zainstalowane. Ich pełną listę znajdziemy w katalogu: wp-content/plugins/. W tym miejscu warto się dobrze zastanowić, czy na pewno wszystkie dotychczasowe pluginy są nam potrzebne. Jest bowiem spore prawdopodobieństwo, że do włamania doszło przez jedną z nich. Wybieramy tylko niezbędne wtyczki i instalujemy ich najnowsze, czyste wersje z repozytorium: Kokpit -> Wtyczki -> Dodaj nową.

Podobnie sprawa ma się, jeżeli chodzi o szablon. Jeżeli szablon był dostarczony przez zewnętrznego dostawcę, warto zweryfikować czy nie ma jego nowszej wersji. Wystarczy, że przegramy czyste pliki skórki do katalogu: wp-content/themes/. Warto również zweryfikować, czy nie ma tam niepotrzebnych i nieużywanych innych szablonów

4. Przeniesienie statycznych plików

Nasza strona zaczyna już powoli działać, brakuje jej jednak jeszcze zdjęć, które zostały dodane przez administrację. Przenosimy je z backupu z katalogu: wp-content/uploads/. Tu też należy zweryfikować, czy znajdują się tam tylko statyczne pliki, jak obrazki.

5. Zmiana wszystkich haseł

Strona już działa, jednak konieczna jest oczywiście zmiana wszystkich haseł w systemie. Mowa tu przede wszystkim o koncie do administracji i bazy danych, warto również zmienić hasło do serwera FTP.

Jak zabezpieczyć się przed atakami na przyszłość

Strona jest już oczyszczona z wszelkich śmieci, jednak jej poziom zabezpieczeń jest taki sam, jak przed atakiem. Jeżeli nic nie zrobimy, problem powróci- to tylko kwestia czasu. Trzeba wprowadzić dodatkowe zabezpieczenia.

To niestety również wiem z własnego doświadczenia. Wyczyściłem wszystkie skrypty, jednak zanim udało mi się wprowadzić wszystkie omawiane tu zabezpieczenia, wszystkie pliki na serwerze były już zainfekowane na nowo…

Rezygnacja z niepotrzebnych rzeczy

Nie ma sensu utrzymywać rzeczy, z których nie korzystamy, tyczy to się przede wszystkim:

• szablonów
• wtyczek
• kont użytkowników

Nieużywane lub mało popularne wtyczki i szablony są zazwyczaj nieaktualizowane, czy to przez nas, czy nawet przez ich autorów. Dlatego dobrze jest ograniczyć się tylko do rozszerzeń bardziej popularnych oraz często aktualizowanych.

WordPress instaluje domyślne skórki, z nich też można zrezygnować i je wywalić.

Zabezpieczenie dostępu do administracji

Zazwyczaj łączymy się do administracji z kilku określonych lokalizacji, takich jak dom, czy praca. Jeżeli mamy stałe IP to najlepszym wyjściem jest odcięcie możliwości logowania się dla wszystkich innych. Ja zrobiłem to przez odpowiedni wpis w pliku: wp-admin/.htaccess:

order deny,allow
deny from all
allow from xx.xx.xx.xxx
allow from xx.xx.xx.xxx

Podmieniamy tylko swoje IP. To, pod jakim numerem IP jesteśmy widoczni w sieci, można np. sprawdzić w serwisie ip.wp.pl.

Dzięki temu zabiegowi tylko my powinniśmy mieć dostęp do administracji, natomiast jeżeli zajdzie taka potrzeba, zawsze można dodać kolejne wpisy, korzystając ze swojego konta FTP do edycji pliku .htaccess.

Automatyczne aktualizacje

Od wersji 3.7 WordPress domyślnie przeprowadza mniejsze aktualizacja automatycznie, np. z wersji 4.6.1 do 4.6.2. Tego typu aktualizacje zazwyczaj dotyczą bezpieczeństwa i nie powinny powodować np. kłopotów z kompatybilnością z wtyczkami.

Jednak większe aktualizacje np. z wersji 4.6 do 4.7 domyślnie wymagają ręcznej ingerencji. Tego typu aktualizacje potencjalnie mogą już spowodować konflikt z zainstalowanymi wtyczkami, jednak prawdopodobieństwo jego wystąpienia jest stosunkowo małe i ze względów bezpieczeństwa zdecydowałem, żeby te aktualizacje też były przeprowadzane automatycznie.

To, jakie aktualizacje mają odbywać się automatycznie, a jakie nie, można skonfigurować przy pomocy wtyczki: Update Control. Ja jednak wolałem zrobić to ręcznie, ponieważ, jak zaznaczyłem wcześniej, wolę minimalizować ilość zainstalowanych wtyczek.

W tym celu do pliku wp-config.php dodajemy poniższy wpis:

define(’WP_AUTO_UPDATE_CORE’, true );

Podobnie sprawa ma się, jeżeli chodzi o aktualizację pluginów i skórek. Tym razem jednak trzeba dodać stosowny wpis w pliku wp-content/themes/[nazwa szablonu]/functions.php

add_filter( 'auto_update_plugin’, '__return_true’ );
add_filter( 'auto_update_theme’, '__return_true’ );

Więcej na ten temat można przeczytać w oficjalnej dokumentacji: Configuring Automatic Background Updates.

Zadbaj o dobre sąsiedztwo

To również niezwykle ważna rzecz, a niestety często o niej zapominamy. Tak było oczywiście i w moim przypadku. Najprawdopodobniej właśnie ten błąd przepłaciłem wspomnianym wcześniej atakiem.

To, że my zabezpieczymy nasz skrypt na wszelkie możliwe sposoby, a nie zadbamy o inne rzeczy znajdujące się na tym samym serwerze, porównałbym do montowania najnowszych drzwi antywłamaniowych w mieszkaniu i jednoczesne zostawienie starego drewnianego okienka w piwnicy. Nasz system zabezpieczeń jest tak dobry, jak najsłabszy jego punkt.

Idealnym wyjściem byłoby trzymanie każdej aplikacji na osobnych serwerach, jednak jak wiemy, ze względów głównie ekonomicznych, robi się tak tylko przy większych projektach.

Jeżeli mamy do dyspozycji serwer dedykowany lub VPS zalecałbym stworzenie dla każdego projektu osobnego użytkownika, o możliwie najmniejszych uprawnieniach. Dzięki temu, jeżeli jeden serwis ucierpi, to jest duża szansa, że pozostałe nie oberwą rykoszetem.

Trochę gorsza sytuacja jest, jeżeli dysponujemy tylko hostingiem współdzielonym. Tutaj zalecałbym daleko posuniętą ostrożność. Co prawda nie mamy wpływu na to, jakie inne systemy będą z nami współdzieliły fizyczną maszynę, ale przynajmniej sami nie trzymajmy starych śmieci na takim serwerze. Jeżeli mamy kilka serwisów, a na jednym zależy nam bardziej, to warto je rozdzielić ze względów bezpieczeństwa, a nie dlatego że wykorzystaliśmy już wszystkie przydzielone zasoby. Nie jest to duży koszt, bo zazwyczaj takie serwery można dostać już za kilkadziesiąt złotych rocznie, a zwiększa to nasz poziom bezpieczeństwa.

Zablokowanie edycji kodu źródłowego z poziomu panelu administracyjnego

Bardzo kusząca i wygodna opcja, ale… niezbyt bezpieczna, zwłaszcza jeżeli z administracji korzysta więcej osób. Zalecałbym wyłączenie takiej możliwości, a jeżeli zajdzie potrzeba edycji plików, to skorzystanie z bezpośredniej edycji na serwerze przez SSH lub FTP.

Możemy to wyłączyć przez nowy wpis w pliku wp-config.php:

define(’DISALLOW_FILE_EDIT’, true );

Ukrycie informacji o błędach

Informacje o błędach z poziomu skryptu PHP są bardzo pomocne, szczególnie na środowisku developerskim, ale pokazywanie ich już na produkcji nie dość, że wygląda bardzo mało profesjonalnie, to jest to zwyczajnie proszenie się o kłopoty. Takie komunikaty bardzo często wykorzystywane są przez atakujących do poznania szczegółów na temat skryptu, do którego chcą się włamać.

Idealną opcją byłoby przechwycenie takich błędów, zapisanie ich do logu, a użytkownikowi wyświetlenie odpowiednio sformatowanego komunikatu o chwilowych problemach na serwerze. Jednak w wersji minimalistycznej wystarczy ukrycie tych błędów, użytkownik natomiast zobaczy w takim wypadku tylko białą stronę.

Błędy ukrywamy przez dodanie poniższego kodu w pliku wp-config.php:

error_reporting(0);
@ini_set(’display_errors’, 0);

Hasła są jak bielizna

Hasła są jak bielizna – to bardzo popularny slogan, który pokazuje dość dosadnie, jak powinno podchodzić się do zmiany haseł. Może niekoniecznie trzeba je zmieniać codziennie, ale jednak dobrym zwyczajem jest ich zmiana raz na pewien czas oraz nieużywanie tego samego hasła w kilku miejscach.

Jeżeli mamy więcej użytkowników, może też okazać się przydatne wymuszenie odpowiedniego poziomu skomplikowania hasła, np. przy pomocy wtyczki: Force Strong Passwords.

Standardowa nazwa użytkownika

Domyślne nazwy użytkownika, w stylu: admin, root itp. są oczywiście jako pierwsze wpisywane przy próbie złamania zabezpieczeń, dlatego warto wysilić się minimalnie i zmienić domyślny login.

Ukrycie informacji o WordPress

Ukrycie wszystkich informacji na temat tego, że strona została wygenerowana przy pomocy skryptu WordPress, jest praktycznie niemożliwe. Pozbycie się jednak przynajmniej podstawowych rzeczy wskazujących na to, z jaką wersją skryptu mamy do czynienia spowoduje, że znaczna część ataków przeprowadzanych automatycznie ominie naszą stronę.

Dwie podstawowe rzeczy to usunięcie pliku readme.html oraz meta tagu generator.

Plik readme.html jest dodawany automatycznie po aktualizacjach, dlatego trzeba go usuwać za każdym razem lub skorzystać z mechanizmów robiących to automatycznie. Można to zrobić przy pomocy wtyczki: Readme Detonator lub zwyczajnie dodać kolejny wpis blokujący w pliku .htaccess:

<FilesMatch „^(readme.html)$”>
order allow,deny
deny from all
</FilesMatch>

Przykładowy meta tag generator wygląda w ten sposób:

<meta name=”generator” content=”WordPress x.x.x” />

Usuwamy go przez dodanie poniższego wpisu w pliku wp-content/themes/[nazwa szablonu]/functions.php:

<?php remove_action(’wp_head’, 'wp_generator’); ?>

Wyłączenie XML-RPC

XML-RPC to prosty protokół XML wykorzystywany do zdalnego wywoływania metod. W WordPress Xml-RPC wykorzystywany jest między innymi do zdalnego dodawania lub edycji postów!

Oczywiście, jeżeli nie chcemy korzystać z tej możliwości, powinniśmy ją zablokować. Więcej o samym API można przeczytać w oficjalnej dokumentacji: XML-RPC Support.

W celu zablokowania dostępu do API dodajemy poniższą komendę do pliku: wp-content/themes/[nazwa szablonu]/functions.php

add_filter( 'xmlrpc_enabled’, '__return_false’ );

lub blokujemy dostęp do pliku przy pomocy pliku .htaccess:

<FilesMatch „^(xmlrpc.php|readme.html|wp-config.php)$”>
order allow,deny
deny from all
</FilesMatch>

Listowanie zawartości katalogu

Wpisując nazwę katalogu w przeglądarce, np. stormit.pl/wp-content/plugins niektóre hostingi pozwalają na wyświetlenie wszystkich plików znajdujących się w tym katalogu. Można w ten sposób uzyskać np. informacje o zainstalowanych wtyczkach, pluginach, czy innych plikach, których obecności nie chcielibyśmy ujawniać.

Możemy to zablokować, np. dodając w takim katalogu pusty plik index.php lub index.html, wtedy przeglądarka wyświetli ten plik, a nie listę wszystkich plików z tego katalogu. Jednak to rozwiązanie działa tylko na jednym wybranym katalogu. Żeby zablokować listowanie plików bardziej globalnie, można dodać do pliku .htaccess poniższy wpis:

Options -Indexes

Uprawnienia do plików

Ze względów bezpieczeństwa zaleca się również modyfikację uprawnień plików na serwerze na następujące:

• katalogi: 755, czyli właściciel posiada prawa do odczytu, zapisu i wykonywania, grupa oraz wszyscy pozostali mają uprawnienia do odczytu i wykonania;
• pliki: 644, czyli właściciel posiada prawa do odczytu i zapisu, grupa oraz wszyscy pozostali tylko do odczytu;
• plik wp-config: 640, czy właściciel posiada prawa do odczytu i zapisu, grupa tylko do odczytu, a wszyscy pozostali nie mają uprawnień do tego pliku;

Poniższymi poleceniami można nadać takie uprawnienia:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 640 wp-config.php

Wyłączenie możliwości rejestracji użytkowników

Jeżeli nie potrzebujemy rejestracji na stronie, to powinniśmy ją wyłączyć. Można to zrobić przez Ustawienia -> Ogólne ->Członkostwo -> Każdy może się zarejestrować.

Ograniczenie ilości nieudanych prób logowania

Przed atakami siłowymi (brute force) warto się zabezpieczyć przez ograniczenie ilości prób logowania się do systemu. Ataki tego typu polegają na wielokrotnych próbach logowania się przy pomocy losowych loginów i haseł lub korzystając z przygotowanej wcześniej bazy najczęściej występujących kombinacji.

Zablokowanie możliwości logowania się np. po 5 nieudanych próbach na 15 minut skutecznie ogranicza możliwości takich ataków. Taki efekt możemy osiągnąć przy pomocy wtyczki: Limit Login Attempts lub Wordfence Security.

Wtyczki pilnujące zabezpieczeń

Znaczną część ręcznej roboty przy zabezpieczeniach można zautomatyzować, korzystając z gotowych wtyczek. Ja bliżej przyjrzałem się dwóm z nich: Wordfence oraz iThemes Security.

Wordfence Security

Wordfence – to wtyczka, która nie bez powodu cieszy się bardzo dużym zainteresowaniem oraz wysokimi ocenami użytkowników WordPressa.

Plugin dostępny jest w dwóch wersjach: darmowej oraz płatnej. Wersja płatna zawiera kilka dodatkowych funkcjonalności oraz wsparcie ze strony producenta wtyczki, jednak jej darmowy odpowiednik powinien być wystarczający dla większości stron.

Wybrane funkcjonalności Wordfence Security

• porównywanie wersji plików – skanowaniu podlegają pliki samego WordPress, wtyczek oraz motywów. Porównywane są one automatycznie z dostępnymi wersjami w oficjalnym repozytorium. Dzięki temu można bardzo szybko wykryć ataki polegające na modyfikacji plików.
• skanowanie plików – przeszukiwanie zawartości plików pod kątem wszystkich znanych zagrożeń
• skanowanie adresów URL – wtyczka weryfikuje np. adresy url w komentarzach, porównując je z bazą niebezpiecznych adresów wykorzystujących phishing lub malware.
• limitowanie prób logowania – blokowany jest dostęp do strony dla danego adresu IP po określonej liczbie nieudanych logowań.
• ochrona online przed znanymi atakami – flagowa funkcjonalność Wordfence Security, polegająca na współdzieleniu między użytkownikami pluginu bazy informacji o znanych atakach oraz ich sprawcach. Dzięki temu, po wykryciu ataku przez jedną ze stron, automatycznie wszystkie inne również blokują napastnika.
• FireWall – pozwalający na blokowanie złośliwych robotów oraz automatów generujących sztuczny ruch. Istnieje również możliwość ręcznego blokowania konkretnych adresów IP i ich klas.

iThemes Security

iThemes Security to kolejna bardzo popularna i ceniona wtyczka zwiększająca bezpieczeństwo. Część jej funkcjonalności pokrywa się z Wordfence Security, jednak ta zawiera również kilka ciekawych dodatków.

Wybrane funkcjonalności iThemes Security

• blokowanie użytkowników generujących błędy 404 – częste występowanie błędów typu HTTP 404, czyli brak strony, może świadczyć o błędzie w systemie, ale również o próbie ataku, polegającego na przeszukiwaniu serwera w celu znalezienia ukrytych plików.
• czasowa blokada administracji – możemy zablokować dostęp do administracji w określonych godzinach, kiedy mamy pewność, że nie będziemy z niej korzystać, np. w nocy.
• banowanie użytkowników – blokowanie dostępu do systemu użytkownikom na podstawie ich adresu IP lub nagłówka User Agent.
• zabezpieczenie przed Brute Force lokalne oraz globalne – wspomniane już wcześniej ograniczenie błędnych prób logowania do systemu. Wtyczka umożliwia ochronę lokalnie oraz daje możliwość współdzielenia informacji o IP, z którego doszło do ataku z pozostałymi stronami korzystającymi z wtyczki. Dzięki czemu atakujący zostanie zablokowany globalnie na wielu stronach.
• backup bazy danych – możliwość cyklicznego i w pełni automatycznego robienia backupów bazy danych i kopiowania ich na serwer oraz wysyłania na wskazany adres email.
• wykrywanie modyfikacji plików – cykliczne lub na żądanie szukanie zmodyfikowanych plików, z możliwością wysłania raportu na maila.
• wymuszenie silnego hasła – można wymusić korzystanie z bardziej skomplikowanych haseł przez użytkowników administracji.
• zablokowanie możliwości edycji plików z poziomu administracji
• wyłączenie XML-RPC

WPScan

WpScan to ciekawy projekt umożliwiający przeprowadzenie symulowanego ataku na naszą stronę opartą o WordPress. Skaner wykorzystuje metodę black-box, czyli przeprowadza atak z zewnątrz, bez znajomości kodu. Skrypt stara się wyciągnąć możliwie jak najwięcej informacji o naszej stronie.

Przy jego pomocy można między innymi wyciągnąć informacje o:

• liście zainstalowanych pluginów i ich wersji;
• dostępnych skórkach i ich wersji;
• nazwach użytkowników;
• serwerze www;
• zainstalowanej wersji PHP;

To, ile informacji uda się w ten sposób wyciągnąć, zależy od tego, jak dobrze zabezpieczyliśmy nasz system.

Zachęcam do przetestowania swojej strony pod tym kątem. Daje to bardzo dobry obraz tego, w jaki sposób mogą być przeprowadzane automatyczne ataki i jak dużo informacji udostępniamy o swoim blogu.

Jak unikać zagrożeń

Nawet mając dobrze zabezpieczony system, możemy paść ofiarą ataku, jeżeli nie będziemy przestrzegać kilku podstawowych reguł bezpieczeństwa.

Regularne kopie zapasowe

Proces tworzenia kopii zapasowych najlepiej zautomatyzować, tak by nie musieć już o tym pamiętać. W zależności od częstotliwości zmian na stronie powinno to się odbywać najlepiej codziennie lub co najmniej raz w tygodniu. Automatyczne kopie można skonfigurować przy pomocy wtyczki: iThemes Security lub pisząc własny skrypt odpalany przez crona.

Dobrze by było, gdyby tego typu kopie zawierały całą bazę danych (ewentualnie z pominięciem kilku tabel zawierających generowane rzeczy) oraz pliki dodawane do repozytorium, czyli domyślnie katalog: wp-content/uploads/.

Instalacja rozszerzeń oraz szablonów tylko z zaufanych źródeł

Często w Internecie można znaleźć płatne pluginy lub skórki udostępniane za darmo. Prawda jest taka, że 99% z nich zawiera już złośliwy kod i udostępniane są zdecydowanie nie bezinteresownie.

Monitorowanie

Niestety trzeba pogodzić się z tym, że nawet najlepsze systemy zabezpieczeń czasem zawodzą. Dlatego właśnie wykonujemy kopie bezpieczeństwa, ale również trzeba na bieżąco monitorować, co się dzieje w naszym systemie. Tylko dzięki temu mamy możliwość reagować, jeżeli już dojdzie do przełamania zabezpieczeń.

Monitorowanie dostępności: Zabbix

Stronę warto podpiąć do narzędzi monitorujących jej dostępność, np. do systemu Zabbix. Dzięki czemu zostaniemy poinformowani o jej niedostępności, co może świadczyć o ataku na nią lub zwyczajnie o problemach z serwerem.

Monitorowanie zaindeksowanych podstron: Google Search Console

Google Search Console również może dostarczyć ciekawych informacji na temat niebezpiecznych zaindeksowanych podstron. Google zależy, żeby strony do których kieruje z wyników wyszukiwania, nie były niebezpieczne dla użytkownika, dlatego monitoruje je pod kątem różnych zagrożeń.

Podsumowanie i wnioski

Decydując się na utrzymywaniu strony na skrypcie tak popularnym, jak WordPress, trzeba liczyć się z faktem, że zabezpieczyć jej łatwo nie będzie. Z racji swojej popularności oraz otwartego kodu jest to jeden z częściej atakowanych systemów.

Wpis przedstawia całą masę zabezpieczeń, które można lub nawet powinno się wprowadzić na swojej stronie. Jednak sama znajomość mechanizmów nie zabezpieczy naszej strony. Warto cyklicznie sprawdzać, czy wszystkie nasze zabezpieczenia działają oraz czy nie dzieje się nic złego w naszym systemie.

Cały czas należy również pamiętać, że o sile wprowadzonych przez nas zabezpieczeń stanowi ich najsłabszy punkt. Tym najsłabszym punktem najczęściej jest sam użytkownik, dlatego zdrowy rozsądek przede wszystkim.

Ze swojej strony życzę powodzenia i wytrwałości we wprowadzaniu zabezpieczeń, bo crackerzy i spamerzy nie śpią 🙂