publikacja: 25 lipca 2013, autor: Szymon Skulimowski, 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ś?

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
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
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

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.

tagi: bezpieczeństwo, brute force

Komentarze

Kuba Mikita 11 lat temu:
Ja używam Wordfence. Dzięki tej wtyczce dowiedziałem się z jakich lokalizacji, jakich IP i z jakimi danymi logowania ktoś próbował się dostać.
Obecnie mam kilka/kilkanaście prób dziennie.
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Czyli miałeś dokładnie to samo co ja parę dni wcześniej (przed zmasowanym atakiem, który ostatecznie rozłożył serwer). Szykuj się. :)
  odpowiedz
2. Krzysiek Dróżdż 10 lat temu:
  Kuba, jak dla mnie ta wtyczka jest spalona – zobacz sobie, ile podatności generowała on sama (https://wpvulndb.com/search?utf8=%E2%9C%93&text=wordfence).
  A biorąc pod uwagę, że pozwalała też na wrzucenie własnego kodu, to…
  Logi prób logowania? Super, ale to jest parę linijek kodu, który nie wygeneruje dodatkowych podatności.
  PS. Jak sobie poprzeglądasz tę bazę, to zobaczysz, że z innymi wtyczkami „bezpieczeństwa” jest dość podobnie, albo gorzej…
  odpowiedz
Szczypek 11 lat temu:
Z jednej strony może powiedzieć że to komplement że taki atak poszedłem na twój serwis :) Wiem, raczej to średnie pocieszenie.
A tak już na poważnie to dzięki za podzielenie się informacjami, sam na szczęście jeszcze się nie spotkałem z tego typu atakiem ( odpukać ). Najgorsze że z reguły człowiek wychodzi z założenia że jego to nie spotka, a jak już spotka to z przeważnie już jest za późno i sprawdzamy datę ostatniego backupu :)
W takim wypadku chyba trzeba zacząć się trochę lepiej zabezpieczać.
Mógłbyś napisać w jaki sposób zauważyłeś pierwsze próby ataku ? Przy administrowaniu wielu serwisów na różnych serwerach sprawdzanie codziennie logów serwera może być dość uciążliwe.
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Faktycznie, to raczej średnie pocieszenie, ale dzięki! :-)
  Mógłbyś napisać w jaki sposób zauważyłeś pierwsze próby ataku?
  Ja zorientowałem się właśnie dzięki przypadkowemu przeglądaniu logów serwera. Dobrym sposobem jest instalacja wspomnianej w artykule wtyczki Limit Login Attempts.
  Nie ochroni ona wprawdzie przed większym atakiem, ale z mniejszymi sobie poradzi. Co ważne – w ustawieniach można włączyć funkcję wysyłania powiadomień do administratora. Dzięki temu będziesz wiedział czy dochodzi do ataków a jeśli tak to w jakiej skali.
  odpowiedz
2. Krzysiek Dróżdż 10 lat temu:
  @Szczypek:
  Raczej nie ma się z czego cieszyć. Bardzo rzadko mamy do czynienia z atakiem na konkretną stronę. Znaczna większość ataków na WP jest robiona na ślepo – łącznie z ignorowaniem faktu czy to w ogóle jest WP ;)
  Mam na serwerze oprócz WP kilka stron nie na WP i tam też dość często zdarzają się próby logowania do wp-login czy xmlrpc ;)
  odpowiedz
Paweł Rabinek 11 lat temu:
Ograniczenie dostępu na poziomie serwera w htaccess to chyba najlepsza metoda zabezpieczenia przed atakiem typu brute force. Nie obciąża to parsera PHP ani bazy danych, a sam serwer poradzi sobie z tym świetnie na tym poziomie. Polecam wszystkim dodanie tego zabezpieczenia, o którym pisze Szymon.
O tym zabezpieczeniu pisałem już w 2006 na moim blogu, choć nie w kontekście WordPressa.
Nie wiedziałem, że jest takie coś jak „DISALLOW_FILE_EDIT” – przydatne, dzięki. Już sobie wyłączyłem.
Bardzo dobry wpis Szymonie, powinieneś publikować częściej :)
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Dzięki Paweł! Rozpocząłem już prace nad kolejnym artykułem :) Może masz pomysł na jakiś interesujący temat?
  odpowiedz
2. Jasiek a.k.a Yeti 11 lat temu:
  To ja bym zaproponował (tak, wiem, że się wcinam, ale to silniejsze ode mnie) jakiś tekst poświęcony szablonom. Jaki się nadaje na jaki typ strony, albo coś w ten deseń. Ew. jakieś przemyślenia na temat sposobu umieszczania reklam (Google AdSense i spółka) na blogu, tak by nie zabijało to oczu :X
  odpowiedz
3. Szymon Skulimowski 11 lat temu:
  Nie żartuj, to nie jest wcinanie się tylko świetna propozycja. Dzięki!
  odpowiedz
4. Jasiek a.k.a Yeti 11 lat temu:
  Trochę wcinka, bo odpowiadam na pytanie zadane komu innemu.
  Ale cieszę się, że propozycje się spodobały i czekam niecierpliwie na teksty :D
  odpowiedz
mintweb 11 lat temu:
Ja polecam także sprawdzony sposób w postaci zmiany adresu panelu. Przykładowo zmieniamy adres panelu z /wp-admin/ na /panel/. Po czymś takim w momencie wchodzenia na stary adres wyskakuje nam błąd 404. Można to łatwo zrobić przy pomocy wtyczki Better WP Security. Swoją drogą wtyczka oferuje dużo więcej możliwości zabezpieczania swojego WordPressa.
odpowiedz
1. Paweł Rabinek 11 lat temu:
  @mintweb – zdaje się, że atak kierowany jest bezpośrednio na plik /wp-login.php więc nie wiem czy to pomoże.
  odpowiedz
2. Szymon Skulimowski 11 lat temu:
  Na pewno lepsze to niż nic, ale tak jak wspomniał Paweł – ataki rozpoczynają się od pliku odpowiadającego za logowanie (wp-login.php) i jeśli on nie jest jakoś dodatkowo zabezpieczony, lub zabezpieczenie odbywa się z udziałem WordPressa (np. poprzez wtyczkę, która filtruje adresy IP) to przy poważniejszym ataku „brute-force” serwer dostanie palpitacji procesora.
  odpowiedz
Niedoszły Bibliotekarz 11 lat temu:
plik .htpasswd lepiej trzymać piętro wyżej niż stronę www, jak ma się stały adres IP warto dodać logowanie do panelu tylko z niego lub z kilku zaufanych.
A za wskazanie przydatnego DISALLOW_FILE_EDIT bardzo dziękuję.
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Zgadza się, to też jest dobre rozwiązanie. Dzięki za przypomnienie!
  odpowiedz
Kamil 11 lat temu:
Świetny tekst. Rozwiązanie już zaimplementowane 5 minut roboty:) Dzięki.
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Cała przyjemność po mojej stronie!
  odpowiedz
Krzysztof 11 lat temu:
Bardzo dobry artykuł, dziękuję. Jakiś czas temu odkryłem i wykorzystuję na wszystkich stronach wtyczkę Hide My WP (co prawda płatna ale dobra). Przede wszystkim zmienia adres panelu logowania, poza tym czyści kod i usuwa informacje wskazujące, że to instalacja WP. Wydaje mi się również, że chyba strony po instalacji przyspieszyły ale to już subiektywne wrażenie :-)
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Niestety, w kontekście ataku „brute force” zastosowanie tej wtyczki nie wystarczy. Autor w opisie podaje przykład strony z aktywną wtyczką:
  http://hide-my-wp.wpwave.com/wp-login.php
  Jeśli miałoby być to skuteczne to błąd powinien być obsługiwany przez serwer a nie WordPress. W powyższym przykładzie pokazywana jest strona 404 WordPressa co samo w sobie generuje obciążenie (czasem większe niż formularz logowania).
  Teoretycznie zastosowanie wtyczki do cachowania powinno trochę pomóc, ale wszystkie z nich standardowo nie biorą pod uwagę stron 404.
  Jeśli chodzi o ataki „brute force” to polecam rozwiązanie opisane w artykule (.htaccess).
  odpowiedz
Kuba 11 lat temu:
Szymon ja zwykle tekst pierwsza klasa, przydatny dla laika i dla bardziej ogarniętych. Wielkie dzięki :) jakiś czas temu mój hosting wprowadził blokadę wp-login.php i zalecił zmianę w wp-config.php na jakąś własną. Pomysł dobry do pierwszej nowej aktualizacji :)
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Kuba, dzięki za miłe słowa!
  Co do hostingów to miałem okazję poznać podejście do tematu dwóch firm:
  * Linuxpl.com – zmienili nazwę wp-login.php na wp-login2.php i przesłali klientowi wiadomość żeby zabezpieczył się we własnym zakresie (sugerując użycie bliżej nieokreślonej wtyczki);
  * Kylos – wprowadzili identyczne jak w powyższym artykule zabezpieczenie na hasło przez .htaccess i przesłali klientowi wiadomość z danymi dostępowymi.
  A z usług jakiej firmy Ty korzystałeś (o ile możesz to zdradzić)?
  odpowiedz
2. Kuba 11 lat temu:
  Pewnie większość będzie zaskoczona, bo obecnie korzystam z usług Hostinger.pl – z opcji za 0 zł i to właśnie miły support z tej firmy mnie poinstruował jak wykonać taką zmianę. Pozdrawiam
  odpowiedz
3. Szymon Skulimowski 11 lat temu:
  Fajnie wiedzieć, że coś takiego istnieje. Jesteś zadowolony z darmowego konta?
  odpowiedz
4. Kuba 11 lat temu:
  Jak narazie nie było ono wystawione na duży ruch odwiedzających, bo to nowy projekt, ale jest w sam raz na początek. Pozdrawiam
  odpowiedz
5. Tomek | zenbox.pl 11 lat temu:
  @Szymon zapomniałeś o nas ;) wycinamy póki co ataki bez ingerencji w skrypty klientów :)
  odpowiedz
6. Szymon Skulimowski 11 lat temu:
  Faktycznie! Dzięki za informację :-)
  odpowiedz
7. Free 10 lat temu:
  I przy okazji blokujecie admina, który akurat chwilowo zapomniał hasła…
  odpowiedz
Maksymilian Śleziak 11 lat temu:
Nie dalej niż 3 dni temu szukałem takiego pluginu do zabezpieczenia logowania w WordPressie – Limit Login Attempts. Dzięki – jest idealny.
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Proszę bardzo, ale uważaj na ilość prób sforsowania logowania – jeśli będzie ona zbyt duża to wtyczka sobie nie poradzi (zbyt duże obciążenie dla serwera). Moim zdaniem lepiej dodać zabezpieczenie przez .htaccess (na hasło jak w powyższym artykule lub na IP).
  odpowiedz
Prowital 11 lat temu:
Plik info.php po całej operacji możemy oczywiście usunąć z serwera co by nie śmiecił, a my po roku nie zachodzili w głowę co to u licha jest.
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Dodałem do treści artykułu, dzięki za trafne spostrzeżenie.
  odpowiedz
Krzysiekn 11 lat temu:
Hej,
Mam prośbę, zrób poradnik o robieniu kilku domen w WORDPRESS MULTISITE.
Z góry dzięki.
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Wpisałem na listę pomysłów na przyszłe tematy, dzięki za sugestię!
  odpowiedz
Krystian 11 lat temu:
Szukasz interesującego tematu na wpis? ;) Postaraj się przedstawić sposoby wytrzymania na krześle ze skóry w temperaturze pokojowej około 30stopni w cieniu, mieszkając na poddaszu :) będę gorąco zainteresowany, choć wiem, że nie tyczy to tematyki bloga – hehe :) bardzo przydatny wpis. skorzystam, brute force strzeż się!
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Trzeba być trochę sado-maso żeby pracować w takich warunkach :-) Nie lepiej przenieść się do innej lokalizacji? Jeśli to nie wchodzi w grę to może inwestycja w klimatyzację?
  odpowiedz
