6 filtrów bezpieczeństwa WordPressa.

Niebezpiecznik, Z3S czy Sekurak robią świetną pracę na rzecz bezpieczeństwa w internecie, dlatego dziwi mnie fakt, czemu blog prowadzony przez Patryka Krawczyńskiego pod adresem nfsec.pl jest tak pomijany. Tym bardziej, że Pan Patryk 14 grudnia 2020 opisał ciekawą podatność WordPressa, która mimo 7 lat nie jest jakoś specjalnie „łatana”. Chodzi dokładnie o XMLRPC, czyli Remote Procedure Call w formacie XML, trochę archaiczne rozwiązanie służące do wymiany danych między web aplikacjami.
Bardzo lubię WordPressa, ale czasem mnie dziwi polityka twórców tego systemu zarządzania treścią stron internetowych, jak dorzucanie na siłę szablonu w wersji 5.6 czy włączanie XMLRPC, który – jak zauważa Patryk Krawczyński – może posłużyć w prosty sposób do zbudowania botnetu, dzięki któremu można DDoS-ować strony. Pomijam już, że samo XMLRPC może służyć do wyciągania prawdziwego adresu IP strony schowanej za Cloudflarem… Więcej znajdziecie w tym konkretnym artykule oraz źródłach, do których linkuje autor.
Niemniej powyżej wspomniany blog o bezpieczeństwie obrazuje jak wiele osób absolutnie pomija kwestię bezpieczeństwa w projektach opartych o WordPressa, dlatego poniżej przedstawiam w 6 punktach, jak wygląda u nas koncepcja bezpieczeństwa zaplanowana dla projektów opartych o tego CMSa.

1. Cloud WAF

Firewall w chmurze, znany też jako reverse proxy, czyli komputer, który łączy hosting naszej strony z odbiorcami i docelowo chroni przed cyberprzestępcami i botami. Czyli zasada jest bardzo prosta. Wpisujemy adres strony i nasze żądanie jako osoby, która chce obejrzeć stronę jest przepuszczone przez serwer proxy, gdzie są zaimplementowane reguły, które zablokują nam dostęp, jeśli serwer uzna, ze jesteśmy atakującym. Najbardziej popularnym rozwiązaniem tego typu jest Cloudflare, który dodajemy standardowo do praktycznie każdego projektu (prócz statycznych stron opartych o czysty HTML). Nawet jeśli operujecie w zakresie darmowych usług jakie świadczy Cloudflare, to jest on niesamowitym narzędziem do walki w hakerami i automatami szukającymi podatności. Oczywiście wymaga to trochę czasu i ręcznej konfiguracji, ale wymierne efekty realnie poprawią bezpieczeństwo waszej witryny. Dobrze, żeby Cloudflare komunikował się z innymi warstwami, które opiszę poniżej. Już pomijam fakt, że Cloudflare co jakiś czas rozszerza swoją darmową ofertę o nowe usługi, a jak ma awarię to przeprosi i opisze przyczyny na swoim blogu w obszernym raporcie. Coś, co jest nieznane w wielu polskich firmach specjalizujących się w IT.
Cloudflare ma wiele alternatyw, które oferują bardzo podobny poziom zabezpieczeń, np. taki Arvan Cloud, który być może niebawem dodamy do naszej oferty jako alternatywę dla osób, dla których CF jest zbyt trudny. Jako ciekawostkę dodam, że wiele konkurencyjnych firm w dziedzinie bezpieczeństwa dla CF, chowa swoje strony internetowe za… Cloudflarem.

Jeśli chcecie zobaczyć jak działa taki cloud WAF, to odsyłam do filmu promocyjnego spod bandery CF.

2. Hosting WAF

Każda szanująca się firma hostingowa powinna dać możliwość włączenia w panelu admina dodatkowego web app firewalla, który jest zainstalowany bezpośrednio na hostingu. Zawsze taką opcję włączamy dla naszych klientów, ponieważ jest to drugi filtr, który będzie dbał o bezpieczeństwo strony internetowej. Najbardziej rozpowszechnionym rozwiązaniem jest ModSecurity, ale istnieje szereg alternatyw jak np. Immunify360, Shadow Deamon, Naxsi, etc – jednak wszystko zależy od firmy hostingowej. Przy czym uczulam, że nie warto wierzyć firmom, które forsują swoje magiczne firewalle, bo ciężko jest nietechnicznej osobie je zweryfikować. Łatwiej jest się przekonać do rozwiązań powszechnie znanych i stosowanych, niż do autorskich kodów, które mało kto testował. Nie oznacza to, że są one z gruntu złe, ale częściej są marketingowym bełkotem, a nie realną ochroną.

Na koniec przypomnę, że trzeba przetestować hostingowy WAF, żeby sprawdzić, czy nie blokuje normalnych zapytań kierowanych pod adresem naszej domeny i ewentualnie ustawić jego siłę obrony na odpowiednim poziomie.

3. Plik .HTACCESS

