Budowanie listy stron
Jeśli prowadzisz blog na WordPressie lub cokolwiek innego na tej popularnej platformie, jesteś narażony na ataki (zresztą nie tylko na niej – każde popularne rozwiązanie kusi spamerów, czy innych „niecnych” ludzi do ataków). Istnieje wiele botów, których celem jest zbieranie stron zbudowanych na danym silniku. Są to tzw. harvestery – przeszukują sieć i gdy natrafią na stronę opartą na np. WordPressie, dodają adres do swojej bazy danych. Przeszukiwań dokonują w różny sposób, najczęściej odpytują Google preparując zapytania, by w wynikach otrzymać jak najwięcej adresów stron zbudowanych na danym silniku. W zapytaniach używają najczęściej tzw. footprintów, czyli swoistych „odcisków palców” (unikalne części w kodzie strony) charakteryzujących dany silnik. Np. dla WordPressa może to być fraza „Powered by WordPress” (wpisz w Google, wraz z cudzysłowem, dla dokładnego dopasowania). To jest oczywiście najprostszy przykład, takich footprintów tworzy się więcej, z reguły bardziej skomplikowanych, wykorzystujących zaawansowane metody wyszukiwania Google. Oczywiście listy stron nikt (chyba?) nie buduje ręcznie, korzysta się w tym celu z dedykowanych aplikacji (np. popularny ScrapeBox), czasem też ze skryptów zamieszczanych na serwerach.
Boty spamujące
Z takiej bazy danych mogą korzystać inne narzędzia, np. boty spamujące, których celem jest (z reguły) zalewanie czego się linkami do pozycjonowanych stron (dobrze jeśli są to tylko strony zapleczowe niskiej jakości, gorzej jeśli linkują do zainfekowanych serwisów). Ich metody ataku, jak i możliwości są różne, w zależności od tego, jak są zbudowane. Z reguły wszystkie wyszukują znanych, charakterystycznych słabych punktów: znanych bugów w popularnych CMS’ach, przestarzałych (dziurawych) wtyczek, formularzy, przez które można przesłać jakieś treści. Najprostsze boty atakują formularze kontaktowe, czy formularze służące do zamieszczania komentarzy. Jeśli bot jest w stanie zidentyfikować na jakim silniku zbudowana jest Twoja strona, to dopasuje do niego swój wektor ataku. Jeśli np. wykryje możliwość zakładania profili użytkowników na blogu, może próbować utworzyć fikcyjne profile, by zamieszczać komentarze, bądź zakładać tematy na forach. Ba, istnieją narzędzia (np. potężny rosyjski soft XRumer, na którym miałem kiedyś przyjemność pracować), które potrafią nawet prowadzić dyskusje na forach między takimi profilami, po to, aby wątek na forum był bardziej widoczny.
Popularne rodzaje ataków na blogi
Oprócz wspomnianych botów spamujących (tudzież aplikacji do tego służących), strony z wspomnianej bazy atakowane mogą być przez osoby próbujące wstrzyknąć złośliwy kod (malware) na stronę. Jest to znacznie groźniejsze działanie, gdyż o ile spam tworzony przez boty można w jakimś stopniu ograniczyć (usuwając słabe punkty), o tyle stronę zaatakowaną przez malware trzeba postawić na nowo (oczywiście z zachowanego backupu sprzed momentu zainfekowania), co wiąże się czasem z utratą części danych, a następnie wykryciem źródła ataku i zabezpieczeniem się przed ponownym. Mając malware na stronie można spodziewać się wszystkiego, po licz się z tym, że ktoś ma pełną kontrolę nad kodem i bazą danych twojego serwisu. Może zamieszczać spam, tworzyć przekierowania do innych stron, zamieszczać kod próbujący po cichu zainfekować komputery osób odwiedzających Twój serwis.
W tym temacie można by pisać jeszcze wiele, możesz zagłębić temat przeszukując serwisy związane z bezpieczeństwem stron.
Zabezpiecz swojego WordPressa
Poniżej przedstawię listę czynności wraz z krótkimi opisami, które zwiększą bezpieczeństwo twojego bloga. Będę opierać się przy tym głównie na kodeksie WordPressa (Brute Force Attacks, oraz na własnych doświadczeniach. Co jakiś czas będę opisywał tutaj kolejne metody zabezpieczeń WordPressa, zatem zachęcam do odwiedzenia strony również w przyszłości.
Przejdź na skróty:
1. Zmiana domyślnego administratora
Narzędzia dokonujące prób włamania na konto administratora metodą siłową (brute-force) z reguły posiadają własne bazy popularnych loginów i haseł, od których zaczynają atak. Należy także wiedzieć, że każdy „utworzony” użytkownik posiada w bazie danych swój unikalny identyfikator (ID), o czym napiszę nieco dalej.
Co należy i można zrobić:
1) Używaj silnych haseł – Aby skutecznie utrudnić pracę takim programom, należy przede wszystkim stosować silne hasła. Myślę, że ta kwestia jest dla ciebie wystarczająco oczywista, dlatego nie będę się w tym temacie bardziej rozpisywał.
2) Zmień login – WordPress podczas standardowej instalacji tworzy konto użytkownika z uprawnieniami administratora, w którym jako login najczęściej występuje „administrator„, bądź „admin„. Dlaczego o tym wspominam? A dlatego, że programy dokonujące włamań na konto administratora, stosujące metodę siłową, zaczynają od domyślnych ustawień WordPressa. Czyli przeprowadzają próbę logowania na konto z identyfikatorem równym 1, jako login podają „admin”, „administrator”. Po próbie logowania na taki istniejący login otrzymuje się komunikat o błędnym haśle (no chyba, że za pierwszym razem uda się trafić właściwe hasło, co jest raczej mało prawdopodobne). Stąd już wiadomo, że wystarcz tylko „odgadnąć” hasło. Przy mniej skomplikowanych hasłach naprawdę nie trzeba długo czekać, aby taki program odszukał właściwą kombinację znaków użytych jako hasło. Aby takie programy miały znacznie utrudnione zadanie, koniecznie należy zmienić login na jakiś mniej oczywisty. Wówczas program próbując „wbić” się do panelu użytkownika, oprócz hasła musi znaleźć wpierw login zarejestrowanego użytkownika. Dlatego istotne jest, aby utworzony login, nie był tak oczywisty jak administrator, admin, szef, czy temu podobne. Najlepiej, aby nie był to typowy „słownikowy” wyraz. Dosyć prostym sposobem może być użycie jakiegoś wyrazu, który trochę zmodyfikujemy, np. lekko przekręcimy, dodamy na końcu jakąś liczbę, np. szefuncio99.
3) Identyfikator użytkownika – Kolejną kwestią jest sam identyfikator użytkownika. Nowo utworzony użytkownik otrzymuje swój identyfikator ID o wartości 1. Każdy kolejny utworzony profil użytkownika ma przypisany identyfikator większy o 1 od największej wartości identyfikatora (tzw. inkrementacja). Czyli kolejny utworzony profil użytkownika będzie posiadał swój identyfikator o wartości 2, następny 3, itd. Znajomość identyfikatora umożliwia poznanie loginu istniejącego użytkownika. Dlatego warto zmienić domyślny identyfikator na inną wartość. Nie polecam zmiany tej wartości bezpośrednio w bazie danych (ze względu na zależności między zapisanym identyfikatorem, a innymi elementami serwisu, takimi jak np. posty, komentarze, itp.). W prosty sposób można to zrobić poprzez utworzenie nowego profilu (co automatycznie skutkować będzie wygenerowaniem temu profilowi identyfikatora o wartości 2) z uprawnieniami administratora.
Wracając do tematu, po utworzeniu nowego profilu, logujemy się na niego, i usuwamy konto utworzone podczas instalacji WordPressa. WordPress grzecznie się zapyta, czy wszystkie utworzone artykuły przez usuwanego użytkownika, ma przypisać zalogowanemu, czy też je usunąć, czy zostawić jako anonimowe (z tego, co pamiętam). Polecam przypisać wszystkie treści zalogowanemu, „nowemu” użytkownikowi.
Dzięki opisanym czynnościom, programom próbującym włamać się w opisany sposób na konto, zajmie zbyt wiele czasu, aby zakończyło się to ich sukcesem.
2. Zabezpieczenie hasłem folderu administratora
Opisany powyżej sposób ataku, może spowodować kilka zagrożeń:
- Po sensownym czasie działania, program może zdobyć dane dostępu do profilu użytkownika.
- Wykonanie wielu prób logowania w krótkim czasie może obciążyć serwer, przez co strona będzie działać zauważalnie wolniej. Może to nawet skutkować czasowym zablokowaniem konta na danym hostingu (programy zabezpieczające serwer mogą uznać to za próbę ataku).
Dobrym rozwiązaniem jest założenie hasła na folder wp-admin. Wiązać się to będzie z tym, że każda próba odwołania się do folderu wp-admin będzie skutkować wyświetleniem okienka dialogowego, w którym należy podać login i hasło.
Będzie tu kilka rzeczy wymagających uwagi. Najprostszym sposobem jest utworzenie pliku .htaccess w folderze wp-admin według schematu:
AuthType Basic AuthGroupFile /dev/null AuthUserFile /home/yourdirectory/.htpasswds/public_html/wp-admin/passwd AuthName "Administratorzy" require valid-user
Podczas próby nieudanego logowania, serwer wyświetli tekstową informację o błędzie, o kodzie 404 lub 401:
ErrorDocument 401 default
Wygląda znacznie lepiej:
ErrorDocument 401 /strona_401.html
Plik strona_401.html należy utworzyć w folderze głównym domeny i wyedytować według potrzeb. Dzięki temu, dodatkowo zamaskujemy fakt, iż serwis oparty jest na WordPressie (oczywiście pozostaną inne ślady, świadczące o tym, iż używana przez nas platforma, to WordPress).
Powyższe rozwiązanie jest skuteczne, jednakże w przypadku używania AJAXa (np. przez wtyczki, czy funkcje motywu), pojawi się problem z prawidłowym działaniem strony (wtyczek). Należy pamiętać, że użycie AJAXa wywołuje plik wp-admin/admin-ajax.php. W prosty sposób ominiemy ten problem, zezwalając na dostęp do pliku admin-ajax.php. W tym celu dopisujemy w tym samym pliku .htaccess reguły:
Order allow,deny
Allow from all
Satisfy any
Nasz plik .htaccess, wyglądać powinie następująco:
AuthType Basic
AuthGroupFile /dev/null
AuthUserFile /home/yourdirectory/.htpasswds/public_html/wp-admin/passwd
AuthName "Administratorzy"
require valid-user
Order allow,deny
Allow from all
Satisfy any
Opisane tutaj czynności można także wykonać za pomocą odpowiednich pluginów, lecz wydaje mi się, że jest to na tyle prosta czynność, iż nie trzeba do tego zaprzęgać kolejnej wtyczki dodatkowo obciążającej stronę.
No niestety botów pełno, recaptcha to mus 🙂