wojcieh 11 lat temu:
Świetny artykuł Szymon,
Czy zablokowanie przy użyciu .htaccess spowoduje również konieczność wprowadzenia hasła dla zwykłych użytkowników do logowania? Na przykład wtedy gdy będą chcieli zostawić komentarz i wymagane jest logowanie.
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Bardzo dobre pytanie!
  Tak, takie zabezpieczenie (hasło lub zakres IP przez .htaccess) będzie obowiązywało wszystkich użytkowników, którzy posiadają zarejestrowane konta.
  Dla 10 osobowej redakcji nie powinno to być problemem (można nawet ustawić oddzielne hasła dla każdego), ale jeśli chodzi o opcję, w której każdy czytelnik może się zarejestrować to wprowadzenie zabezpieczenia w tej postaci będzie dosyć uciążliwe (dla czytelnika).
  Nie patrzyłem na to pod tym kątem. Sprawdzę co zamiast tego można zrobić i dam znać w komentarzu poniżej.
  Dzięki Wojtek!
  odpowiedz
2. Paweł Knapek 11 lat temu:
  Metoda skuteczna, niestety faktycznie w przypadku otwartego dostępu dla użytkowników nieco upierdliwa kolejna autoryzacja. Czasem stosuję inny trik w postaci „bramki”.
  Tworzę sobie pliczek pośredniczący w logowaniu – ustawia ciacho i kieruje na wp-login.php, w .htaccess zaś daję warunek sprawdzający dla wp-login.php czy ciacho istnieje, jeżeli nie – posyłamy w kosmos. ;)
  Takim to sposobem bezpośrednie odwołania do wp-login.php ładnie są wycinane, a faktyczni użytkownicy logują się za pośrednictwem określonego linka – tego można nawet jawnie na stronie użyć lub bardziej hardkorowo akcją JS’a zrealizować.
  Jak słusznie zauważono, w przypadku brutala i ddosa zasada jest prosta – wycinać wcześniej i na ile to możliwe, nie dopuszczać do interpretera i bazy …inaczej serwer szybko idzie zajechać.
  Z przyczyn oczywistych wtyczki tutaj raczej nie zdają egzaminu. Trzeba blokować na poziomie firewalla, pliku .htaccess etc. Wypada wspomnieć o ModSecurity ….a także o chmurkach – taki cloudflare jest w stanie sporo przyjąć i wyblokować.
  Warto zwrócić uwagę również na błędy – głównie 404-ki, mało kto o nich pamięta …a zazwyczaj większość leci przez wordpressa. Dobrze jest sobie dla plików statycznych wykluczyć, by nie mieliły idąc przez WP.
  Dynamiczne można keszować …np. W3TC (przy czym trzeba się liczyć z tym, że taka stronka błędu będzie zwracała kod 200)
  odpowiedz
3. Szymon Skulimowski 11 lat temu:
  Paweł, dzięki serdeczne za podzielenie się swoim przepisem! :) Mógłbyś jeszcze zdradzić w jaki sposób tworzysz ciasteczko i jak je potem sprawdzasz?
  odpowiedz
4. Paweł Knapek 11 lat temu:
  Właściwie bez znaczenia w jaki sposób. Tutaj taki na szybko malutki przykładzik z pehapowym setcookie http://pastebin.com/X7Manm0j
  odpowiedz
5. Szymon Skulimowski 11 lat temu:
  Aha… dzięki za przykład :)
  odpowiedz
6. marsjaninzmarsa 11 lat temu:
  Dobry pomysł, dzięki wielkie, wydaje mi się to być świetnym rozwiązaniem dla projektów gdzie logowanie jednak jest wymagane. :D
  odpowiedz
7. Rafiozoo 7 lat temu:
  Dzięki, Paweł Knapek!
  Gratuluję kreatywności!
  odpowiedz
webvilla 11 lat temu:
Chciałam podziękować za ten artykuł i pomoc!
pozdrawiam
Beata
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Nie ma sprawy, dzięki za komentarz! :)
  odpowiedz
2. Arla 11 lat temu:
  Wpis i blog świetny, ja niestety też się z tym problemem spotkałam. Teraz wiem co robić. Dzięki
  odpowiedz
3. wbielak 11 lat temu:
  To stosunkowo proste.
  Ataki tego typu są w 99% automatyczne więc z reguły wystarczy w komentarzu wpisać jakie jest hasło ;)
  Na przykład na zasadzie „login to user a hasło to nazwa witryny”
  odpowiedz
4. Szymon Skulimowski 11 lat temu:
  @wbielak, czy dobrze mi się wydaje, że chciałeś odpowiedzieć na inny komentarz? Jeśli tak, to daj znać o który chodziło, chętnie przeniosę go w odpowiednie miejsce.
  odpowiedz
Krzysiekn 11 lat temu:
Dokładnie to jeden z moich blogów ma taki atak codziennie. Hosting home.pl , ale w ogóle nic nie zwalnia :). Zmieniam hasło codziennie ;D
odpowiedz
Kuba 11 lat temu:
Dziś właśnie zastanawiałem się jak zabezpieczyć bloga. Mam obecnie zainstalowane Wordfence Security i WebsiteDefender. Warto trzymać oba? Po pracy zabezpieczę pliki zgodnie z Twoją instrukcją. Dzięki za ciekawy artykuł.
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Nie korzystam z tych wtyczek, ale z tego co zauważyłem to:
  – Wordfence Security ma charakter bardziej informacyjny (np. wyświetla informację o uprawnieniach newralgicznych plików) a jedyną rzeczą, którą można zrobić to zmiana prefiksu tabel w bazie danych.
  – Wordfence Security jest trochę przeładowana niepotrzebnymi funkcjami a inne dostępne są dopiero po wykupieniu abonamentu. Skaner plików wydaje się całkiem fajny, ale błędnie zaznacza pliki standardowych motywów w polskiej wersji językowej.
  Pierwszą można więc zainstalować jedynie w celach informacyjnych i potem od razu odinstalować. Druga faktycznie może coś pomóc, ale jej działanie nie wykorzystuje możliwości serwera (htaccess) więc przy wspomnianym w artykule zmasowanym ataku brute-force na nic się nie zda.
  Ale to tak na szybko. Prawdziwy potencjał Wordfence Security będzie można ustalić dopiero po dłuższym użytkowaniu. Być może jest to wtyczka, którą warto posiadać w swojej kolekcji.
  odpowiedz
2. Jacek Lewandowski 11 lat temu:
  Dzięki za artykuł. Zabezpieczenie wdrożone :D
  Od paru dni używam Wordfence Security i również zdecydowanie zachęcam do zapoznania się z jej możliwościami. Może ona np. z powodzeniem zastąpić Limit Login Attempts, ponieważ posiada taką opcje – można ustawić dopuszczalną ilość błędnych logowań osobno na login i hasło. Opcje firewalla pozwalają również na blokowanie po IP (bezterminowe lub okresowe) robotów i użytkowników generujących częste 404-ki i zapytania do serwera. Świetną sprawą jest powiadamianie na maila o każdym logowaniu lub nieudanej próbie logowania do panelu, o użyciu formularza odzyskiwania hasła, o wszelkich problemach, i… wiele, wiele innych.
  Godna polecenia jest też „Better WP Security” choć miałem przypadek konfliktu z innymi wtyczkami.
  odpowiedz
3. Zielony Architekt 11 lat temu:
  Obawiam się, że w większości przypadków serwisy siedzą na współdzielonym hostingu i wtedy zwykle użytkownik nie ma możliwości samodzielnego konfigurowania regułek firewalla. Artykuł jest super, bo pokazuje konkretne możliwości na poziomie modułów/wtyczek do WP.
  odpowiedz
Miszczunio WuJitsu 11 lat temu:
Co prawda z WP jeszcze nie próbowałem ale z wieloma CMS-ami, gdzie zmiana adminowni nie jest możliwa w prosty sposób, a mamy dostęp do ssh proponuję posiłować się z całkowitym ukryciem panelu.
Najpierw dodajemy nową subdomenę. W zależności od tego czy można ją wskazać na dowolny katalog, czy drzewko katalogów jest automatycznie zakładane, poprzez ssh tworzymy dowiązanie do katalogu wp-admin o nazwie zastępującej katalog subdomeny.
Tym sposobem do zarządzania blogaskiem łączymy się przez ukrytypanel.mojegoblogaska.kom
Pozostaje wyprowadzić hakierskie skrypty w pole przekierowując htaccessem cały ruch spod /wp-admin na statyczną 404/500-kę czy gdzie tam pieprz rośnie. Można nawet i na główną, ale lepiej odciągnąć łyrdpresa całkowicie od zarzynania serwera ;)
ps. bez dostępu do ssh możliwość stworzenia symlinka wciąż istnieje. Należy uśmiechnąć się do adminów hostingu* z taką prośbą.
*u największych dostawców hostingowych nie liczcie na to
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Nie robiłem tego wcześniej, ale zdecydowanie warto to wypróbować.
  Jeśli będziesz miał kiedyś okazję przetestować to na WordPressie to daj znać jak poszło i czy trzeba wykonać jeszcze jakieś dodatkowe akcje.
  Dzięki za przydatną wskazówkę.
  odpowiedz
Andrzej 11 lat temu:
Ciekawy artykuł, mam tylko jedno 'ale’ co do generowania losowych haseł. Z doświadczenia wiem, że takie rozwiązanie się nie sprawdza. Możesz mieć hasło zapisane na kartce, telefonie, czole, gdziekolwiek ale kiedy znajdziesz się w sytuacji, kiedy nie masz dostępu do żadnej z tych rzeczy, a trzeba wprowadzić krytyczne poprawki na stronie. Oczywiście idea losowych haseł nie tyczy się tylko WP. Tu pojawia się pytanie: co łatwiej zapamiętać? 8sjrk4k2ajs8302j3j3msks91lko czy np. !Czerwona@Doniczka@Za@Oknem! – jedno i drugie hasło ma 28 znaków, chwała temu, który zapamięta kilka różnych haseł pierwszego typu, ale pokuszę się o twierdzenie, że przy brute force (i nie tylko) oba hasła mają tę samą wagę.
Szymon, co sądzisz o takim podejściu to tematu? Przy okazji, wielkie dzięki, wprowadziłeś mnie w świat WP od kuchni.
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Świetne pytanie!
  Zapamiętywanie haseł jest w porządku pod warunkiem, że nie jest ich zbyt dużo (i, że nie masz sklerozy). Ale – konto pocztowe, profil na portalu społecznościowych, bankowość internetowa, serwis aukcyjny, dane dostępowe do serwera i panelu administracyjnego strony – nikt przecież nie zapamięta tylu informacji a użycie jednego hasła do wszystkich do strzał w stopę.
  Zapisywanie na kartce też jest OK, ale zarządzanie nimi, zwłaszcza przy większej ilości silnych haseł może być mocno kłopotliwe.
  Na końcu pozostaje jeszcze moja ulubiona metoda czyli programy do zarządzania hasłami. Ja korzystam z KeePassa i polecam to każdej osobie, które ma styczność z komputerem. 291 – tyle rekordów liczy obecnie moja baza i cały czas rośnie.
  Mobilność? Wystarczy bazę wraz z przenośną wersją KeePassa zapisać na pendrivie lub Dropboxie.
  odpowiedz
Łukasz 11 lat temu:
Ciekawy opis. Ciekawsze jest jeszcze rozwiązanie. A jak wygląda sprawa z aktualizacją samego WordPressa? Wiadomo, że powinna być zawsze najnowsza wersja, jednak przy większej ilości stron jest to nieco uciążliwe i nie zawsze da się wykonać aktualizację sprawnie po jej opublikowaniu. Czy posiadanie WP np. w wersji 3.5 może prowadzić do łatwiejszego włamania się na stronę?
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Tak, każda nowa wersja WordPressa eliminuje część błędów z poprzednich wersji, które są związane z bezpieczeństwem. Przykładowo – aktualizacja WordPress 3.5.2 posiadała 7 istotnych poprawek w tym zakresie.
  Reasumując – aktualizowanie WP, wtyczek i motywów to jedna z podstawowych czynności jeśli chodzi o bezpieczeństwo.
  odpowiedz
