Tácticas para lidiar con robots que se portan mal

Tengo un sitio que, por razones regulatorias, no puede indexarse o buscarse automáticamente. Esto significa que debemos mantener alejados a todos los robots y evitar que recorran el sitio.

Obviamente hemos tenido un archivo robots.txt que no permite nada desde el principio. Sin embargo, observar el archivo robots.txt es algo que solo los robots con buen comportamiento hacen. Recientemente hemos tenido algunos problemas con robots que no se comportan bien. He configurado Apache para prohibir algunos agentes de usuario, pero es bastante fácil evitarlo .

Entonces, la pregunta es, ¿hay alguna forma de configurar Apache (tal vez instalando algún módulo?) Para detectar un comportamiento similar al robot y responder? ¿Alguna otra idea?

Por el momento, todo lo que puedo hacer es prohibir las direcciones IP basadas en la inspección manual de los registros y eso simplemente no es una estrategia viable a largo plazo.

apache web-crawlers user-agent

— Kris
fuente

Dado que está preguntando sobre los módulos de Apache (consulte mod_evasive) y su solución puede terminar involucrando algunas reglas personalizadas de análisis de registros e iptables, este tema puede ser un mejor candidato para ServerFault.com si tiene preguntas sobre el bloqueo de comportamientos de bot específicos.

— danlefree

Respuestas:

Puede vincular a una página oculta que, cuando se visita, captura el agente de uso y la dirección IP del bot y luego agrega uno o ambos a un archivo .htaccess que los bloquea permanentemente. Está automatizado para que no tenga que hacer nada para mantenerlo.

— John Conde
fuente

Esa es una idea muy interesante, aunque en caso de que estén utilizando un agente de usuario muy genérico, no desearía bloquear automáticamente ningún agente de usuario.

— Kris

Me quedaría con las direcciones IP entonces. Además, si usa direcciones I y ve un patrón de un bloque de IP, puede bloquearlas fácilmente con una regla simple en lugar de mantener una larga lista de IP individuales.

— John Conde

Usted puede utilizar el método descrito a parar casualmente malos los robots de rastreo de su sitio. Pero 1) es posible evitar (los robots malos, y sus amos, pueden aprender a identificar honeypots y saber cómo evitarlos); y 2) Este método también puede bloquear usuarios humanos legítimos que han sido reasignados IP que han sido incluidos en la lista negra como pertenecientes a robots que se portan mal. Si tiene la obligación legal o reglamentaria de no indexar o sellar automáticamente su sitio, debe usar la autenticación adecuada y solo dar acceso a los usuarios autenticados. Todo lo demás no es seguro.

— Radical libre el

Buena idea. Pero, si lo implementara, apuesto a que seguiría golpeando accidentalmente el honeypot y seguiría siendo bloqueado desde mi propio sitio.

— JW01

@ JW01 Todo lo que tiene que hacer para evitar eso es no visitar la página que maneja esto. Dado que no hay contenido en él, debería ser fácil de hacer.

— John Conde

Puede aprovechar el trabajo que otras personas han realizado para identificar las IP incorrectas utilizando un módulo Apache que interactúa con la lista negra de IP de Project Honeypot . Si está haciendo esto a gran escala, probablemente sería cortés ofrecerle un honeypot.

— Peter Taylor
fuente

Me sorprendió cuando agregué la lista negra de IP de Project Honeypot en mi sitio. Años de angustia terminaron simplemente bloqueando a los malos. Creo que también puedes detectar los robots de los motores de búsqueda. Entonces, más 1 para eso.

— JW01

Pero el quid de la cuestión es: si tiene páginas públicas, espere que se indexen. Por lo tanto, se necesita algún tipo de autenticación. Ver la respuesta de Michael Hampton .

— JW01

Como Gisle Hannemyr mencionó en un comentario , la mejor manera de hacerlo es solicitar el inicio de sesión de todos los usuarios y no proporcionar el contenido restringido a nadie que no haya iniciado sesión.

Si no puede solicitar inicios de sesión por alguna razón, todavía puede usar un par de retrocesos (descargo de responsabilidad: ambos son culpa mía o parcial):

El OWASP ModSecurity Core Rule Set contiene una serie de reglas diseñadas para detectar la automatización, incluso cuando el bot ha tomado medidas para disfrazarse como un navegador (por ejemplo, falsificando su cadena de User-Agent). Si tiene el control total de su servidor, como un VPS, un servidor dedicado o algo más grande que eso, puede usar estas reglas con ModSecurity .

Este conjunto de reglas también contiene otras reglas destinadas a detener una amplia variedad de actividades inapropiadas; si no lo has mirado, definitivamente deberías.
Si no tiene el control total de su servidor (es decir, está en un alojamiento web compartido) y su host no le permite usar sus propias reglas de ModSecurity, puede probar algo a nivel de aplicación, como mi propio Bad comportamiento . Comencé este proyecto en 2005 para combatir el spam de blogs y los raspadores de contenido, como los que le preocupan. Se puede agregar a cualquier sitio web basado en PHP.

También debo tener en cuenta que muchas de las reglas de mal comportamiento se han incorporado al conjunto de reglas de ModSecurity Core, por lo que siempre que haya habilitado esas reglas, ejecutar ambas sería bastante redundante. Estas reglas se anotan en el conjunto de reglas principales como originadas en el mal comportamiento.

— Michael Hampton
fuente