6 rad jak zabezpieczyć WordPressa

WordPress cieszy się coraz większym gronem zwolenników i użytkowników. Efektem ubocznym tej popularności jest rosnące zagrożenie skutecznym atakiem na strony oparte na WordPressie. Warto zadbać o bezpieczeństwo WordPressa. Podpowiadamy jak zrobić.

WordPress to platforma która z roku na rok zdobywa nowych zwolenników. Szacuje się, że około 30% stron w całym Internecie jest obsługiwana właśnie przez WordPressa. Swoją ogromną popularność zawdzięcza prostocie obsługi panelu administracyjnego, mnogością motywów oraz bardzo dużej społeczności, która jest zawsze skora do pomocy.
Jednak największą zaletą WordPressa są wtyczki oraz system akcji i filtrów. To właśnie dzięki tym rozwiązaniom z mało funkcjonalnego narzędzia do tworzenia blogów można stworzyć również stronę firmową, portal społecznościowy lub nawet aplikację umożliwiającą rezerwację miejsc.

Ogromny sukces WordPressa przekłada się również na ogromne zainteresowanie ludzi z ciemnej strony internetu. Według statystyk Wordfence około 5 – 6 tysięcy stron opartych na WordPressie pada próbie ataku w ciągu każdej minuty! Niestety, niektóre z tych prób dochodzą do skutku, co może mieć bardzo niekorzystny wpływ na naszą stronę oraz odbiór firmy w Internecie.

Strona może stać się farmą linków, a to oznacza, że będzie linkowała do stron na których zależy przestępcy. Taki rodzaj ataku powoduje spadek naszych pozycji w wyszukiwarce Google. Co więcej, strona może przekierowywać do treści pornograficznych lub zawierających złośliwe oprogramowanie.

Coraz większą popularnością zaczynają się cieszyć ataki przeprowadzane za pomocą typu typu ransomware. Są to narzędzia do szyfrowania danych zawartych na serwerze lub dysku ofiary. Jeśli nasza strona zostanie zaatakowana oraz zakodowana, przestępca może żądać od nas okupu za przywrócenie strony do działania.

Dodatkowo przestępca dostając się do panelu administracyjnego naszej strony może wykraść wrażliwe dane osobowe użytkowników korzystających z danego serwisu. Dodatkowo w przypadku sklepów istnieje ryzyko przekierowania przelewów klientów na konto atakującego.

Jak się przed tym chronić?

1. Nie instalować WordPressa. Szokujące ale prawdziwe 😉 Większość stron nie potrzebuje WordPressa ani żadnego innego systemu CMS. Strona firmowa zawierająca cztery zakładki oraz jedną aktualność sprzed dwóch lat naprawdę nie potrzebuje strony z CMS. Najlepszym wyjściem jest stworzenie statycznej strony zawierającej tylko pliki html. W przypadku stosowania statycznej strony internetowej, co prawda mamy mniejszą wygodę przy wprowadzaniu nowych treści, z drugiej strony brak wykonywalnych plików ze skryptami PHP po stronie serwera skutecznie zablokuje zdecydowaną większość ataków. W przypadku stron statycznych jedyną możliwością na atak jest zdobycie dostępu do konta FTP.

2. Aktualizacje. Temat szalenie ważny, ale często pomijany przez użytkowników WordPressa. Platforma WordPress cały czas się rozwija, dodatkowo zainstalowane wtyczki oraz motywy ulegają aktualizacją. Oprócz dodawania nowych funkcjonalności aktualizacje zawierają także łatki bezpieczeństwa. Zapobiegają one wykorzystaniu podatności, które zostały odkryte oraz zgłoszone do zespołu WordPress lub osób tworzących daną wtyczkę lub motyw. Każdy popełnia błędy, dlatego warto zawsze aktualizować wszystko i zawsze 😉