sten 11 lat temu:
Dzięki za użyteczny content mam jednak problem.
Robię wszystko jak opisujesz, wrzucam pliki gdzie trzeba. Próba zalogowania do /wp-admin powoduje pojawienie się dodatkowego okna.
Niestety wpisywanie loginu i hasła nic nie daje. Cały czas pojawia się okno. W czym jest problem?
Próbowałem wrzucać .htpasswd do wszystkich możliwych katalogów.
Odnalezienie tego pliku na serwerze poprzez url bar ten NIE stanowi problemu.
Czy to jest jakaś kwestia domeny?
Daj proszę znać czy masz jakąś wskazówkę.
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Jesteś pewien, że podajesz poprawne dane (tekst zapisany w pliku .htpasswd jest zakodowany więc różni się od tego, które trzeba wpisać)?
  odpowiedz
2. sten 11 lat temu:
  Jestem pewny. Podaje te dane, które zostały wpisane przed zakodowaniem.
  Czy adres do pliku w .htaccessie powinien zaczynać się od „http” czy od „/”.
  Próbowałem obu schematów i nic.
  odpowiedz
3. Szymon Skulimowski 11 lat temu:
  Powinien zaczynać się od /.
  To jest ta sama konstrukcja, którą podaje plik info.php.
  Przykładowo – jeśli info.php wgramy do katalogu głównego WordPressa a .htpasswd o jeden katalog wyżej to ścieżki będą wyglądały następująco:
  info.php:
  /home/klient.dhosting.pl/wpn/wpninja.pl/public_html/info.php
  .htpasswd:
  /home/klient.dhosting.pl/wpn/wpninja.pl/.htpasswd
  odpowiedz
Michał Wendrowski 11 lat temu:
Bardzo skuteczną formą zabezpieczenia się przed atakami bruteforce jest dwuskładnikowe uwierzytelnianie. Wprowadza ono kolejny element do procesu logowania (komórkę albo urządzenie). Najprostszym systemem dwuskładnikowego uwierzytelniania jest Rublon:
https://wordpress.org/plugins/rublon/
Rublon ochroni Twoje konto przed dostępem z nieznanych urządzeń, nawet jeśli Twoje hasło zostanie skradzione. Jest to niewidoczne dwuskładnikowe uwierzytelnianie. Więcej info: http://www.rublon.com/pl.
Instalacja jest bardzo prosta: najpierw należy zainstalować aplikację mobilną Rublon (dostępną dla Android, BlackBerry, iPhone i Windows Phone: https://rublon.com/pl/get). Następnie plugin WordPress, aktywować go klikając na „Aktywuj Rublon” i skanując kod QR przy pomocy appki Rublon smartfonem. Następnie wejść do profilu użytkownika i kliknąć na „Zabezpiecz konto Rublonem” — voila :-)
Swoje blogi już zabezpieczyli Rublonem m.in. http://www.sprawnymarketing.pl, http://www.domeny.tv., http://www.minicrm.pl, http://www.wpseo.pl, blog.itauditor.pl, http://www.bikemarket.pl, http://www.usaudio.com.
odpowiedz
1. wojcieh 11 lat temu:
  A nie wiem czy nie będzie lepsza ta wtyczka – https://wordpress.org/plugins/google-authenticator/
  odpowiedz
2. Michał Wendrowski 11 lat temu:
  Wojciechu, dziękuję za zainteresowanie Rublonem! :-)
  Zapoznaj się proszę z zaletami Rublona:
  https://rublon.com/pl/what/advantages
  Rublon to w tym momencie najprostszy, najwygodniejszy sposób dwuskładnikowego uwierzytelniania. Rozwiązania konkurencyjne są zbyt uciążliwe w użyciu, dlatego mało kto chce z nich korzystać.
  odpowiedz
3. marsjaninzmarsa 11 lat temu:
  Polemizowałbym z tym, że „mało kto chce z nich korzystać”. ;)
  Przewagą rozwiązań konkurencyjnych jest również decentralizacja, która znacznie zwiększa bezpieczeństwo.
  odpowiedz
4. Krzysiek Dróżdż 10 lat temu:
  @Michał:
  ” są zbyt uciążliwe w użyciu, dlatego mało kto chce z nich korzystać”?
  C’mon… Jak już chcesz jechać po konkurencji, to zrób to chociaż z pomysłem… ;)
  odpowiedz
Łukasz 11 lat temu:
Dzięki za pomoc :) Osobiście korzystam z Better WP Security.
odpowiedz
ralokles 11 lat temu:
Witam.
Bardzo dobry tekst. Próbowałem wprowadzić takie zabezpieczenie u siebie, ale po wykonaniu wszystkich punktów serwer podał taki komunikat:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator at… to inform them of the time this error occurred, and the actions you performed just before this error.
More information about this error may be available in the server error log.
Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.
Apache/2.4.6 (Unix) OpenSSL/1.0.0-fips mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 Server at worldpoliticsjournal.com Port 80
Czy wiecie jak rozwiązać ten problem?
odpowiedz
1. marsjaninzmarsa 11 lat temu:
  Musiałeś popełnić gdzieś błąd w składni pliku .htaccess, w logach powinieneś mieć bardziej szczegółowe informacje.
  odpowiedz
wbielak 11 lat temu:
Dodam jeszcze że idealny układ to własny serwer i odpowiednie regułki obcinające ruch zanim dotrze do PHPa
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Dzięki za przydatną wskazówkę!
  Mógłbyś to nieco rozwinąć lub podać odnośniki do materiałów na ten temat? Teraz korzystam ze współdzielonego hostingu, ale zastanawiam się nad przejściem na VPS. Wtedy z pewnością skorzystam z Twojej rady :-)
  odpowiedz
2. Tomek | zenbox.pl 11 lat temu:
  Dokładnie :) My zrobiliśmy to na warstwie serwera, aby każdy klient był domyślnie chroniony.
  odpowiedz
december 11 lat temu:
Dzisiaj LinuxPL sam wprowadził takie zabezpieczenia do wszystkich WordPressów: http://blog.meloniq.net/2013/09/02/linuxpl-wylaczenie-zabezpieczenia-panelu-logowania-do-wordpressa/
Tylko to wyłączyło moje hasło i oczywiście nikt nie wie, jak to naprawić (po wykonaniu instrukcji z posta zabezpieczenie znika całkowicie i dostęp do wp-login.php jest niezabezpieczony).
Zresztą metoda poinformowania o loginie i haśle – zamiast przesłać mailem – bezcenna. Już nie mówię o łatwiejszych do odgadnięcia!
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  To już drugi fail z ich strony :-)
  odpowiedz
SERVITIUM 11 lat temu:
Widocznie był zmasowany atak na WP w Polsce :-)
U jednego z klientów przez nieuwagę zapomniałem ukryć domyślne ścieżki do wp-login i wp-admin i w krótkim okresie czasu miałem ~20000 prób logowań.
Na szczęście od razu dostałem informację emailową o próbach nieudanego logowania.
Po 3 minutach i włączeniu jednej opcji, już nie było ataków.
Domyślnie zaraz po instalacji WP jako pierwszą wtyczkę instaluję „Better WP Security” najlepsze z przetestowanych do bezpieczeństwa i zawierająca funkcjonalności co powyżej wskazane.
Zrobisz w niej wszystko: zmienić ID admina, zmienisz domyślną nazwę 'admin’, ukryjesz ścieki domyślne do wp-login i wp-admin, wykryjesz próby włamań i dużej liczby odwołań 404, dostaniesz powiadomienia email i masa innych.
odpowiedz
Anonim 11 lat temu:
Będę musiał pomyśleć o tym na swoim blogu. Dzięki za temat
odpowiedz
Mateusz 11 lat temu:
Szymon, zainspirowałeś mnie i dodałem swoje 3 gorsze: http://slick.pl/kb/wordpress/wordpress-how-to-prevent-brute-force-attacks/
Jeśli masz (lub inni czytelnicy) coś do dodania to zapraszam do lektury i sekcji komentarzy. :-)
odpowiedz
Łukasz 11 lat temu:
A ja mam problem – uruchomiłem zabezpieczenie przez htaccessa i strona w ogóle się nie ładuje – jest błąd wewnętrzny serwera, podobnie jak napisał ralokles wyżej. W czym jest problem? Jak zabezpieczałem tą metodą cały serwis, to nie było problemu, ale jak tylko dostęp do wp-login.php wywala błąd.
odpowiedz
1. Mateusz 11 lat temu:
  Zobacz mój artykuł. Zapewne dostajesz Internal Error 500 a to w większości przypadków jest spowodowane złym powiązaniem .htaccess i .htpasswd.
  odpowiedz
2. Łukasz 11 lat temu:
  Rozumiem, czyli jak wynika z Twojego artykułu – zabezpieczenie wtyczką Better WP Security wystarczy? Czyli nie trzeba się bawić w htaccesa?
  odpowiedz
3. Mateusz 11 lat temu:
  Inaczej. Zabezpieczenie WordPressa wtyczką to jedno a dodatkowe zabezpieczenie wp-login przez .htaccess & .htpasswd to drugie. To dwa niezależne rozwiązania. Wybierz to co jest dobre dla Ciebie.
  odpowiedz
4. Łukasz 11 lat temu:
  A które jest bezpieczniejsze? Czy ta wtyczka wystarczy w zupełności czy nie koniecznie?
  odpowiedz
5. Mateusz 11 lat temu:
  Mi wystarczyła wtyczka ponieważ zmieniłem sobie dzięki niej url’a z wp-login.php na unikalny adres, którego bot używając brute-force nie jest w stanie znaleźć wchodząc tylko na 404.
  odpowiedz
6. Szymon Skulimowski 11 lat temu:
  @Mateusz,
  „(…) tylko na 404…” – warto się nad tym zastanowić bo jeśli strona błędu 404 jest obsługiwana przez WordPress to nadal generowane jest obciążenie serwera. Dla pojedynczych prób włamania nie będzie to miało żadnego znaczenia, ale przy zmasowanym ataku może to doprowadzić do przeciążenia (w efekcie nasza strona przestanie działać) :)
  odpowiedz
Marcin 11 lat temu:
A ja polecam jednak metodę ze zmianą nazwy pliku wp-login.php, choć ten ostatni, jak zauważył Szymon trzeba i tak zostawić, to wystarczy w nim zostawić bardzo mało, bo sam header. tak czy inaczej inne spojrzenie, wraz z gotowym kodem: Atak na wp-login.php i bardzo proste rozwiązanie.
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Dzięki! W artykule podałeś jak zapobiec nadpisaniu wp-login.php przy aktualizacji WordPressa, który postawiony jest na nginx. Czy można coś takiego zrobić dla starego, poczciwego Apache? :-)
  odpowiedz
2. Marcin 11 lat temu:
  Słusznie, uzupełniłem reguły też dla apache’a.
  odpowiedz
3. Szymon Skulimowski 11 lat temu:
  Przetestowałem i działa wyśmienicie!
  Tylko jedna uwaga – to zabezpieczenie przed aktualizacją pliku nie powstrzymuje skryptu przed podmianą pliku na nowy, ale ogranicza do niego dostęp od strony przeglądarki więc wychodzi właściwie na to samo :-)
  odpowiedz
4. Marcin Pietrzak 11 lat temu:
  Dokładnie, po dodaniu banowania plik wp-login może być bez kłopotu aktualizowany i na nic to nie wpływa.
  odpowiedz
5. Szymon Skulimowski 11 lat temu:
  Jedyna wada tego rozwiązania to konieczność pilnowania na własną rękę czy przypadkiem kolejna aktualizacja WP nie wprowadza jakiś znaczących zmian do pliku formularza logowania.
  Gdyby udało się obejść to byłoby genialnie.
  odpowiedz
6. Paweł Knapek 11 lat temu:
  Zerknij w komentarze, bo podałem tam właśnie tego typu fixa.
  odpowiedz
7. Marcin Pietrzak 11 lat temu:
  @Szymon: ban na wp-login.php załatwia całkowicie sprawę aktualizacji, bo bez znaczenia czy plik istnieje, czy nie to i tak nie jest sprawdzany/pobierany, sam serwer zwróci dla takiego zapytania kod 403.
  odpowiedz
