Zabezpieczanie strony logowania w WordPress

Dla specjalistów Webmastering
#1

Znalazłem 4 sposoby, które zabezpieczają stronę logowania.

Dylemat jest o to które zjada najmniej zasobów serwera w czasie ataków a jednocześnie jest skuteczne i wygodne.

1. Dwuskładnikowe uwierzytelnienie z google za pomocą wtyczki typu " Google Authenticator"

2. Zmiana linku do logowania.

3. HTTP Basic Authentication. Użyć generatora .htpasswd i w pliku.htaccess dodać kod

<Directory "/var/www/html/ ">
AuthType Basic
AuthName "tell me something"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user
 
AllowOverride All
Allow from All
</Directory>

ma to pokazać logowaniu hasłem i loginem przed logowaniem do panelu admina.

4. Strona logowania wyświetli się tylko po poprawnym user-agent

 <FilesMatch ^((wp-login|admin)\.php$)$>
 SetEnvIfNoCase user-Agent ^mojtajnykod [NC] my_bot
 Order Deny,Allow
 Deny from all
 Allow from env=my_bot
 </FilesMatch>

Od razu napiszę moje uwagi:
ad 1.
Słyszałem, że można to łatwo obejść ? Druga sprawa czy bot widząc dodatkowe uwierzytelnienie odpuści czy będzie jak szalony próbował wpisać poprawny login, hasło i dodatkowy kod ? Jeśli tak to w czasie ataku serwer zdechnie…

ad 2.
To u mnie odpada, dużo osób ma później problemy z dostaniem się do panelu logowania. No i także wyczytałem, ze to jest słabe bo bot może znaleźć ten link do logowania.

ad 3.
Wydaje mi się dobrą metoda na ochronę strony logowania. Tylko jak to ma się do obciążenia serwera gdy bot będzie usilnie próbował zgadnąć login i hasło ? A moze to jest łatwe do obejścia ?

ad 4.
Ta metoda moim zdaniem jest najskuteczniejsza. nie słyszałem jeszcze aby boty ustawiały losowe User-Agenty a co dopiero by trafił na mój tajny kod. No i teoretycznie na moje oko serwer odpoczywa bo wyświetla tylko stronę z informacją o braku uprawnień.

Forbidden
You don’t have permission to access /wp-login.php on this server.
ale czy to da się obejść ? A sama metoda dosyć niewygodna.
To samo można zrobić po IP, ale chcę także z tel się czasem zalogować wiec odpada.

Więc jak Wy uważacie co jest najlepsze ? A może ktoś zna jeszcze coś innego ?

#2

Nie wiem jak z obejściem, ale na pewno będzie zjadało dodatkowe zasoby serwera, więc przy ataku szybciej serwer zdechnie.

ad2.
moim zdaniem jest to najlepsze rozwiązanie, a w połączeniu z ukryciem informacji o tym że strona stoi na WP, wręcz bezkonkurencyjne. Przy próbie wejścia na wp-admin bot od razu dostanie stronę od serwera http z błędem 404 bez angażowania w to PHP, dodatkowo bot nie będzie miał pewności czy strona w ogóle działa na WP (w przypadku dodatkowo ukrytych danych o WP).

ad3.
Taki login i hasło znają wszyscy którzy mają dostęp do panelu - możliwość wycieknięcia, dodatkowo przy zabraniu komuś dostępu do panelu trzeba zmieniać hasło. Oczywiście jest opcja dodania więcej niż jednego usera i hasła, ale jest to metoda upierdliwa w zarządzaniu i nadzorowaniu.
Największym minusem jest to, że hasła trzeba zmieniać regularnie bo wcześniej czy później bot je złamie. Dodatkowo takie zabezpieczanie pokazuje, że coś pod danym linkiem jest ukryte, więc może to mieć odwrotny skutek - zwiększony ruch. Plus jest taki, że dopóki nie poda się loginu i hasła nie jest angażowany do pracy php, lecz działa sam serwer HTTP do tego przesyłanych jest mniej danych (o ile bot je pobiera to zmniejszy się zużycie transferu).