To jest kolejny front, który powinien być brany pod uwagę, jeśli chodzi o zabezpieczanie naszej strony czy sklepu online. Plik .htaccess to nic innego jak konfiguracyjny plik, który pozwala zarządzać kontem hostingowym. Może np. służyć do przekierowań czy do blokad, a nawet do ustawiania prostych ograniczeń w postaci wymuszania hasła dostępu. W internecie, czy naszej serii Zabezpieczamy WordPressa znajdziecie przykłady, w jaki sposób można używać tego pliku do ochrony własnej witryny internetowej. Pamiętać należy jednak, że dyrektywy w pliku htaccess mogą być różne dla różnego rodzaju serwera, dlatego trzeba zerknąć do dokumentacji lub dedykowanych poradników.
Żeby dodatkowo skorzystać z potencjału tego rozwiązania polecam zapoznać się z projektem 7G Firewall, czyli bardzo obszernymi i zaawansowanymi regułami, które pomogą odrzucać od naszej strony niebezpieczne żądania. W sumie taki prawdziwy firewall. Ostatnią wersją jak zdradza nazwa jest 7 generacja, ale za chwilę pojawi się wersja 8G. Póki co odsyłam was do strony projektu.

4. Kod zaszyty w WP

Same pliki WordPressa mogą być kolejnym mocnym ogniwem, który zastosujemy do ochrony naszej strony. Możemy zmienić w nich sole strony, prefix bazy (podczas instalacji), oflagować ciasteczka, zmienić domyślną nazwę folderu z pluginami, wyciągnąć domyślne dane z wp-config, zablokować nieszczęsny XMLRPC, zablokować REST-API, zablokować info o CMSie, itd. Możliwości jest tyle, co poradników w internecie i część znajdziecie w naszej serii Zabezpieczamy WordPressa, bo my z reguły je dodajemy do każdego projektu opartego o WP.
Żeby być klarownym opiszę jak działa zmiana domyślnej nazwy folderu plugin. Boty z reguły szukają po domyślnej ścieżce, która właśnie zawiera plugins i jeśli zmienimy jego nazwę, np. na baboki, to w odpowiedzi bot otrzyma odpowiedź 404 albo 403 i sobie pójdzie.
Jedyne o czym należy pamiętać, to żeby nie kopiować bezmyślnie kodów z internetu, tylko wcześniej je zrozumieć i sprawdzić na testowej stronie.

5. Wtyczki bezpieczeństwa

Część ludzi, którzy słyszą o wtyczkach bezpieczeństwa doznaje konsternacji, bo z jednej strony są doradcy, którzy wmawiają, że wtyczki są nic nie warte, a z drugiej osoby, które reklamują je jako remedium na wszystkich hakerów. Jeśli spotkasz takiego agitatora – obojętnie z którego strony – to pamiętaj, że albo chce na Tobie zarobić albo jest niespełna rozumu i bezmyślnie powtarza zasłyszane głupoty.
Wtyczki bezpieczeństwa, i niekoniecznie mówię tu o kombajnach pokroju Wordfence, a też o pluginach, które np. włączają tylko 2FA podczas logowania, robią swoją robotę, ale nie należy zapominać, że same są pełne kodów i mogą zawierać dziury, które ułatwią atak na stronę. Jednak w połączeniu z tymi wszystkimi rozwiązaniami, które ogólnie opisałem powyżej jest to bardzo dobrą płaszczyzną ochrony, bo może np. zawierać kontekstowy WAF albo może wymieniać informacje – np. o zablokowanych adresach IP – z Cloudflarem (my stosujemy takie rozwiązanie w pakiecie SEO Firewall). A wszystko tak naprawdę zależy od 6 czynnika, czyli….

6. …od Ciebie.

Tak, to TY jesteś głównym i najważniejszym mianownikiem, który ma spajać wszystkie 5 poprzednich rzeczy odpowiedzialnych za ochronę. Nie ma Ciebie, to nie ma ochrony. Oczywiście można część rzeczy zautomatyzować, ale to od człowieka powinna zależeć ostateczna decyzja, to od człowieka powinno zależeć co jest włączone, a co nie. Dlatego Twoja świadomość samego CMS-a oraz rozwiązań, które są powyżej sprawi, że Twoja strona będzie bardzo odporna na sieciowe ataki.

Mało tego, możesz dodatkowo swoim zachowaniem wpływać bezpośrednio na bezpieczeństwo własnej witryny i to w kilku płaszczyznach:
– sprawdzaj logi (bardzo ułatwiają to wtyczki bezpieczeństwa, bo przedstawiają je w przystępny sposób)
– testuj stronę ( nie potrzebujesz wiedzy technicznej, bo możesz użyć automatycznych skanerów)
– rób audyty strony (np. czy hasła nie są za łatwe, kto ma jakie uprawnienia, etc)
– przygotuj sobie strategię w razie ataku, który skończy się powodzeniem.

Jeśli nawet nie będziesz potrafił żadnej z tych rzeczy , to ostatecznie wynajmiesz opiekę techniczną, np. nas lub kogoś kto naprawi ci stronę po infekcji malwarem. Przecież wiadomo, że serwer raczej sam sobie ochrony nie wynajmie, no chyba, że przez pomyłkę stworzyłeś sztuczną inteligencję. 😉