8. Szymon Skulimowski 11 lat temu:
  Wydaje mi się, że deklaracja, którą podałeś dla Apache ogranicza jedynie dostęp do pliku z zewnątrz i nie uchroni to wcale pliku przed aktualizacją WP. Pewnie to kwestia ustawień serwera, ale mówię tu z perspektywy standardowego hostingu dla zwykłego użytkownika :-)
  Ale nie w tym rzecz.
  Chodzi mi o to, że poprzez zmianę nazwy pliku wp-login.php w sposób, który opisałeś odcinamy się od aktualizacji jego kodu w przyszłości. Nie żeby wp-login.php był jakoś często aktualizowany, ale stwarza to pewne niebezpieczeństwo, że w pewnym momencie obudzimy się z ręką w przysłowiowym nocniku :)
  Z tego co zauważyłem to jest to właśnie ta kwestia, o której wspominał Ci już Paweł w jednym z komentarzy na Twojej stronie.
  odpowiedz
9. Marcin Pietrzak 11 lat temu:
  Ban w .htaccess i symlink – załatwia i dostęp i aktualizacje.
  odpowiedz
Jakub 11 lat temu:
Mam problem z logowaniem poprzez .htacces.
Wszystkie kroki wykonałem tak jak byly opisane powyżej. Po wywołaniu adresu strona.com/wp-login.php podaję login i hasło. W tym momencie wyskakuje mi ponownie okienko logowania i nie mogę przejść przez ten proces.
Mam serwer na home, IdeaWebServer/v0.80
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Czy jesteś pewien, że wprowadziłeś poprawną ścieżkę do pliku z zapisanym hasłem? I, że dane dostępowe, które podajesz w formularzu są poprawne?
  odpowiedz
2. Jakub 11 lat temu:
  Udało mi się rozwiązać problem. Okazało się, że na home używane jest szyfrowanie hasla w crypt() (ja tworzyłem hasło w MD5). Dodatkowo inaczej wygląda ścieżka do .htpasswd (jest poziom wyżej niż .htacces).
```
AuthName "Podaj haslo"
AuthType Basic
AuthUserFile ../.htpasswd
<Files wp-login.php>
require valid-user
</Files>

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
```
  odpowiedz
3. marsjaninzmarsa 11 lat temu:
  Racja, Home.pl… oni zawsze muszą wszystko inaczej. :x
  odpowiedz
4. Szymon Skulimowski 11 lat temu:
  Dzięki Jakub za podzielenie się kodem! :-)
  odpowiedz
5. Kasia 10 lat temu:
  Do tworzenia takiego hasła (zaszyfrowanego w crypt()) może się przydać ta strona… :) To tak dla potomnych, bo sama też szukałam. http://www.kxs.net/support/htaccess_pw.html
  odpowiedz
6. Szymon Skulimowski 10 lat temu:
  Dzięki Kasia!
  odpowiedz
Marek 11 lat temu:
Do panelu mojego bloga juz wiele razy próbowano sie włamać. mam wrażenie, ze to właśnie roboty starają się forsować wejście do skryptu.
Cyklicznie ktoś próbuje dostać się do środka. czasami jak mnie nie ma dłuższy czas na necie, poprzez „PSPad” na FTP zmieniam nazwę pliku „wp-login.php” na inna nazwę np: „wp-ssgsgsg.pl”.
Nie mogę zrozumieć dlaczego w tym skrypcie nie można zmienić nazwy logowania? To definitywnie pomogło by. Ale cóż? Nie można mieć wszystkiego :)
Pozdrawiam,
Marek
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  W takim razie powinieneś zainteresować się metodą opisaną w artykule (hasło na .htaccess) :-)
  odpowiedz
Ignacy 11 lat temu:
Co prawda nie doświadczyłem ataku „brute force”, ale myślę, że to zasługa hostingu. Natomiast przykład powyższej konfiguracji bardzo mi się przyda.
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Warto pamiętać, że takie rozwiązanie to także dodatkowe zabezpieczenie przed innymi atakami, które dzieją się z wykorzystaniem panelu administracyjnego.
  odpowiedz
Karol 11 lat temu:
Hej
A nie możesz może zrobić wtyczki do wordpressa która automatycznie robiłaby coś takiego?
Bo mam sporo wordpressów i trochę nie chce mi sie tracić czasu na robienie tego zabiegu ręcznie.
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Hej Karol,
  ja sam nie posiadam wystarczającej wiedzy żeby przerobić to na wtyczkę, ale gdyby coś takiego istniało to też bym z chętnie skorzystał (jeśli ktoś natrafi na coś takiego to będę bardzo wdzięczny za informację).
  Z drugiej strony nie ma tu aż tyle roboty – robisz to raz i zapominasz (byle nie hasło choć wtedy wystarczy zmodyfikować zapis w odpowiednim pliku i po kłopocie).
  Z ciekawości – ile masz tych WordPressów?
  Pozdrawiam,
  Szymon
  odpowiedz
Katar 11 lat temu:
Dzisiaj dostałem mejla z info o 5 próbach błędnego logowania i blokadzie na kilka godz.
1. Czyli jest jakieś zabezpieczenie w standardzie? Bo nie mam żadnych wtyczek typu security.
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Od kogo otrzymałeś wiadomość? Od firmy, u której masz wykupiony hosting?
  odpowiedz
2. Katar 11 lat temu:
  Ok już rozwiązana ta zagadka ;) Mejla dostałem ze swojego wp, po przejrzeniu wtyczek okazało się że ta odpowiedzialna za logowanie, panel i rejestracje ma włączoną opcje zabezpieczeń. Dokładnie to Theme My Login.
  Jest tam jeszcze opcja reCAPTCHA Settings w której nie wiem o co kaman a by się przydała bo boty się rejestrują co jakiś czas. Jak ktoś coś wie to pisać.
  I mam jeszcze jedno pytanie. Mam kilka stron na wp a rekordzista ma 19 wtyczek. To dużo czy mało? ile macie u siebie? Mówi się że im mniej tym lepiej:/
  odpowiedz
3. Szymon Skulimowski 11 lat temu:
  Uaktywnienie opcji reCAPTCHA powinno wyświetlić na stronie logowania taki graficzny obrazek, z którego trzeba przepisać tekst. Najwidoczniej ta funkcja wtyczki aktualnie nie działa (u mnie nic się nie pojawiło a patrząc po forum ze wsparciem technicznym to nie jest to odosobniony przypadek) :-)
  odpowiedz
4. Szymon Skulimowski 11 lat temu:
  Ah, jeśli chodzi o Twoje pytanie odnośnie liczby wtyczek to wszystko zależy od tego jakie to ważniejsza od ilości wtyczek jest ich jakość. 1 słabo zakodowana wtyczka potrafi narobić więcej szkód niż 30 dobrych.
  A odpowiadając wprost to WPNinja korzysta aktualnie z 27 wtyczek. Kto da więcej? :)
  odpowiedz
Krzysztof 11 lat temu:
A ja bym prosił o odpowiedź, co może być przyczyną, że moje pliki php w wordpress zostały zainfekowane? Na początku każdego pliku powstał kod. Zresztą nie tylko na blogu również w innych plikach php na serwerze.
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  2 bardzo popularne przyczyny to:
  1. Wyciek danych dostępowych do serwera przez FTP.
  Tu możliwości jest bardzo dużo. Załóżmy, że Ty lub inna osoba, której powierzyłeś dane dostępowe zapisała je na stałe na komputerze w niezabezpieczonej formie (plik tekstowy, mail w programie pocztowym a nawet wprowadzenie danych na stałe do klienta FTP). Wystarczy teraz, że na takim komputerze pojawi się program wyłapujący takie dane (złośliwe oprogramowanie).
  2. Trzymanie na serwerze kodu podatnego na ataki.
  Do tego zaliczają się takie rzeczy jak: stara wersja skryptu TimThumb, nieaktualizowane wtyczki, motywy i sam WordPress, dodatki pochodzące z niezaufanego (nie z oficjalnego katalogu WP) źródła a także rzeczy zupełnie niezwiązane z WP, ale postawione obok niego (np. stary skrypt phpBB).
  odpowiedz
Krzysztof 11 lat temu:
Co do samego ataku bruteforce istnieje jeszcze metoda, która pozwoli nam się przed nim bronić, mianowicie możemy udostępnić logowanie tylko dla danego adresu IP.
Nie jest to rozwiązanie idealne, ale lepszy rydz niż nic. Poniżej kod dla pliku .htaccess:
```
<Files wp-login.php>
order deny,allow
Deny from all

#Pierwszy adres IP, z którego będziemy mogli się zalogować
allow from xx.xxx.xx.xx

#Kolejny adres IP, który będzie dopuszczony do panelu logowania
allow from xx.xxx.xx.xx
</Files>
```
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Zgadza się, to również zda egzamin, ale tylko wtedy gdy mamy stałe adresy IP a w dzisiejszym świecie jest to coraz trudniejsze.
  odpowiedz
2. Klasyk 11 lat temu:
  Gdzie dokładnie umieszcza się ten kod.
  Czy wrzuca się cały plik w jakieś miejsce? Jeśli tak, to jakie?
  Czy też dokleja do pliku htaccess? Jeśli tak, to w które miejsce?
  odpowiedz
3. Szymon Skulimowski 11 lat temu:
  Kod trzeba dokleić do pliku .htaccess, który powinien znajdować się w katalogu głównym WordPressa. Jeśli go tam nie ma to można go stworzyć ręcznie.
  Miejsce doklejenia jest w zasadzie dowolne, ale żeby przypadkiem niczego nie popsuć lepiej wstawić na początku lub na końcu.
  odpowiedz
4. Drwal Pustynny 11 lat temu:
  To jeszcze inaczej. Zezwolić na dostęp tylko z Polski. Ataki są raczej z tego co widzę z poza Polski.
  odpowiedz
Kamil 11 lat temu:
Ja tak krótko, chciałem tylko podziękować, naprawdę świetny wpis. Od jakiegoś czasu uczę się wszystkiego z WordPressem, bardzo przydatna informacja odnośnie ochrony. I – co bardzo ważne – prosto i przejrzyście objaśnione i wytłumaczone jak zrobić krok po kroku, nawet dla laika. Jeszcze raz dzięki ;)
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Cieszę się, że artykuł Ci się spodobał. Dzięki! :-) A może masz jakieś sugestie co do kolejnych tematów na kolejne wpisy?
  odpowiedz
2. Kamil 11 lat temu:
  Kurcze, normalnie to mam miliony pytań, a teraz to niewiele mi przychodzi do głowy ;) Szczerze mówiąc to zastanawiają mnie niektóre zagadnienia części wizualnej strony, typu jak zrobić zakładki z menu z boku strony, jak ma na przykład mój imiennik na stronie http://www.lipinski-kamil.pl/. Podobne zakładki są robione z linkami do facebooka czy innych portali społecznościowych, ale jako przyciski menu używa się do tego specjalnej wtyczki czy to jest już zabawa z kodem?
  I jeszcze tak, nie wiem czy dla innych okaże się to pomocne, ale chodzi o dwa, w sumie totalnie przeciwne pomysły na wykorzystanie wordpressa. Pierwszy, chodzi o zwykłą stronę będącą np tylko wizytówką dla jakiejś firmy, gdzie nie ma potrzeby prowadzenia bloga i robienia wpisów, potrzebna jest np strona główna z krótkim opisem firmy, kilka podstron, widgetów z boku i git. Jak wyeliminować ze strony głównej miejsce na wpisy, tak, żeby nie zostawiać po nim pustego obszaru tylko od razu zaaranżować jako jedną ze stron?
  I drugi, przeciwny pomysł to może jakiś artykuł o tworzeniu bardziej rozbudowanych stron i serwisów na bazie wordpressa, czytałem różne porównania z Joomlą, która jednak jest bardziej polecana do bardziej rozwiniętych stron. Na co trzeba uważać czy co byś polecał przy budowie bardziej rozwiniętych stron wordpressem, czy może jednak faktycznie korzystać przy tym z innych CMSów?
  Pozdrawiam, gdybym na wpadł na coś jeszcze dam znać ;)
  odpowiedz
3. marsjaninzmarsa 11 lat temu:
  Jeśli chodzi o stronę-wizytówkę ze statyczną stroną główną, to pytanie jest trywialne, wystarczy wybrać odpowiednią opcję w Ustawienia -> Czytanie. :)
  odpowiedz
