Jak zhakierowałem antyweb.pl – czyli co zrobić by poprawić bezpieczeństwo WordPressa

Dla niezorientowanych – [1] antyweb.pl to popularny w niektórych kręgach blog o tematyce IT utrzymany w warstwie treści w mojej subiektywnej opinii trochę w klimacie bulwarówki „Fakt” i prowadzony przez Grzegorza Marczaka vel hazana. Bardzo często hazan w swojej blogowej twórczości jawi się jako swoisty guru sieci Web a także bezwzględny komentator internetowych wydarzeń (wielokrotnie łaja na łamach swojego bloga naszą-klasę, twittera czy nazwa.pl).

Niestety, rzeczywisty poziom jego wiedzy merytorycznej i profesjonalizmu został niedawno poddany krytyce przez nagłośnioną na wykop.pl [2] sprawę problemów z serwerem, na którym stoi antyweb (pojawiły się opinie, że co to za spec, który nie potrafi zapewnić ciągłości działania swojego serwisu?). Okazuje się, że w kwestii zabezpieczeń antyweb.pl prezentuje się również nieciekawie.

Otóż – trochę poszperałem, trochę poczytałem i udało mi się zalogować do panelu administracyjnego antyweb.pl jako admin :) Jak to zrobiłem? Szczegółowy opis już niedługo w tym poscie wraz ze wskazówkami jak lepiej zabezpieczać blogi oparte o silnik WordPress. Na razie publikuję tylko screenshoty jakie zachowałem sobie na pamiątkę tuż po ataku, aby w przyszłości pochwalić się wnukom ;)

Moja aktywność superusera na antyweb.pl ograniczyła się do dodania gościnnego wpisu (prawda, że ładne kolory i zdjęcie?) i zmiany hasła admina.

Wiem, aktualizacja WP to ból. Zwłaszcza w przypadku, gdy nasza strona oparta jest o dużą liczbę wtyczek i modyfikacji plików źrodłowych WP (czego praktycznie nigdy nie powinno się robić). Wiadomo, że nie wszystkie z nich będą poprawnie działać z nowszą wersją.

Dobra wiadomość w tym względzie jest taka, że wraz z ostatnimi wersjami WP dostajemy do ręki wygodny mechanizm automatycznej aktualizacji zarówno samego WP jak i poszczególnych pluginów.

Jeżeli wolimy robić to ręcznie – okej – ale pluginy pobierajmy nie z prywatnych stron ich autorów tylko z [7] oficjalnego repozytorium WP. Powód? Zanim plugin trafi do repozytorium przechodzi weryfikację również pod kątem bezpieczeństwa.

Budując stronę opartą o WP zawsze należy starać się zminimalizować liczbę wykorzystywanych wtyczek i oprzeć się na „corowej” funkcjonalności WP. Zresztą – wraz z kolejnymi wersjami coraz więcej popularnych wtyczek wcielana jest do kodu źrodłowego WP.

Domyślnie WordPress dodaje do kodu HTML generowanej strony i kodu XML kanałów RSS informację o swojej wersji:

<meta name="generator" content="WordPress 2.5" /> //kod HTML
<generator>http://wordpress.org/?v=2.5</generator> //kanał RSS

Usunięcie tych wpisów to jedna z pierwszych rzeczy, które należy uczynić w celu poprawy bezpieczeństwa bloga. Można to zrealizować np. za pomocą następującego kodu, który umieszczamy np. w pliku functions.php w ramach aktywnego szablonu:

function i_want_no_generators()  {
return '';
}
add_filter('the_generator','i_want_no_generators');

Panel administracyjny większości blogów opartych o WP dostępny jest pod bardzo oczywistym adresem: nazwadomeny.pl/wp-admin. Co zrobić, aby utrudnić dostęp do tej części? Jednym z rozwiązań jest umieszczenie plików źródłowych WP we własnym, trudnym do odgadnięcia katalogu np. nazwadomeny.pl/wpcore4234234/.

