Autoryzowany dostęp do WordPressa. Zabezpieczamy wp-admin

A

W tym wpisie pokażę Ci, w jaki sposób zabezpieczyć swojego WordPressa przed nieautoryzowanym dostępem. Zrobimy to poprzez limit na katalog wp-admin oraz skrypt wp-login.php.

Po co?

© WordFence.com – źródła ataków

Mówiąc prosto. Dla bezpieczeństwa. Według raportu WordFence z 2016 roku, wordpressowe boty potrafią w ciągu 16 godzin próbować zalogować się metodą brute force na naszą stronę nawet 6 milionów razy! Czym jest metoda brute force? W dużym skrócie – bot wchodzi na stronę logowania, podaje domyślny login admin(dlatego nie warto go używać) i słownikowo próbuje zgadnąć hasło podając od najbardziej oczywistych jak np. admin1 czy qwerty aż po słownikowe hasła wyciągane z różnych baz które wyciekły do internetu. Dla zobrazowania skali zagrożenia, mój blog w dniu publikacji tego posta ma raptem 20 dni istnienia w internecie, w logach widzę, że dotychczas boty próbowały wejść na wp-admin 2 mln razy. To aż 4100 razy na godzinę! Warto nadmienić, że taka ilość prób logowania znacząco obciąża naszą stronę.

Co mogę z tym zrobić?

Najlepszym sposobem jest zabezpieczenie katalogu wp-admin oraz pliku wp-login.php już na poziomie samego serwera. Zdecydowanie odradzam wszystkie wtyczki „bezpieczeństwa”, więcej z tym szkód niż pożytku. O tym dlaczego uważam, że pluginy bezpieczeństwa są do dupy wkrótce. Ale do rzeczy…

Dla przykładu przyjmijmy, że nasza strona znajduje się w katalogu:

/home/użytkownik/domains/domena.pl/public_html/

W pierwszej kolejności, potrzebujemy pliku .htpasswd, który jest swoistą lokalną bazą użytkowników, którzy mają dostęp dalej. Taki plik możemy wygenerować tutaj. Jak już to zrobimy umieszczamy ten plik w /home/użytkownik/domains/domena.pl/ następnie do pliku .htaccess w katalogu public_html dodajemy taki wpis:

<FilesMatch "wp-login.php"> AuthType Basic AuthName "Secure Area" AuthUserFile "/home/użytkownik/domains/domena.pl/.htpasswd" require valid-user </FilesMatch>

Ostanim krokiem jest dodanie pliku .htaccess do katalogu wp-admin a w nim:

AuthName "WP-Admin"  AuthUserFile /home/użytkownik/domains/domena.pl/.htpasswd  Require valid-user 

Jak to działa?

Zanim wejdziemy na stronę logowania serwer zapyta nas dodatkowo o dane autoryzacyjne. W praktyce możesz zobaczyć to u mnie. Jeśli podamy złe dane serwer odrzuci połączenie. WordPress zostaje odciążony, nasza strona działa szybciej.

O autorze

Filip Nowacki

Swoją przygodę z IT rozpoczął mając 13 lat, kiedy to stworzył swoją pierwszą stronę internetową. Obecnie pracuje jako backend & mobile developer, rozwijając kilka ogólnopolskich produktów o zasięgu blisko 15 milionów użytkowników. Prywatnie maniak optymalizacji, testów A/B, motoryzacji i architektury aplikacji.

4 komentarze

  • Pewna serwerownia blokuje dostęp botów poprzez login i hasło podane w AuthName. Z jakiegoś powodu boty spokojnie się logują do wp-admina. Na dodatek serwer nieprawidłowo ustawiony, więc wstawienie własnego hasła zajęło mi chwilę (bo zwykłe wstawienie własnego htpasswd i adresu w htaccessie powodowało nieskończone przeładowanie strony). Jedna uwaga co do admin-ajax.php. W ten sposób usunąłeś pytanie o hasło, żeby ajax działał po stronie klientów (o ile w wordpressie są wtyczki używające wywołań w tle). I nie, nie tylko pluginy mogą się z tym plikiem komunikować. Każdy może wywołać adres i dostanie odpowiedź (domyślnie pewnie o braku parametrów).

    Przydała by się jeszcze jedna rzecz: xmlrpc. To jeszcze jedna rzecz, która potrafi zamordować serwer.

    • Zgadza się, był chyba nawet w którejś wersji bug, że poprzez xmlrpc szło wykonywać atak DoS.
      Co do admin-ajax.php podasz jakiś przykład? Zainteresowałeś mnie tym, jeśli faktycznie popełniłem błąd to się poprawię.

      Btw, o którym hostingu mówisz? 🙂

      • Nazwa zaczyna się na L i kończy się na L. Nie będę im robić reklamy 😉

        Nadal przez xmlrpc można wykonywać ddosa. WordPress domyślnie nie limituje ilość wywołań tego adresu, który de facto służy chyba tylko do publikowania postów poprzez email (chyba, że pingback jeszcze przez to idzie?).

        Templatka „Engine” używa admin-ajax.php do wykonywania porównań postów (albo czegoś podobnego). Wysyłane jest {„content”:””,”cssactive”:””,”comparing”:[]} w _POST. Przy bezpośrednim wejściu otrzymuje się 0. Atak może polegać na wysyłaniu żądań sprofilowanych pod określone wtyczki (bot nawet nie musi sprawdzać czy wtyczka jest zainstalowana, bo jeśli jest w dziurawej wersji, to złośliwy kod przejdzie).

        To, co masz podane w htaccessie odnośnie dostępu do admin-ajax.php mówi co następuje:
        kolejność warunków: pozwól, odmów
        pozwól na dostęp wszystkim
        pomiń pytanie o użytkownika

        Jeśli na stronie nie jest używany ajax (czyli ani szablon, ani wtyczki nie komunikują się z serwerem, co można sprawdzić w konsoli narzędzi deweloperskich/firebugu), to można od strony klientów pominąć te warunki (albo lepiej, wymusić podanie loginu i hasła serwerowego), lub dać deny from all (wtedy od strony admina trzeba zadbać o odblokowanie).

        Jeśli natomiast ajax jest używany, to gugiel pod hasłem „admin-ajax.php exploit” daje niezbyt wesoły obraz (miejmy nadzieję, że większość z tych rzeczy została poprawiona).

  • Faktycznie, wcześniej dostawałem po kilka maili dziennie z wtyczki do bezpieczeństwa że ktoś próbuje się zalogować, teraz zero. MEEGA!