4. Kamil 11 lat temu:
  Aaa faktycznie, moje niedopatrzenie. Dzięki ;)
  odpowiedz
5. Szymon Skulimowski 11 lat temu:
  W przypadku Kamila Lipińskiego takie latające menu to kawałek własnego kodu, ale w katalogu wtyczek też można znaleźć coś podobnego, np. CodeFlavors floating menu.
  Jeśli zaś chodzi o niestandardowe wykorzystanie WP to tak naprawdę to co opisałeś to 8/10 zleceń, które realizuję dla klientów :)
  Co lepiej wybrać – WordPress, Drupal a może Joomla? To dobre pytanie, ale nie ma na nie prostej odpowiedzi. To tak jak z systemami operacyjnymi – Windows, OS a może Linux? Wszystko tak naprawdę zależy od tego co chcesz osiągnąć oraz jakimi środkami i wiedzą dysponujesz.
  Jeśli pytasz wprost czy WP nadaje się do bardziej rozbudowanych stron to jasne, dlaczego nie? WP jest zdecydowanie najpopularniejszy dlatego ciągną do niego wszyscy. Także osoby, które kupują zagraniczny hosting za 20 zł / rok, motyw-kombajn na ThemeForest i uruchamiają po 50 wtyczek. A potem jęczą, że WP to szajs bo muli :-)
  odpowiedz
Kamil 11 lat temu:
A propos Themeforest… polecasz ich rozbudowane szablony czy lepiej pobawić się prostszymi, ale przy odpowiedniej własnej przeróbce? Miałeś jakieś doświadczenia z ich motywami?
odpowiedz
1. marsjaninzmarsa 11 lat temu:
  *Zdecydowane nie* szablonom z Themeforest, szczególnie tym zaawansowanym… zmiana w nich jednego duperela, którego zmiany autor nie przewidział to jest masakra, kod jest najczęściej tragicznej jakości, lubią się wysypywać, wchodzić w konflikty z wtyczkami, są przeładowane… ja generalnie jeśli ktoś proponuje mi przeróbkę szablonu, to do tych z Themeforest doliczam z góry +40%…
  odpowiedz
2. Szymon Skulimowski 11 lat temu:
  Podzielam zdanie marsjaninazmarsa choć chciałbym wierzyć, że gdzieś tam w zakamarkach ThemeForest istnieją nie tylko dobre, ale i genialne motywy. Ja niestety takich nie spotkałem, ale z drugiej strony już od bardzo dawna omijam je szerokim łukiem.
  odpowiedz
3. Tomek | zenbox.pl 11 lat temu:
  Co do themeforest to trzeba rozdzielić pewne sprawy.
  1. Front – wygląd – tutaj mamy setki pięknych po prostu skórek.
  2. Backend – kod – w 80% tragedia, pisana na kolanie, pełno niepotrzebnych odwołań etc.
  I potem taki blog, który mógłby wytrzymać ruch 10x większy leży i kwiczy przy 10 osobach online.
  odpowiedz
4. Szymon Skulimowski 11 lat temu:
  Ad 1. „Pięknych” bo wypełnionych treścią przez ich autorów :-) A potem zdziwienie, że jednak „na froncie” nie wygląda to już tak wspaniale.
  odpowiedz
5. Tomek | zenbox.pl 11 lat temu:
  A tak tak to klasyka klasyki. :D
  odpowiedz
Drwall 11 lat temu:
Ja mam taki problem, że po dodaniu kodu .htaccess, nie wyświetla się grafika i css w oknie logowania wordpressa. Dlaczego?
Okno jest pozbawione styli i grafiki.
odpowiedz
1. Drwall 11 lat temu:
  A przepraszam, chyba już jest ok.
  W ostatnich dniach mam próby logowania z takich IP:
  91.208.16.239
  83.169.17.183
  176.56.236.211
  80.65.63.211
  176.102.37.56
  80.82.59.227
  115.135.243.85
  195.200.245.110
  195.5.16.208
  164.177.249.161
  109.239.44.208
  178.90.44.17
  178.89.57.19
  37.212.133.122
  94.113.94.59
  213.21.35.105
  5.76.106.243
  odpowiedz
2. Drwall 11 lat temu:
  Kurcze a jednak nie działa.
  Zarówno na xamppie lokalnie jak i na serwerze mam z tym problem.
  I z tego co widzę problem stwarza fragment
  require valid-user
  Jesli wyciągnę require valid-user poza obręb to pojawi się monit o hasło.
  Jeśli natomiast require valid-user będzie umieszczone w tagu Files to monit się nie pojawi.
  Plik htaccess mam umieszczony w folderze wp-admin
  Zatem gdzie jest problem?
  odpowiedz
3. Drwall 11 lat temu:
  Uff z nadmiaru projektów uparłem się by plik htaccess z kodem był umieszczony w folderze wp-admin. A z tego co widzę ma on być w głównym folderze.
  Mam też pytanie, bo widzę że tutaj na blogu nie stosujesz tego rozwiązania, masz jakiś alternatywny sposób?
  odpowiedz
4. Paweł Knapek 11 lat temu:
  A co właściwie zabezpieczasz? Jeżeli wp-login.php, to kod wrzucasz do .htaccess w katalogu głównym bloga.
  Jeżeli podany wyżej nie działa, spróbuj tak http://pastebin.com/0gXM1q9v
  odpowiedz
5. Drwall 11 lat temu:
  Już wszystko gra, to są skutki robienia 20 rzeczy na raz, nie doczytałem gdzie ma znaleźć się wpis związany z autoryzacją po htaccess, okazuje się właśnie, że w folderze głównym, a ja z uporem maniaka wrzucałem to do wp-admin, zmylił mnie fakt, że tam tez znajduje się wp-login.php. Teraz działa wszystko poprawnie.
  odpowiedz
Ado 11 lat temu:
Moja strona została zaatakowana, musiał naprawdę walczyć, dobrze że zrobiłem kopię zapasową. Teraz używam Wordfence Security, i jestem bardzo zadowolony. Dzięki za instrukcje.
odpowiedz
Edzik 11 lat temu:
Witam, a czy ktoś używał wtyczki All In One WP Security & Firewall? Ma sporo zabezpieczeń ale czy wystarczy dla zabezpieczenia WordPressa? Dziękuję
odpowiedz
1. Szymon Skulimowski 11 lat temu:
  Nie korzystałem, ale wtyczka wygląda całkiem obiecująco. Choć mam awersję do kombajnów, zwłaszcza takich „All in One” to z pewnością ją przetestuję. A jak Twoje wrażenia? Daje radę?
  odpowiedz
2. Edzik 11 lat temu:
  Generalnie podoba mi się, ma większość potrzebnych rzeczy, ale nie działa mi np zmiana prefixu bazy danych i ustawienia strony maintenance- ale tu chyba jest jakiś problem ze skinem- wywalało jakieś błędy php, ale do tego można prostą wtyczkę zainstalować. Podoba mi si e jakby coś nie działało włączeniu np funkcji firewalla, to mona resetować jego ustawienia. Mam nadzieje że wtyczka będzie rozwijana, to może te problemy będą rozwiązane. A czy już miałeś okazję przetestować wtyczkę?
  odpowiedz
3. Szymon Skulimowski 11 lat temu:
  Nie miałem okazji jej przetestować, tym bardziej dzięki za Twoją opinię.
  odpowiedz
4. Kasia 10 lat temu:
  Ta wtyczka jest genialna, zanim zdążyłam ustawić inny adres do logowania, to zdążyłam dostać 5 powiadomień z automatycznymi banami adresów IP po samych próbach logowania na moją stronę za pomocą loginu admin… :D
  odpowiedz
WordPress na home.pl? 7 rzeczy, na które trzeba uważać | WPNinja 11 lat temu:
[…] nazwa administratora sugerowana jest najgorsza z możliwych opcji czyli […]
odpowiedz
Demotywatory 11 lat temu:
Dzięki za poradnik, również skorzystałem z porad zamieszczonych w poradniku. Teraz nie dość że zabezpieczam się przed atakiem to mam podwójne zabezpieczenie (uwierzytelnienie + panel logowania).
Czy masz jakiś poradnik dotyczący ddos, miałem wczoraj taki przypadek że 420 000 razy pobierany był jeden z obrazków na mojej stronie, jak można się łatwo domyślić strona padła, musiałem wykupić nowy transfer dla domeny.
Profilaktycznie na serwerze włączyłem limit transferu dla domen, przykładowo jeśli w poprzednim miesiącu strona zużyła 5 gb transferu, można ustawić limit miesięczny 10 gb. Powinno nas to przynajmniej trochę uchronić przed kolejnymi wydatkami. Zobaczymy jak to się sprawdzi w praktyce.
odpowiedz
1. Demotywatory 11 lat temu:
  Trochę czasu spędziłem na szukaniu sposobu aby zabezpieczyć się przed ddos i postanowiłem tu wrócić, aby podzielić się z Wami swoim znaleziskiem. Znalazłem coś takiego: cloudflare.com
  Właśnie dopiero zaczynam testować więc swojej opinii tutaj nie wyrażę, ale wygląda obiecująco. Dodajemy stronę, a następnie podmieniamy dns na te które pokaże nam cloudflare.
  odpowiedz
2. Szymon Skulimowski 11 lat temu:
  Ja sam nie znam sposobu na takie zabezpieczenia obrazków więc tym bardziej jestem ciekaw – jak wyszły testy z CloudFlare?
  odpowiedz
3. Demotywatory 11 lat temu:
  Jak do tej pory się spisuje, ze statystyk CloudFlare wynika, że ataki były przeprowadzane, ale nie przedostały się na moją stronę także polecam ;))
  odpowiedz
kejsi72 11 lat temu:
A ja zauważyłem jeszcze jeden, dość istotny, problem (czy ktoś to może potwierdzić?).
Dotyczy zabezpieczonych stron, dostępnych na hasło; po podaniu prawidłowego hasła do strony pojawia się okienko do autoryzacji sposobem, o jakim mowa w artykule. Można coś z tym zrobić, bo to praktycznie dyskwalifikuje ten sposób zabezpieczenia… :(
odpowiedz
1. Karol Trybulski 11 lat temu:
  Cześć :)
  Mógłbyś opisać problem jeszcze raz? Rozumiem, że to okienko wyskakuje dopiero po zalogowaniu się, czy masz na myśli co innego?
  odpowiedz
2. kejsi72 11 lat temu:
  Cześć,
  zabezpieczenie zostało zrobione zgodnie z opisem i żeby się dostać do panelu admina należy w wyskakującym okienku podać ustaloną nazwę użytkownika i hasło, po czym pojawia się dopiero właściwa strona logowania. Na tym etapie wszystko świetnie działa. Zauważyłem natomiast, że w przypadku wchodzenia na wpis lub stronę zabezpieczoną hasłem po wpisaniu prawidłowego hasła do strony użytkownikowi pokazuje się jeszcze to okienko z dodatkowym zabezpieczeniem, czego nie było w planie, bo on ma wejść tylko na zabezpieczoną stronę, a nie zaplecze serwisu… Taki użytkownik wogóle nie musi się logować, on ma tylko wejść na zabezpieczoną hasłem stronę… w związku z takim nieprzewidzianym działaniem dodatkowej ochrony, musiałem ją wyłączyć do czasu znalezienia rozwiązania.
  odpowiedz
3. Karol Trybulski 11 lat temu:
  Cześć :)
  Sprawdziłem i rzeczywiście to nie działa. Logowanie do wpisu zabezpieczonego hasłem odbywa się poprzez wp-login.php?action=postpass stąd te problemy.
  Jak tylko wymyślę jak to obejść dam znać :)
  odpowiedz
4. Szymon Skulimowski 11 lat temu:
  Dla przejrzystości – wydzieliłem dyskusję do osobnego wątku.
  odpowiedz
