12 myśli na temat “Atak na wp-login.php i bardzo proste rozwiązanie”

    1. @Łukasz: faktycznie dla instalacji na apache’u będzie taka sytuacja jak przedstawiasz i wtedy warto zawartość pliku wp-login.php zmienić na header(„HTTP/1.0 404 Not Found”, dopiszę to.

  1. Nie lepiej zamiast tykać wp pliki ukryć url do wp-login.php?

    W efekcie zamiast:

    domena.pl/wp-login.php => np: domena.pl/kokpit

  2. @Marcin, zostaje jeszcze kwestia wspomnianych aktualizacji, które skutecznie rozkładają całość przywracając oryginalny wp-login, no i konieczność ręcznej zabawy plikami…

    Aby to było funkcjonalne jako wtyczka, wypadało by nieco rozwinąć -automatyzując operacje plikowe- mam nadzieję, że rozumiesz w czym rzecz. ;)
    -pewną podpowiedź do tego typu rozwinięcia może stanowić taki najprostszy przykładzik pastebin.com/P7CBttfH

  3. Nie łatwiej wyciąć dostęp do pliku przez dodatkową autoryzacje (na apache / lighttpd / nginx)? Klient będzie musiał (raz na jakiś czas) wpisać swój login i hasło dwukrotnie.

    Oczywiście boty pewnie będą dalej próbowały się dobijać, ale obciążenie serwera powinno spaść niemal do zera.

  4. @Paweł: śmiało, kod jest na GPL można pobierać i modyfikować. :D Ale! u mnie serwer www nie ma prawa zapisu w katalogach oprócz /wp-content/files (instalacja MU).

    Kod aktualizuję bezpośrednio z subversion (svn switch) co dodatkowo ma kilka zalet i wad, ale generalnie będę widział pliki, szczególnie że svn zakrzyczy że plik wp-login.php znikł trzeba go odtworzyć.

    Zawsze można dać w konfiguracji virtuala bana na /wp-login.php, więc kwestię pojawianie się pliku uważam za ogarniętą.

    @Daggerka: można, ale podstawowe logowanie dla niektórych klientów jest problemem, podwójne będzie dla nich nie do ogarnięcia.

    Chyba najlepszym rozwiązaniem jest zbanowanie tego pliku w konfiguracji vhosta.

  5. Jeszcze pojawia się kwestia odzyskiwania hasła.
    Po zmianie nazwy pliku wp-login.php na własną można się logować, natomiast po próbie odzyskiwania hasła (wpisanie nazwy użytkownika i akceptacja) przekierowuje na domyślny plik wp-login.php

    1. @Maciej: faktycznie tak jest, już zacząłem pisać dalej (tutaj działa odzyskiwanie hasła), ale sprawa okazała się bardzo pracochłonna, bo jest bardzo dużo akcji związanych z logowaniem. Dodatkowo okazało się, że to co już zrobiłem nie działa dla WordPressa stojącego jako pojedyncza strona (ten tutaj to multisite) i jak testowałem lokalnie wyszło, że odzyskiwanie hasła nadal nie działa.

      Jak tylko znajdę troszkę czasu, postaram się całość opanować i udostępnić.

  6. Najważniejsze, że już jakaś podstawa jest, która zabezpiecza przed atakiem.
    U mnie zaczęło się od jednej strony, a później kolejne zaczęły być atakowane. Klienci się rzadko sami logują do panelu, więc na razie powinno to wystarczyć.
    To i tak duża pomoc z Twojej strony, za którą dziękuję. Czekam również na zmodernizowane rozwiązanie ;)

  7. Zgadzam się z DMati. Najprostszym rozwiązaniem będzie dodanie do pliku .htaccess nastepującej reguły:

    RewriteRule ^/kokpit/?$ /wp-login.php [QSA,L]

    To powinno załatwić sprawę.

Możliwość komentowania jest wyłączona.

Jeżeli chcesz skomentować, napisz mail na adres marcin w domenie strony na której jesteś. Dodam twoj komentarz.