Security Bot — defensa perimetral reactiva.
Sistema en Python que protege el perímetro de Funidelia, e-commerce de Zaragoza: bloqueo de IPs abusivas y mitigación de abuso de endpoints en tiempo real.
Sistema de respuesta automática a patrones anómalos de tráfico en el perímetro de Funiglobal: bloqueo en tiempo real de IPs sospechosas, mitigación de abuso de endpoints públicos y correlación de señales con SIEM. Construido como conjunto de daemons Python que consumen métricas en streaming (InfluxDB), enriquecen contra reglas dinámicas en Redis y persisten audit trail en Elastic.
Problema
El perímetro de un e-commerce moderno recibe tráfico abusivo no clasificable por WAF tradicional: bots de scraping que rotan IPs, credential stuffing distribuido, abuso de endpoints de búsqueda donde el coste del request supera al de la respuesta. Las reglas estáticas tipo "100 req/min" o caen cortas (false negatives) o castigan al usuario legítimo (false positives).
Arquitectura
El bot opera en tres planos:
- Ingestión: consume métricas de aplicación y logs de nginx desde InfluxDB cada N segundos. Sin polling al backend; presión cero sobre los servicios productivos.
- Decisión: motor de reglas Python que evalúa firmas dinámicas — ratios entre endpoints, fingerprints de user-agent, geo-clustering de IPs nuevas — contra estado mantenido en Redis. Las reglas se actualizan en caliente sin redeploy.
- Respuesta: acciones graduales — captcha, rate-limit, soft-ban, hard-ban — emitidas vía scripts Bash que tocan iptables / fail2ban / WAF según nivel. Audit trail completo a Elastic para revisión post-hoc.
Resultado
Reducción medible del coste cloud asociado a tráfico no humano sobre endpoints caros (búsqueda, catálogo paginado) sin degradar la experiencia legítima. El sistema lleva en producción desde 2022 y sigue activo — la mejor señal de que las firmas dinámicas siguen siendo útiles.
Por qué funciona
La clave es que las reglas son dinámicas y se actualizan en caliente: en lugar de umbrales estáticos tipo "100 req/min" —que generan falsos positivos y negativos a partes iguales—, el motor correlaciona señales (ratios entre endpoints, fingerprints de user-agent, geo-clustering de IPs nuevas) y escala su respuesta de forma gradual, del captcha al hard-ban. Y al alimentarse de métricas ya presentes en InfluxDB en vez de sondear los servicios, añade presión cero sobre el backend productivo mientras protege los endpoints más costosos.