publikacja: 25 lipca 2013, autor: , komentarzy 248 https://wpninja.pl/artykuly/jak-zabezpieczyc-wordpressa-przed-atakiem-brute-force-i-dlaczego-jeszcze-tego-nie-zrobiles/

Jak zabezpieczyć WordPressa przed atakiem „brute force” i dlaczego jeszcze tego nie zrobiłeś?

Jak zabezpieczyć WordPressa przed atakiem „brute force” i dlaczego jeszcze tego nie zrobiłeś?

Narastająca liczba ataków "brute force" jest prawdziwą zmorą WordPressowych blogerów. Ostatnio sam się o tym przekonałem w dosyć bolesny sposób. Wprawdzie nikt się nie włamał, ale obciążenie związane z licznymi próbami rozłożyło serwer na łopatki. Czym jest atak "brute force", jak przebiegał on w moim przypadku i, co najważniejsze, jak się przed nim zabezpieczyć?

„brute force” w kontekście WordPressa

W przypadku WordPressa celem wspomnianego ataku jest uzyskanie dostępu do panelu administracyjnego. Wykorzystywane są do tego specjalne skrypty, które poprzez formularz logowania próbują wszystkich możliwych kombinacji aż natrafią na tą właściwą.

  • jak przebiega atak?

    Proces odbywa się całkowicie automatycznie i najczęściej pochodzi z różnych komputerów. Skrypty są napisane w taki sposób, że w pierwszej kolejności wykorzystują listę najczęściej używanych danych dostępowych.

    Przykładowo, 5 bardzo popularnych fraz to:

    • dla nazwy użytkownika: admin, test, administrator, support, aaa
    • dla hasła: admin, 123456, password, 12345678, 666666

    Jak widać użycie „admin” zarówno do nazwy użytkownika jak i hasła to zdecydowany faworyt. Winę za taki stan rzeczy po części ponosi sam WordPress, który przy instalacji sugeruje „admin” jako nazwę użytkownika (w wersjach wcześniejszych niż 3.0 wręcz ją narzucał):

    Sugerowanie "admin" jako nazwy użytkownika / WordPress 3.5.2

    Sugerowanie „admin” jako nazwy użytkownika / WordPress 3.5.2

  • kto jest narażony na atak?

    Krótko mówiąc – wszyscy użytkownicy WordPressa. Nawet ci, którzy używają wersji hostowanej (wordpress.com) nie mogą czuć się bezpiecznie.

    Niestety, wraz ze wzrostem popularności WordPressa rośnie zainteresowanie nim wśród hakerów, którym zależy na dotarciu do jak największej liczby potencjalnych ofiar.

  • jakie mogą być skutki udanego ataku?

    Po uzyskaniu dostępu do panelu administracyjnego skrypt może zrobić wszystko to, na co pozwoliła mu fantazja jego twórcy:

    • dodać ukryte odnośniki do ofert środków na potencję itp.,
    • wysyłać spam z Twojego konta pocztowego,
    • wykraść bazę zawierającą dane dostępowe wszystkich użytkowników,
    • uruchamiać strony pornograficzne w tle,
    • podmienić stronę na treści zawierające manifest hakera,
    • uruchamiać aplikacje Java na komputerze czytelnika,
    • instalować wtyczki o różnym przeznaczeniu.

    Mało? Dorzućmy do tego prawdopodobieństwo użycia Twoich danych dostępowych przy atakach na inne strony (może na Twoje konto PayPal?).

  • czy mocne hasło i niestandardowa nazwa użytkownika wystarczą?

    Byłoby świetnie, ale niestety nie.

    Każda jednorazowa próba ataku wykorzystuje zasoby serwera, na którym znajduje się strona. Serwer musi wyświetlić stronę logowania, przetworzyć podane dane i zwrócić odpowiedni komunikat z błędem, a to generuje tzw. obciążenie.

    Przy pojedynczych próbach włamania obciążenie jest minimalne, ale przy zmasowanym ataku zaczyna robić się nieciekawie.

    I właśnie to spotkało moją stronę.

Przebieg ataku „brute force”