5. kejsi72 10 lat temu:
  Zauważyłem, że problem nie występuje w serwisach, w których zainstalowałem wtyczkę zmieniającą stronę logowania albo przekierowującą na określone podstrony po zalogowaniu. I tak np. zabezpieczone hasłami strony serwisu z korzystającego z wtyczki Theme My Login (http://www.jfarthing.com/extend/wordpress-plugins/theme-my-login/) działają prawidłowo.
  odpowiedz
6. Kasia 10 lat temu:
  A czy znalazł ktoś inne rozwiązanie tego problemu (bez wtyczki zmieniającej podstronę po zalogowaniu)?
  odpowiedz
Krzysiekn 10 lat temu:
W sumie nie napiszę trochę pod kątem tego zabezpieczenia, ale najbardziej polecam zabezpieczyć WordPressa przez „weryfikację dwuetapową” taką jaka jest stosowana przez Google i to… przez ich aplikację na Androida (ze sklepu Play), za pomocą smartphone’a.
( http://krzysiekn.pl/ochrona-swojego-konta-na-blogu-wordpress-weryfikacja-dwuetapowa/ )
odpowiedz
1. Krzysiekn 10 lat temu:
  Dodatkowo, po zrobieniu tego zabezpieczenia przez .htaccess nie możemy się zalogować do aplikacji WordPress na naszym smartphonie ;/
  odpowiedz
Julia 10 lat temu:
Dzięki za poradnik, Super artykuł. Czy ktoś „All in one” przetestował?
odpowiedz
1. Paweł 10 lat temu:
  Tak, daje radę. Choć jak to z tego typu wtyczkami bywa, w pewnych sytuacjach niektóre opcje mogą sprawiać problemy – zwłaszcza te dot. logowania czy dodatkowe regułki firewalla ;)
  odpowiedz
Batłomiej 10 lat temu:
Bardzo ciekawy artykuł z pewnością przyda się wielu osobom korzystyjącym z WordPress’a/ swego czasu miałem częste ataki na stronę własnie metoda brute force, na szczęscie w pore zabezpieczyłem strone. :)
odpowiedz
Natalia 10 lat temu:
Witaj Szymonie.
Zrobiłam zabezpieczenie dwóch WP hasłem poprzez plik .htaccess. Na jednej stronie wszystko działa prawidłowo. Na drugiej zdarza się, że „wymusza” podanie hasła na stronie głównej i podstronach – co może być powodem? Mam tu wtyczkę All In One WP Security, czy to ona może coś mieszać?
odpowiedz
1. Natalia 10 lat temu:
  Edit: problem wygląda na taki sam, jaki ma @kejsi72 – czy ktoś znalazł rozwiązanie?
  odpowiedz
2. Szymon Skulimowski 10 lat temu:
  Niestety, nie znalazłem jeszcze rozwiązania tego problemu. Może ktoś z czytelników będzie wiedział jak temu zaradzić?
  odpowiedz
3. Natalia 10 lat temu:
  Póki co ustawiłam we wtyczce zmianę adresu logowania. Zobaczymy, jak się sprawdzi.
  odpowiedz
Drwal pustynny 10 lat temu:
Szymonie a tak z ciekawości zapytam, jakiego rozwiązania używasz? Bo widzę, że można wejść na Twój formularz logowania. Więc wnioskuję, że nie stosujesz zabezpieczenia po .htaccess
Jakie zatem rozwiązanie się sprawdza u Ciebie zważywszy, że masz użytkowników, którzy się logują.
odpowiedz
1. Szymon Skulimowski 10 lat temu:
  Zgadza się. Kiedyś korzystałem z rozwiązania opisanego w powyższym wpisie i sprawdzało się w 100%. Teraz testuję jakość hostingu (Zenbox), który chwali się, że takie zabezpieczenie i ewentualne obciążenie serwera bierze na siebie. Jak na razie jest tak jak mówią.
  odpowiedz
gielo 10 lat temu:
no a ja polecam wtyczkę All In One WP Security i jej dokładną konfigurację. Zabezpiecza przed BruteForce, spamerami, crackerami i innym syfem. Jest to chyba obecnie najlepszy kombajn zabezpieczający WP skupiający wszelkie opcje w jednym miejscu. Dość prosty w konfiguracji zaznaczam, więc może z niego skorzystać każdy.
odpowiedz
AgaK 10 lat temu:
Ja również skorzystałam z porad dotyczących zabezpieczenia mojego WP po tym jak zauważyłam znaczne zwiększenie obciążenie procesora i nasilenie wizyt z Rosji. Dziękuję bardzo za porady bo okazały się bardzo pomocne.
odpowiedz
Damian 10 lat temu:
Świetny poradnik. W home.pl jak zwykle są problemy i info.php nie działa. Ścieżkę do pliku .htpasswd trzeba wpisać tak: ../.htpasswd
odpowiedz
Jakub 10 lat temu:
Szymonie, padłem ofiarą takich właśnie ataków jak opisujesz, 10 wordpressów, totalna masakra, tydzień czyszczenia, zainfekowało całość, potworzyło swoje wtyczki, swoich userów z uprawnieniami admina, pliki w wielu katalogach, pozmienialo pliki oryginalne.. nie jestem super mocny w kwestiach programowania, ale z pomocą Twojego poradnika i wsparciem konsultacyjnym kolegi Pawla Samuraja jakoś sobie z tym poradziłem… z czyszczeniem i zabezpieczeniem.
btw – dla innych rada – używałem wtyczki wordfence dzięki której w ogóle zorientowałem się, że coś podejrzanego się dzieje. a do sprawdzania czy czyszczenie odniosło skutek wspierałem się securi security online scaner.
MAM PYTANIE
wprowadzilem zabezpieczenie .htaccess i wszystko działa fajnie.. tylko że część mojej strony jest zahasłowana, jako tzw. panel klienta, proste zabezpieczenie wpisów i stron WP hasłem.. no i teraz zahasłowało mi całość – i logowanie do panelu admina i do tych stron.. nie da się tego jakoś rozdzielić, tzn żeby panel admina był tak zabezpieczony, a hasłowane strony nie?
odpowiedz
Kamil 10 lat temu:
Trochę odgrzewanie tematu ale akurat mam problemy ze swoją instalacją i zmieniłem nazwę pliku wp-login.php na inną i w pliku wp-login pozmieniałem też wszystkie nazwy na tą nową. Wszystko działą dobrze poza wylogowywaniem, ciągle podczas klikania w przycisk Wyloguj przenosi do wp-login.php?action=logout&_wpnonce zamiast np do wp-kokpit.php?….
I tu moje pytania:
1. Gdzie można zmienić ten link do wylogowywania się?
2. Czemu opisujesz tutaj wykorzystania hasła na stronę wp-login a sam tego nie uzywasz na tym blogu? ;)
Pozdrawiam.
odpowiedz
1. Paweł 10 lat temu:
  zobacz sobie http://iworks.pl/2013/09/25/atak-na-wp-login-rozwiazanie/
  odpowiedz
Monika 10 lat temu:
Witam
Generator htpasswd z podanego przez ciebie linku niestety nie działa…
odpowiedz
1. Szymon Skulimowski 10 lat temu:
  Generator już działa, to były jakieś problemy z ich serwerem.
  odpowiedz
Lukas 10 lat temu:
Witam!
Byłbym wdzięczny za pomoc. Zrobiłem wszystko zgodnie z opisem. Pojawia się okno logowania, jednak po wpisaniu loginu i hasła (prawidłowych) – wyskakuje komunikat:
404 Not Found
Looks like you have taken a wrong turn…..
Don’t worry… it happens to the best of us.
Ps. strona jest na serwerach linuxpl, którzy dodają podobne „zabezpieczenie” , ale próbowałem również ze zmianą nazwy wp-login.php i jest niestety to samo
odpowiedz
Patryk Zieliński 10 lat temu:
Dobry i solidny wpis. Polecam także wtyczke iThemes Security.
odpowiedz
Joanna 10 lat temu:
Wreszcie coś czytelnie i jasno napisanego. Mam stronę na superhost i już drugi raz przytrafił mi się zmasowany atak. Strona została wyłączona przez usługodawcę po raz drugi. Serwis sprawdzałam na oklicznośc zainfekowania, ale nic nie pokazuje. Mam pytanie czy jak na stronie wprowadzam zmiany tylko z jednego, statycznego adresu IP mogę w plik .htaccess wpisać ten adres a resztę all deny? Czy po wpisaniu takiego wpisu zablokuje dostep do panelu admina czy do całego serwisu? Czy przy takim wpisie roboty goole będa mogły indeksowac stronę? Jak powinien wyglądać taki wpis prawidłowo?
odpowiedz
1. Joanna 10 lat temu:
  P.S. generator haseł nie działą. Może mają Brute Force ;)
  odpowiedz
2. Joanna 10 lat temu:
  Taki wpis do pliku .htaccess znalazłam. Napisz co o tym myślisz?:
  allow from 213…. (tu IP adres trzeba wpisać)
  deny from all
  odpowiedz
3. Szymon Skulimowski 10 lat temu:
  Generator już działa, pewnie mieli jakąś chwilową awarię.
  Jeśli wprowadzisz powyższy zapis do .htaccess, który znajduje się w katalogu głównym WP to zablokujesz całą stronę. Możesz zrobić to dla pliku .htaccess, który znajduje się w katalogu /wp-admin/ – wtedy blokada obejmie tylko panel administracyjny (ale nie sam formularz logowania).
  odpowiedz
InfoPage 10 lat temu:
Ładnie, prawie dwa lata temu porada napisana, a ja dopiero dziś z niej skorzystałem…
Kilka chwil i zamontowane! Dodatkowo zamontowałem Limit Login Attempts i dodałem definicje do wp-config.php. Jak szaleć, to szaleć na całego!!!
Dziękuję ślicznie i zapraszam w „moje progi”!
PS. Jeszcze tylko przeczytać wszystkie komentarze, a nuż coś ciekawego się w nich kryje?
odpowiedz
Pawel 10 lat temu:
Dzięki za pomoc, właśnie miałem atak brute, dowiedziałem się o nim z wtyczki „Wordfence Security”, która jednak tylko informowała mnie o próbach logowania (około 2000 prób, tyleż samo e-maili dostałem od tej wtyczki). Jej jedynym działaniem było blokowanie IP napastnika, ale ten atakował z różnych adresów IP więc nic to blokowanie nie pomogło (ponoć płatna wersja lepiej by się spisała, ale mam akurat pilniejsze wydatki).
Wkurzyłem się, odpaliłem google, znalazłem ten poradnik i wszystko gra. Dzięki!
odpowiedz
Łukasz 10 lat temu:
A co sądzisz o systemie prewencyjnym, czy warto, czy się opłaca. Szukam porady, bo mam bloga i nie chciałbym z dnia na dzień utracić wszystkie wpisy. Na razie wiem tylko tyle, że system nie jest antywirusem, jest jego uzupełnieniem coś jak tu https://www.penetrator24.com/ Atak przez hakera nie musi być zwykłym wirusem, często polega na wykorzystaniu luki w konfiguracji komputera lub zainstalowanym oprogramowaniu – i wtedy antywirus staje się bezsilny.
odpowiedz
Atak na stronę – brute force? słownikowy? Jak się zabezpieczyć? – Poradnik informatyka 10 lat temu:
[…] https://wpninja.pl/artykuly/jak-zabezpieczyc-wordpressa-przed-atakiem-brute-force-i-dlaczego-jeszcze-… […]
odpowiedz
Marcin 10 lat temu:
Dzięki za ten artykuł. Dzięki niemu zainstalowałem Wordfence Security. Wyczka monituje pojedyncze ataki. Zauważyłem też jedną rzecz po włączeniu wtyczki Wordfence Security, ruch na stronie spadł o 60%. Co to znaczy? Czy owe 60% to były jakieś boty, czy po włączeniu wtyczki ktoś z użytkowników możne mieć problemy z poprawnym działaniem strony?
odpowiedz
Jan 10 lat temu:
Witam
Post bardzo dobry, faktycznie każdy blog może być zaatakowany.
Wczoraj to spotkało mojego bloga, tyle że mam wtyczkę Wordfence,
to i o ataku momentalnie byłem informowany. Ograniczyłem ilość
nieudanych prób logowania do 1, blokowanie adresów wydłużyłem
do 10 dni.
Dziś uruchomiłem blokowanie dostępu do strony logowanie, prawie
jak w opisano w tym artykule. Znaczy ciut sobie życie ułatwiłem.
Otóż skorzystałem z funkcji C panel konta hostingowe zabezpieczenia
dostępu do katalogów.
To skraca cały proces tworzenia wpisu w pliku htaccess, dodaje automatycznie
plik passwd z danymi logowania w bezpiecznej lokalizacji ( nie w public_html).
Również szyfruje hasło algorytmem md5, czyli nie trzeba z zewnętrznego generatora
korzystać.
Pozostało jedynie nieco zmodyfikować wpisy w pliku htaccess, bo oryginalnie
jest blokowany dostęp do całego bloga, nie do pliku wp-login.php.
Wszystko zajęło 2 minuty, działa jak należy.
odpowiedz
LouKash 9 lat temu:
Nie sprawdzałeś może w praktyce jakiegoś firewalla dla WP? :)
odpowiedz
1. Jan Kamiński 9 lat temu:
  Też by coś takie się przydało
  odpowiedz
