Obrona przed atakiem wywołuje pętlę przekierowań

Próbuję zablokować dostęp do wp-login.php ponieważ wtyczka Hide login, która w zasadzie wywoływała błąd 404 pod tym adresem z jakiegoś powodu nie pomogła. Boty nadal atakują mi wp-login.php Zużywają trasnfer i przeciążają serwer.

Zablokowałem przez deny from all w htacces, ale działa tak samo jak usunięcie lub zmiana nazwy pliku wp-login.php Mianowcie powstaje pętla przekierowań. Chyba jakieś reguły dodawane z w .htaccess lub inne przekierowania powodują ten problem.

Powodują taką pętle i zamiast 403 albo 404 wywołuje mi 302.

Czy możecie zerknąć mi do tego .httacces

<Files xmlrpc.php>
order deny,allow
deny from all
</Files>
<FilesMatch "wp-login.php">
Order Deny,Allow
deny from all
allow from XX.XXX.XXX.XXX
</FilesMatch>


RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://www.%1%{REQUEST_URI} [L,NE,R=301]


Deny From 46.251.227.60
Deny From 62.87.249.67
Deny From 83.20.99.59
Deny From 83.241.11.192
Deny From 87.118.108.40
Deny From 87.118.114.82
Deny From 87.118.112.32
Deny From 87.118.118.133
Deny From 88.190.37.223
Deny From 91.201.66.84
Deny From 91.201.66.4
Deny From 91.201.66.90
Deny From 91.207.6.90
Deny From 91.224.160.6
Deny From 91.224.160.33
Deny From 91.226.32.72
Deny From 92.241.169.70
Deny From 92.241.169.78
Deny From 94.102.63.15
Deny From 94.229.65.176
Deny From 94.142.128.59
Deny From 96.47.225.
Deny From 96.47.224.
Deny From 109.230.216.20
Deny From 109.230.245.232
Deny From 173.44.37.
Deny From 188.92.75.229
Deny From 188.143.232.14
Deny From 192.76.82.75
Deny From 194.8.74.171
Deny From 194.8.74.220
Deny From 194.8.75.42
Deny From 194.8.75.54
Deny From 194.8.75.145
Deny From 194.8.75.151
Deny From 194.8.75.159
Deny From 194.8.75.161
Deny From 194.8.75.163
Deny From 194.165.42.49
Deny From 195.238.188.164
Deny From 199.15.233.
Deny From 199.15.234.
Allow From .ahrefs.com
Allow From .httpstatus.io
Allow From 167.99.129.42
SetEnvIfNoCase User-Agent .*Updownerbot.* bad_bot
SetEnvIfNoCase User-Agent .*spbot.* bad_bot
SetEnvIfNoCase User-Agent .*findlinks.* bad_bot
SetEnvIfNoCase User-Agent .*Twiceler.* bad_bot
SetEnvIfNoCase User-Agent .*Moreoverbot.* bad_bot
SetEnvIfNoCase User-Agent .*Nutch.* bad_bot
SetEnvIfNoCase User-Agent .*VoilaBot BETA 1.2.* bad_bot
SetEnvIfNoCase User-Agent .*libwww-perl/5.805.* bad_bot
SetEnvIfNoCase User-Agent .*Sogou web spider/3.0.* bad_bot
SetEnvIfNoCase User-Agent .*TurnitinBot.* bad_bot
SetEnvIfNoCase User-Agent .*psbot.* bad_bot
SetEnvIfNoCase User-Agent .*Ezooms.* bad_bot
SetEnvIfNoCase User-Agent .*Speedy Spider.* bad_bot
SetEnvIfNoCase User-Agent .*Exabot.* bad_bot
SetEnvIfNoCase User-Agent .*Charlotte/1.0b.* bad_bot
SetEnvIfNoCase User-Agent .*boitho.com-dc.* bad_bot
SetEnvIfNoCase User-Agent .*ajSitemap.* bad_bot
SetEnvIfNoCase User-Agent .*bot/1.0.* bad_bot
SetEnvIfNoCase User-Agent .*WebDataCentreBot/1.0.* bad_bot
SetEnvIfNoCase User-Agent .*Java.* bad_bot
SetEnvIfNoCase User-Agent .*SapphireWebCrawler.* bad_bot
SetEnvIfNoCase User-Agent .*Yandex.* bad_bot
SetEnvIfNoCase User-Agent .*Baiduspider.* bad_bot
SetEnvIfNoCase User-Agent .*Rankivabot.* bad_bot
SetEnvIfNoCase User-Agent .*DBLBot/1.0.* bad_bot
order allow,deny
deny from env=bad_bot
allow from all 





order allow,deny
deny from env=bad_bot
allow from all 

