WordPress jest najbardziej popularnym CMS’em i dzięki temu na stronach internetowych na WP można dodać wiele świetnych, darmowych rozszerzeń oraz bardzo łatwo jest znaleźć osobę, która nas wesprze w pracach.
Niestety jest także druga strona medalu, a mianowicie hakerom bardziej opłaca się stworzyć wirusy na popularną platformę, bo mogą je wykorzystać do zainfekowania większej liczby stron internetowych. Dlatego niestety wirus na WordPressie jest częstym zjawiskiem. Jak się przed tym ustrzec? Tego dowiesz się w tym artykule!
Wirus na WordPressie – jak się go łapie?
Całkiem łatwo jest złapać wirusa na stronie WWW, to tak jak z przeziębieniem w zimę. Hakerzy są zazwyczaj bardzo kreatywni i sposobów na złapanie wirusa jest bardzo dużo. Roznoszone są one zazwyczaj drogą kropelkową np. przez luki bezpieczeństwa lub poprzez kontakt bezpośredni np. wykradzione hasło. Najczęstsze przyczyny znajdziesz poniżej.
- Luki bezpieczeństwa we wtyczkach lub motywach.
- Zbyt proste dane do logowania do panelu WordPress.
- Złamane lub wykradzione dane do logowania do FTP.
- Wirus na komputerze, który wykradł zapamiętane w przeglądarce dane do logowania.
- Niesprawdzona firma hostingowa.
Jak rozpoznać, że złapaliśmy wirusa na WordPressie?
Zazwyczaj trudno jest zauważyć, że strona została zainfekowana, ponieważ większość wirusów działa w tle i wykorzystuje stronę internetową do własnych celów np. rozsyłania spamu. Znów podobnie do przeziębienia, objawy widać dopiero po jakimś czasie od momentu zarażenia. Więc jak to stwierdzić?
- Pojawiają się odbiorcom komunikaty, żeby nie wchodzić na stronę, bo jest ona zainfekowana.
- Spowolnienie ładowania strony internetowej.
- Niewielkie zmiany na stronie, które wyglądają jak błąd w kodzie.
- Maile (z domeny, na której jest strona) trafiają innym notorycznie do spamu.
- Informacja od hostingodawcy, że serwer rozsyła SPAM.
Ubezpieczenie – L4 dla Twojej strony WWW
Na wypadek choroby warto się ubezpieczyć i dobrze jest zrobić dodatkowe backupy strony WWW. W artykule “Zabezpiecz się! – czyli jak robić backup strony WWW?” dowiesz się, jak zadbać o to. Backupy są jak L4 – dzięki nim nie stracisz swoich danych, ale także szybciej wykurujesz stronę i przywrócisz ją do pełni zdrowia.
Profilaktyka – jak się ustrzec przed infekcją strony WWW?
Wprowadź kilka zabezpieczeń, które zadziałają jak witamina C dla Twojej strony WWW i utrudnią złapanie infekcji.
- Aktualizuj WordPressa, wtyczki oraz motyw (także te nieaktywne).
- Instaluj wtyczki, motywy tylko ze sprawdzonych źródeł (polecam ThemeForest lub darmowe z WordPress.org).
- Nie używaj oczywistych loginów dla użytkowników panelu CMS (np. admin).
- Używaj silnych haseł (zarówno dla użytkowników, jak i do panelu FTP oraz bazy danych).
- Nie zapamiętuj hasła do panelu CMS w przeglądarce.
- Nie instaluj wtyczek do bezpieczeństwa na WordPressie – często robią więcej złego niż dobrego – lepiej udać się do specjalisty w tej dziedzinie, jeśli myślisz o swojej stronie WWW na poważnie.
Leczenie objawów – usuwanie wirusa z WordPressa
Tutaj proponowałabym pójście ze stroną internetową do lekarza. Nie wiadomo jaki wirus na WordPressie nas dopadł i jak najlepiej go usunąć. W tym celu warto skorzystać z pomocy specjalisty od bezpieczeństwa.
Co mogę jeszcze zrobić?
Możesz wprowadzić jeszcze kilka technicznych usprawnień do WordPressa, aby go dodatkowo zabezpieczyć – zadziałają one jak szczepionka na grypę (lub kompleks witamin i ziółek, jeśli nie uznajesz szczepionek). W tym celu najlepiej skorzystać z wiedzy specjalistów lub podążać za wskazówkami Krzysztofa Dróżdża, który jest specjalistą w tej dziedzinie. Przygotował świetną prezentację na ten temat Wyczaruj sobie spokój.
Czy przytrafił Ci się już kiedyś wirus na WordPressie? Daj znać w komentarzu!
P.S. Ruszyła przedsprzedaż książki Chcę WWWięcej! Jeśli interesuje Ciebie ten artykuł, to musisz ją zobaczyć. Kliknij tu i sprawdź!
29 Komentarze
I właśnie dlatego używam CMS-a, który nie łapie wirusów 🙂
Andrzeju, każde oprogramowanie łapie wirusy – dawno dawno temu nie było CMSów, a wyobraź sobie, że aplikacje PHP także były podatne na ataki.
To nie jest tak, że WordPress jest na wirusy podatny. Podatne są źle zrobione strony, których nikt nie utrzymuje.
Równie dobrze mógłbyś kupić samochód marki X, nie naprawiać go, nie serwisować, a potem narzekać, że w samochodach marki X silnik się zaciera…
Oczywiście, sama strona swoją drogą. Ale to są ekstremalne przypadki, gdzie aż się prosi o włamanie np. podczas jawnego przekazywania parametrów.
Jednakże WP i inne Opensourcowe CMS-y mają to do siebie, że ich kod jest znany, popularny, często używany. Ludzie niemalże zawodowo zajmują się szukaniem w nich dziur a oczywiście im bardziej skomplikowany system tym większe prawdopodobieństwo ich znalezienia. Co więcej, zanim ludzie zaktualizują WP na swoich stronach, tysiące z nich jest podatne na ataki.
To nie jest kwestia tego, że akurat WP jest podatny. Jak napisała Ola we wstępie, hackerom opłaca się atakować WP, bo jest popularny. Do użytkownika należy wybór czy postawi na wygodę czy bezpieczeństwo. Ja postawiłem na bezpieczeństwo.
Nie do końca się zgodzę. To nie są ekstremalne przypadki, gdzie cokolwiek aż się prosi, bo bezpieczeństwo oprogramowania to nie jest trywialne zagadnienie…
Owszem, OpenSource’y mają to do siebie, że ich kod jest jawny. Dzięki temu dziury łatwiej jest znaleźć, a następnie są one łatane… I właśnie to poprawia bezpieczeństwo danego systemu, a często i innych. Np. w ramach szukania dziur w WordPressie, znalezione były podatności w bibliotekach, z których korzysta cała masa innych aplikacji pisanych w PHP.
Obawiam się, że mylisz pojęcie bezpieczeństwa z poczuciem bezpieczeństwa. W kryptografii zasadą jest, że algorytm szyfrowania nie może zostać uznany za bezpieczny, jeśli jest niejawny. Niejawność, nie jest bowiem miarą bezpieczeństwa – takie bezpieczeństwo opiera się na niewiedzy i tajemnicy. Jeśli tajemnica wycieknie, to całe Twoje bezpieczeństwo runie. Bezpieczny algorytm to taki, który mimo jawności, nie daje złamać szyfru. Dlatego właśnie algorytmy, z których korzystasz na co dzień są jawne i wręcz zapraszają do ich łamania (oferowane są olbrzymie nagrody za ich złamanie).
Wcale nie jest trudno napisać bezpieczne oprogramowanie.
Owszem, w opensourcowych szybko znajduje się dziury, ale… są one poprawiane w kodzie do pobrania a nie w stronach docelowych. A jak często są one aktualizowane w praktyce? Podpowiem, że często widuję serwisy nieaktualizowane od kilku lat. Więc co im po tym, że ktoś załata dziurę? Lepiej, żeby ta potencjalna dziura po prostu nie została znaleziona.
Nie piszemy o kryptografii tylko o klasycznych błędach pozwalających na nieautoryzowany dostęp do systemu np. niesprawdzanie poprawności wprowadzanych danych czy jawne przekazywanie zmiennych przez GET. Może pomyliłeś blogi, ale tu piszemy o typowych stronach i blogach a nie systemach bankowych i wojskowych. Tu jedynym szyfrem może być HASH z hasła administratora 🙂
Wcale nie jest trudno napisać bezpieczne oprogramowanie? Poważnie… I dlatego np. błędy zabezpieczeń znajdowane są w Linuxie, Unixie, Windowsie, Apache’u, czy OpenSSL? Wybacz, ale nie – wcale nie jest tak łatwo napisać bezpieczne oprogramowanie – a tym trudniejsze jest to zadanie, jeśli nie piszesz każdego jego fragmentu – a tego nie robisz nigdy, bo zawsze w którymś momencie robisz “odcięcie” i bazujesz na jakiejś bibliotece…
Podstawowe zasady bezpieczeństwa są dokładnie takie same, niezależnie od tego, czy tworzysz oprogramowanie rakiet balistycznych, czy domowego budzika. Jeśli bezpieczeństwo Twoich pieniędzy polega na tym, że nikt nie wie, pod którym drzewem je zakopałeś, to jest to złudzenie, a nie bezpieczeństwo. Chyba, że właśnie na takim poziomie bezpieczeństwa chcesz się zatrzymać i Ci ono odpowiada – tylko potem proszę nie płakać, że pieniądze/strona zniknęły.
Natomiast już w tym momencie widzę, że nie ma, o czym dalej rozmawiać, bo HASH z hasła, nie jest szyfrem. A akurat głupi hash hasła jest sporym problemem kryptograficznym i użycie błędnego algorytmu naraża często użytkowników na utratę kont…
PS. To, że rozmawiamy w gronie bardziej czy mniej podstawowych użytkowników nie znaczy chyba, że mamy być ignorantami… Nie mam pewnie nawet podstawowej wiedzy medycznej, ale nie przyszłoby mi do głowy napisać, że prosto jest przeprowadzić operację…
Tym ważniejsze jest właśnie podkreślanie, jak istotne w pracy z OpenSource (ale nie tylko), jest higiena pracy, aktualizacje, itd. A nie udawanie, że OpenSource jest zły, bo jego dziury są jawne i naprawiane, a “MójSource” jest dobry, bo jest dziurawy jak ser, ale tylko ja znam te dziury – no chyba, że korzystam w nim z dziurawej biblioteki, której nie zaktualizowałem, bo nawet nie wiem, że ma dziury…
Nie porównujmy wielkiego systemu operacyjnego do CMSa. To nie ta skala.
Tak się składa, że pisząc swojego CMSa napisałem KAŻDY fragment, związany z działaniem systemu. Jedyne zewnętrzne biblioteki do TinyMce i jQuery – nie spodziewam się tu dziur, bo są to zamknięte twory. A jeśli nawet są, to po stronie serwera działam juz na własnym kodzie w PHP.
Co do hasha, to masz rację, nie jest szyfrem. A tak się składa, że w większości stron jest to jedyny element najbardziej zbliżony do szyfru. Faktycznie, nie musimy o tym rozmawiać w kontekście typowej strony www. Powtórzę, zwykła strona, blog, wizytówka to nie to samo co np. skomplikowany system bankowy. Tu nawet nie ma co szyfrować.
Z czystej ciekawości, jak w swoim CMSie zabezpieczasz się przed XSS?
Ale dlaczego Ty się akurat szyfrowania uczepiłeś? Czy bezpieczeństwo to szyfry? Co Ci po szyfrach, jeśli wystarczy durne SQL Injection czy XSS, żeby rozłożyć całą stronę?
Na czym polega “zamkniętość” TinyMCE czy jQuery?
Tak
To Ty zacząłeś pisać o szyfrowaniu.
Działają po stronie przeglądarki i jedyne czemu mogą zaszkodzić to błędnie coś wyświetlić. Każdy plik działający po stronie serwera musi przejść przed jeden z trzech plików, inaczej się nie wykona. A tam następuje sprawdzanie parametrów.
No chyba, że o czymś nie wiem 🙂 Jak jQuery może zaszkodzić serwerowi?
A bezpieczeństwo strony to szkodzenie tylko serwerowi…?
Nie odpowiedziałeś, na pytanie o sposób zabezpieczenia przed XSS w Twoim CMSie – czyżby bezpieczeństwo przez tajemnicę…?
Żeby nie przedłużać tej jałowej dyskusji, po prostu włam mi się na mojego bloga i osobiście sprawdź jakość moich zabezpieczeń. Na dobrą sprawę, jeśli faktycznie jest tam dziura, to lepiej, żebyś Ty ją znalazł a nie ktoś inny 🙂
Podpowiem, że z obcych kodów (oprócz TinyMce i jQuery) mam tam jeszcze Disqusa, Google Analytics i sklep Cupsell, jeśli to w czymś pomoże.
Andrzeju, nie zamierzam się nigdzie włamywać, bo jest to działanie nielegalne. Jeśli chcesz zlecić testy penetracyjne, to zapraszam do mnie, lub poszukaj odpowiedniej firmy na rynku.
Natomiast zrozum, że Twoje podejście na zasadzie “ja napisałem, to jest lepsze, bo tylko ja wiem, co jest źle”, jest co najmniej bzdurne i może mieć odniesienie co najwyżej do Twojej osoby.
Dlaczego? To proste – nie każdy, np. Ola, będzie pisać swojego CMSa tylko po to, żeby blogować. Ma zatem wybór – użyć WordPressa, którego kod jest jawny i wiele ludzi go pilnuje i wyłapuje w nim dziury, a potem je łata, albo kod zamknięty Firmy Ad3, która uznaje, że skoro kod jest tajemny, to nie trzeba nic z nim robić… Tyle, że jeśli Ola już zdecyduje się na ofertę firmy Ad3, to kod przestaje być tajny i nagle znajdują się ludzie, którzy znają jego bolączki i je wykorzystają.
Wybacz, za długo już działam w branży softu i stron, żeby uwierzyć w bajkę o tym, jak to autorskie rozwiązanie z tajnym kodem jest lepsze (dla kogokolwiek poza autorem tego kodu).
Mylisz się niemal w każdym zdaniu, ale nie będziemy teraz tego tutaj roztrząsać.
Sprecyzujmy, mylę się Twoim zdaniem – zdaniem fotografa i grafika, z wykształceniem niemającym nic wspólnego z oprogramowaniem i który ani razu nie był zatrudniony jako programista…
Ubolewam natomiast nad tym, że nie chcesz roztrząsać, bo chętnie bym się czegoś nauczył od autora “najlepszego CMSa na świecie”, w którym trywialne zabezpieczenie przed XSS jest tak trywialne, że aż musi pozostać tajne, żeby działało (lub nie wyszło, że go brak), a jednocześnie część formularzy nie ma nawet ustawionego atrybutu action, wielojęzyczność nie spełnia żadnych standardów wyszukiwarek, itd…
Muszę Cię zmartwić. Z wykształcenia jestem bardziej programistą niż grafikiem.
Do tej pory żyłam w błogiej nieświadomości…niby wiem, że są wirusy, ale nie pomyślałam, że można tak łatwo go złapać na WP!
Nie bez powodu przyrównałam wirusa do przeziębienia 🙂 Łatwiej złapać niż nam się wydaje…
Olu,
dlaczego akurat taka kolejność najczęstszych przyczyn infekcji? Nie współgra ona z żadnymi statystykami, które widziałem, ani z moim doświadczeniem z czyszczeniem malware’u czy zabezpieczaniem stron.
Objawy, o których piszesz, to już końcowe stadium… Wtedy zazwyczaj backupy już nie pomogą. Malware bardzo często działa dwufazowo – najpierw infekuje i zostawia backdoory, a dopiero po określonym czasie zaczyna swoją szkodliwą działalność. Robi się to właśnie po to, żeby strona przywrócona z backupu, zawierała już te backdoory – czyli jej ponowne zainfekowanie było dziecinnie proste. Nie jest więc istotne to, jak często robisz backupy (Twój hosting robi je codziennie), ale czy je weryfikujesz, gwarantujesz ich integralność oraz jak długo je przechowujesz.
Nieprawdą jest natomiast, że różne wirusy usuwa się w różny sposób oraz, że nie wiadomo, jak je usunąć. Każdy malware infekujący WordPressa działa na kilku prostych zasadach, a w Codexie od dawna znajduje się poradnik, co zrobić, gdy Twoja strona została zainfekowana: https://codex.wordpress.org/FAQ_My_site_was_hacked
Chciałbym też zwrócić uwagę na jeszcze jeden fakt, który od pewnego czasu w kontekście infekcji, malware’u i wirusów jest kluczowy. Google zmieniło politykę i w przypadku stron, które cyklicznie są infekowane, ten paskudny czerwony ekran informujący o zagrożeniu, będzie nakładany na 30 dni bez możliwości zdjęcia… Wyobraź sobie, co się stanie z Twoim blogiem, jeśli przez 30 dni będzie informował o zagrożeniu… Ta zmiana powoduje, że nie jest istotne usunięcie malware’u, ale sprawienie, żeby po usunięciu nie powrócił…
PS. Podoba mi się, że rejestrując się w usłudze, którą polecasz, trzeba zaakceptować regulamin, który nie istnieje (link nawet nie jest podpięty)… Nie wiem, czy dałbym dostęp do mojej strony/serwera komuś (nigdzie na stronie nie jestem w stanie znaleźć informacji o podmiocie odpowiedzialnym za ową stronę, żadnego regulaminu, polityki prywatności, ani nawet warunków świadczenia usługi, którą kupuję… czyli nie spełnia nawet wymogów polskiego prawa…)
Krzysiek,
kolejność przyczyn infekcji jest przypadkowa i wynika z rozmów z kolegami po fachu na ostatnich WordUpach oraz WordCampie i mojego doświadczenia w czyszczeniu, jednak nie jest one bardzo duże, bo po prostu nie lubię w tym grzebać. Dlatego też odsyłam w tym wpisie do osób, które bardziej się na tym znają. Artykuł jest skierowany do osób początkujących na WordPressie i specjalnie nie opisuję tematu zbyt obszernie, bo obawiam się, że zanudziłabym ich. Gdybym pisała do tych bardziej obeznanych to bym od razu odesłała do Twojej prezentacji, bo nie da się tematu opisać lepiej niż Ty to zrobiłeś 🙂
Natomiast dobrze, że piszesz o usłudze chłopaków, przekażę im tę informację – nie patrzyłam na to pod kątem prawnym, bo się na tym po prostu nie znam. Znam ich z WordUpów oraz z Gdyni i wiem, że znają się na swojej robocie, dlatego też ich polecam.
Wiesz, dziwi mnie po prostu podawanie hostingu, jako przyczyny, bo praktycznie w żadnych sensownych statystykach nie jest to przyczyną udanych ataków na strony… Owszem, pojawia się często zła konfiguracja hostingu, ale oznacza ona zupełnie co innego – właśnie słabe hasło FTP, brak separacji, itp.
Możliwe, że się znają. Nie mam pojęcia, kto za tym stoi, bo nigdzie na stronie nie widzę takiej informacji. Dlatego, szczególnie w przypadku bezpieczeństwa, skrajnie zaskakujące wydaje mi się polecanie usługi, która nie informuje o podmiocie odpowiedzialnym, ani nie podaje regulaminu, a prosi o pieniądze. I pomijam tu nawet fakt zgodności z polskim prawem…
To trochę tak, jakbym Ci polecił fajne tabletki, które co prawda nie mają opakowania ani ulotki, ale jak kupisz, to na pewno Ci na coś pomogą…
Uczenie ludzi takiego podejścia do bezpieczeństwa, raczej obniża ich bezpieczeństwo… Bo nigdy nie powinnaś instalować na serwerze rzeczy niewiadomego pochodzenia, których nie jesteś pewna. A Ty jeszcze namawiasz do płacenia za to 😉
Rzeczywiście zastosowałam tutaj skrót myślowy i pisząc o hostingu mam na myśli kiepskie rozwiązania zastosowane przez firmę lub przez klienta jak np. brak separacji lub pozwalanie na zastosowanie słabego słownikowego hasła.
A co do polecanej firmy, to przekazałam już chłopakom Twoje uwagi, niech działają 🙂
Darmowy jest https://webanti.com – nie ma co ale on działa i nie trzeba nawet płacić 🙂
No, z tym działaniem, to bym nie szalał. Działa tak samo skutecznie, jak Wordfence, bo dokładnie na tej samej zasadzie…
Skrypt uruchamiany na Twoim serwerze (czyli w przypadku infekcji malware może go po prostu wywalić), który wysyła Twoje pliki na ich serwer, gdzie są skanowane “ich magicznym rozwiązaniem”, które działa lepiej niż serwerowe oprogramowanie antywirusowe wielkich firm… Tia… Ale przynajmniej wiadomo, kto za tym stoi…
U mnie na szczęście bez wirusów (odpukać). Dzięki za Twoje wskazówki, staram się je stosować, jak hasła, wtyczki z repozytorium WordPressa i aktualizacje 🙂
Powodzenia 🙂
Cenna wiedza, dziękuję! 🙂
Do listy symptomów jesiennej choroby dodałbym – coś dziwnego dzieje się w wynikach wyszukiwania strony. Ostatnio mój klient zamiast tytułu strony i opisu miał chińskie znaczki. Ostatnio przeglądałem kilka innych witryn i natrafiłem na podobny problem. Wszystko to za sprawą wstrzykniętego kodu.
Reszta bezbłędnie wypunktowana Olu! Kolejny wartościowy wpis o WP.
Na szczęście nie miałam z tym jeszcze problemu. 95% na moim blogu to praca własna. Aż strach pomyśleć co by było gdyby tak się stało… Dziękuję za wpis
Zajmuje się zawodowo usuwaniem wirusów, niestety w przypadku ataku pluginy już nie pomogą w 100%, ale aż to się nie stanie warto stosować takie jak wordfence czy loginizer, warto dbać aktualizacje wordpress i pluginów oraz backup strony, w najlepszym wypadku wykonany na innym serwerze, do tego dobry serwer z częstym własnym backupem i supportem.