3. Kopia bezpieczeństwa. Tworzenie kopii bezpieczeństwa powinno być nieodzownym elementem podczas administracji stroną opartą o platformę WordPress. Zabezpiecza nas ona nie tylko przed atakami, ale również przed wypadkami losowymi takim jak awaria serwera, pożar serwerowni.
Warto pamiętać, że jeśli posiadamy kopię bezpieczeństwa i zostaniemy zaatakowani, możemy bardzo szybko podmienić zainfekowaną stronę na kopię bezpieczeństwa. Jednak takie rozwiązanie nie przyczyni się do odparcia kolejnego ataku. Należy więc poczynić kroki zapobiegające kolejnym atakom. Jakie? Aktualizacje, zmiana wszystkich możliwych haseł, przyjrzenie się liście użytkowników WordPressa oraz usunięcie tych podejrzanych lub nieaktywnych.
Godną polecenia wtyczką umożliwiającą szybkie tworzenie kopii bezpieczeństwa jest Duplicator. Wtyczka tworzy całkowitą kopie plików zawartych na serwerze oraz bazy danych. Pakuje je w jeden plik zip oraz dodaje plik instalacyjny. Dzięki takiemu rozwiązaniu proces przywracania czy kopiowania strony zajmuję kilka minut.

4. Wtyczki zwiększające bezpieczeństwo. Ataki na platformę WordPress doprowadziły do powstania specjalnych wtyczek poprawiających bezpieczeństwo całej platformy.
Najpopularniejsza wtyczką, mogąca pochwalić się przeszło milionem aktywnych instalacji jest Wordfence. Wtyczka monitoruje system plików platformy, zgłasza mailowo wszelkie modyfikacje plików, kontroluje proces logowania oraz blokuje użytkowników, którzy próbują zalogować się „siłowo” na naszą stronę. Umożliwia także podejrzenie aktualnego ruchu na stronie (można się bardzo zdziwić po zobaczeniu jak dziwne ruchy mają „użytkownicy”), jego lokalizacji oraz potencjału zagrożenia. Instalacja oraz podstawowa konfiguracja jest banalnie prosta i sprowadza się tylko do podania adresu e-mail, na który będą spływały powiadomienia o zagrożeniach.
Drugą wtyczką wartą polecenia jest All in One Firewall and Security. Posiada ona bardzo dużo możliwości konfiguracji. Specjalny system punktów informuje nas o tym jaki poziom zabezpieczeń uzyskaliśmy. Niestety im wyższy wynik, tym bardziej strona staje się kłopotliwa w obsłudze czy nawet logowaniu – taki bonus do większego bezpieczeństwa. Coś kosztem czegoś, dlatego każdy administrator strony powinien powinien znaleźć optymalny dla siebie punkt, tak by korzystanie ze strony było zarówno bezpieczne, jak i wygodne. Dla stron, które mogłyby być statyczne warto maksymalnie podnieść poziom bezpieczeństwa, a dla portali, w których mamy użytkowników, zbyt wysokie podniesienie ograniczeń może skutkować zablokowaniem możliwości logowania się dla tych użytkowników do serwisu.
5. Hasła. Temat niby oklepany ale… cały czas zdarzają się kwiatki typu:

login:admin hasło:admin
login:admin hasło:123456
login: nazwa_firmy hasło: qwaszx

Osoby, które teoretycznie nie znają hasła do witryny mogą w krótszym lub dłuższym czasie metodą prób zgadnąć hasło do serwisu i cieszyć się z pełnego autoryzowanego dostępu! W Internecie bez trudu można znaleźć listy haseł używanych przez internautów (np. plik z 20 milionami haseł!). Następnie za pomocą odpowiedniego automatu można bombardować stronę przez 24h/7dni w tygodniu aż do momentu odgadnięcia hasła lub końca listy haseł. WordPress od niedawna wprowadził system generowania haseł, i powiedzmy sobie szczerze, że należy go używać. Przykładowe hasła są mało przyjazne do zapamiętania , np.:

