Analizamos el tráfico con una herramienta de honeypot: ¿podemos confiar en los niveles de riesgo reportados y qué hacemos ahora?

No puedes lidiar con los bots bloqueando IPs estáticas porque las redes de bots cambian de IP continuamente. Configura un rate limiting en el servidor web que uses. Ralentiza temporalmente o redirige a una comprobación del navegador a quienes hagan más de cinco peticiones por segundo a los endpoints del carrito y de búsqueda.

Esos sitios de consulta gratuitos suelen ser muy lentos actualizando sus bases de datos. Incluso una IP de un centro de datos limpia hace tres meses puede seguir apareciendo como atacante en el sistema. Si bloqueas mirando directamente la lista, perderás clientes potenciales que se conecten desde redes móviles.

La solución más práctica que puedes aplicar ya mismo es subir un punto el nivel de seguridad en el panel donde gestionas tu dominio y poner una verificación automática del navegador (challenge) a las peticiones de rastreo que vengan de países sospechosos. El usuario real abre la página, mientras que los bots de rastreo simples se quedan pillados.

El orden a seguir debería ser más o menos este: 1) Busca un patrón común de agente de usuario (user-agent) en los registros del servidor. 2) Añade un enlace trampa oculto en páginas a las que los buscadores no deban acceder e aisla durante 24 horas las direcciones IP que entren ahí. 3) Pon límite de peticiones en las páginas de pago y carrito.

nosotros una vez tb bloqueamos cincuenta ips por puro panico y resulta q era la red de la oficina de un cliente q hacia pedidos al por mayor. los tios vieron q la web no cargaba y pidieron en otro lado, lo de bloquear ips estaticas es super arriesgado.

El mes pasado detectamos 3.000 IPs distintas pegándole a nuestro servidor en un rastreo similar. En herramientas externas 1.200 parecían arriesgadas, pero al analizar vimos que solo 75 estaban haciendo scraping real de datos. Actuar por IP sin mirar el comportamiento es una pérdida de tiempo.

¿Esas peticiones que entran están a un nivel como para bloquear la CPU del servidor o solo hacen bulto en los registros de acceso? ¿Y los rangos horarios en los que llegan siguen un patrón fijo o están totalmente repartidos a lo largo del día?

Es correcto en general, pero falta un detalle. El tiempo que tardas en detectar un problema determina directamente su coste.

Lo dejo como nota, por si sirve.

Este enfoque tiene un coste, y no se habla de ello. Al tomar decisiones, escribe también el peor escenario, no solo el mejor.

Lo importante no es la cifra, sino en qué se basa esa cifra. Corrijanme si me equivoco.

Lo que voy a preguntar sonará un poco novato perdonadme. La gente no defiende el proceso defiende la costumbre. La resistencia viene de ahí.

Un informe de escaneo automático no es lo mismo que una prueba de penetración. Corrijanme si me equivoco.

Estoy totalmente de acuerdo. Si no lo pones por escrito desde el principio, luego surgen discusiones.

Me han quedado claras las dudas, gracias.

Tema muy oportuno. Al tomar decisiones, escribe también el peor escenario, no solo el mejor.

Lo dejo como nota, por si sirve.

No tengo ninguna experiencia en verificador de honeypot, por eso pregunto. Lo que más tiempo nos hacía perder era no saber quién tomaba las decisiones.

Si es la primera vez que lo hacéis, empezad poco a poco, la escala llegará después.

Yo no me apresuraría. Una copia de seguridad no probada no es una copia de seguridad.

Empezad con una pequeña prueba, no lo integréis todo de golpe. Espero que le sea útil.

A nosotros nos pasó esto. Si obtienes tres respuestas distintas sobre un tema, la pregunta está mal formulada.

Los primeros tres meses todo va bien, los problemas aparecen en el cuarto.

Estoy de acuerdo. Si regañas las falsas alarmas, nadie volverá a reportar.

Espero que le sea útil.

A nosotros nos pasó esto. Lo que más tiempo nos hacía perder era no saber quién tomaba las decisiones.

Por supuesto, cambia si tu situación es diferente.