ad4.
Pierwsze słyszę o takiej metodzie zabezpieczania, z tego powodu że może spowodować więcej problemów niż pożytku. Co jeśli zechcesz zalogować się z innej przeglądarki? Lub co w przypadku gdy przeglądarka dostanie aktualizację i user-agent nie będzie pasował? Stracisz dostęp do strony. Dużo lepszym rozwiązaniem wydaje mi się filtrowanie po adresie IP. Jeśli zakładamy że logujesz się do panelu tylko z jednego komputera to będzie to nie będziesz miał minusów które były przy filtrowaniu po user-agent, jedynie dojdzie problem z logowaniem z innych sieci niż Twoja. Oczywiście może być też problem jeśli masz zmienny adres IP, ale zarówno ten problem jak i problem z logowaniem z innej sieci można bardzo prosto załatwić poprzez postawienie np. na VPS serwera Proxy lub serwera VPN za pomocą którego będziesz się łączył ze stroną. W ten sposób masz z dowolnego miejsca na świecie stały adres IP oraz możesz w łatwy sposób dodawać lub zabierać uprawnienia do łączenia się z takim serwerem, a tym samym z Twoją stroną.

Osobiście dla zwykłych stron nie widzę sensu strzelać z armaty do komara i jedynym sensownym rozwiązaniem jest moim zdaniem zmiana adresu panelu admina. Jeśli nikt nie umieści nigdzie bezpośredniego linku to nie widzę możliwości dowiedzenia się gdzie jest PA, jedynie zgadywanie, ale to jest tak samo czasochłonne jak w przypadku zgadywania hasła.
Natomiast dla większych stron bezsensowne jest moim zdaniem w ogóle udostępnianie w świat PA, wręcz uważam że taki folder powinien być skasowany i przeniesiony na inny serwer najlepiej lokalny (dostępny tylko w intranecie firmowym, ewentualnie za pomocą serwera VPN/Proxy), albo dostępny z poziomu zupełnie innej domeny (ewentualnie subdomeny).

1 polubienie
#3

  1. Czyli jak myślałem.

  2. Jednak chyba spróbuję i zrobię kopię. Tylko jak ukryć info, że coś stoi na WP ?

  3. Jedna osoba administruje stronę. Możesz mieć rację, ze trafiając na taką stronę będzie kusiło aby przejść dalej.

  4. User-Agenta zmieniam w GoogleChrome wtyczką “user Agent Switcher” a na Androidzie na szczęście Dephin ma opcję zmiany User-Agenta. Ale fakt, dosyć niewygodna metoda. Już lepsza ta 3, ale czy sposób 3 i 4 nie da podobnego efektu “ciekawości” i próby złamania jednak zabezpieczenia tego rodzaju ?

Panel admina musi być, jak mam dodawać posty bez jego udziału ? :slight_smile: A kombinowanie o subdomenach itp to już za dużo, jak napisałeś nie potrzebna armata na komara.

#4

Jest z tym bardzo dużo zabawy jeśli chcesz mieć za darmo, a jak nie to istnieje płatna wtyczka (przynajmniej istniała) która nazywa się chyba hidemywp, ale jak się tym interesowałem spotkałem się z informacjami że jest ona zainfekowana.

Jeśli się nie mylę jest istotna różnica w przypadku hasła wyświetla Ci się strona, w przypadku niepoprawnego UA chyba dostaniesz 404, albo jakiś 50X co mówi napastnikowi tyle co nic - albo coś tam jest albo nie takie 50/50, a strona z loginem i hasłem jednak mówi że coś tam siedzi zabezpieczonego, a skoro jest zabezpieczone to może i ciekawe.

1 polubienie
#5

Po złym wpisaniu User-Agenta jest

Forbidden
You don’t have permission to access /wp-login.php on this server.

Na razie korzystam z tej metody. Zmiana linku do logowania to tragedia dla tych co się nie znają, są wtyczki ale stare i sporo osób ma problem później.