Mimo iż atak nie zakończył się powodzeniem, to i tak moja strona przestała działać. A wszystko wyglądało tak:

  • 7 dni wcześniej:

    Zauważam pierwsze próby włamania się do panelu administracyjnego, ale z uwagi na ich niewielką ilość całkowicie je lekceważę.

  • 3 dni wcześniej:

    Liczba prób dostania się do panelu administracyjnego nieznacznie rośnie. Z ciekawości rozpoczynam testowanie wtyczek:

    • Limit Login Attempts: umożliwia zablokowanie danego IP po n-nieudanych próbach zalogowania;
    • Stealth Login Page: zastępuje wszystkie adresy strony z formularzem logowania jednym, unikalnym.

    Wnioski? Wtyczki może i przydatne, ale tylko dla pojedynczych prób włamania. Przy zmasowanym ataku, który mnie czekał na nic się nie zdały, ponieważ ich działanie również korzysta z zasobów serwera.

  • atak, godzina 16:

    Liczba prób sforsowania formularza logowania rośnie do liczby 2 na sekundę. Oczywiście ja nic o tym nie wiem.

  • atak, godzina 17:

    Dociera do mnie, że coś jest nie tak. Przy próbie wyświetlenia strony (z konta administratora) wyświetla się poniższy komunikat:

    Service Temporarily Unavailable

    The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

    Zaglądam do logów serwera i zauważam, że jest sporo odwołań do wp-login.php, który odpowiada za formularz logowania:

    (...)
    [16:30:01] 0.384 /home/xxx/domains/wpninja.pl/public_html/wp-login.php
    [16:30:01] 0.384 /home/xxx/domains/wpninja.pl/public_html/wp-login.php
    [16:30:02] 0.424 /home/xxx/domains/wpninja.pl/public_html/wp-login.php
    [16:30:03] 0.392 /home/xxx/domains/wpninja.pl/public_html/wp-login.php
    [16:30:04] 0.388 /home/xxx/domains/wpninja.pl/public_html/wp-login.php
    [16:30:04] 0.376 /home/xxx/domains/wpninja.pl/public_html/wp-login.php
    [16:30:05] 0.372 /home/xxx/domains/wpninja.pl/public_html/wp-login.php
    [16:30:05] 0.372 /home/xxx/domains/wpninja.pl/public_html/wp-login.php
    (...)

    (kolejne wartości oddzielone spacją to: godzina, poziom obciążenia procesora i plik)

    Widziałem to już wcześniej, ale nie w takiej ilości. Na wszelki wypadek blokuję plik wp-login.php poprzez zmianę praw dostępu (chmod) na 000, próby włamania spadają z 2 na sekundę do 0. Mimo to, strona nadal nie daje znaków życia.

    Sprawdzam po kolei: serwer pocztowy – działa, FTP – działa, wyświetlanie stron dla niezalogowanych – działa (dzięki wtyczce do cachowania), zaplanowana publikacja – brak. Dochodzi godzina transportu 4 liter z biura do domu więc z myślą, że to tylko chwilowa „czkawka” serwera, postanawiam czekać…

  • atak, godzina 22:

    Nic się nie zmieniło, strona nadal nie działa więc postanawiam skontaktować się z obsługą techniczną serwera. Spisuję wszystkie istotne informacje w liście i z cichą nadzieją na szybką odpowiedź klikam „wyślij”.

  • atak, godzina 22:09:

    Udało się, mimo później pory ktoś zareagował. Czytam:

    (…) z tego właśnie czasu (16-17) wisiało wiele zawieszonych procesów PHP, które uniemożliwiły powstawanie nowych.

    Po ręcznym usunięciu zawieszonych procesów (przez administratora serwera) wszystko wróciło do normy. Idę spać ze spokojną głową.

  • dzień później:

    Loguję się do panelu klienta w firmie hostingowej i przeglądam dane dotyczące wygenerowanego obciążenia za poprzedni dzień:

    Statystyki obciążenia serwera z dnia ataku

    Statystyki obciążenia serwera z dnia ataku

    Dzień, w którym został przeprowadzony atak „brute force” (trwający zaledwie 1 godzinę) wygenerował obciążenie 8-9 razy większe niż zwykle. Gdybym nie zorientował się w porę, to po 3-5 godzinach wyczerpałbym cały dostępny limit obciążenia a wtedy moja strona zostałaby najprawdopodobniej zablokowana (aż do momentu opłacenia faktury za dodatkowe zasoby).

    Pozostaje jeszcze jedno pytanie – co zrobić żeby skutecznie zabezpieczyć się przed podobnymi sytuacjami w przyszłości?

Zabezpieczanie się przed atakiem

Okazuje się, że jednym z prostszych sposobów a przy tym bardzo skutecznym jest nałożenie dodatkowego hasła poprzez plik .htaccess.

