¿Cómo puedo bloquear los bots que golpean constantemente las mismas URL?

4

Los bots me están golpeando con fuerza y no estoy seguro de cómo detenerlos sin bloquear mi tráfico legítimo. Creé algunas reglas iptables que dicen, si X conexiones en X segundos, bloquean, pero eso no me sirve de mucho cuando el robot solo hace 2 o 3 solicitudes cada 30 segundos.

Idealmente, me gustaría identificar estos bots por las direcciones URL y cuántas veces están llegando a esa URL, estoy seguro de que puedo hacer esto con algún código, pero me preguntaba si alguien por ahí ya tiene una solución que no lo hace. No implique código, y preferiblemente bloques a través de iptables .

Cualquier idea, pensamiento, sugerencia es muy apreciada.

Aquí está la salida de mi registro de acceso:

27.153.233.93 - - [02/Nov/2013:10:44:54 +0000] "GET /register/ HTTP/1.1" 200 8296
192.99.2.188 - - [02/Nov/2013:10:44:54 +0000] "GET /register/ HTTP/1.1" 200 8296
110.86.164.186 - - [02/Nov/2013:10:44:54 +0000] "GET /register/ HTTP/1.1" 200 8296
121.205.239.188 - - [02/Nov/2013:10:44:54 +0000] "POST /register/ HTTP/1.1" 44 339
27.153.233.93 - - [02/Nov/2013:10:44:54 +0000] "POST /register/ HTTP/1.1" 44 339
36.251.24.146 - - [02/Nov/2013:10:44:54 +0000] "GET /wp-login.php HTTP/1.1" 200 1655
110.86.164.186 - - [02/Nov/2013:10:44:55 +0000] "POST /register/ HTTP/1.1" 44 339
192.99.2.188 - - [02/Nov/2013:10:44:54 +0000] "POST /register/ HTTP/1.1" 302 20
110.85.107.18 - - [02/Nov/2013:10:44:56 +0000] "GET /register/ HTTP/1.1" 200 8296
110.86.187.169 - - [02/Nov/2013:10:44:56 +0000] "GET /register/ HTTP/1.1" 200 8296
125.117.214.174 - - [02/Nov/2013:10:44:55 +0000] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 1166
110.85.107.18 - - [02/Nov/2013:10:44:56 +0000] "POST /register/ HTTP/1.1" 44 339
110.86.187.169 - - [02/Nov/2013:10:44:56 +0000] "POST /register/ HTTP/1.1" 44 339
192.99.2.188 - - [02/Nov/2013:10:44:55 +0000] "GET / HTTP/1.1" 200 10718
110.89.13.58 - - [02/Nov/2013:10:44:57 +0000] "GET /register/ HTTP/1.1" 200 8296
36.251.24.146 - - [02/Nov/2013:10:44:57 +0000] "POST /wp-login.php HTTP/1.1" 302 20
110.89.13.58 - - [02/Nov/2013:10:44:57 +0000] "POST /register/ HTTP/1.1" 44 339
218.86.50.83 - - [02/Nov/2013:10:44:58 +0000] "GET /register/ HTTP/1.1" 200 8296
218.86.50.83 - - [02/Nov/2013:10:44:58 +0000] "POST /register/ HTTP/1.1" 44 339
117.26.195.51 - - [02/Nov/2013:10:44:58 +0000] "GET /register/ HTTP/1.1" 200 8296
120.43.20.103 - - [02/Nov/2013:10:44:58 +0000] "GET /register/ HTTP/1.1" 200 8296
121.205.196.193 - - [02/Nov/2013:10:44:58 +0000] "GET /register/ HTTP/1.1" 200 8296
117.26.195.51 - - [02/Nov/2013:10:44:58 +0000] "POST /register/ HTTP/1.1" 44 339
120.43.20.103 - - [02/Nov/2013:10:44:58 +0000] "POST /register/ HTTP/1.1" 44 339
120.37.207.234 - - [02/Nov/2013:10:44:59 +0000] "GET /register/ HTTP/1.1" 200 8296
27.153.210.2 - - [02/Nov/2013:10:44:59 +0000] "GET /register/ HTTP/1.1" 200 8296
121.205.196.193 - - [02/Nov/2013:10:44:59 +0000] "POST /register/ HTTP/1.1" 44 339
120.37.207.234 - - [02/Nov/2013:10:44:59 +0000] "POST /register/ HTTP/1.1" 44 339
120.37.206.69 - - [02/Nov/2013:10:44:59 +0000] "GET /register/ HTTP/1.1" 200 8296
120.37.206.69 - - [02/Nov/2013:10:44:59 +0000] "POST /register/ HTTP/1.1" 44 339
27.159.234.10 - - [02/Nov/2013:10:44:59 +0000] "GET /register/ HTTP/1.1" 200 8296
27.159.234.10 - - [02/Nov/2013:10:45:00 +0000] "POST /register/ HTTP/1.1" 44 339
    
pregunta Jeffrey L. Roberts 02.11.2013 - 11:51
fuente

5 respuestas

7

Parece que Fail2ban se ajusta perfectamente a su escenario. Es bastante configurable, por lo que debería poder configurar lo que necesita consultando un poco la documentación.

    
respondido por el Ayrx 02.11.2013 - 13:43
fuente
4