#6

Więc na jedno wychodzi, chyba że jest opcja ustawienia jaką informacje serwer ma wyświetlić, ale tego Ci nie powiem bo się nigdy w takie rzeczy nie bawiłem.

#7

No okej, to jak “będę miał jaja” to spróbuję z tą zmianą adresu logowania.

#8

Jeśli to jest Twoja strona to gdzie tu problem? Nawet jak zapomnisz jaki jest adres możesz sprawdzić sobie na FTP. Jeśli to jest czyjaś strona i robisz ją na zlecenie to dobrze jest wysłać mail czy wydrukować jakiś dokument (w ogóle stworzyć taki dokument i przekazać) z jakimś podsumowaniem projektu i informacjami. W nim możesz umieścić właśnie adres do strony z panelem, a jeśli adres będzie jakasstrona.example/pomarancze/ to raczej ciężko będzie to zapomnieć, możesz też jako adres dać kombinację z nazwą firmy np cebulacorp.example/cebula-admin. Również łatwe do zapamiętania i logiczne do przypomnienia, a jeśli dodatkowo wyślesz informacje o tym na maila albo dasz w formie dokumentu to zawsze wiadomo gdzie szukać tych informacji - to jak z przypominaniem sobie loginu i hasła do rzadko odwiedzanego serwisu.
Jeśli jedynym argumentem przeciw takiemu rozwiązaniu jest to że właściciel strony zapomni jaki był adres, to równie dobrze może zapomnieć loginu i hasła HTTP, a nawet powiedziałbym że szybciej zapomni login i trudne hasło niż adres /pomarancze.

#9

UWAGA WAŻNE:
zapomniałem napisać o tym już w pierwszym poście. Bez względu na to które rozwiązanie chcesz zastosować warto zabezpieczyć serwer w ModSecurity i dobrze go skonfigurować, to mocno ogranicza możliwości skutecznego ataku i zdecydowanie pozwala odciążyć serwer.

#10

Możesz też spróbować pozostawić plik wp-login.php na swoim miejscu i dodać pod linijką
* @param WP_Error $wp_error Optional. The error to pass. Default empty. */

Taki kod:

if (isset($_GET['cred'])) {

        $seccode = trim(wp_unslash($_GET['cred']));
        if ( $seccode == 'mojklucz' ) setcookie( "uac", "MK4CHXHWqMK4CHXHWq", time()+120, COOKIEPATH, COOKIE_DOMAIN ); else { http_response_code(404); exit(); }

} else {

        if (isset($_COOKIE['uac'])) {

            if ( $_COOKIE['uac'] != 'MK4CHXHWqMK4CHXHWq' ) { http_response_code(404); exit(); }

        } else {

            http_response_code(404);
            exit();


        }

}

Jak to działa?

W adresie po wp-admin.php? dodajesz cred=mojklucz i jeżeli klucz jest poprawny to tworzy się ciasteczko “uac” o wartości “MK4CHXHWqMK4CHXHWq” na 120 sekund, czyli na czas uwierzytelnienia login+hasło. (pojawia się strona logowania)

Jeżeli klucz “cred” jest błędny to błąd 404.

Jeżeli nie wpiszesz cred=mojklucz do URL to sprawdzane jest, czy istnieje ciasteczko o nazwie “uac” i wartości “MK4CHXHWqMK4CHXHWq” - jeżeli jest normalnie pojawia się strona logowania, jeżeli nie istnieje, wygasło lub ma inną wartość to pojawia się błąd 404 jak przy braku pliku.

Oczywiście nazwę ciasteczka, wartość, klucz sobie zmień. Dałem tylko przykładową.

2 polubienia
#11

To jest super pomysł !
Czyli po wpisaniu www.XYZ.pl/wp-admin wyświetli się 404 i muszę wpisać www.XYZ.pl/wp-admin?cred=jakiskod aby logowanie zostało wyświetlone ?