$PMBHhSUJE6Qk?(f”D<7
3?PQGr3.TGnlcb7M6}mY
,AJJDXq@=}}5hBioy%qR
Kw*MTz{(m(qq”z-$8′]X
:.;63xk/do[4Qo”v/j@0

Dają jednak gwarancję, że raczej nie znajdują się na żadnej liście haseł, a ich złamanie poprzez zwykłe odgadnięcie zajmie przynajmniej 100 lat 😉 Dodatkowo nigdy nie powinniśmy ustawiać nazwy użytkownika na słowo admin, administrator!

6. Wyznacz osobę odpowiedzialną za stronę. WordPress nie jest bezobsługowy. Raz postawiony będzie spełniał swoją rolę, ale na pewno z biegiem czasu będzie coraz bardziej podatny na ataki, dzięki wykrytym podatnościom na atak danej wersji WordPressa, wtyczki bądź motywu. Dlatego każda strona powinna posiadać swojego opiekuna który będzie na nią regularnie zaglądał, wykonywał kopie bezpieczeństwa, aktualizował wszystko do najnowszych wersji oraz analizował logi z wtyczek bezpieczeństwa. Nie może to też być to osoba z podstawową znajomością obsługi komputera. Ta osoba musi to czuć, mieć pojęcie o funkcjonowaniu stron WWW, WordPressa oraz choć podstawową wiedzę z zakresu PHP, HTML, CSS, JS.

Podsumowując, WordPress jest narzędziem, z którego bezpiecznie korzystają miliony użytkowników. Jednak sukces WordPressa posiada również swoją ciemną stronę, w postaci ogromnego zainteresowania wykorzystania platformy do celów niezgodnych z zamiarem administratora/właściciela. Niestety nigdy nie mozemy być w 100% pewni, że nas system jest wolny od luk, jednak dzięki monitoringowi strony oraz śledzeniu nowych podatności możemy uchronić się przed zdecydowaną większością ataków.

Powiązane wpisy

Dodaj komentarz

10 comments

  1. Krzysiek Dróżdż

    Pozwolę sobie podjąć polemikę… Zatem po kolei:

    1. Nie bardzo wiem, co, Drogi Michale, masz na myśli pisząc, że WordPress z roku na rok zyskuje na popularności, bo, co prawda jest to najpopularniejszy CMS, ale jednak od ponad roku raczej udziału „w rynku” mu nie przybywa.

    2. Nie wiem też na czym bazujesz twierdzenie, że coraz częstsze są ataki „ransomware”. Są to bardzo rzadkie ataki i w zasadzie nie ma się co nad nimi skupiać. Dlaczego? Prawie każdy hosting jest w stanie Cię po takim ataku uratować. Owszem, pewnie stracisz 2 dni historii, albo coś w tym stylu, ale nikt nie będzie płacił okupu…

    I przejdźmy do samych rad na temat zabezpieczania WordPressa… Zacząłbym od rady, aby swoją wiedzę na temat bezpieczeństwa WP czerpać z rzetelnych źródeł… Dlaczego? O tym poniżej…

    Rada 1. Tak, ale tylko pod warunkiem, że tworzysz naprawdę statyczną stronę. Niestety prędzej czy później będziesz na tej stronie musiał dodać formularz kontaktowy i pojawi się problem. Jeśli wrzucisz tam plik PHP, to już zaczną się schody – i uwierz mi, jak patrzę na formularze, które klienci mają na stronach, to napisanie tego samemu przez przeciętnego „weba” skończy się opłakanymi skutkami.

    Rada 2. Nie, nie warto. A właściwie nie warto wszystko i zawsze. To tak, jakbyś powiedział, że warto zawsze połykać wszystkie witaminy. O tym szerzej pisałem tutaj: http://wpmagus.pl/artykuly/aktualizowac-zwlekac-ignorowac/

    Rada 3. Kopie bezpieczeństwa to świetna rzecz. Pod warunkiem, że jesteś w stanie zapewnić ich oryginalność i bezpieczeństwo. Jeśli kopie przechowujesz na serwerze, to oczywiście po ataku są nic nie warte. Dlaczego? Bo skoro malware wdarł się na Twój serwer, to mógł te kopie dowolnie zmodyfikować. Pokazywałem to ostatnio na WordUpie w Trójmieście: https://www.youtube.com/watch?v=sKCRUBhiusY

    Dochodzi też jeszcze drugi aspekt. Typowa infekcja zazwyczaj nie ujawnia się od razu. Malware bardzo często wgrywa sobie backdoora, a potem czeka (z moich obserwacji wynika, że około 1-2 miesiące) zanim zacznie powodować widoczne skutki. Po co? Właśnie po to, żeby właściciel strony nie miał już backupów bez backdoorów. Jeśli więc widzisz, że Twoja strona robi coś złego, to pewnie już jest stanowczo za późno na odtwarzanie backupów – też są już zainfekowane.

    Rada 4. I to jest właśnie ten punkt, w którym ewidentnie widać, że warto się uczyć ze źródeł, które wiedzą, co piszą. Wordfence, jak i inne wtyczki tego typu, nie zabezpieczają Cię zupełnie przed niczym. Dlaczego? Bo działają na tym samym serwerze. Na powyższym filmie z Trójmiasta dokładnie pokazuję, jak przebiega atak i ile wart jest w tym przypadku Wordfence. A żeby tego było mało, wtyczki te same w sobie często zawierają podatności. Wordfence miał ich w tym roku już kilka, przy czym jedna z nich pozwalała przejąć kontrolę nad stroną… No rzeczywiście – zwiększa bezpieczeństwo…

    Rada 5. Warto też zablokować listowanie użytkowników. A tak swoją drogą… Ciekawe, jaki login użytkownika ma autor tego tekstu, hmm… Spójrzmy no na archiwum jego wpisów: http://blog.verseo.pl/author/admin/

    Rada 6. Dobry pomysł. Choć radziłbym, aby była to osoba, która zna tematykę bezpieczeństwa WordPressa, a nie tylko posiadała podstawową wiedzę z zakresu PHP (podstawy raczej nie będą tu wystarczające).

    • Michał

      Polemika zawsze mile widziana;)

      Więc tak:
      1. Zyskuje z roku na rok, może już się to wszystko wysyca i nie ma jakiś znaczących wzrostów ale jednak krzywa cały czas pnie się do góry.
      Tutaj znalazłem staty udziału WordPressa „na ryku” od 2011 do 2016
      WordPress 13.1% 15.8% 17.4% 21.0% 23.3% 25.6%

      2. Generalny trend jest taki, że tego typu ataki są coraz częściej notowane, może rzeczywiście w przypadku stron nie musi być to tak bolesne (jeśli dostawca hostingu zadba o backupy), jak w przypadku zaszyfrowania dysku na komputerze osobistym. Jednak tak jak napisałeś, kwestia backapuów na których już coś mogło się dziać dużo wcześniej może nieco utrudnić sprawę. Stronę można przywrócić, ale czy jutro znów nie zobaczymy żądania okupu?;) W zeszłym roku nie pamiętam takich historii, natomiast w tym spotkałem się już z zakodowanymi stronami.

      Jeśli chodzi o komentarze do rad:
      Rada 1 – Tak wiem, że formularz może wyglądać bardzo różnie. Tylko czy jeśli na stronie mamy trzy zakładki plus form to instalując WordPressa trochę strzelamy do mrówki armatą. Zobacz przy statyku pilnujemy tylko FTP, nie interesują nas aktualizacje, bazy danych, nowe podatności w samym wordpressie, wtyczkach, motywach, bibliotekach. Jeśli nawet coś się sypnie trudno czyścimy całość i wrzucamy raz jeszcze (możemy zmienić kod od formularza), zmieniamy dostęp do FTP, ewentualnie do całego panelu hostingowego i pozamiatane.

      Rada 2 – Przeczytałem wpis. Pomysł z poligonem sam stosuje. Jednak z doświadczenia wiem, że zdecydowana większość osób po odbiorze strony nie zrobi żadnej aktualizacji. Przez to Rada nr 1, o WordPressa trzeba dbać a statyka postawisz i stoi. Aby stosować Twój schemat trzeba siedzieć w temacie, analizować co się dzieje, czytać changelogi. Dla wielu to oznacza za wiele czasu, czytania „dziwnych” rzeczy, jeszcze po angielsku. Jednak zostanę przy swoim, że lepiej zaktualizować i najwyżej jak coś się posypie to przywracać z kopii bezpieczeństwa, niż ominąć krytyczną łatkę;)

      Rada 3 – Nie trzymam żadnej kopi na serwerze.

      Rada 4 – Ach ten hejt na Wordfenca… Nie można stwierdzić, że nie zabezpieczają przed niczym. Tylko dzisiaj dostałem 5 maili od Wordfenca że jakiś Turek, Niemiec czy inny Ukrainiec próbowali swoich sił przy logowaniu na stronach, i nie próbowali tego milion razy tylko za 20 dostali bana i się zabawa skończyła dla danego IP.
      Obejrzałem Twoje wystąpienie z WordUp, rzeczywiście punkt dla Ciebie, nic nie wykrył chociaż dużo pomajstrowałeś( oglądałem film w częściach i mogę się mylić ale wydaje mi się, że nie zapuściłeś skanu po utworzeniu nowego pliku w katalogu głównym WP, coś mi się zdaje że to akurat Wordfence od razu by pokazał;) . Ale tak to już jest z takimi customowymi kodami, że najtrudniej jest je wykryć. Notabene przypomniała mi się moja historia z początku programowania, gdy jako nastolatek napisałem pierwszego „wirusa” w TurboPascalu. Prymityw jakich mało, znajdował plik exe usuwał go i sam zapisywał się pod tą nazwą. Myślisz, że ten kod dla ówczesnego Nortona czy NODa stanowił jakieś zagrożenie…żadnego, wszystkie skany czyste!
      W sumie z tego co napisałeś nasuwa się pytanie – czy warto instalować antywirusa na komputerze? Przecież to ten sam mechanizm, wirus i antywirus egzystują w tym samym systemie z tą różnicą że nie na serwerze tylko np. na moim czy twoim laptopie. Najlepsze jest to, że wirusy stosowały sztuczki z ukrywaniem się przed antywirusem już w epoce DOSa. Ale mimo wszystko ich używamy. Dlaczego? Przecież żaden antywirus nie da Ci gwarancji 100% zabezpieczenia komputera. Jeśli zablokuje chociaż 1 na 100 ataków to już jest lepiej niż gdyby go nie było. Tak samo jest z Wordfencem, może łatwo go obejść jakimiś trikami, ale przyblokuje ataki „hakjerów” którzy tworzą kod kiepskiej jakości albo znajdują go w cebuli. Bo takich perełek programistycznych jest raczej mało w porównaniu do całego syfu puszczanego albo przez wspomnianych „hakjerów” albo z automatu przez roboty sieciowe, gdzie dominuje eval,base64 + jakieś krzaczki w js. Dla mnie niezaciemniony, dobrze ukryty kod jest zmorą nad którą trzeba porządnie posiedzieć. A jeśli jeszcze byłby w jakimś stopniu polimorficzny to już tylko płakać i szukać;)
      Dodatkowym plusem Wordfenca jest jego prostota, jego podstawowa konfiguracja przypomina konfiguracje ziemniaka, co dla szarego użytkownika też jest dużym ułatwieniem.
      Odnośnie podatności Wordfenca, to nie myli się tylko ten który nic nie robi. Załatane, może jeszcze coś wyjdzie – załatają. Dlatego rada z punktu drugiego jest ważna.
      Podatności niestety są czymś co było, jest i będzie. Tak na szybko dwa linki z prawie tej samej branży:
      Krytyczny błąd NOD
      Norton

      Rada 5 – hehe nie jest tak łatwo jak mogłoby się wydawać;) forsuj login admin na milion i jeden sposobów, nie będziesz pierwszy;)

      Rada 6 – W sumie tak, wiedza z zakresu bezpieczeństwa jest w tym przypadku ważna. Jeśli nie ma się takiego człowieka można zawsze zlecić na zewnątrz.

      • Krzysiek Dróżdż

        No to po kolei:

        Z tym rośnięciem krzywej, to chyba zależy, gdzie patrzysz, bo dokładnie na tej samej stronie:
        https://w3techs.com/technologies/history_overview/content_management 😉

        2. Generalny trend nie ma tu nic do rzeczy. To, że coraz częściej kradnie się mercedesy, nie ma wpływu na to, czy ktoś ukradnie Twoją stronę/domenę. O ile rozumiem, artykuł nie jest o przestępstwach komputerowych, tylko o ochronie własnej strony przed atakami. A w takim kontekście, rozmowa o ransomware nie ma najmniejszego sensu. Wmawianie ludziom, że to coraz częstszy przypadek, jest po prostu niepoważne.

        Rada 1. Oczywiście wręcz przeciwnie. Nadal interesują nas wszystkie podatności we wszystkich użytych bibliotekach. Kiedy ostatnio sprawdzałeś podatności np. PHPMailera? A niby co, on nie może mieć podatności? To, że jakiś soft nie ma aktualizacji i nie informuje Cię o nich (oraz nie wskazuje, jakie dokładnie podatności zostały naprawione) bynajmniej nie oznacza, że jest on podatności pozbawiony. Pośledź trochę różne biblioteki PHP, to zobaczysz, jak często masz styczność z wadliwym softem na serwerach klientów i nawet o tym nie wiesz…

        „Czyścimy całość i pozamiatane” – no, a pozycje strony klienta w tym czasie pięknie pikują w dół 😉

        Rada 2. To chyba coś tu namieszałeś, bo nie wiem, z czym mam polemizować. Poligon jest zły, bo trzeba śledzić zmiany, a robienie tego live na produkcji jest OK, bo można cofnąć zmiany…? Jeśli pilnowanie bezpieczeństwa Twojej strony jest zbyt trudne dla Ciebie, to zleć to komuś – tak samo, jak co roku jeździsz na przegląd z samochodem, aby skontrolować jego stan. Proste. Chyba, że lubisz potem ratować w popłochu wszystkie strony, jakie posiadasz…

        Rada 3 – „Nie trzymam żadnej kopi na serwerze” – i bardzo dobrze. Mam nadzieję, że poza tym, weryfikujesz także poprawność przechowywanych kopii 😉

        Rada 4 – „Ach ten hejt na Wordfenca…” – to nie jest hejt… Spójrz proszę w kod tej wtyczki i zobacz, co ona dokładnie robi, a jak wielu podstawowych dobrych praktyk PHP nie przestrzega. Jeśli autorzy nie potrafią napisać kodu, który poprawnie obsługuje bazę danych, to może warto mieć wątpliwości co do tego, na ile są w stanie Cię zabezpieczyć.

        Innymi słowy… Jak przyjdzie do mnie 60-letni ochroniarz, z podbitym okiem i zaoferuje, że będzie mnie ochraniał, to mam wątpliwości. Tym bardziej, jeśli dowiem się, że w historii średnio co kilka miesięcy ten właśnie ochroniarz sam otwierał drzwi włamywaczom.

        Jeśli więc masz Wordfence’a, który sam co chwilę ma naprawiane podatności (czyli kod jest słaby), a do tego ktoś Ci jednoznacznie pokazuje, że ta wtyczka Cię nie zabezpiecza (bo nijak nie zabezpiecza przed modyfikacją plików na serwerze, a jeśli taka nastąpi, to malware jest w stanie bez problemu Wordfence’a zneutralizować), to chyba szkoda czasu na instalację badziewia, które robi sieczkę z bazy danych i spowalnia stronę…

        Do throttlingu czy ograniczenia błędnych logowań wcale nie potrzebujesz Wordfence’a – co więcej – inne mechanizmy są znacznie lepsze, wydajniejsze i pozbawione całej masy wad…

        „Obejrzałem Twoje wystąpienie z WordUp, rzeczywiście punkt dla Ciebie, nic nie wykrył chociaż dużo pomajstrowałeś( oglądałem film w częściach i mogę się mylić ale wydaje mi się, że nie zapuściłeś skanu po utworzeniu nowego pliku w katalogu głównym WP, coś mi się zdaje że to akurat Wordfence od razu by pokazał;) . Ale tak to już jest z takimi customowymi kodami, że najtrudniej jest je wykryć.”

        Nie, nie majstrowałem nic. Wykorzystałem jedną wadliwą wtyczkę, która pozwoliła mi wgrać na serwer mój kod PHP. (Taką lukę kilka razy posiadał choćby RevSlider). A zaraz po jego wgraniu, przy użyciu tego pliku zmodyfikowałem pliki używanego przez stroę motywu tak, aby zneutralizować Wordfence’a.

        Skany możesz wykonywać dowolne i Wordfence nic nie pokaże. Dlaczego? Bo tak jest napisany, że bez najmniejszego problemu mogę się wpiąć między jego frontend i backend i odpowiadać na jego własne requesty. Jeśli chcesz, to zamiast braku ostrzeżeń, mogę tam wstawić ostrzeżenia o treści „Ala ma kota”, albo „Uważaj, spadniesz z krzesła”. Na tym właśnie polega mój zarzut wobec Wordfence’a – pracuje na tym samym serwerze, który chroni i w żaden sensowny sposób nie weryfikuje integralności komunikacji.

        „W sumie z tego co napisałeś nasuwa się pytanie – czy warto instalować antywirusa na komputerze? Przecież to ten sam mechanizm, wirus i antywirus egzystują w tym samym systemie z tą różnicą że nie na serwerze tylko np. na moim czy twoim laptopie.”

        Nie, to jest kompletnie inny mechanizm. Ignorujesz totalnie role użytkowników, procesy, kolejność uruchamiania i warstwy systemu.

        „Przecież żaden antywirus nie da Ci gwarancji 100% zabezpieczenia komputera. Jeśli zablokuje chociaż 1 na 100 ataków to już jest lepiej niż gdyby go nie było.”

        Tak, ale… Żaden antywirus nie ma dziur, które wpuszczają na Twój komputer wirusy 😉
        I oczywiście to nadal nie jest to samo, bo… role, warstwy, itd.

        „Dodatkowym plusem Wordfenca jest jego prostota, jego podstawowa konfiguracja przypomina konfiguracje ziemniaka” – i chroni Cię mniej więcej tak samo dobrze, jak ziemniak właśnie 😉

        Problem Wordfence’a (i jemu podobnych) polega na tym, że próbuje on udawać, że robi coś, czego bynajmniej nawet nie próbuje za bardzo robić, a jednocześnie daje poczucie, że nie trzeba się tym martwić, bo ktoś się już tym zajmuje. To trochę tak, jakbyś miał robota, który sypie do psiej miski jedzenie i informuje, że nakarmił psa. I będzie to robił nawet, gdy pies zdechnie i będzie się rozkładał obok miski…

        Rada 5. Bynajmniej nie zamierzam niczego forsować. Dopóki nie zawrzemy umowy na testy penetracyjne, takie forsowanie nie byłoby zbyt legalne 😉

        Rada 6. Pełna zgoda. W końcu 🙂

        PS. Niesamowite, że ludzkość nie wymyśliła jeszcze czegoś lepszego niż komentarze… Nie podejmuję się już chyba odpowiadania na Twoją ewentualną odpowiedź na ten komentarz, bo to będzie chyba logistycznie niemożliwe 😉 (chyba, że z każdego punktu zrobimy zupełnie osobny wątek… :P)

        • Michał

          No to jedziemy dalej. Postaram się już jak najkrócej;) 1. „Z tym rośnięciem krzywej, to chyba zależy, gdzie patrzysz, bo dokładnie na tej samej stronie….” ale po przełączeniu na widok nie po miesiącach tylko po latach: https://w3techs.com/technologies/history_overview/content_management/ms/y Widać, że mimo spadku na początku tego roku cały czas podnosimy się do góry, na dzień dzisiejszy już jest więcej niż na początku roku. Na dole jest wykres lepiej widać;) 2. Może i przypadki są marginalne jednak piszę to co sam obserwuję.

          Rada 1: Oczywiście wręcz tak jak pisze;) KISS obowiązuje bezwzględnie. Nie ma co ładować na siłę WP tam gdzie go nie potrzeba. Dla strony z trzema zakładkami i formem na dobrą sprawę nie potrzebujesz, żadnej biblioteki. Kilka linijek w PHP żeby wysłać maila oczywiście może mieć podatności ale to już średnio ogarnięty web zrobi dobrze.
          – no, a pozycje strony klienta w tym czasie pięknie pikują w dół”
          Oj tutaj chyba trochę źle ten cudzysłów umieściłeś, jak już powinno być tak: „Czyścimy całość (…) i pozamiatane” ale to i tak mała manipulacja by była;) pełny cytat szedł tak: „czyścimy całość i wrzucamy raz jeszcze (możemy zmienić kod od formularza), zmieniamy dostęp do FTP, ewentualnie do całego panelu hostingowego i pozamiatane.” Myślę, że po takim zabiegu nic nie będzie pikować w dół.

          Rada 2: Więc wyprostujmy: Poligon jest ok. I jak najbardziej należy go stosować. Jednak Ty piszesz jak powinno być a ja napisze jak jest. Codziennie widzę strony na WP (chociaż problem dotyczy wszystkich CMSów). Zdecydowana większość ma ogromne zaległości z aktualizacjami ( spotykane też takie ze stary dashboardem), są zazwyczaj pozostawione same sobie(przecież chodzi), a problemy i pretensje zaczynają się wtedy jak się zaczyna sypać. Wpis był raczej dedykowany ludziom mniej doświadczonym, którzy nie znają się jakoś super na zasadach działania WP. Należy pamiętać, że aktualizacje są ok. Ludzie bardziej w temacie mogą sobie kombinować,analizować. Ludzie mniej obeznani dla bezpieczeństwa własnej strony-> robię kopie, aktualizuje
          lub super jeśli mam poligon na którym testuje co się stanie po aktualizacjach, i tak robię kopie, aktualizuje
          albo jednak inwestuję w statyka.

          Rada 3: Jakoś sobie radzę;)

          Rada 4: Odnośnie naszego ochroniarza… to się zgodzę, że ma podbite oko, dostało mu się kilka razy po wykryciu luk, jednak się chłopak poprawił, uważa już na te luki. Może nie jest doborową jednostką SWAT, która może ochraniać stronę banku czy sklepu z dziesiątkami sprzedaży dziennie.
          Wordfence(czy jemu podobne) ogranicza potencjalne ataki, nigdy w 100% ale jak pisałem niech się uda raz to już jest lepiej jakby go nie było. Ważne też aby był aktualny.
          Napisałeś, że zneutralizowałeś Wordfenca, ok ale czy każdy złośliwy kod posiada funkcje odpowiedzialna za neutralizacje? Tak jak pisałem wcześniej są perełki i są gnioty programistyczne. Można się chociaż przed gniotami obronić.

          Czy kod który przedstawiasz na WordUpie jest gdzieś dostępny? chętnie bym sobie zobaczył jak to wszystko tam sobie działa;)

          Odnośnie tego: „Tak, ale… Żaden antywirus nie ma dziur, które wpuszczają na Twój komputer wirusy I oczywiście to nadal nie jest to samo, bo… role, warstwy, itd.”
          Ponowie link:
          https://sekurak.pl/antywirus-eset-nod32-remote-admin-aktualizujcie-asap/
          A tutaj jak to wyglądało w realu:
          https://www.youtube.com/watch?v=Sk-CuFMXods&feature=youtu.be
          No na taki atak przez zwykłą stronę WWW to się chyba nawet Wordfence schowa;) Należy pamiętać, że antywirusy zazwyczaj działają z dość dużymi uprawnieniami, więc jeśli mają dziurę , kod można wykonać też z takimi uprawnieniami, wtedy role, warstwy nie będą już tak chronić jak powinny.

          Rada 5: Oczywiście, rozumiemy;)

          Rada 6: Uff;)

  2. Krzysztof

    serio poelcacie wordfence .. najbardziej dziurawa wtyczka w historii 🙂

    • Michał

      Tak jak napisałem powyżej, ważne aby był aktualny;)

  3. Mariusz Szczerbal

    Ciekawym, aczkolwiek zapomnianym rozwiązaniem jest zablokowania możliwości edycji kodu z poziomu panelu admina, jeżeli nie będziemy już nic zmieniać w kodzie.

    • Michał

      Istnieje o wiele więcej sposobów na poprawę bezpieczeństwa WordPressa niż te przytoczone. Twój pomysł jest jednym z nich. Taką blokadę umożliwia np. All in One Firewall and Security.

      • Krzysiek Dróżdż

        Michał,

        Sorry, ale do tego wystarczy jeden wpis w wp-config. Naprawdę, nie instaluj badziewnego kombajnu tylko po to, żeby nie zajrzeć do pliku, bo to po prostu bez sensu…

  4. Janunsz Kamiński

    Dobry artykuł i dobra polemika w komentarzach 🙂 Ostatnia jeszcze bardziej rozkrywa ten temat.

Copyright © 2017 Agencja Interaktywna Verseo - wszelkie prawa zastrzeżone

Regulamin szkolenia | Polityka prywatności | Witryna wykorzystuje pliki cookies