¿Cómo puedo detener un ataque de bot en mi sitio?

14

Tengo un sitio (construido con WordPress) que está actualmente bajo un ataque de bot (lo mejor que puedo decir). Se solicita un archivo una y otra vez, y el referente lo es (casi siempre) turkyoutube.org/player/player.swf. El archivo que se solicita está dentro de mis archivos de tema y siempre va seguido de " ?v=" y una cadena larga (es decir r.php?v=Wby02FlVyms&title=izlesen.tk_Wby02FlVyms&toke).

Intenté establecer una regla .htaccess para ese referente, que parece funcionar, excepto que ahora mi página 404 se está cargando una y otra vez, que todavía usa mucho ancho de banda. ¿Hay alguna manera de crear una regla .htaccess que no requiera el uso de ancho de banda por mi parte?

También intenté crear un archivo robots.txt, pero el ataque parece estar ignorando eso.

#This is the relevant part of the .htaccess file:
RewriteCond %{HTTP_REFERER} turkyoutube\.org [NC]
RewriteRule .* - [F]
Travis Northcutt
fuente
2
¿El ataque proviene de la misma IP cada vez?
Ben Hoffman
¿Su .htaccessregla está activando intencionalmente el archivo 404? Parece que arrojar un error simple de permiso denegado sería menos uso de ancho de banda.
artlung
Esta es la parte relevante del archivo .htaccess: RewriteCond% {HTTP_REFERER} turkyoutube \ .org [NC] RewriteRule. * - [F]
Travis Northcutt
Sin embargo, aunque mis registros de acceso muestran "Código HTTP: 404", parece que mi uso de ancho de banda se detuvo cuando hice ese cambio de .htaccess.
Travis Northcutt
¿Tiene el .htaccesscódigo que publicó antes o después de las principales .htaccessreglas de WordPress ?
artlung

Respuestas:

8

¿Qué tal una pequeña maniobra de corbomita ?

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

Tenga en cuenta que no se ha probado pero debe redirigir las solicitudes de ellos a sí mismos con un 401 Not Authorizedcódigo de estado. Es decir, si el bot incluso maneja redirecciones (muy poco probable), pero aún verá el código de estado. Un código de estado 404 puede ser más efectivo. Cualquiera de los dos debería decirle al bot que probablemente debería rendirse.

La regla que publicaste en los comentarios también es más que adecuada si amplías la expresión para que coincida con el host un poco más. Utilizo algo cercano (en cuanto a la regla real) para bloquear la coincidencia de agentes de usuario libwww-perl:

RewriteCond %{HTTP_USER_AGENT} libwww-perl.*
RewriteRule .* - [F,L]
Tim Post
fuente
¿Le parece que muchos bots tienen HTTP_USER_AGENT = libwww-perl? Esto parece algo sobre lo que la mayoría de los bots mentirían.
Liam
@Liam: sorprendentemente, un porcentaje decente de ellos nunca intenta disfrazarse de un navegador real (aunque seguramente, más lo hacen). Pensé que también era extraño :)
Tim Post
Tenga en cuenta que está usando mucha expresión regular muy lenta aquí. El .*$es equivalente a nada, que es mucho más rápido. Además RewriteRule .* - [F,L], no es necesario *porque ignora la entrada de todos modos.
Alexis Wilke
2

Además del bloqueo de IP, examinaría los archivos que se solicitan. Es algo bastante común que se exploten los sistemas de código abierto como WordPress y Joomla, que es una de las razones por las que se actualizan con frecuencia. Si ha descuidado algunas actualizaciones, es posible que alguien haya penetrado en su sitio.

Me ha sucedido ese escenario dos veces, una vez en un sitio de prueba que nunca se implementó por completo (pero se dejó en su lugar) y otra vez en un sitio web de la compañía donde un empleado con acceso válido "coló" un phpBB para su familia para comunicarse: las actualizaciones habrían evitado los problemas. En ambos casos, el problema se encontró con la analítica, ya que parece ser cierto en su caso. El ataque de Joomla inyectó JavaScript que provocó que el navegador del usuario cargara software, mientras que este último permitió que el hacker cargara archivos al servidor que formaban parte de un sitio de Google "alternativo" distribuido que llevó al usuario a p * rn cada vez. Aunque no es del todo un truco común, consulte la tabla de usuarios de la base de datos, por si acaso.

Ciertamente no pretendo causar alarma, pero nunca está de más tomarse el tiempo de explorar su sitio de vez en cuando para saber exactamente lo que está sucediendo. A veces te sorprenderá lo que encuentres.

bpeterson76
fuente
Creo que esto es exactamente lo que está sucediendo, en realidad. Parece que el archivo que se solicita no debería estar allí. Afortunadamente, un colaborador amigable de WordPress se contactó conmigo, así que siento que lo resolveremos.
Travis Northcutt
1

Si el ataque proviene del mismo número de IP cada vez (o un pequeño conjunto de números de IP), debe bloquear ese número de IP en su firewall. Eso no debería costar ningún ancho de banda o carga en su servidor web.

Si lo está alojando en una máquina Linux que tiene acceso raíz a este artículo, explica cómo hacerlo.

Kris
fuente
No viene de la misma IP cada vez.
Travis Northcutt
0

Uso DenyHosts [1] en todos mis servidores. DenyHosts no permite todas las IP que no pudieron iniciar sesión después de n veces. También puedes enviar notificaciones. Por lo tanto, tiene una excelente descripción general de qué ips / hosts provienen los inicios de sesión; y también tiene una función de actualización web y otras excelentes características. Pero todavía es muy simple de instalar.

Otro método es no permitir todos los rangos / bloques de IP (por ejemplo) de China u otros países que no sean su grupo objetivo. Esto se puede hacer con las "listas negras" en línea o simplemente con el archivo hosts.deny (como DenyHosts).

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

fwaechter
fuente
-1

Simplemente haga el redireccionamiento 301 al sitio fbi.

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

Hot Bizzle
fuente