WordPress to bezkonkurencyjne narzędzie demokracji tej bardziej kreatywnej części internetu. Pierwsza platforma, która skutecznie odbiera chleb profesjonalnym i drogim programistom, dzięki której stworzenie strony internetowej z prawdziwego zdarzenia stało się proste i szybkie. Nie trzeba umieć kodować, nie trzeba wiedzieć co to jest PHP i SQL, a dzięki licznym narzędziom wspierającym i autoinstalatorom już nawet nie trzeba umieć skonfigurować sobie domeny. Wystarczy kliknąć jeden link, wybrać sobie login i hasło, i już po minucie strona www będzie gotowa. Teraz tylko trzeba się zalogować i wypełnić wszystko treścią. No i za co ci wszyscy informatycy biorą kasę? – zapytasz.
Ten demokratyczny świat byłby piękny, gdyby nie to, że zdajemy sobie sprawy jak bardzo jest on tajemniczy, mroczny i niebezpieczny. Na co dzień administruję trochę z przypadku, trochę z musu, kilkunastoma stronami opartymi o ten popularny CMS. Jedną z nich jest ten blog. Jest to inicjatywa dosyć niszowa, ale postawiłem na regularność publikacji i jakość materiałów. Cieszy mnie więc każdy nowy czytelnik, każdy komentarz czy reakcja na wpis na spiętych ze stroną mediach społecznościowych. Mija pierwszy rok pracy nad blogiem, więc pierwsze efekty już widać.
Jak zostałem alfonsem?
Pewnego jesiennego dnia narzędzie Google napisało mi maila. Zazwyczaj Narzędzie pisze: „Poprawienie pozycji witryny w wynikach wyszukiwania”, co jest swego rodzaju nagrodą za ciężką pracę dla Narzędzia: odpowiednie dobierania fraz kluczowych, robienie metaopisów i te wszystkie inne drobiazgi tak ważne dla Narzędzia, a pozornie mało znaczące. Bo kto lubi tracić wieczór na zmianę nazw czy opisów alternatywnych do zdjęć na stronie? Przecież nazw i opisów nawet nie widać. Narzędzie widzi.
Tym razem Narzędzie napisało, że bardzo mu przykro, ale wygląda na to, że strona moja padła ofiarą ataków i od dziś nabija statystyki na takie słowa jak: milf, fuck, teens, a także gradpa i migdet, łącząc te i inne wyrażenia we wszelkich możliwych kombinacjach. Po dwóch dniach już połowa odwiedzających ten blog miała nadzieję na właśnie takie atrakcje. Niestety, alfons ze mnie słaby, więc wychodzili rozczarowani, ale niefajne statystyki rosły, także nawet Google zaczęło się godzić z faktem, że zmieniłem branżę.
Przez parę dni, niektóre wyniki wyszukiwania w Google nie wyglądały znajomo. Chociaż, zależy jakie kto ma znajomości.
Jak to? Atak zzewnątrz? Wirus? Jakaś luka na serwerze? Czy to możliwe? Pewnie, że możliwe. Jako stary użytkownik WordPress, pamiętający jeszcze wersje 2.x, znam doskonale wady tego rozwiązania. Wiem, że zdarzają się bugi i luki w systemie przez które niebezpieczny śmieć może dostać się do kodu strony i narobić szkód. Co ciekawe: w wielu przypadkach można tego nawet nie zauważyć, bo kto, oprócz doświadczonych administratorów, korzysta na poważnie z Google Search Console czy choćby wpisuje w wyszukiwarkę site:mojastrona.pl. Różnica między wirusami, które pamiętamy z czasów przed-internetowych, a tymi współczesnymi jest taka, że ówczesnym autorom tego typu tworów zależało na rozgłosię. Ludzie z mojego pokolenia przywykli, że wirus od razu zgłasza swoją obecność, choćby poprzez wyświetlanie dziwnych treści, spowalnianie działania strony (bo „lewe” skrypty ładują się w tle, zabierając zasoby), a nawet włączanie przekierowań na strony porno. Dziś jednak zadaniem wirusa jest pozostać jak najdłużej niezauważonym i robić swoją robotę po cichu. Na przykład: indeksować twoją domenę na hasła z którymi nie chciałbyś być kojarzony (vide: milf itd.). Zadaniem wirusa jest przynosić zyski swojemu twórcy, i to wcale nie poprzez okradanie internetowych kont bankowych czy szyfrowanie dysków i szantażowanie użytkowników. Zwyczajnie, po cichu, powolutku.
Jest coś jeszcze. W czasach, gdy popularni dostawcy usług hostingowych dodają do swoich usług autoinstalatory, poziom wiedzy przeciętnego użytkownika WordPress spada, bo do grona twórców i opiekunów stron dołączają ludzie, którzy o administrowaniu nie wiedzą nic. Nie są przygotowani nawet na ręczną edycję bazy danych czy rozdzielenie rekordów domeny tak, aby strona i poczta mogły być na innych serwerach. A co dopiero, gdy mowa jest o bezpieczeństwie. Doskonale zdaję sobie sprawę, że słowa wordpress i wirus w jednym zapytaniu pojawiają się dopiero wtedy, gdy widać pierwsze objawy infekcji.
Dlaczego WordPress
Tak wyglądały zapytania w Google Analytics zanim zdążyłem zaregować. A wystarczył jeden dzień.
Przyczyna jest jedna: jest popularny. To powie każdy doświadczony administrator. Często skrót myślowy brzmi: to WordPress jest winny, bo to WordPress. Dawniej, gdy strony internetowe powstawały od pierwszej linijki kodu, haker próbujący się włamać każdorazowo zaczynał od zera. Jasne, luki zdarzają się we frameworkach, a programiści popełniają wciąż te same błędy, więc katalog możliwości jest znany, jednak nigdy wcześniej w internecie nie było wielu milionów stron postawionych na tym samym CMS-ie. Znalezienie luki w jego kodzie pozwala teoretycznie włamać się na każdą z tych stron. A do tego dochodzą jeszcze skórki, wtyczki i konfiguracja serwera. Wszędzie tam użytkownik czy programista mogą się pomylić lub po prostu nie przewidzieć pewnych niedoskonałości kodu i mamy potencjalny problem.
Paliwem dla całego procesu jest niewielka świadomość przeciętnego użytkownika o tym, jak naprawdę wygląda ta część internetu, której znajduję się pod warstwą oglądaną na co dzień. Pod kolorowymi stronami mamy przecież prawdziwe walki robotów, skanowanie zasobów kodu i baz danych. To trochę tak, jakby pod naszymi stopami był drugi świat ciągnący się do samego jądra Ziemi. To, co na powierzchni, to tylko mały element całości. A pod powierzchnią, a przynajmniej poza naszym zsięgiem mam walkę o kasę i zasoby, o których nie mamy nawet pojęcia. Większość ataków jest przeprowadzana z Chin, Rosji czy Afryki Północnej i można śmiało powiedzieć, że w internecie trwa regularna wojna Dobra ze Złem.
WordPress nie jest winny tak z zasady. To popularny mit, bo na system najprościej zwalić winę. Statystki podane przez WPSmackDown pokazją, że za włamy odpowiadają:
- 41% – słabe zabezpieczenia serwera wynikające z zaniedbań firm hostingowych
- 29% – luki w skórce/temacie WordPressa
- 22% – luki we wtyczkach
- 8% – słabe hasła
Widać wyraźnie, że błędy w kodzie dodatków czy w zabezpieczeniach serwera są znacznie większym problemem, niż stosowanie słabych haseł. Co nie oznacza, że hasło może być byle jakie. Chodzi o to, że dróg do złamania strony może być wiele, a admin niekoniecznie może wszystko przewidzieć i wszystkiemu zapobiec. No ale może się przynajmniej postarać.
To jest problem globalny
Ogólnie uważam, że rok 2017 będzie rokiem w którym jak nigdy wcześniej odczujemy problemy związane z bezpieczeństwem sieci i nadużywaniem jej specyfiki. Nie nie mam na myśli tylko wirusów i innych zagrożeń, ale nawet tak dobrze znany i prawie zaakceptowany problem SPAM-u. W 2017 będziemy to słowo odmieniali przez wszystkie przypadki, bo wiele firm już cierpi z powodu małej skuteczności walki z tym zjawiskiem.
Sprawy bezpieczeństwa są bardzo ważne. Dziś podjąłem temat popularnych CMS-ów, jak WordPress (ale także Joomla!, Drupal czy Magento itp.), więc na nich się skupimy. Sucuri, znane z cenionego i skutecznego, aczkolwiek dosyć kosztownego narzędzia do ratowania przed wirusami na stronach, wydało raport oparty na swoich statystykach. To konkretne badanie dotyczy pierwszego kwartału 2016 roku, więc jest bardzo aktualne, nawet w świecie internetu. Jeśli weźmiemy pod uwagę CMS, to aż 78% wszystkich zgłoszonych infekcji dotyczy WordPressa. Na drugim miejscu jest Joomla! z wynikiem… 14%. Reszta to statystyczny plankton. Widać wyraźnie, że cyberprzestępcy wzięli na celownik właśnie WordPressa i nie odpuszczają.
Infekcje wg platform CMS. Jak widać WordPress rządzi raczej jego pozycja na podium nie jest zagrożona (źródło: Sucuri Website Hacked Report 2016 Q1).
Idziemy dalej: za 24% infekcji odpowiadają nieaktulane wtyczki. WordPress jako CMS tworzony wspólnymi siłami nie ma dobrych narzędzi eliminujących przestarzałe i wadliwe plug-iny. Owszem, ocena wtyczki i data ostatniej aktualizacji jest dla admina konkretną wskazówką, ale jak widać, nie zawsze to pomaga. Szczególnie, że na liście popularnych wtyczek podatnych na ataki znajdują się m.in. RevSlider (1. miejsce) i GravityForms (2. miejsce). Używasz którejś? Powinieneś się bać? Niekoniecznie. Hakerzy wykorzystują przede wszystkim fakt, że użytkownicy nie aktualizują dodatków i włamania dotyczą przede wszystkim luk w starszych wersjach. A więc sytuacji, gdy admin nie wchodzi na stronę przez kilka miesięcy, bo teoretycznie nie musi. Jak widać – musi, a często nawet kilkutygodniowa rozłąka wystarczy, aby przegapić niemiłą niespodziankę.
Warto też dodać, że infekcje atakują raczej ze sporym rozmachem. Sucuri podaje, że podczas „czyszczenia” zainfekowanej strony naprawiają średnio 132 pliki. Podczas, gdy ten skormny blog składa się z około 5-6 tysięcy plików, to liczba ta może wydawać się niewielka. Jednak spróbuj znaleźć i naprawić wszystkie 132 igły w takim stogu siana. Każdy z tych plików może nie tylko zniszczyć stronę. Wśród plików znalezionych podczas skanowania występują głównie pliki malware, ale także SPAM-SEO (wykorzytujące twoją witrynę do budowania własnych wyników, w szczególności na stronach pornograficznych czy e-hazardowych), ale także do wykonywania ataków DD0S na inne strony (wykorzystujące twoją witrynę do zmasowanego ataku na inne strony). I wisienka na torcie: na zainfekowanych stronach prawie zawsze znajdowano pliki back door, których głównym celem jest utrzymanie kontroli nad stroną i – jak sama nazwa wskazuje – tylnego wejścia na nią, tak aby re-infekcja pozornie „wyleczonej” instacji była prosta i szybka.
W ramach prasówki jeszcze raz zachęcam do pobrania i przeczytania raportu. Można go znaleźć tutaj.
Nie jestem amatorem, a jednak…
Uważam, że moje strony są przyzwoicie zabezpieczone, ale i tak nie powstrzymałem włamania. Od czegoś trzeba jednak zacząć. Tak więc kończymy część teoretyczną i przechodzimy do praktyki. Zaczniemy od podstaw, kóre powinny stać się dekalogiem każego domorosłego admina. W zasadzie pentalogiem, bo zasad jest 5:
Dla początkujących:
Atak typu brute force to w największym skrócie taka sytuacja, gdy skrypt próbuje zalogować się na stronę jako administrator, wielokrotnie próbując różne kombinacje i możliwości. Na dobrze zabezpieczonej stronie to trudne, ale jeśli login to „admin” na hasło „qwerty123”, to twoja strona zostanie zhackowana w mniej niż minutę. To samo dotyczy haseł złożonych ze zbitek pierwszych liter imienia, nazwiska itp. podobnych trików.
Zabezpiecz stronę mało oczywistym loginem i hasłem trudnym do złamania. Naprawdę trudnym. W brute force robot będzie ponawiał próbę logowania się na twoje konto, aż do skutku. A skutkiem może być albo udane włamanie, albo wykonanie takie ilości nieudanych prób, że robot się wycofa, uznając atak za nieopłacalny.
To jest tak oczywiste, że aż straszne, że trzeba o tym pisać. Najwięcej problemów bierze się z tego, że administratorzy nie aktualizują kodu strony. W przypadku WordPress wystarczy nadusić jeden przycisk. Nie trzeba nic wiedzieć, trzeba jedynie o tym pamiętać. Warto dodać, że często głównym powodem wypuszczenia przez deweloperów nowszej wersji były właśnie odkryte luki zabezpieczeń. Jeśli nie pamiętamy o aktualizacji, to w zasadzie zostawiamy wirusom otwarte drzwi.
To samo dotyczy wtyczek i skórek. Aktualizujemy zawsze, gdy pojawiają się nowe wersje. A to oznacza, że logujemy się do swojego WordPressa nie rzadziej niż raz na tydzień, aby zerknąć co tam słychać. Dotyczy to także tych stron, które powstały jako statyczna wizytówka i teoretycznie nie mamy powodu się tam logować. Mamy, uwierz mi. Większość wpadek zaczyna się właśnie od zapomnianych stron, które teoretycznie nie wymagają obsługi.
Tutaj liczy się umiar. Gdy eksperymentujemy ze stroną często testujemy różne skórki, instalujemy liczne wtyczki. W efekcie jest tak, że połowa z nich nie jest używana, tylko zalega w instancji. Nawet wyłączona wtyczka dalej jest kawałkiem kodu na naszej stronie, potencjalnie niebezpiecznym. Jeśli jej nie używamy, to ją wyinstalujmy. Nawet aktualna można być potencjalnym ogniskiem problemu.
Rezygnujemy w ogólne z dodatków, które od dawna nie były aktualizowane przez autorów, są mało popularne lub pochodzą spoza sprawdzonych repozytoriów. Dbajmy o to, aby w instancji były zainstalowane jedynie używane i potrzebne elementy ze sprawdzonego źródła.
Zdarzało się już w przeszłości, że robale uzyskiwały dostęp do całego serwera dzięki dostępowi przez FTP, a powodem tego były wirusy na komputerze admina. Wykradzenie haseł zapamiętanych w Total Commanderze czy FileZille to naprawdę małe wyzwanie. Podobnie jest z hasłami zapamiętanymi w przeglądarkach, szczególnie, gdy nie masz dobergo antywirusa z firewallem.
Zweryfikuj dostępy do FTP (oby hasło do FTP nie było takie samo jak do strony…) i oducz się zapamiętywania haseł w programach. Jeśli masz większe ambicje, to postaraj się łączyć z serwerem przez sFTP, a nawet SSH, co nie jest takie łatwe, ale da się zrobić.
W trakcie prac nad stroną i później – gdy jest ona już „w produkcji” zdarza się, że zakładasz konta dodatkowym administratorom, edytorom i innym użytkownikom. Nie raz też bywa tak, że zezwalasz na używanie przez kolegów prostych haseł, żeby im życia nie utrudniać.
Zweryfikuj te konta, szczególną uwagę zwróć na administratorów. Na pewno nie każdy potrzebuje konto o takim poziomie dostępu. Dla świętego spokoju zmuś wszystkich do resetu hasła przynajmniej raz do roku i usuń konta z których nikt nie korzysa.
Z tymi zadaniami powinieneś sobie poradzić w jakąś godzinę. A to oznacza, że pora przejść do bardziej zaawansowanych kroków, czyli druga cześć, trochę rozleglejsza. Jednak zanim do niego przejdziemy spójrz na efekt zaniedbania w wykonaniu jednego z adminów. To akurat nie moja strona, ale miałem okazję walczyć o jej odzyksanie.
To był moment krytyczny. Zapytania do bazy danych występują w ilości kilku na sekundę. W ciągu dnia było ich ponad 15 tysięcy (!) i kończyło się to zawieszeniem bazy. W takim momecie pomaga oczywiście firewall, bo jak widać ataki następują z jednego adresu IP, który można zablokować na zaporze. Smaczku całej historii dodaje fakt, że to IP „zaprzyjaźnionego” serwera na którym pozostały resztki startej strony, porzuconej i zapomnianej. Kod został zainfekonwany, a nowa strona, już na nowym serwerze, była atakowana poporzez domenę.
Blokowanie IP w zaporze finalnie niewiele daje, bo rzadko jesteśmy w tak komforotowej sytacji, aby mieć tylko jeden, stały IP do zablokowania. Poza tym w powyższym przykładzie widać, że firewall to nie wszystko. Mimo, że wirus nie przedostał się na stronę (widzimy przecież logi z zapory), to każde skuteczne działanie firewalla oznacza wykorzystanie zasobów serwera, co w tym przypadku prowadziło do zawieszania się strony kilka razy dziennie. Nieskuteczne zresztą też. Robot wysyła zapytanie, otrzymuje odpowiedź… i tak kilkanaście tysięcy razy na dobę.
Także naprawdę warto ogarnąć temat głębiej zanim będzie za późno. Kolejna porcja, tym razem już wymagająca trochę wiedzy i sprawności.
A tak na serio: jak się odważysz i nic nie zepsujesz, to przez chwilę poczujesz się jak prawdziwy haker. Napisałbym, że jak Kevin Mitnick, ale pewnie już nikt nie pamięta, kto to był.
Dla zaawansowanych:
Niedawno zauważyłem, że po instalacji WordPress na jednym z serwerów kluczowy dla bezpieczeństwa plik wp-config.php dostał automatycznie uprawnienia 644. Jest to uprawnienie domyślne, jednak bardzo niebezpieczne. Wyobraź sobie, że każdy ma dostęp do pliku i jego zawartości. No dobra, nie każdy, bo dostęp do samego folderu nie jest prosty, ale przecież w tym pliku mamy zapisane login i hasło do bazy danych. Informacje te nie są w żaden sposób szyfrowane, więc taka niespodzianka to totalna maskra, a dla mnie duże rozczarowanie.
Wchodzimy przez FTP, wyszukujemy plik wp-config.php w głównym katalogu i zmieniamy jego uprawnienia na 600. Każdy klient FTP, jak Total Commander czy FileZilla ma taką możliwość i jest to dosyć prosta operacja.
Popularne boty wyszukujące dziur w naszym kodzie spróbują się dowiedzieć jak wygląda strukrura bazy danych. Domyślna baza WordPress ma prefix wp_, więc znajdziemy tam tabele np. wp_options, wp_posts, wp_users itd. Jednym z najskuteczniejszych sposobów na zabezpieczenie się przed atakami jest utrudnienie botom zorientowania się w sytuacji.
Zmiana prefiksu to bardziej skomplikowana operacja, dlatego zamiast ją opisywać dokładnie, polecam zapoznanie się z ą instrukcją: http://www.seowp.pl/zmiana-prefiksu-bazy-danych-po-zainstalowaniu-wordpress/. Natomiast jeśli dopiero instalujesz WordPressa, to sprawa jest bardzo prosta. Podczas instalajcji, gdy podajesz parametry bazy danych, można zmienić prefiks. Da się to zrobić jedynie podczas instalacji ręcznej, a nie przez autoinstalatory, które są oferowane przez firmy hostingowe.
Jak wiadomo do WordPressa logujemy się przez domyślny adres: twojastrona.pl/wp-admin – to i roboty też to wiedzą. Skanują więc całe pule adresów IP w poszukiwaniu stron logowania charakterystycznych dla tego CMS-a. Warto więc sprawić, aby strona logowania była inna, niż domyślne wp-admin.
Można to robić ręcznie w kodzie, ale nie polecam, to bo sporo roboty i sporo do zepsucia. Jeden błąd i naszym oczom ukaże się white screen of death, jak to się ładnie zwykło określać ten moment w życiu admina, gdy dociera do niego, że zrobił coś bardzo złego swojej stronie. Dlatego polecam wtyczkę, która szybko załatwi temat: https://wordpress.org/plugins/wps-hide-login/. Pamiętaj, żeby wybrać opcję mało oczywistą, bo zmiana z /wp-admin na np. /login niewiele da.
To jest ogromny temat. Plik .htaccess to zestaw instrukcji za pomocą których można zmienić ustawienia serwera Apache dla naszych kluczowych katalogów. Dlatego to w nim właśnie dodajemy ważne ograniczenia i blokady. Jego funkcje są bardzo bogate i wychodzą daleko poza zabezpieczanie WordPressa.
Trudno tutaj wskazać konkretne rozwiązanie, bo każdy admin ma własne podejście do tego tematu. Na pewno warto odnaleźć i otworzyć ten plik, i przyjrzeć się jego zawartości. Można też sobie poczytać w internetach o różnych opcjach. Jest na przykład opcja hardkorowa, jeśli logujesz się do WordPressa z jednego miejsca i masz tam stałe IP, to możesz zablokować możliwość dostępu z innych lokalizacji. Wystarczy dodać parę linijek kodu:
AuthName "Example Access Control" AuthType Basic order deny, allow deny from all allow from 00.000.000.00
Oczywiście zamiast zer wpisujesz własne IP. Ten sam kod, lekko zmodyfikowany, może posłużyć do blokowania danych adresów IP, więc możliwości jest dużo. Często zapory stosują plik .htaccess umieszczając w nim właśnie czarną listę IP, co jest rozwiązaniem doraźnym, ale lepsze to, niż nic.
Możemy wykorzystać plik .htaccess również do wprowadzenia dodatkowego logowania czyli BasicAuth. W ten sposób będzie trzeba zalogować się dwa razy, co utrudni życie robotom. Jak nie uda im się przejść przez BasicAuth, to nie będzie nawet mowy o forsowaniu WordPressa, więc jest to popularna i skuteczna metoda na ataki brute force pod warunkiem, że logujemy się dwa razy innym loginem i hasłem.
Aby włączyć to zabezpieczenie należy utworzyć plik .htaccess w katalogu /wp-admin – pod warunkiem, że jeszcze tam tego pliku nie ma. Jeśli jest, to edytujesz. Jeśli nie ma – to tworzysz taki np. w Notatniku. Zabezpieczenie składa się z dwóch elementów. Do .htaccess dodajesz:
AuthType Basic AuthName "Wymagana dodatkowa autoryzacja:" AuthUserFile .htpasswd Require valid-user
Jako stary haker (w końcu jesteśmy już w punkcie 10.) zauważyłeś na pewno, że wpis odwołuje się do tajemniczego pliku .htpasswd . Dokładnie tak. Plik o tej nazwie tworzysz w Notatniku i wrzucasz również do /wp-admin. Plik ten składa się z jeden linijki kodu i zawierał będzie login oraz hasło rozdzielone dwukropkiem. Co ważne – hasło powinno być zakodowane w Crypt(), więc do jego wygenerowania użyj tego linku: http://www.web2generators.com/apache-tools/htpasswd-generator. Jeśli więc chciałbyś użyć login jannowak a hasło: starakoza, to w pliku powinna się znaleźć tylko jedna linijka:
jannowak:$apr1$q1mc69d5$Rn2sPKYzknkOitKwNSNMp/
Jeszcze raz przypominam – oba pliki w /wp-admin, a dane logowania w .htpasswd powinny być inne, niż do WordPressa.
Jeśli dotarłeś do tego etapu to chyba nie muszę tłumaczyć dlaczego wp-config.php jest plikiem tak ważnym i warażliwym. Jak już zło w czystej postaci dostanie się na serwer, to może modyfikować ten plik (lub po prostu wykraść login i hasło do bazy danych.
Robimy dwie rzeczy. Po pierwsze: zabezpieczamy ten plik przed modyfikacją. W tym celu dopisujemy do pliku .htaccess taki oto kawałek kodu:
<FilesMatch "wp-config.*\.php|\.htaccess|readme\.html">
Order allow,deny
Deny from all
</FilesMatch>
A po drugie: generujemy sobie własne klucze (znajdziesz je u dołu pliku wp-config.php
) poprzez ten link: https://api.wordpress.org/secret-key/1.1/salt/. W zasadzie to możemy wybrać odwrotną kolejność, bo wypadałoby najpierw zmodyfikować plik, a później dopiero nakazać serwerowi blokowanie modyfikacji.
Chodzi o to, aby nie było możliwości grzebania w plikach szablonu bezpośrednio z WordPressa. Obecnie możemy to zrobić przez Panel w sekcji Wygląd > Edycja. To dosyć niebezpieczne, bo wirus może modyfikować część plików nawet nie dostając się na serwer. Wystarczy złamane hasło administratora. A umówmy się – ta funkcja edycji jest praktycznie nieużywana, więc możemy ją sobie ograniczyć.
Odnajdujemy plik wp-config.php , który przed chwilą zabezpieczaliśmy nowymi kluczami i dopisujemy jedną linijkę kodu:
define('DISALLOW_FILE_EDIT',true);
Wersja dla leniwych
Jeśli nie martwisz się aż tak bardzo jak ja, a kariera internetowego alfonsa nie jest ci straszna, to możesz też skorzystać z wtyczki, która przynajmniej częściowo zautomatyzuje ochronę. Ja polecam All in One WP Security & Firewall. Wtyczka ma do włączonia kilkadziesiąt opcji, które mogą naprawdę solidnie zabezpieczyć stronę. Oczywiście to wszystko nie zwalnia cię z myślenia.
Jeśli masz podejrzenia, że twoja strona już jest zainfekowana, to polecam fajny skaner, który prześwietli pliki i usunie złośliwy kod – Anti-Malware Security and Brute-Force Firewall – ja, gdy pomagam na nie swoich stronach, to zaczynam właśnie od tego, zanim rozpocznę mozolne przeglądanie plików bezpośrednio na serwerze.
Żadne wtyczki nie ochronią cię tak naprawdę w przypadku, gdy doprowadzisz do poważnej infekcji. Firewall zatrzyma ataki, ale jeśli są ich tysiące w ciągu każdej godziny, to twoja strona prędzej czy później tego nie wytrzyma. Skaner plików znajdzie kawałki złośliwego kodu, ale jeśli na serwerze zostału umieszczone backdoory, to kod po kilku minutach wróci. Dlatego tak ważne jest zachowanie najwyższej higieny na stronie i stosowanie zabezpieczeń.
Warto też przemyśleć hosting. Jeśli ktoś się dziwi i bulwersuje, że musi zapłacić za miejsce na serwerze kilkaset złotych w skali roku, to czego może oczekiwać od firmy hostingowej? Że w przypadku problemów mu bezinteresownie pomoże? Nie twierdzę, że hosting ma być drogi (bo to ponownie temat-rzeka), ale na pewno nie warto stosować niesprawdzonych rozwiązań, ani trzymać swoich stron kątem u znajomego na serwerze, bo ten akurat ma miejsce.
Posłuchaj mnie, bo jestem człowiekiem, który najwięcej odsłon w 2016 roku uzyskał w roli internetowego alfonsa. Więc wiem, co mówię.
15 Comments
Ciekawy case i wpis . Jak to często w życiu bywa najsłabszym ogniwem systemu jest człowiek . Warto więc pójść za radą i przede wszystkim zweryfikować kto ma na naszej stronie uprawnienia admina i czy faktycznie są mu niezbędne 😉
Dziękuje, podpisuję się pod tą radą. U mnie podejrzewam właśnie infekcję konta admina, która się wzięła od zainfekowanego komputera (wykradzione wszystkie hasła z klienta ftp), więc akcja była masowa, bo jeśli black door miał dostęp do całego http://FTP... nawet nie chcę myśleć.
Cześć. Mam ten sam problem. Najprawdopodobniej skorzystam z backupu jaki oferuje mi dostawca hostingu. Mam nadzieję, że to pomoże.
Jak wiele zła te wygenerowane linki wyrządzają pod względem SEO? W Search Console mam kilkanaście tysięcy wygenerowanych linków. Czy Google da mi bana za to?
Świetny artykuł.
Czyli atak na Twoją stronę polegał na podmianie zawartości, która pozycjonowała stronę pod kątem wyszukiwanych fraz w Google?
Dzięki Wojtku. Tak, dokładnie tak. Backdoor polegał na zmianie wpisu w .htaccess, który z kolei nadpisywał index.php, a wtedy już chulaj dusza… niestety, zorientowałem się dopiero po 4 dniach, bo dane z Analyticsa mnie zdziwiły (dużo czytelników z Pakistanu) ;-). No i po nitce do kłębka.
Generalnie, próby logowania na admina szły z Maroka.
Cześć!
Z doświadczenia wiem, że największym grzechem jest zapamiętywanie haseł, zwłaszcza w programach do obsługi FTP. Szczególnie popularne FileZilla i TotalCommander są zagrożone. Łatwo o robaka który dostanie się na serwer i zaatakuje WordPressa właśnie z tej strony.
Takie mamy czasy że musimy pamiętać setki haseł, pinów etc., dlatego zrozumiałym jest potrzeba ich przechowywania. Polecam do tego menadżery haseł takie jak KeePass.
Dzięki, słuszna uwaga, ja też się przerzuciłem w pewnym zakresie na taki portfel haseł, bo realnie nawet przy jednej stronie – hasła: admin, ftp, panel admina domeny czy co tam jeszcze. A jak robal ma wejście na ftp, to niestety już jest dramat.
Dzieki, super porady. De facto lektura twojego wpisu zainspirowała mnie do dalszych poszukiwań i … natrafiłem na książkę, która bardziej wyczerpuje temat „WordPress i Joomla! Zabezpieczanie i ratowanie stron WWW” Helion. Także dla zainteresowanych tematyką jak zabezpieczyć WP i nie zostać kolejnym alf…. polecam!
Artykuł, jakiego szukałam. Mam nadzieję, że pomoże rozwiązać problem przekierowania na strony xxx.
Przekierowanie ma miejsce tylko z wyników wyszukiwania i dotyczy wszystkich stron oprócz głównej (ta akurat wyświetla się prawidłowo). Poprosiłam home.pl o przeskanowanie i nie wykazało ono obecności potencjalnie niebezpiecznych plików w ramach Państwa serwera. Czy próbować wtedy zmian w pliku .htaccess?
Jeśli tak się dzieje, to jakiś złośliwy chochlik ma wejście na stronę jak admin. Najczęściej ma wejście do plików przez FTP i może zmieniać zapisy w htaccess. Może też zmieniać same pliki dodając kawalek kodu, który nie będzie podejrzany dla home.pl. Realnie home.pl nie sprawdzi dokładnie strony, ponieważ w tym wypadku to nie jest wirus, tylko działanie nieautoryzowane kogoś obcego, zapewne zautomatyzowane. Więc zdecydowanie polecalbym sprawdzenie htaccess, a później tez index.php, header.php.
Świetnie. Dziękuję za podpowiedź. Czy zmiany te są umieszczane na końcu kodu w pliku czy różnie to może być? Pytam, bo nie jestem programistą i nie mam pojęcia, jak może wyglądać ten podejrzany fragment kodu.
Różnie, ale zazwyczaj jest to początek lub koniec skryptu. Samo znalezienie nie jest specjalnie trudne bo bierzesz kilka plików i możesz je zwyczajnie porównać z oryginałami pobranymi chociażby ze strony WP. Często jest jednak tak, że wstrzyknięty kod poleciał na wszystkie pliki z rozszerzeniem .php i wtedy zabawa w ręczne usuwanie tego zajmie Ci sporo czasu i lepiej poprosić operatora hostingowego żeby pomógł Ci to wyczyścić – tu jednak nie wiem czy home. Prewencyjnie zastosuj u siebie jakąś wtyczkę, które będzie monitorowała integralność plików np. WordFence czy wspomniane w tekście Sucuri.
Najlepiej zacząć od wgrania aktualnej wersji wordpress i pluginów, tylko nie nadpisanie, bo pliki z wirusem mogą pozostać. Należy usunąć stare katalogi i wgrać wszystko od nowa. Jeżeli mamy plik z szablomem sprawa jest dość łatwa, jeżeli nie musimy go przeglądnąć pod kątem polecenia eval. Sprawdzamy plik config, generujemy nowe klucze i usuwamy nie potrzebnych administratorów, np dodanych przez wirusa. Zmiana hasła ftp czy wordpress jest zwykle podrzędna, bo wirusy dostają się zwykle przez dziure w kodzie. Na koniec strone zabezpieczamy przy pomocy wordfence i loginizer.
Pewnie nie jestem odosobniony w swoich problemach mimo, ze nikt sie do mnie nie wlamal. Przestrzegalem aktualizacji WordPress’a bardziej niz mycia zebow a i to nie pozwolilo mi uniknac problemow. Moja strona www jest martwa mimo, ze wyswietla sie calkiem dobrze. Problemem jest to ze nie da sie jej aktualizowac. Przeczytalem kilka artykulow, bloga i co tam mi podpowiedzial dr Google. I co? I nic. Jezyk ktorym sie posluguja koledzy piszacy porady a nawet Ci ktorzy o ta porade prosza jest hermetyczny (nawet nie probuje go przytoczyc). Dla zwyklego zjadacza chleba i urzytkownika serwisu www kompletnie niezrozumialy. Stad moja prosba, czy ktos moglby sie zajac moja strona i przywrocic jej poprzednia, przed aktualizacja, funkcjonalnosc.
Jezeli ktos mialby na to ochote i czas prosze o tel. 501 123 333 (Tadeusz)
PS. Byc moze uprzedzajac pytania, konstruktor strony, ktory bylby najbardziej predystynowany do tej pracy, jest nieosiagalny.
Ciekawe. Ale jak się nie nie ma pojęcia o bezpieczeństwie w internecie i tworzeniu bezpiecznych stron internetowych to lepiej sobie odpuścić ten temat, nawet w przypadku tak prostego systemu jak wordpress. Jak widać, dla laików w temacie nawet taki prosty cms może stworzyć problemy. Polecam jakiś podstawowoy kurs tworzenia stron i bezpieczeństwa.