No tiene mucha información en ese registro, por lo que debe asumir algo (o usar alguna herramienta que lo haga por usted).

Por ejemplo, diga que la mayoría de sus clientes están en EE. UU. / EMEA. Entonces quizás todas las direcciones IP provenientes de China pueden ser bloqueadas. Puede obtenerlos con WHOIS en los registros o probar los servicios en línea:

  • Parece que IPDeny no tiene datos: enlace
  • NirSoft tiene algo, pero no está demasiado actualizado ( enlace )
  • enlace también tiene compatibilidad con el formato .htaccess

Manualmente (con la ventaja de solo bloquear subredes realmente "culpables"):

$ whois 218.86.50.83 | grep "country\|inetnum" | sort | uniq
country:        CN
inetnum:        218.85.0.0 - 218.86.127.255
# iptables-deny 218.85.0.0/15

$ # Repeat for all "suspicious" IPs in your access.log

Para averiguar quién te está golpeando, puedes hacer una estadística en access.log y los primeros bits de la IP entrante, agrupándolos por hora:

$ grep "GET /register/" /path/to/access.log| cut -f 1,4 -d " " | cut -f1-2 -d: | sed -e 's/\(.*\)\.[0-9]* .*:\(.*\)/ /g' | sort | uniq -c | sort -n

Si desea agrupar por redes más amplias,

$ grep "GET /register/" /path/to/access.log | cut -f 1,4 -d " " | cut -f1-2 -d: | sed -e 's/\(.*\)\.[0-9]*\.[0-9]* .*:\(.*\)/ /g' | sort | uniq -c | sort -n

Esto para tu muestra te da

  1 10 110.85
  1 10 110.89
  1 10 117.26
  1 10 120.43
  1 10 121.205
  1 10 192.99
  1 10 218.86
  1 10 27.159
  2 10 110.86
  2 10 120.37
  2 10 27.153

y ahora puede buscar, por ejemplo, ^ 27.153 en access.log (aún en China, todavía cubierto por ip2location).

    
respondido por el LSerni 02.11.2013 - 13:46
fuente
3

Sería mucho mejor detener este tipo de ataques en el perímetro en lugar de en el propio servidor. La mayoría de los firewalls de capa de aplicación vienen con una lista de reputación de IP. No quiero recomendar ningún producto específico, pero CISCO, Juniper y la mayoría de los otros proveedores que ofrecen el firewall y la funcionalidad IDP también brindan servicios de reputación de IP. Consulte a su equipo de red y ellos pueden proporcionarle la configuración específica que necesita.

Además, puede usar Mod Security , que es un firewall de capa de aplicación de código abierto. La ventaja de la seguridad mod es que, aparte de la amplia gama de ataques que puede detener, también tiene la capacidad de registrar las solicitudes HTTP POST completas. Apache no hace esto por defecto. Una vez que tenga el paquete completo, también puede analizarlo en busca de cualquier firma de ataque. Por ejemplo, si el bot utiliza un parámetro POST particular o la longitud del encabezado del paquete, etc., también puede desarrollar firmas de ataque basadas en esos parámetros.

    
respondido por el void_in 02.11.2013 - 14:16
fuente
2

si esas URL son legítimas, fail2ban como terry mencionado sería la forma más fácil de hacerlo. otra forma, pero mucho más complicada en términos de configuración y mantenimiento sería usar snort / suricata; también tiene umbrales / límites de velocidad, y los bloques basados en ip pueden cancelarse después de un cierto tiempo.

el problema ocurre cuando tienes solo 1 o 2 hits por bot en esas urls; la única oportunidad de bloquear intentos maliciosos sin afectar a los usuarios normales que se me ocurren (pero podría afectar a usuarios legítimos)

  • cambiar / registrar / a / registrar-solo-humanos / en su aplicación
  • bloquear a cualquiera que intente usar / registrar /

btw, tu registro de acceso se ve perdido para perder algunos valores, como el referente y el agente de usuario. ¿Puedes ver un patrón, basado en el agente de usuario, por ejemplo, es siempre el mismo? Si es así, también puede intentar bloquear en función de uri / user-agents.

Si esas URL no son legítimas, simplemente bloquee a cualquiera que quiera acceder a ellas.

    
respondido por el that guy from over there 03.11.2013 - 09:18
fuente
1

Como se mencionó, puede bloquear todo el país y también puede bloquear las direcciones IP de los servidores: desde el Centro de datos de Amazon como ejemplo.

Estoy utilizando la lista de IP que proporciona: enlace

Puedes usar un filtro fail2ban como este:

[Definition]
failregex = ^ .* POST /register.*
            ^ .* PUT /register.*

y el archivo de configuración correspondiente:

[register]
enabled  = true
port     = http,https
filter   = wp-login
action = iptables-multiport[name=wp-login, port="http,https", protocol=tcp]
logpath  = /var/log/.../*access.log
bantime = 36000
findtime = 172800
maxretry = 4
    
respondido por el Nicolas 29.07.2015 - 20:13
fuente

Lea otras preguntas en las etiquetas