Cały proces to 3 proste kroki:

  • krok 1: utwórz plik z danymi dostępowymi

    Zacznij od przygotowania specjalnego pliku, w którym przechowywane będą dane dostępowe:

    • utwórz na pulpicie nowy plik o dowolnej nazwie (np. .htpasswd);
    • otwórz stronę ze specjalnym generatorem, wypełnij pola „username” oraz „password” podając odpowiednio nazwę użytkownika oraz hasło, którymi będziesz się posługiwać i kliknij na „create .htpasswd file”;
    • skopiuj wygenerowany ciąg znaków (będzie rozpoczynał się od nazwy użytkownika) do utworzonego wcześniej pliku;
    • prześlij plik na serwer (np. za pomocą klienta FTP), lokalizacja jest właściwie dowolna, ale najlepiej żeby plik znajdował się poza katalogiem przeznaczonym na pliki stron (katalog taki nazywa się najczęściej public_html).
  • krok 2: ustal adres pliku na serwerze

    Teraz ustal adres (ścieżkę) na serwerze do wgranego przed chwilą pliku. Jeśli go znasz to świetnie, możesz ominąć ten krok, a jeśli nie to:

    • utwórz na pulpicie nowy plik PHP o dowolnej nazwie (np. info.php);
    • w treści pliku podaj następujący ciąg:
      <?php echo dirname( __FILE__ ); ?>

      (jest to funkcja PHP, która wyświetli ścieżkę na serwerze);

    • prześlij plik na serwer (FTP) do miejsca, w którym będzie można go otworzyć w przeglądarce (np. do katalogu głównego Twojego WordPressa);
    • otwórz plik w przeglądarce; jeśli wgrałeś go do katalogu głównego WordPressa a Twoja strona dostępna jest pod adresem:
      http://nazwa-strony.pl

      to adres pliku będzie następujący:

      http://nazwa-strony.pl/info.php

    Ciąg, który się pojawi będzie przypominał coś w stylu:

    /home/klient.dhosting.pl/wpn/wpninja.pl/public_html/

    Jest to ścieżka do katalogu, w którym znajduje się plik info.php. Teraz powinieneś ją tak zmodyfikować, aby wskazywała on na wgrany w 1. kroku plik .htpasswd. Tzn. jeśli wgrałeś go do katalogu o jeden poziom wyżej, to pełna ścieżka będzie następująca (bazując na naszym przykładzie):

    /home/klient.dhosting.pl/wpn/wpninja.pl/.htpasswd

    Po ustaleniu adresu możesz usunąć info.php z serwera.

  • krok 3: uaktywnij zabezpieczenie

    W ostatnim kroku powiesz serwerowi, żeby udostępnił użytkownikowi plik wp-login.php (to właśnie on odpowiada za formularz logowania) dopiero po poprawnym wpisaniu danych dostępowych:

    • otwórz plik .htaccess, który znajduje się w katalogu głównym Twojego WordPressa (jeśli go tam nie ma to możesz go utworzyć);
    • dodaj na początku pliku poniższą formułkę:
      AuthName "Restricted Area"
      AuthType Basic
      AuthUserFile /home/klient.dhosting.pl/wpn/wpninja.pl/.htpasswd
      <Files wp-login.php>
      require valid-user
      </Files>
       
      ErrorDocument 401 "Denied"
      ErrorDocument 403 "Denied"
    • w wierszu 3. zmień adres ścieżki na tą, którą ustaliłeś w poprzednim kroku.

Gotowe!

Teraz przy próbie dostania się do panelu administracyjnego zostaniesz poproszony o podanie nazwy użytkownika i hasła. Dopiero, gdy podasz poprawne dane, uzyskasz dostęp do formularza logowania.

Wymagane dodatkowe uwierzytelnienie

Wymagane dodatkowe uwierzytelnienie

Wszystko dzieje się bez udziału WordPressa, dzięki czemu wykorzystywane są do tego minimalne zasoby serwera i żaden brute force czy inny szajs nie jest Ci już straszny (no, przynajmniej nie w tak dużym stopniu jak wcześniej).

nginx?

Jeśli zamiast serwera Apache wykorzystujesz nginx to podobną instrukcję znajdziesz w artykule Protecting the WordPress login in nginx.

Czy można zrobić coś jeszcze?

Jasne! Oprócz powyższego na pewno warto jeszcze zadbać o niestandardową nazwę użytkownika (możesz to zrobić w dowolnym momencie) oraz o silne hasło, najlepiej wygenerowane automatycznie.