A jak ten sposób @Domker ma wpływ na serwer ? Przy bruteforce serwer nie zdechnie ? Na moje oko amatora nie powinien.

Jakieś wady tego na oko super rozwiązania o którym nie miałem przyjemności poczytać przez miesiąc ciągłego szukania porad itp itd ?

#12

Dokładnie tak.

Brudeforce nic nie da, bo parametr jest opcjonalny. Jeżeli go nie przekażesz w URL to sprawdzana jest tylko obecność odpowiedniego ciasteczka - jeżeli nie ma to 404.
Bot by musiał “wiedzieć” w ogóle, że trzeba przekazać taki parametr o takiej wartości.

Wady - jeżeli zdradzisz komuś “cred=jakiskod” lub jakiś inny sposób wejdzie w posiadanie tych danych (przykładowo jeżeli historii przeglądarki nie czyścisz i ktoś się do niej dobierze, bo będzie w odwiedzonych ten URL z parametrem) to strona logowania się wyświetli.

#13

Czy taki kod do wp-admin.php trzeba będzie dopisywać po każdej aktualizacji WP?

#14

Jeżeli do “post_update” sobie dodasz to nie. Drugi sposób to napisanie tego jako plugin do wordpressa (o ile się chce :P)

#15

Czyli sposób idealny dla osób czyszczących historie - a ja zawsze czyszczę.

Wieczorem spróbuję i zobaczymy jak to działa, wydaje się proste. Aż za proste, mogli by to wprowadzić w WorsPresie jeśli jest 1 user :smiley:
A tak to trzeba szukać sposobów na zabezpieczenia aby nie stracić swoich wypocin.

Dziękuję. Wieczorem się odezwę czy działa.

A bym zapomniał. Kod tylko z literami i bez polskich znaków i specjalnych (małpy, wykrzykniki iyp) ?

#16

Pobierany parametr jest trimowany i slashe są też usuwane dla bezpieczeństwa, więc alfanumeryczny będzie ok.

#17

Co to jest i jak się tego używa?

#18

Nie co to jest tylko też musisz sobie to stworzyć. Tak tylko nazwałem jako proces po-updejtowy.

W update-core.php po linijce:
show_message( __('WordPress updated successfully') );

Dodajesz kod, który naniesie Ci zmiany w nowym pliku wp-login.php.
http://php.net/manual/de/function.xdiff-file-patch.php

@NieznanyZnany daj znać jak zadziała, bo kod pisałem samodzielnie “z palca”.

#19

Nie uważam by tworzenie modyfikacji plików core WordPressa było dobrym rozwiązaniem. Co do Twojej propozycji to hmmm … ma sens gdy bot zorientuje się że dostaje 404, jeśli nie to nadal obciążasz serwer ponieważ ingerujesz blokowanie parser PHP, tym samym wczytujesz cały core worpdressa i wykonujesz maskę kodu zanim w ogóle dojdzie do zwrócenia 404, a wszystko to po nic. Rozwiązanie fajne o ile mamy do czynienia z botem który zauważy, że dostaje 404, a nie ślepo wysyła żądania post z losowymi danymi logowania.

Inaczej mówiąc bez ModSecurity nie zmniejszamy obciążenia względem żadnej ochrony. Różnica w porównaniu do przeniesienia na inny URL jest taka że jeśli mam do czynienia z tak samo słabym botem to tutaj ucinamy obsługę żądania na poziomie serwera HTTP jeszcze przed oddaniem obsługi żądania interpreterowi PHP.

1 polubienie
#20

Masz rację wszystko zależy od bota tak naprawdę.
Błąd 404 jest jako “header” wysyłany, więc jeżeli bot czyta nagłówki to przerwie “pracę”.

Można też wyżej to umieścić tuż po:
"<?php"
, a więc przed wykonaniem innego kodu.

@Fizyda
Można też bez ingerencji w update-core.php - mianowicie ustawić watcher w CRON, który sprawdza, czy obecna jest modyfikacja w tym pliku PHP. Jeżeli nie to scala diffa.

1 polubienie