2. Paweł 9 lat temu:
  Z wtyczkuf np. Simple Security Firewall, ewentualnie NinjaFirewall.
  Choć prawdę mówiąc firewall na poziomie samego pehapa, to średnio dobry pomysł.
  odpowiedz
Jacek 9 lat temu:
temat ciekawy, od paru godzin borykam się z tym kodem i w zasadzie częściowo działa. Uprzedzę pytania – hasło jest dobre i miejsce też jest dobre, ponieważ podczas wpisania strony http://www.nazwa_strony.pl/wp-login pojawia się do wpisania hasło i to akurat działa dobrze. Sama strona główna też się wyświetla bez logowania dobrze.
Co w takim razie zrobiłem źle, że każda podstrona wyświetla mi teraz błąd ” [Error : Błąd] [404] File Not Found „? Tak samo zachowują się wpisy – jakby nie istniały, a istnieją na pewno, bo wystarczy, że usunę htaccess i wszystko hula jak ta lala… w czym jest problem?
Podaję wpisany kod:
```
AuthName "Restricted Area"
AuthType Basic
AuthUserFile xxxxxxxxxxxxtu podaje sciezkexxxxxxxxxxxxx
<Files wp-login.php>
require valid-user
</Files>

ErrorDocument 401 "Denied"
ErrorDocument 403 "Denied"
# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

order allow,deny
deny from 89.248.166.72
allow from all
# END WordPress
```
proszę o pomoc
odpowiedz
1. Szymon Skulimowski 9 lat temu:
  Powyższy kod powinien działać – przetestowałem go na swoim koncie i obyło się bez problemów. Z jakiego hostingu korzystasz?
  Jeśli możesz zalogować się do panelu administracyjnego to spróbuj jeszcze otworzyć stronę „Ustawienia / Bezpośrednie odnośniki” i bez wprowadzania zmian kliknąć na „Zapisz zmiany”.
  odpowiedz
2. Jacek 9 lat temu:
  hosting jest bardzo dobry, płacę a niego prawie tałzena rocznie, z osobnym dedykiem więc po tamtej stronie jest ok.
  sprawdzałeś u siebie z tym kodem podstrony? bo strona główna u mnie tez działa dobrze ale jak kliknę dowolny wpis lub link to wyskakuje błąd.
  odpowiedz
3. Jacek 9 lat temu:
  może łatwiej będzie jak podam adres strony: http://www.centrum-rozwoju.pl
  teraz jest wstawiony ten powyższy kod i strona ładuje się dobrze ale kliknięcie czegokolwiek skutkuje błędem.
  Po wpisaniu wp-login wyskakuje poprawnie okienko z hasłem więc samo wywoływanie i logowanie działa dobrze (ścieżki prawidłowe). Natomiast nie działają podstrony – tylko dlaczego? i jak to naprawić :)
  odpowiedz
4. Paweł 9 lat temu:
  Właściwie to wszystkie regułki autoryzacji powinny być tutaj wewnątrz bloku Files.
  odpowiedz
5. Jacek 9 lat temu:
  niestety to nie pomogło – problem leży gdzie indziej. Tylko gdzie? :)
  odpowiedz
6. Paweł 9 lat temu:
  No tak, po zerknięciu w podany link można odpowiedzieć – przyczyna problemów jest infekcja ( patrz np. https://sitecheck.sucuri.net/results/centrum-rozwoju.pl/ ).
  -po dokładnym oczyszczeniu z syfu i zabezpieczeniu powinno wszystko wrócic do normy.
  odpowiedz
7. Jacek 9 lat temu:
  masakra :) przeskanowałem antywirusem na dysku, coś znalazł, wykasował ale na stronie nadal widnieje. myślę jednak, ze to nie jest zasługa tego robaka. Mam zainstalowanych kilka wtyczek i tu kolega słusznie zauważył, że może się coś ze sobą gryzie. Oto lista:
  Antispam Bee
  iThemes Security
  Login LockDown
  Smart 404
  WP Limit Login Attempts
  SI CAPTCHA Anti-Spam
  Które zatem usunąć? Proszę pomóżcie :)
  odpowiedz
8. Paweł 9 lat temu:
  Antywirusem to sobie możesz….
  Tutaj opisałem w uproszczeniu metodę odsyfiania strony http://pl.forums.wordpress.org/topic/zlosliwe-oprogramowanie
  Co do wtyczek, to wywalił bym iThemes, Limit Login i Login LockDown.
  Zamiast tego podstawowe zabezpieczenia + autoryzacja w .htaccess i tyle.
  odpowiedz
9. Jacek 9 lat temu:
  sprawdziłem to rozwiązanie na innej stronie z wordpresem, bez wirusów i dzieje się to samo, czyli dostęp jest tylko do strony głównej a wszystkie podstrony wyświetlają się z błędem. Logowanie oczywiście jest poprawne i wszystko jest ja trzeba – poza tym, że podstrony nie działają.
  Podajcie mi proszę choć jedną stronę, na której to działa. Widzę, że sam autor nie stosuje tego rozwiązania więc zaczynam się zastanawiać czy to komukolwiek działa…
  odpowiedz
10. Szymon Skulimowski 9 lat temu:
  Jacek, wspomniałeś wcześniej, że korzystasz z dedykowanego serwera. Możliwe, że jego konfiguracje nieco odbiega od standardowych hostingów współdzielonych i stąd te problemy. W takim przypadku najlepiej skontaktować się obsługą techniczną i opisać jaki efekt chce się osiągnąć. Na pewno pomogą :)
  odpowiedz
11. Lukacjusz 8 lat temu:
  Dokładnie powinno być:
  AuthName „Restricted Area”
  AuthType Basic
  AuthUserFile xxxxxxxxxxxxtu podaje sciezkexxxxxxxxxxxxx
  require valid-user
  odpowiedz
Paweł 9 lat temu:
Sprawdziłem Twoje rozwiązanie. Pojawia się okno do logowania. Po wpisaniu danych w tym okienku dostaję komunikat „Ta strona internetowa zawiera pętlę przekierowań”. Podejrzewam, że po dopisaniu kodu na początku pliku .htaccess kod źle może współdziałać z pozostałym kodem, którego jest sporo od innych wtyczek jak np. na mojej stronie Wordfence. To może być ta przyczyna, czy to może być jeszcze coś innego? Jeśli to przez kod z wtyczki, to lepiej taką wtyczkę do bezpieczeństwa wyłączyć i zostawić tylko takie zabezpieczenie jak proponujesz, jak uważasz Szymonie?
odpowiedz
1. Szymon Skulimowski 9 lat temu:
  Tak, to może być wina już używanych wtyczek. Jeśli masz możliwość to możesz je chwilowo wyłączyć i wtedy przetestować rozwiązanie z artykułu. Ja sam nie za bardzo ufam takim „kombajnom”, zarówno jeśli chodzi o bezpieczeństwo jak i np. pozycjonowanie.
  odpowiedz
Mateusz 9 lat temu:
Dzięki za ten artykuł i wskazówki jak zabezpieczyć WP przed atakiem.
Ustawiłem u siebie zabezpieczenie katalogu wp-admin za pomocą .htaccess/htpasswd
ale na stronie głównej korzystam z pluginu zM Ajax Login i plugiu WP User fronted, a chciałbym by były one dostępne, muszę wykluczyć z tego zabezpieczenia katalogi odpowiedzialne za tą funkcjonalność?
Obecny kod pyta o hasło po próbie logowania i nie pozwala na autoryzację logowania (monit apache o dane zdefiniowane w htpasswd po podaniu danych logowania wp):
„AuthName „Restricted Area”
AuthType Basic
AuthUserFile /…/wp-admin/.htpasswd
AuthGroupFile /dev/null
require valid-user”
odpowiedz
1. Szymon Skulimowski 9 lat temu:
  na stronie głównej korzystam z pluginu zM Ajax Login i plugiu WP User fronted
  Czy mógłbyś podać odnośniki do wymienionych wtyczek?
  odpowiedz
J 9 lat temu:
Dzięki za świetny artykuł!
Niestety u mnie patent nie działa – przeglądarka wypluwa błąd przekierowań.
Próbowałem z wyłączeniem Wordfencea – nie pomogło.
Co z tym począć? (atakująąą!)
odpowiedz
1. Szymon Skulimowski 9 lat temu:
  Spróbuj dodać poniższą linijkę do pliku .htaccess:
  ErrorDocument 401 default
  odpowiedz
Jan 9 lat temu:
przydatny wpis, ja jak tylko zobaczyłem próby logowania po 2 hasła dziennie z jednego ip to momentalnie zablokowałem plik wp-login.php, potem umożliwiłem logowanie tylko i wyłącznie z określonych przeglądarek gdyż loguje się u mnie w panelu kilka osób z zmiennym ip ale przeglądarki mają stałe ;) zresztą łatwiej jest mi samemu kontrolować i zmieniać kto może się zalogować nawet jeżeli osoba zmieni przeglądarkę lub uaktualni to tylko to podmieniam a dodatkowo dodałem własną statystykę wszystkich wejść do pliku wp-login.php wtedy wiem kto próbował a jeżeli powtarza się często ip blokuję dostęp dla tego ip do całej strony aby przypadkiem coś się mu nie udało ;) , przy niewielkiej modyfikacji kodu źródłowego można zamienić nazwę pliku służącego do logowania z wp-login.php na np(stefan-abrakadabra.php) wówczas mało kto wpadnie na taki plik do logowania na naszej stronie, przydatne może być także nie informowanie lub raczej nie wyświetlanie komunikatu o błędach (403,404,503,500,….. ) po co komuś ułatwiać zdobywanie informacji o tym że przykładowo nasz serwer został przeciążony, dodatkowo można utworzyć kilka pułapek poprzez utworzenie kilku katalogów/plików o nazwach np(admin, pass, image, img, ….. ) w których skrypt zapisze dane odwiedzającego – dodać można także na stronie ukryte linki do plików które tak samo wyłapią pseudo odwiedzających. Polecam także używanie wymyślnych loginów oraz bardzo silnych haseł (cyfry, LiTeRy, znaki) min. 20 znakowe i nie powielanych do logowania w innych miejscach a zmienianych co jakiś czas w nieregularnych odstępach czasowych. A jeżeli sporadycznie korzystamy z bloga to np umożliwić logowanie tylko i wyłącznie w sobotę pomiędzy godziną 17.15 a 18.28. Sam przetestowałem kilkanaście jak nie więcej sposobów „zabezpieczenia się” a wybrałem kilka ;) i jak dla mnie stworzyłem zaawansowaną statystykę żeby wiedzieć co,gdzie,kiedy,… dzieję się na stronie, wolę zablokować jakieś ip 3 miesiące przed tym jak mi namiesza lub może namieszać na stronie niż 5 min po tym jak mi już namiesza.
odpowiedz
1. Szymon Skulimowski 9 lat temu:
  Dzięki za treściwy komentarz! Bezpieczeństwo jest ważne, ale nie możemy też przesadzać bo skończy się na tym, że zamiast robić coś związanego z celem istnienia strony/bloga (pozyskiwać nowych klientów, dzielić się swoją pasją itp.) spędzamy godziny na zakładaniu kolejnych kłódek (lub konserwacji już istniejących) :-)
  odpowiedz