Niestety, nie ma zabezpieczeń idealnych i każdą stronę można zhakować. Poniższe 3 wskazówki pomogą zminimalizować straty w przypadku włamania do panelu administratora:

  • kopia zapasowa:

    Dzięki aktualnej kopii zapasowej łatwiej będzie przywrócić stronę do życia.

  • wyłączenie funkcji zmiany kodu przez panel:

    Będąc w panelu administracyjnym masz dostęp do edytora kodu aktualnie używanego motywu („Wygląd / Edytor”) oraz zainstalowanych wtyczek („Wtyczki / Edytor”). Osobiście nie znam żadnej osoby, która by z tego korzystała. Jeśli Ty również nie wprowadzasz zmian w ten sposób, to najlepiej wyłączyć tę funkcję. Wystarczy, że w pliku wp-config.php dodasz następującą deklarację:

    define( 'DISALLOW_FILE_EDIT', TRUE );
  • włączenie irytującego pytania o dane dostępowe do FTP:

    Włączenie ostatniej opcji jest nieco upierdliwe, bo za każdym razem gdy będzisz chciał zaktualizować wtyczkę, motyw czy samego WordPressa, to będziesz musiał podać dane dostępowe do FTP. Jeśli jednak robisz to rzadko, to na pewno warto to wprowadzić. Tutaj również wystarczy jedna deklaracja w pliku wp-config.php:

    define( 'FS_METHOD', 'ftpext' );

Przemyślenia, czyli czego się nauczyłem?

  • proste rozwiązania są czasem najlepsze:

    Miałem okazję przetestować 2 wtyczki, ale żadna nie spełniła swojego zadania. Całkiem prawdopodobne, że gdybym miał więcej czasu to natrafiłbym na taką, która faktycznie by coś pomogła. Metoda z hasłem na .htaccess jest prosta a przy tym skuteczna.

  • dobrze jest mieć wtyczkę do cachowania:

    Dzięki temu nikt z odwiedzających niczego nie zauważył. Część rzeczy wprawdzie nie działała (np. wysyłanie nowych komentarzy), ale tragedii nie było. Popularne wtyczki tego typu to W3 Total Cache, Hyper Cache czy WP Super Cache). Ja używam tej ostatniej.

  • nie można zbytnio liczyć na pomoc od strony usługodawcy hostingu:

    Nawet mnie nie poinformowali – to nic, że boty wygenerowały obciążenie 8-9 razy większe niż zwykle, to nie ich problem (po przekroczeniu dopuszczalnego poziomu obciążenia strona jest blokowana i w celu odblokowania należy uiścić opłatę).

    Dlatego też warto co jakiś czas kontrolować logi serwera i poziom obciążenia. A jeśli nie mamy głowy, ochoty lub czasu na takie cyrki to zawsze można przejść na hosting, który zrobi wszystko za nas (np. zenbox).

  • ataki „brute force” są bliżej niż nam się wydaje

    Do tej pory myślałem, że zmasowane ataki przeprowadzane są jedynie na duże i popularne serwisy. Nie zdawałem sobie też do końca sprawy z tego, że nawet jeśli atak nie dojdzie do skutku, to i tak ze względu na ogromne obciążenie może się to skończyć wyłączeniem strony.

    Trzeba pogodzić się z tym, że takie ataki to prostu nowy rodzaj spamu i pytanie wcale nie brzmi „czy mnie też to spotka?” tylko „kiedy?”.

Wasze sposoby na walkę z atakami „brute force”

Masz poradę dla innych? – prześlij ją za pomocą komentarza.
Najciekawsze wpisy opublikuję w tym miejscu.

Dodaj własny komentarz

Odnośniki z innych stron

Lista innych stron, które w jakiś sposób odnoszą się do opublikowanej tutaj treści:

  1. WordPress na home.pl? 7 rzeczy, na które trzeba uważać | WPNinja

    […] nazwa administratora sugerowana jest najgorsza z możliwych opcji czyli […]

  2. Atak na stronę - brute force? słownikowy? Jak się zabezpieczyć? - Poradnik informatyka

    […] https://wpninja.pl/artykuly/jak-zabezpieczyc-wordpressa-przed-atakiem-brute-force-i-dlaczego-jeszcze-&#8230; […]

  3. Strona na WordPress - sprawdź czy nie została zaatakowana

    […] Jak zabezpieczyć WordPressa przed atakiem „brute force” i dlaczego jeszcze tego nie zrobiłeś? – https://wpninja.pl/artykuly/jak-zabezpieczyc-wordpressa-przed-atakiem-brute-force-i-dlaczego-jeszcze-… […]

  4. Kurs WordPress: Ochrona przed Spamem i hakerami – Jakub Jaworowicz WordPress & Marketing Specialist

    […] zapoznanie się z Wpisem Szymka o tutaj, ale dodam uwagi […]