# BEGIN WordPress
# Dyrektywy zawarte między "BEGIN WordPress" oraz "END WordPress"
# są generowane dynamicznie i powinny być modyfikowane tylko za pomocą
# filtrów WordPressa. Zmiany dokonane bezpośrednio tutaj będą nadpisywane.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType text/html "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 1 month"
</IfModule>

Jedyne co możesz zrobić to wyciąć te adresy na FW albo pozbyć się WP

Na WP nie siedzę, ale tak myślę - nie da się zmienić adresu panelu?
OK, piszesz że zmiana nazwy nie pomaga i powstaje pętla przekierowań. Ale tak się zastanawiam - jakby prawdziwy panel dać pod innym adresem, a pod tym domyślnym postawić atrapę - wygląda jak normalny formularz do logowania, ale wciśnięcie Submit nic nie robi. Niech sobie boty klikają do skutku :D

Albo np. zrobić takie chamskie przekierowanie - jak wejdzie na wp-login.php to dać kod 301 i przerzucić na PornHub ;)

@cerrato To nic nie da, bo boty już widzą że to wp i będą próbować i nie ma znaczenia że strony nie ma bo i tak transfer ciągną

@hzmzp a zrobienie 301 gdzieś w świat? Transferu jakoś dużo to nie zużyje, nie popadajmy w paranoję. Co o tym sądzisz?

Jak już to 301 na główną stronę. Do tego przeniesienie loginu na inny URL + ograniczenie w .htaccess na ten URL dla konkretnego IP a najlepiej jeszcze jakiś HTTP auth login na ten URL.
WordPress już jest stary jak świat a z tym loginem jak był problem tak jest.

jurek1980 napisał(a):

Jak już to 301 na główną stronę. Do tego przeniesienie loginu na inny URL + ograniczenie w .htaccess na ten URL dla konkretnego IP a najlepiej jeszcze jakiś HTTP auth login na ten URL.
WordPress już jest stary jak świat a z tym loginem jak był problem tak jest.

No ale to i tak będą wchodzić i przechodzić na główną, skoro nie pomaga 404. Transfer schodzi i do tego zużycie zasobów codziennie przychodzi e-mail.

Może warto jakieś zakresy IP zablokować zagraniczne, ale nie wiem jak.

Co to masz? VPS, hosting?

hzmzp napisał(a):

Co to masz? VPS, hosting?

Hosting, nie wiem czemu wszystkie Wordpressy robią mi pętlę przekierowań jak się zablokokuje lub usunie wp-login.php To od którejś tam wersji chyba mi się zaczęło tak robić. To normalne, czy coś mi zmienia jakiś zapis w htaccess lbu wtyczka?

Popraw reguły dla wp-login.php

Obecna reguła:

<FilesMatch "wp-login.php">
Order Deny,Allow
deny from all
allow from XX.XXX.XXX.XXX
</FilesMatch>

Może powodować problem, jeśli WordPress lub jakaś wtyczka próbuje się dostać do wp-login.php w inny sposób (np. AJAX). Spróbuj zmienić na:

<FilesMatch "wp-login.php">
Require all denied
Require ip XX.XXX.XXX.XXX
</FilesMatch>

Jest to nowsza metoda (w Apache 2.4) i lepiej współpracuje z innymi regułami.
Uniknij konfliktu z WordPressowym RewriteRule

Obecnie masz reguły WordPressa:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Jeśli wp-login.php zostanie zablokowany/usunięty, to te reguły mogą nadal próbować go wywołać, prowadząc do pętli. Możesz dodać wyjątek:

RewriteCond %{REQUEST_URI} !^/wp-login.php$ [NC]

Tak więc pełna wersja będzie wyglądać tak:

RewriteCond %{REQUEST_URI} !^/wp-login.php$ [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Sprawdź przekierowanie HTTPS

Twoja obecna reguła:

RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://www.%1%{REQUEST_URI} [L,NE,R=301]

Jeśli np. wp-login.php jest przekierowywany do HTTPS, a jednocześnie blokowany, to może powodować pętlę. Zamiast tego przetestuj:

RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} !^/wp-login.php$ [NC]
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,NE,R=301]

To wykluczy wp-login.php z przekierowań do HTTPS.

Niektóre wtyczki (np. do zabezpieczeń) mogą nadpisywać reguły .htaccess. Warto wyłączyć je na chwilę i zobaczyć, czy problem ustąpi.

Spróbuj wprowadzić te zmiany i daj znać, czy pomogło!

Jutro spróbuję wgrać te poprawki, bo już mi zablokowali konto. Mam wrażenie, że intensywność przybiera na sile.