Dostęp do sekcji administracyjnej (nazwadomeny.pl/wpcore4234234/wp-admin trzymając się dalej naszego przykładu) warto dodatkowo ograniczyć za pomocą pliku .htaccess – wprowadzić hasło lub zezwolić na połączenia tylko z określonych adresów IP.

Pózniej wystarczy już tylko zmienić lokalizację i ewentualnie nazwę katalogu wp-content np. na taką: nazwadomeny.pl/content i ustawić nowe scieżki w pliku wp-config.php za pomocą dyrektyw WP_CONTENT_URL i WP_CONTENT_DIR.

Należy również nadmienić, iż począwszy od wersji 2.6 WP ma pełne wsparcie dla protokołu SSL – warto więc rozważyć ograniczenie dostępu do sekcji administracyjnej tylko dla tego typu połączeń. Domyślnie hasło przesyłane jest przecież jawnym tekstem, który łatwo można „wysniffować” np. w sieci lokalnej.

Z tej funkcji praktycznie rzadko kto korzysta, a stwarza ona dodatkowe zagrożenie dla strony.

Bez tego zabiegu przy niektórych konfiguracjach serwera atakujący może podejrzeć listę wykorzystywanych wtyczek.

Stwórz cron joba, który robi backup bazy WP np. co drugi czy trzeci dzień. Backupy przechowuj w katalogu niedostępnym z poziomu WWW.

Na zakończenie parę refleksji. WP jest najpopularniejszą platformą blogową w Internecie. Co więcej, beztrosko wykorzystywany jest coraz częściej jako system CMS do budowy serwisów i małych portali – także tych firmowych. Przecież już w tej chwili istnieją w Sieci firmy, których działalność oparta jest właściwie całkowicie o WP (np. sieć blogów [9] blomedia). Osobiście bardzo lubię WP, baaa nawet można powiedzieć, że go trochę kocham (takie małe zboczenie). Ale ludzie oczarowani prostotą WP często przymykają oczy na kwestie zabezpieczeń tego systemu – tzn. niby oficjalnie przyznają, że zdają sobie sprawę z zagrożeń i mają na uwadze bezpieczeństwo, ale gdy przychodzi np. do aktualizacji oprogramowania zawsze odkładane jest to „na później” no bo przecież TO nie może przytrafić się właśnie mi.

Chciałem moją „akcją marketingową” – przyznaję – dalece kontrowersyjną i budzącą skrajne emocje – wywołać małe „trzęsienie ziemi” i zwrócić internautom i blogerom uwagę na ten problem. Oczywiście – mogłem to zrobić w bardziej cywilizowanej formie (i zastanawiam się, że być może trochę „pojechalem po bandzie”) – ALE – czy efekt byłby ten sam? Wydaje mi się, że nie – że informacja o poprawie bezpieczeństwa WP zaginęła by gdzieś wśród setek innych zupełnie niezauważona. A tak być może właściciele WordPressowych blogów zaczną pytać sami siebie, czy naprawdę zrobili wszystko, aby blogować i prowadzić swój ewentualny biznes bardziej bezpiecznie.

Tak jak napisałem w komentarzach – „tajemnicza funkcjonalność” WP 2.5 jest dokładnie opisana i wisi w Sieci gdzieś od końca kwietnia i nie jest to strona, której trzeba się wybitnie naszukać. Przy czym – możecie wierzyć lub nie – odkryłem mechanizm na podstawie wyczytanej gdzieś krótkiej wzmianki – na stronę z dokładnym opisem natrafiłem później.

Osobiście nic do hazana nie mam – i chociaż uważam, że [10] antyweb.pl pisany jest czasami trochę zbyt stronniczo i surowo – przyznaję, że zaglądam tam raz czy dwa razy na kwartał.

kminek.pl

Jak zhakierowałem antyweb.pl – czyli co zrobić by poprawić bezpieczeństwo WordPressa Grzegorz Wójcik