Come posso fermare un attacco bot sul mio sito?

14

Ho un sito (costruito con wordpress) che è attualmente sotto un attacco bot (come meglio posso dire). Un file viene richiesto più e più volte e il referrer lo è (quasi sempre) turkyoutube.org/player/player.swf. Il file richiesto è contenuto nei miei file di temi ed è sempre seguito da " ?v=" e da una stringa lunga (ad es r.php?v=Wby02FlVyms&title=izlesen.tk_Wby02FlVyms&toke.).

Ho provato a impostare una regola .htaccess per quel referrer, che sembra funzionare, tranne per il fatto che ora la mia pagina 404 viene caricata più e più volte, che sta ancora usando molta larghezza di banda. C'è un modo per creare una regola .htaccess che non richiede l'utilizzo della larghezza di banda da parte mia?

Ho anche provato a creare un file robots.txt, ma l'attacco sembra ignorarlo.

#This is the relevant part of the .htaccess file:
RewriteCond %{HTTP_REFERER} turkyoutube\.org [NC]
RewriteRule .* - [F]

htaccess botattack

— Travis Northcutt
fonte

2

L'attacco proviene sempre dallo stesso IP?

— Ben Hoffman,

La tua .htaccessregola sta attivando intenzionalmente il file 404? Sembra che lanciare un semplice errore di autorizzazione negata sarebbe un minore utilizzo della larghezza di banda.

— artlung,

Questa è la parte rilevante del file .htaccess: RewriteCond% {HTTP_REFERER} turkyoutube \ .org [NC] RewriteRule. * - [F]

— Travis Northcutt

Tuttavia, anche se i miei registri di accesso mostrano "Codice Http: 404", sembra che il mio utilizzo della larghezza di banda si sia interrotto quando ho apportato la modifica .htaccess.

— Travis Northcutt,

Hai il .htaccesscodice che hai pubblicato prima o dopo le principali .htaccessregole di wordpress ?

— artlung,

8

Che ne dici di una piccola manovra di corbomite ?

RewriteEngine on
RewriteCond %{HTTP_REFERER} ^http(s)?://(www\.)?turkyoutube.org.*$ [NC]
RewriteRule ^(.*)$ http://127.0.0.1/$1 [R=401,L]

Nota, non testato , ma dovrebbe reindirizzare le richieste da loro a se stesse con un 401 Not Authorizedcodice di stato. Cioè, se il bot gestisce anche i reindirizzamenti (molto improbabile), ma vedrà comunque il codice di stato. Un codice di stato 404 potrebbe essere più efficace. O uno dovrebbe dire al bot che probabilmente dovrebbe rinunciare.

La regola che hai pubblicato nei commenti è anche più che adeguata se estendi l'espressione per abbinare un po 'di più l'host. Uso qualcosa di simile (per quanto riguarda la regola reale) per bloccare la corrispondenza degli user-agent libwww-perl:

RewriteCond %{HTTP_USER_AGENT} libwww-perl.*
RewriteRule .* - [F,L]

— Tim Post
fonte

Trovi che molti robot abbiano HTTP_USER_AGENT = libwww-perl? Questo sembra qualcosa su cui la maggior parte dei robot mentirebbe.

— Liam,

@Liam - sorprendentemente, una discreta percentuale di loro non tenta mai di mascherarsi come un vero browser (anche se sicuramente, più che altro). Ho pensato che fosse anche strano :)

— Tim Post

Nota che stai usando molta regex molto lenta qui. Il .*$equivale a nulla, che è molto più veloce. Anche il RewriteRule .* - [F,L], non è necessario per il *fatto che si ignora comunque la voce.

— Alexis Wilke,

2

A parte il blocco IP, analizzerei i file richiesti. È una cosa abbastanza comune per i sistemi open source come WordPress e Joomla da sfruttare, motivo per cui vengono frequentemente aggiornati. Se hai trascurato alcuni aggiornamenti, è possibile che qualcuno sia penetrato nel tuo sito.

Ho avuto quello scenario che mi è successo due volte, una volta su un sito di test che non è mai stato completamente implementato (ma è stato lasciato sul posto) e un'altra volta su un sito Web aziendale in cui un dipendente con accesso valido ha "nascosto" un phpBB per la sua famiglia comunicare - gli aggiornamenti avrebbero impedito i problemi. In entrambi i casi, il problema è stato riscontrato con l'analisi in quanto potrebbe essere vero nel tuo caso. L'attacco di Joomla ha iniettato javascript che ha causato il caricamento del software nel browser dell'utente, mentre quest'ultimo ha permesso all'hacker di caricare file sul server che facevano parte di un sito google "alternativo" distribuito che portava l'utente a p * rn ogni volta. Sebbene non sia del tutto un hack comune, controlla la tabella degli utenti DB, per ogni evenienza.

Sicuramente non intendo causare allarme, ma non fa mai male dedicare del tempo a scavare nel tuo sito ogni tanto per sapere esattamente cosa sta succedendo. A volte rimarrai sorpreso da ciò che trovi.

— bpeterson76
fonte

Penso che questo sia esattamente ciò che sta accadendo, in realtà. Sembra che il file richiesto non dovrebbe nemmeno essere lì. Per fortuna, un collaboratore amichevole di wordpress mi ha contattato, quindi sento che lo capiremo.

— Travis Northcutt,

1

Se l'attacco proviene ogni volta dallo stesso numero IP (o da una piccola serie di numeri IP), dovresti bloccare quel numero IP nel tuo firewall. Ciò non dovrebbe costare alcuna larghezza di banda o carico sul tuo server web.

Se lo stai ospitando su un computer Linux con accesso root a questo articolo, spiega come farlo.

— Kris
fonte

Non proviene sempre dallo stesso IP.

— Travis Northcutt,

0

Uso DenyHosts [1] su tutti i miei server. DenyHosts non consente tutti gli IP a cui non è stato possibile accedere dopo n volte. Puoi anche inviare notifiche. Quindi hai una grande panoramica da cui provengono ips / host gli accessi; e ha anche una funzione di aggiornamento web e altre fantastiche funzionalità. Ma è ancora molto semplice da installare.

Un altro metodo consiste nell'impedire tutti gli intervalli / blocchi IP (ad esempio) dalla Cina o da altri paesi che non fanno parte del gruppo target. Questo può essere fatto con "Blacklist" online o semplicemente con il file hosts.deny (come DenyHosts).

[1] http://denyhosts.sourceforge.net/

— fwaechter
fonte

-1

Basta semplicemente reindirizzare 301 al sito fbi.

RewriteEngine su RewriteCond% {HTTP_REFERER} ^ http (s)?: // (www.)? Turkyoutube.org. $ [NC] RewriteRule ^ (. ) $ Http://www.fbi.gov [R = 301, L]

— Bizzle caldo
fonte