Ok, odblokowali. Już wiem co powoduje pętlę

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/wp-login.php$ [NC]
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Niestety dodanie wyjątku nie pomaga, a to jest dodawana reguła wpis z Wordpressa z modrewrite, bez tego podstrony nie będą się otwierać. Please Help.

Ten zapis

RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} !^/wp-login.php$ [NC]
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,NE,R=301]

wywołuje mi też przekierowanie z http://domena/wp-login.php na https://www.www.domena/wp-login.php

Z kolei ten mój niby działa, ale przy innych wersjach z adresu www i bez www przekirowouje mi przy blokadzie na

https://www.domena.pl/403.shtml a to już nie jest 403 tylko 404

Dlaczego nie użyjesz Cloudflare jako reverse proxy po prostu?

Nie umiem właśnie próbuję czytać jak to zrobić. Założyłem konto i podają mi dns do zmiany, ale co ja muszę na serwerze ustawić. Ja mam hosting współdzielony.

Musisz, z tego co pamiętam, zmienić nameserver na te które Cloudlfare podaje na strone na ktorej masz zarejestrowany domain.

Spróbuję.

"Moje" boty się przedstawiają Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36
A ip co sekundę inne. To raczej po tym nie zablokuję?

On ma jakieś swoje tam algorytmy do detectowania botów, szczerze nie znam się za bardzo.

Rozwaiłem sobie certyfikat, to w Tym Cloudflair sie ustawia nowy i trzeba usunąć stary na serwerze Let's Encrypt, czy jak?

Kod błędu: SSL_ERROR_NO_CYPHER_OVERLAP

W ustawieniach SSL/TLS w Cloudflare musisz ustawić opcję 'full'.

Wygenerowałem nowy certyfikat Let's Encrypt na moim hosingu i zmieniłem z Flexible na full

Na razie nie działa, ale może potrzebuje trochę więcej czasu.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Nieobsługiwany protokół
Klient i serwer nie obsługują wspólnej wersji protokołu SSL lub mechanizmu szyfrowania.

na zwykły 'Full' nie 'Full (Strict)', jakby co.

Tak zmieniłem. Na zwykły Full

a co mam wybrać w Direct Admin na swoim hostingu?

• Wklej wstępnie wygenerowany certyfikat i klucz

• Utwórz żądanie certyfikatu

• Użyj najlepszego certyfikatu zgodności

• Utwórz własny samopodpisany certyfikat

Mam zaznaczone na wklej wstępnie wygenerowany certyfikat i klucz.

Zostaw to, co było przed tym.

no po wygenerowaniu zrobiło się to: Wklej wstępnie wygenerowany certyfikat i klucz i tka zostawiłem

W Clodflair mam Full

Na razie nie działa

Nie wiem, jak to wygląda po stronie twojego hostingu. Masz nginx, apache? Może warto zrestartować serwer.

Apach chyba. Ok już działa certyfikat.

Zostaje mi rozgryzienie pętli przekierowań i wywołanie 403.

Jak usunę cały wpis z mod_rewrite czyli

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/wp-login.php$ [NC]
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

To pętla znika. Nie działają podstrony, ale wp-login.php wywala w końcu 403, tylko co mnie szczególnie dziwi w przeglądarce daje mi 403, a w logach serwera dalej leci 404 i transfer zjada.

RewriteCond %{REQUEST_URI} !^/wp-login.php$ [NC]

niestety też nie pomaga

Z kolei przekierowania https i powodują otwieranie strony domena.pl/403.shtml swoje storn błędu, a to jest też 404.

jakieś 20 lat temu po ciągłych irytacjach miałem plan napisać debugger do mod_rewrite ale nie myślałem że tak długo to pożyje, zamiast tego zmieniłem technologie.
Jestem zdziwiony że nadal taki nie istnieje, natomiast z tego co widzę możesz włączyć logowanie

LogLevel alert rewrite:trace6

https://httpd.apache.org/docs/2.4/mod/mod_rewrite.html#logging

Polecam też użycie mod_rewrite do przekierowania całego ruchu do jednego skryptu php i sterowanie ruchem za jego pomocą (co jest pewnie minimalnie bardziej obciążające dla serwera ale za to mamy pełną kontrolę)

Co to znaczy włączyć logowanie??? Czego w jakim celu?

LogLevel alert rewrite:trace6

niestety to raczej przerasta moje możliwości, żeby coś takiego napisać.Ja się kilka dni męczyłem, żeby zrobić poprawnie przekierowania na www i https bazując na regułkach, które znalazłem w internecie. Większość nie działała poprawnie pomijając jakąś wersję albo robiąc jakieś łańcuchy przekierowań.

403 udaje mi się wywołać jedynie blokując wszystko

Order Deny,Allow
Deny from all