Strona na WordPress – sprawdź czy nie została zaatakowana 9 lat temu:
[…] 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-… […]
odpowiedz
Michał 9 lat temu:
Cześć, Dałbyś radę stworzyć taki poradnik na joomle 3x?
pozdrawiam
odpowiedz
ziko 9 lat temu:
Używałem wtyczki Brute force Login protection, zmieniałem też nazwę wp-admin.php, nic nie pomogło.
Twoje rozwiązanie brzmi rozsądnie, zaaplikowałem je właśnie, czekam na efekty.
Dzięki.
odpowiedz
Grzegorz Szymański 9 lat temu:
Wartościowy i wyczerpujący wpis. Sporo się z niego dowiedziałem – dzięki. Przejrzałem wszystkie komentarze i nie rzuciła mi się w oczy wtyczka iThemes. Nikt z niej nie korzysta? Według mnie całkiem nieźle radzi sobie z zabezpieczeniem blog i atakami „brute force”. Tutaj możecie pobrać: https://pl.wordpress.org/plugins/better-wp-security/
odpowiedz
1. Paweł 9 lat temu:
  Wtyczka z gatunku zainstaluj-skonfiguruj-odinstaluj -to samo można osiągnąć i bez niej …w dodatku bezpieczniej.
  Tego rodzaju wtyczki dają złudne poczucie bezpieczeństwa – niby mają zabezpieczać, a same często wprowadzają dodatkowe luki. To jak byś się zabezpieczał przed złodziejem montując w drzwiach kilka zamków antywłamaniowych, a zostawiał otwarte okna. ;)
  https://wpvulndb.com/search?text=better+wp+security
  https://wpvulndb.com/search?text=ithemes+security
  …
  odpowiedz
moniajkaa 9 lat temu:
Witaj,
ze względu na zwiększone ataki na moją stronę próbowałam zastosować Twoje rozwiązanie na mojej stronie. Niestety po wpisaniu dodatkowego loginu i hasła pojawia się informacja Page Not Found. Nie mogę wejść na stronę wp-admin Jaka może być przyczyna?
odpowiedz
Lukasz 8 lat temu:
Witam, próbuje wprowadzić tę procedurę logowania i mam strasznie noobskie pytanie.
Pisząc utwórz plik .htpasswd, o jaki format pliku chodzi…
odpowiedz
1. Szymon Skulimowski 8 lat temu:
  Jeśli system operacyjny nie pozwala na stworzenie takiego pliku to nazwij go htpasswd.txt, wrzuć na serwer i dopiero tam zmień na .htpasswd (np. za pomocą klienta FTP).
  odpowiedz
2. Paweł 8 lat temu:
  Windows normalnie nie pozwala na zmianę nazwy np. na zaczynającą się od kropki, więc pozornie trudno stworzyć taki plik.
  Da się to jednak łatwo obejść z poziomu notatnika np. Notepad++ przez najzwyklejsze „Zapisz jako”. ;)
  Oczywiście można również tworzyć/zmieniać nazwę przez FTPa, przez shella, skryptowo z poziomu PHP.
  odpowiedz
Artur 8 lat temu:
Czy zabezpieczenie przez dodatkowe logowanie .htpasswd nadaje się do sklepu internetowego, gdzie klienci logują się, aby pobierać zakupione pliki?
odpowiedz
1. Paweł 8 lat temu:
  Nie specjalnie …znaczy spełnia dobrze swoją funkcję, ale klienci raczej nie lubią logować się 10 razy.
  odpowiedz
Kurs WordPress: Ochrona przed Spamem i hakerami – Jakub Jaworowicz WordPress & Marketing Specialist 8 lat temu:
[…] zapoznanie się z Wpisem Szymka o tutaj, ale dodam uwagi […]
odpowiedz
Rubaszny 8 lat temu:
Szymon – to pytanie już padało pare razy ale nie widzę sensownej jednoznacznej odpowiedzi jak to dobrze zrobić. Czy jest jakaś opcja zabezpieczenia przed atakami strony na której użytkownicy publikują content a więc potrzebują logowania? Oczywiście bez opcji aby musieli wpisywać hasła kilka razy. Z góry dziękuje za odpowiedź i pewnie jeszcze wielu czytelników.
odpowiedz
1. Anonim 8 lat temu:
  Poza typowymi zabezpieczeniami można zmienić adres logowania – można to zrobić np. wtyczkami: wp hide & security enhacer, shield wordpress security, hide my wordpress, wps hide login itp. Ważna, by użytkownikom nadawać możliwie niskie uprawnienia np. współpracownika lub autora. Zablokować xmlrpc jeśli nie jest wykorzystywane.
  odpowiedz
Joanna 8 lat temu:
Jak sprawdzić, czy po ataku strona nie jest zakażona? Jakimi narzędziami? Jakieś rady, podpowiedzi (może to jest temat na wpis?)?
Pozdrawiam
Joanna
odpowiedz
1. Paweł 8 lat temu:
  Jeżeli objawy są jawne, widoczne na zewnątrz, to złośliwy kod wyłapać mogą skanery pokroju: sitecheck.sucuri.net , quttera.com/scanwebsite itp.
  Jeżeli jest niejawna, to można próbować skanować wtyczkami pokroju: Quttera Web Malware Scanner, AntiVirus, CWIS etc.
  To taka wersja uproszczona, dla klikaczy.
  odpowiedz
2. Joanna 8 lat temu:
  Stronę przeskanowałam, dziękuję! Objawów jawnych nie ma w ogóle, poza jednym – nadal są dni, kiedy serwer ma obciążenie ponad miarę. Normalnie wykorzystuję około 10GB na miesiąc. W momencie ataku, w jednym dniu miałam 45GB i zawieszenie serwera. Panowie mi „dolali” jeszcze 10GB, ale widzę, że któregoś dnia znowu było obciążenie 1,4GB, co jest nieprawdopodobne (inna sprawa, że tego dnia firma hostująca miała awarię) i w ogóle niezgodne ze statystykami. Brakuje mi też statystyk z dnia ataku i wcześniej… Na razie zmieniłam wszystkie hasła, zrobiłam wszystkie aktualizacje, zabezpieczyłam przez .htpasswd i czekam na katastrofę, bo tam nadal jest coś nie tak. I kolejne, nawet niewielkie obciążenie, a mam zawieszoną stronę do końca miesiąca…
  odpowiedz
3. Paweł 8 lat temu:
  Warto sprawdzić w statystykach czy w logach, co dokładnie generuje ruch na stronie. Mogą to być złośliwe boty czy próby ataku brute-force, mogą być i zwykłe roboty indeksujące wyszukiwarek – które w pewnych sytuacjach potrafią szaleć po stronie. A może ktoś podkrada media hotlinkując. Trudno zgadywać.
  odpowiedz
Łukasz 8 lat temu:
A ja się zastanawiam, która metoda jest lepsza – hasło w htacsess tu opisane czy może deny na wp-login i symlink do niego. W zasadzie chyba można zastosować oba na raz?
odpowiedz
1. Paweł 8 lat temu:
  Lukasz, bez znaczenia …byle by działało poprawnie i nie generowało zbędnego obciążenia. Bywa, że ktoś sobie coś „zablokuje”, a potem boty kładą maszynę stukając w WordPressową stronę błędu etc. ;p
  A czy będziesz blokował przez basicAuth, po ciachu, po refererze, user agencie, IP, czy kombinując symlinkami, to już bez znaczenia. Byle by tylko intruz zaliczył bezwarunkowego killa jak najmniejszym kosztem.
  odpowiedz
2. Szymon Skulimowski 8 lat temu:
  Przeniosłem komentarze we właściwe miejsce :-)
  odpowiedz
Piter 8 lat temu:
Użyłem tej metody – jest świetna, ale PSUJE wpisy zabezpieczone hasłem. A mam na stronach np. galerie zdjęć dla innych przeglądających na hasło. Czy znacie jakiś sposób na obejście tego problemu?
odpowiedz
1. Paweł 8 lat temu:
  Tu przykładowe obejście https://pastebin.com/jwPFBDGh
  Można też kombinować od takiej strony http://iworks.pl/2013/09/25/atak-na-wp-login-rozwiazanie/ , można i próbować omijać warunkami z użyciem ENV https://httpd.apache.org/docs/2.4/mod/mod_setenvif.html
  odpowiedz
2. Piter 8 lat temu:
  Dzięki Paweł za wskazówki.
  Odnośnie metody symlinka do wp-login (faktycznie ładnie banuje wp-login), ale widzę jeden mankament – po wpisaniu w adresie na końcu /admin lub /login, nie dostaje bana tylko przenosi do symlinka, a więc bardzo łatwo odkryć jaki jest nowy link do wp-login. No chyba, że coś źle zrobiłem.
  odpowiedz
3. Paweł 8 lat temu:
  Odkryć i owszem, bo w temacie nie chodzi o tajność, co o zabezpieczenie przed brutalem przeradzającym się nieraz w DDoS ….czyli, ograniczeniem zużycia zasobów przy próbach nastukania tutaj w wp-login.php, a boty w 99% stukają w niego bezpośrednio – na ślepo.
  Możesz sobie np. regułką rewriterule zablokować /admin i /login, to już nie będzie tych przekierowań. Ale /wp-admin i tak przekieruje, albo w kodzie będzie można podglądnąć jak masz formularz logowania dodany albo chociaż w formie linka logowania.
  Jak zerkniesz na mój 1 i 2 komentarz od góry, to jest tam przykładowy, mało inwazyjny sposób oparty na ciastku. Nie potrzeba żadnych podmian adresów ani ukrywania wp-login.php przed światem ;)
  Oczywiście można kombinować na wiele innych sposobów, wszystko zależy od konkretnych potrzeb.
  odpowiedz
Tomek 7 lat temu:
Najgorsze jest to że takie ataki nie ustają, u mnie ostatnio próby wejścia skutecznie uniemożliwiły wejście mi samemu, nie wspominając o ładnym rachunku za serwer.. Twój wpis to lek na to całe zło, muszę bardziej dbać o zabezpieczenia :)
odpowiedz
Artur 7 lat temu:
Bardzo pomogłeś mi tym wpisem. Ciężko znaleźć coś konkretnego na ten temat w sieci. Jednak również jak kolega wyżej miałem problem z tymi wpisami zabezpieczonymi hasłem. Jednak fajnie, że dorzuciłeś w linku mały poradnik. Teraz wszystko śmiga jak powinno. Będę wpadać tutaj częściej. Prowadzę własnego bloga na WordPress’ie i czasami jednak takiej wiedzy mi brakuje.
odpowiedz
Paweł Mansfeld 6 lat temu:
Super artykuł, tyle czasu a nadal aktualny. Taki blog ma sens! Dzięki i pozdrawiam serdecznie.
odpowiedz
coach 6 lat temu:
dzięki za wartosciowe info :)
odpowiedz
irys 6 lat temu:
ja osobiście używam Ninja Firewall dla WP… niezawodny…
odpowiedz
Grzegorz 6 lat temu:
Sam ostatnio się borykałem z włamem na moje konto w Linuxpl i szukam wszystkiego, co zapewni mi bezpieczeństwo :). Do końca nie wiem, w jaki sposób atakujący zyskał dostęp, jednak kilka katalogów zostało zainfekowanych. Prawdopodobnie winowajcą był WordPress, chociaż nie wiem czy wykorzystano lukę lub metodę brute force. Wszystko przeskanowałem i usunąłem ręcznie, poinstalowałem Firewalle (Wordfence), zmieniłem hasła i mam nadzieję, że sytuacja się nie powtórzy.
odpowiedz
Michał 5 lat temu:
Czy nadal ataki typu brute force są popularne?
odpowiedz
1. Bitec 5 lat temu:
  miałem zamiar zadać dokładnie to samo pytanie, kiedyś sam miałem z tym duży problem, jednak od dawna mam zupełny spokój.
  odpowiedz
2. maciej 5 lat temu:
  Niestety nadal są popularne. Mam zainstalowaną wtyczkę wyłapującą tego typu ataki i jest ich bardzo dużo.
  odpowiedz
3. Michał 5 lat temu:
  To ciekawe, bo skuteczność takich ataków wydaje się nie być za duża.
  odpowiedz
4. Patec 5 lat temu:
  Tutaj wszystko się rozchodzi o ilość ;) Stron na WP jest mnóstwo!
  odpowiedz