Pisałem dzisiaj krótki poradnik dla klienta, jak prosto zabezpieczyć stronę na WordPress i tak o to powstał niniejszy artykuł, który udostępniam wszystkim czytelnikom, jako że w ostatnich miesiącach na polskie strony idą zmasowane ataki i zabezpieczenie strony jest sprawą priorytetową dla każdego z nas. Przedstawiam mini poradnik do podstawowej ochrony stron na WordPress, który zatrzymuje większość ataków zanim dotrą do strony docelowej. Oczywiście metod na zabezpieczenie WordPress jest znacznie więcej, jednak te są podstawą od której należy zacząć, także w przypadku lepszej jakości stron zapleczowych.
Wtyczka WordPress Firewall
Wtyczka autorstwa seoegghead – Pobierz
Jest też nowa wersja WordPress Firewall 2 autorstwa Matthew Pavkova, jednakże jeszcze jej nie testowałem na WordPressowskich instalacjach – Pobierz
Dlaczego akurat ta wtyczka? Na rynku oprogramowania znajdziemy masę wtyczek, o wiele bardziej kompleksowych. WordPress Firewall oferuje podstawowy aparat filtrowania zapytań (posiada tylko podstawowe opcje konfiguracyjne) ale jednocześnie najmniej obciąża serwer ze wszystkich wtyczek związanych z zabezpieczaniem WordPress. Jeśli zajdzie potrzeba można skorzystać z bardziej rozbudowanych alternatyw jak Wordfence Security lub BulletProof Security (BulletProof to najbardziej zasobożerna wtyczka ze wszystkich, ale oferuje najbardziej rozbudowane funkcje do zabezpieczenia WordPress).
Zabezpieczenie wp-login.php metodą htaccess na UserAgent
Regułka do dodania do pliku .htaccess
<FilesMatch ^((wp-login|admin)\.php$)$>
SetEnvIfNoCase user-Agent ^mojtajnykod [NC] my_bot
Order Deny,Allow
Deny from all
Allow from env=my_bot
</FilesMatch>
Po dodaniu kodu do .htaccess, tylko osoby które legitymują się konkretnym UserAgent String (mojtajnykod), będą mogły zalogować się do strony WordPress. User Agent zmieniamy standardowo poprzez konfigurację przeglądarki na ciąg „mojtajnykod”. Możemy również użyć wtyczek dedykowanych, dla Google Chrome – User-Agent Switcher for Chrome, dla Firefox, Waterfox, Pale Moon – User Agent Switcher for Firefox. Na urządzeniach z Androidem można użyć przeglądarki Dolphin, gdzie można łatwo podmienić User Agent.
W przypadku użycia błędnego User Agent podczas dostępu do strony logowania lub panelu admina, pojawi się błąd jak poniżej…
Oczywiście metoda jest dość nieporęczna i nie każdy klient będzie chciał ją zastosować, niemniej jednak jest bardzo skuteczna przeciw atakom DDOS na stronę logowania wp-login, znacząco zmniejszając ryzyko włamania, jak również minimalizując obciążenie serwera przy zmasowanych próbach ataków (a tych w ostatnim czasie bardzo dużo). Trzeba też pamiętać, by przed wejściem na inne stronki zmienić User Agent na domyślny (spreparowanego użyć tylko do zalogowania się na administrowaną stronę). Hasło oczywiście warto zmieniać co kilka miesięcy, nie zapominając o modyfikacji konfiguracji UserAgent w przeglądarkach używanych do logowania.
Wtyczka Limit Login Attempts
Stara ale jara jak to mówią 🙂 Do blokowania ataków DDOS na wp-login, jak ktoś nawet odgadnie hasło z User Agent to będzie miał do pokonania jeszcze tę zaporę. W zależności od naszej konfiguracji, 3 lub 4-krotna zła próba zalogowania zakończy się zbanowaniem adresu IP na okres 24h, przy kolejnych próbach adres IP może zostać dożywotnio zbanowany.
Limit Login Attempts można pobrać z oficjalnego repozytorium wtyczek – Pobierz. Oczywiście w jej zastępstwie możecie zainstalować inną wtyczkę oferującą podobną funkcjonalność, jednak mam do niej sentyment dlatego rekomenduję 🙂
Blokowanie adresów IP lub podsieci
Blokowanie abusywnych adresów IP i/lub całych podsieci atakujących instalacje WodPressowskie. Jakiś czas temu z uwagi na zmasowane ataki udostępniłem tego typu plik. Więcej informacji znajdziesz na podstronie – https://techformator.pl/plik-htaccess-z-lista-abusywnych-podsieci/
Jego zawartość proszę dodać do istniejącego pliku .htaccess. Wbrew panującym opiniom co niektórych osób dodanie jednej linijki kodu z nawet 1000 adresów podsieci nie powoduje znaczącego obniżenia wydajności serwera, niemniej jednak adresy IP i/lub podsieci można efektywniej blokować dodając regułki do pliku konfiguracji serwera lub bezpośrednio na firewallu. W sieci dostępne są skrypty do zamiany regułek htaccess deny na IPtables, zawsze można też samemu napisać taki skrypt w bashu.
Monitorowanie
Blokowanie jest tylko jedną stroną medalu. Równie istotną rzeczą jest monitorowanie działań użytkowników/botów. Na stronach możemy zainstalować dedykowane wtyczki identyfikujące działalność użytkowników (np. Wordfence Security posiada taką funkcję), warto również co jakiś czas przeglądać logi serwera. Do łatwiejszego przeglądania można użyć komercyjnej aplikacji Apache Logs Viewer. W przypadku wykrycia podejrzanego działania, można zablokować adres IP lub całą podsieć, zablokować abusywne query strings. Istnieją również systemy zbierające dane o atakach i wysyłające do nas mail. W przypadku gdy mamy poinstalowanych wiele zaplecz, można w ten sposób wydobyć sporo cennych informacji, które pozwolą zwiększyć bezpieczeństwo nie tylko u klientów, ale również w sieci blogów zapleczowych.
Jak będzie czas, postaram się napisać bardziej kompleksowy poradnik w zakresie zabezpieczania systemu CMS WordPress.
Małe podlinkowanie artykułu który kiedyś napisałem zbierając informacje na ten temat z sieci
http://mojeprogramy.com/zabezpieczenie-wordpress
A obecnie używam wtyczki All In One WP Security, która ma w sobie sporo dobrych funkcjonalności
A tu polecane muszę przetestować
Temat na TOP-ie więc proszę innych czytających o stosowane przez nich rozwiązania
Chyba pomyliłeś DDOS z brute forcem 🙂
Przecież zmasowany atak słownikowy lub brute force na strony logowania to nic innego jak DDOS (ten sam schemat tylko inny cel, w pierwszym złamanie zabezpieczeń, w drugim całkowite zablokowanie możliwości odpowiedzi serwera). W przypadku gdy na stronę logowania idzie pełno ataków serwer zamiast obsługiwać normalne zapytania od użytkowników musi poświęcać swój czas na obsługę śmieciowych queries od atakujących na wp-login i dlatego napisałem DDOS. PS. Mówię tutaj o floodowaniu podstrony i wtedy sformułowanie DDOS jest zasadne, aczkolwiek faktycznie jeśli chcemy być precyzyjni można pokusić się o sformułowanie brute force lub dictionary attack co nie zmienia charakteru tych typów ataku bo przy zmasowanym ataku to będzie typowy DDOS na stronę, z tym że konkretną – logowania. Dzięki za komentarz. Pozdrawiam!
Ja korzystam z cloudflare i polecam innym 😉
Regularne backupy to podstawa.
Już 20 minut używam różnych kombinacji i mimo to nie chce zadziałać sposób z useragent. Nawet wziąłem Twój kod żywcem do .htaccess z „mojtajnykod”, ustawiłem taki user-agent na FF i nie działa (sprawdzałem narzędziem online – widzi user-agent w postaci mojtajnykod). Masz proszę jakiś pomysł, że mi to nie działa? Powiem, że testowałem rozwiązanie z logowaniem jedynie z określonego IP i to u mnie poprawnie działa…
Przykład:
Dodajesz regułkę do htaccess ze swoim tajnym kodem.
W przeglądarce instalujesz dodatek UserAgent (w przykładzie UserAgentSwitcher dla Firefox)
Definiujesz nowy useragent (New => New useragent)
Poniżej zrzut…
Następnie przed logowaniem do WordPress zmieniasz useragent w przeglądarce na „logowanie do wp”.
Metoda prosta i skuteczna.
Dodam jeszcze, że jak masz zabezpieczenie ustawione nie tylko na wp-login ale i na panel admina, to czynności administracyjne będziesz mógł wykonać wyłącznie z tym konkretnym user agent. Każdy inny spowoduje zablokowanie dostępu do panelu administracyjnego.
Wraz z tą metodą warto jeszcze w htaccess zabezpieczyć sam dostęp do pliku .htaccess na serwerze, tak by nie można dostać się do niego „z zewnątrz”. Oczywiście pomijam kwestię uprawnień, bo to jest jasne.
Dziękuję za szybką odpowiedź, ale u mnie chyba któreś z poleceń w .htaccess jest nie interpretowane przez mój hosting (hekko)….Bo mam wszystko identycznie. Szkoda, bo to fajna metoda, dużo lepsza od blokowania IP, które niestety raz po raz mi się zmienia.
Od dawna nie korzystam z usług Hekko bo to kiepski hosting, także nie doradzę. Dyrektywy w htaccess też bazują na priorytetyzacji, trzeba by było wszystko od A do Z prześwietlić.
Wczoraj posiedziałem troche bo chciałem roboty wyeliminować szkodliwe i tak sie nazbierała lista 5tyś.
Blokowanie ich w robots.txt jest mało skuteczne (ale nie o tym)
Czy dodanie az takiej liczby do htaccesa nie spowoduje jakiegoś wolniejszego działania strony bo bede musiał niezłe filtrować i czy w ogolę stosowanie takiej liczby ma sens a moze lepiej zablokować wszytko i odblokować tylko wybrane (ale nie wiem jak to zrobić)
Jeżeli serwer jest kiepsko zoptymalizowany to może być spadek wydajności, natomiast jeżeli admin serwera jest kumaty i wie co i jak, dodanie nawet większych partii danych nie spowoduje dużych spadków, różnice liczone są w milisekundach. Najlepszym wariantem jest blokowanie bezpośrednio na firewallu, a najlepiej sprzętowym, wtedy serwer w ogóle nie odczuwa skutków blokowania.
Aby zastosować blokowanie na firewallu (softwareowym) trzeba mieć VPS-a lub serwer dedykowany, na hostingach współdzielonych możesz zastosować jedynie htaccess.
Wykorzystując plik htaccess musisz sobie odpowiedzieć na pytanie, po co chcę to zrobić i jakie korzyści z tego wynikają.
Htaccess można wykorzystać do blokowania adresów IP skąd idą ataki na stronę, możesz również przyblokować znane bad boty (USER_AGENT), które przy każdej próbie dostępu otrzymają 403. Możesz również blokować via htaccess bad queries, czyli zapytania, które mają za zadanie sprawdzenie zabezpieczeń witryny i/lub przesłanie instrukcji szkodliwych dla strony. Za pomocą htaccess możesz również blokować fake traffic, generowany przez różnego typu stronki do nabijania ruchu. Taki traffic jest szczególnie w sklepach internetowych niepożądany i powoduje zwiększenie ilości pracy podczas raportowania. Ogólnie zasada jest prosta, wszelki ruch który ma małe szanse na konwersję powinien zostać ograniczony lub całkiem zablokowany. Zmniejszenie fakeowego ruchu, to również niższe koszty utrzymania infrastruktury oraz polepszenie satysfakcji użytkowania witryny przez zwykłych (realnych) użytkowników. Zalet jest wiele i one znacznie przewyższają wady wynikające z zastosowania htaccess czyli spadek responsywności serwera – bo on jest zauważalny ale liczony przeważnie w milisekundach, chyba że admin serwera schrzanił jego konfigurację – wtedy duże pliki htaccess mogą już w większym stopniu spowolnić działanie witryny.
Zrób sobie proste testy, najlepiej puść serię testów z htaccess wypełnionym regułkami blokowania i puściutkim – wtedy będziesz miał czarno na białym jakie Twój serwer otrzymuje opóźnienia wynikające z kwestii czasu przetwarzania pliku.
Największe opóźnienia generuje nie allow,deny ale mod_rewrite i jeśli miałbym wskazać regułki których należy unikać, to właśnie byłaby ta druga wykorzystująca mod_rewrite.
Odnosząc się do blokowania robots.txt – robots nie gwarantuje zablokowania bota, poza tym tego typu bot wejdzie na stronę, pobierze wpierw plik robots, zinterpretuje jego regułki i dopiero wtedy podejmie decyzję o opuszczeniu indeksowania witryny, więc na ścisłość masz 1 wygenerowane wejście na sesję.
Szkodliwe boty zaleca się blokować bezpośrednio w htaccess a nie w robots.txt ponieważ one nie respektują żadnych reguł w robots.
Pozdrawiam!
Cześć,
bardzo fajne porady. W sumie jest to taki must have dla osób prowadzących stronę na WordPressie. Jednak mam pewną wątpliwość co do metody z dyrektywami konfiguracyjnymi w htaccess. Widzę, że ktoś nawet pytał o tą metodę. Czy nie lepiej (i przede wszystkim krócej i bezpieczniej) zamiast User-Agenta zdefiniować tam adres IP administratora na zasadzie działania białych list?
Pozdrawiam HEP
Masz całkowitą rację, na adres IP uzyskuje się większe bezpieczeństwo, jednakże jest kilka kwestii:
a) Jeśli mamy zmienne IP to już tej metody nie zastosujemy (chyba że wykorzystamy pośrednika ze stałym IP np. VPN, dedykowane IP i tunel SSH),
b) Jeżeli sieć z której korzystamy na co dzień (w domu) np. WiFi lokalnego dostawcy neta czy osiedlowa, identyfikuje nas jednym adresem IP (external IP) to i tak ryzyko tylko ograniczamy, każdy będący w sieci zostanie „wpuszczony” na stronę.
c) W przypadku logowania się na www z domu, z pracy, czy z urządzeń mobilnych – mając tym samym różne adresy IP, musimy dodać każdy z nich. Z mobile o tyle problem, że wielu dostawców oferuje zmienne IP. Można to przeskoczyć stosując VPN, więc na siłę, dla chcącego znajdzie się rozwiązanie 🙂
Nie zmienia to faktu, że na IP jest bezpieczniej, ale na UA jest wygodniej i elastyczniej.
W jaki sposób zablokować dostęp do witryny z poziomu .htaccess tylko dla konkretnej wersji przeglądarki? Mam na myśli np. firefox 47.1
@Adam, dobry temat na odrębny artykuł. Bardzo łatwo to zrobić. Wygospodaruję dzisiaj z 30 minut i przygotuję odrębny poradnik na ten temat. Pozdrawiam i dzięki za pomysł na artykuł 🙂
Dzięki Mariusz w takim razie czekam na artykuł z niecierpliwością bo muszę zablokować dostęp do strony pewnym osobom a raczej botom a mogę ich tylko zlokalizować po wersji przeglądarki
@Adam, zgodnie z obietnicą stworzyłem wpis na temat blokowania konkretnych wersji przeglądarek – https://techformator.pl/htaccess-jak-zablokowac-dostep-do-witryny-dla-danej-wersji-przegladarki/
Czy zetknęliście sie z tym, aby ta wtyczka wp security all in one blokowała dzałanie wpisów o przekierowaniach 301 w htacess? Mam kuriozalną sytuację (jak dla mnie), że niektóre przekierowania 301 mi działają, a inne nie. I w dodatku strony przekierowywane nie różnią się wcale zawartoscią. Po prostu przekierowanie z nazwa 1 na nazwa2 działa, a z nazwa3 na nazwa4 nie działa :/ Używam w tej wtyczce modułu apache. Gdy robię to samo używając modułu wordpressowego działa 🙂 🙂
A kod samego przekierowania wygląda tak (wpis został przez wtyczkę dodany po znaczniku „# END WordPress”
# Created by Redirection
# Thu, 17 Nov 2016 12:19:01 +0000
# Redirection 2.4.5
RewriteRule ^/event/nazwa1$ /event/nazwa2/ [R=301,L]
RewriteRule ^/event/nazwa3$ /event/nazwa4/ [R=301,L]
# End of Redirection
NIe kumam – zapewne problem jest gdzieś wyżej w htaccess ale nie chcę tu lepić robali
Ktoś ma jakieś doświadczenia w tym zakresie?
Ciężko powiedzieć, trzeba analizować ten konkretny przypadek. Rzeczy które mogą powodować problemy mogą być zaszyte w zupełnie innym miejscu np. wtyczkach do cachowania o ile są stosowane i mają uaktywnione opcje cachowania przekierowań. Temat do analiz 🙂
PS. Użyj alternatywnej wtyczki np. Safe Redirect Manager i sprawdź sytuację.
Dzięki MAriusz – sprawdzę tamtą wtyczkę
Faktycznie redirections różnie się zachowuje na stronach – na jednej stronie w ogóle mi przekierowań w wersji apache nie włączał. WordPressowy moduł działa bo chyba nie interweniuje on w htacess. Tu mnie zaintrygowało że jedno przekierowanie zadziałało a inne juznie wchodzą
No ja dlatego na zapleczach z Redirection całkiem zrezygnowałem, bo działało jak chciało. Safe Redirect Manager w większości przypadków działał prawidłowo, choć jego obsługa nie była najwygodniejsza.
Witam, bardzo spodobał mi się sposób dostępu do panelu WP przez UserAgent. Problem w tym, że skopiowałem Twoją regułę do htaccess, dodałem nowe konto w dodatku UserAgentSwitcher (tak jak na Twoim zrzucie ekranu). Zmieniam profil na mojtajnykod i wpisując adres strony do panelu admina i dostaje błąd 403. Jakiś pomysł co robię źle ?
Wpierw sprawdź, czy faktycznie Twoja przeglądarka poprawnie legitymuje się na zewnątrz „tajnym kodem”.
Możesz wykorzystać do tego to małe narzędzie – https://techformator.pl/tools/simple-user-agent-checker.php
Dzięki za wartościowy artykuł. Będę polecał innym.
Napisałeś powyżej, że nie polecasz Hekko. Ja noszę się z zamiarem zmiany hostingu z linuxpl. Wszystko jest ok, ale gdy chciałem wykupić cert SSL, to zażądali 240 zł za najtańszy. Nie mają SNI.
Jeżeli nie Hekko, to jaki hosting byś polecił? Oczywiście na WP.
@Konrad, z hostingów na chwilę obecną mogę polecić myDevil, również dlatego, że oferują do konta darmowe certyfikaty Let’s Encrypt (auto-odnawialne), a to jest niesamowity atut. Jest też Unixstorm, ale oni kompletnie nie wspierają Let’s Encrypt i nie da się nawet u nich zweryfikować manualnie certyfikatów od LE. HTTPS to niestety konieczność, może nie za pół roku, rok, ale za 2 lata każdy serwis będzie musiał go mieć, kwestia czasu.