Cómo la FSF bloquea botnets con automatización

Si operas servicios expuestos a internet, ya sabes que el problema no es solo el ataque grande y visible. El desgaste real suele venir de miles de intentos pequeños y repetidos: login bruteforce, scans, scraping, abuso de formularios, picos raros desde rangos de IP que cambian todo el tiempo. Ahí es donde una botnet deja de ser un concepto abstracto y se vuelve ruido constante en tus logs, en tu CPU y en tu tiempo.

La Free Software Foundation publicó un caso práctico muy útil sobre cómo sus sysadmins usan automatización y reacción en cadena para cortar ese tipo de abuso sin depender de respuestas manuales cada vez que aparece una IP nueva. El enfoque no es magia ni una regla única que arregla todo. Es más bien un sistema de detección, respuesta y escalamiento que reduce el trabajo repetitivo y hace que la defensa mejore con cada incidente.

Qué problema resuelve este enfoque

Cuando un servicio público se expone a bots, el primer costo no suele ser el downtime. El primer costo es el tiempo humano. Alguien tiene que mirar alertas, confirmar si el tráfico es legítimo, decidir si se bloquea una IP, actualizar reglas y verificar que no rompió nada. Si eso pasa diez veces al día, el equipo termina operando en modo reactivo permanente.

En el post de la FSF, la idea central es usar reacción automática para que una señal detectada dispare una serie de acciones predefinidas. No se trata de bloquear por bloquear, sino de convertir una observación repetida en una respuesta consistente. Eso sirve especialmente cuando ves patrones como estos:

• muchas conexiones fallidas desde la misma red o desde redes vecinas;
• bursts de requests con user agents obvios o vacíos;
• intentos de autenticación fuera de horario y desde países o ASNs poco habituales para tu base de usuarios;
• tráfico que parece distribuido, pero comparte comportamiento en ventanas cortas de tiempo.

La ventaja de automatizar no es solo velocidad. También reduces la variabilidad humana. Si hoy bloqueas una IP y mañana decides esperar, la política se vuelve inconsistente. Con automatización, el criterio queda escrito y el sistema actúa igual cada vez.

Qué significa “reacción en cadena” en la práctica

La reacción en cadena es simple: un evento dispara una acción, esa acción genera nueva información y esa nueva información dispara otra acción. Por ejemplo, un detector ve 50 intentos fallidos en 2 minutos, el sistema marca la IP, la agrega a una lista temporal, notifica al equipo y, si el comportamiento continúa desde otras IPs del mismo rango, eleva la severidad.

Ese modelo funciona bien porque no dependes de una sola barrera. Tienes varias capas pequeñas que cooperan. Si una falla, las demás siguen aportando contexto. Y si el bot cambia de IP, no necesariamente cambia de comportamiento, así que tu sistema puede seguir el rastro.

La clave está en que cada paso sea barato. Si tu detector consume más recursos que el ataque, perdiste. Si tu notificación produce más ruido que valor, también perdiste. La idea es que la defensa automatizada sea liviana, medible y reversible.

Cómo se arma el flujo de defensa

La FSF no presenta esto como una receta universal, y eso es bueno. Cada servicio tiene su propio perfil de riesgo. Pero sí deja ver una arquitectura útil para cualquier equipo que administre servicios expuestos: observación, decisión, ejecución y revisión.

Piensa en este flujo como una cadena corta:

1. Detectas un patrón anómalo.
2. Correlacionas con reglas simples o listas de reputación.
3. Ejecutas una respuesta automática, normalmente temporal.
4. Registras el evento para revisar falsos positivos.
5. Ajustas umbrales y excepciones con base en datos reales.

Eso te evita el clásico problema de tener herramientas de seguridad desconectadas entre sí. No basta con mirar logs. Tampoco basta con bloquear en firewall. El valor aparece cuando conectas eventos con acciones.

Señales que sí valen la pena automatizar

No todo merece una respuesta automática. Si automatizas demasiado, terminas bloqueando usuarios legítimos por errores menores. Por eso conviene elegir señales de alta repetición y bajo costo de verificación. En la práctica, suelen funcionar mejor estas:

• más de 20 intentos fallidos de autenticación en 5 minutos desde la misma IP;
• más de 100 requests a rutas sensibles en 1 minuto con el mismo patrón de user agent;
• múltiples errores 403 o 404 concentrados en rutas de administración;
• actividad desde IPs que ya fueron marcadas por el sistema en las últimas 24 horas.

La idea no es que estos números sean universales. Son ejemplos de umbrales que puedes adaptar. Si tu servicio tiene poco tráfico, 20 intentos puede ser demasiado. Si tu plataforma recibe miles de requests por minuto, quizá ese umbral sea bajo. Lo correcto es partir de tu línea base y medir.

Tabla de ejemplo para decidir respuestas

La tabla no reemplaza tu criterio, pero te ayuda a convertir sensaciones en reglas. Si un patrón aparece una y otra vez, merece una respuesta automática. Si no, mejor mantenerlo en observación y evitar falsos positivos.

Qué aporta la automatización frente al bloqueo manual

El bloqueo manual parece más controlado, pero tiene tres problemas muy concretos. Primero, llega tarde. Segundo, depende de que alguien esté mirando. Tercero, no escala cuando el ataque se distribuye. Una botnet no te manda una sola IP molesta. Te manda cientos de fuentes pequeñas que cambian de forma constante.

La automatización te da una ventaja táctica: convierte una tarea repetitiva en una política. Eso no significa que elimines al humano del circuito. Significa que el humano deja de hacer trabajo mecánico y se concentra en ajustar reglas, investigar patrones y responder a casos raros.

La FSF usa este tipo de lógica para que el sistema reaccione sin esperar a que alguien abra una consola y copie una IP a una lista. Y eso, en servicios expuestos, ahorra minutos valiosos. En incidentes de alto volumen, esos minutos son la diferencia entre una molestia contenida y una cola de alertas interminable.

Herramientas que encajan bien con este enfoque

No necesitas una plataforma compleja para empezar. De hecho, muchas defensas útiles se construyen con piezas simples que ya conoces. Algunas opciones típicas son:

• firewall dinámico con listas temporales;
• fail2ban o herramientas similares para patrones de autenticación;
• scripts que consumen logs y actualizan reglas;
• alertas vía correo, chat o ticket cuando el umbral se cruza;
• métricas para ver si el bloqueo reduce el ruido o solo lo mueve de lugar.

Si trabajas con Linux, también conviene revisar la documentación oficial de nftables para entender cómo aplicar reglas de forma más limpia que con configuraciones viejas de iptables. Puedes empezar por la documentación del proyecto en https://wiki.nftables.org/.

Cómo evitar romper usuarios legítimos

Automatizar defensas sin pensar en falsos positivos es la forma más rápida de generar problemas internos. Un equipo de soporte, una VPN corporativa compartida o usuarios detrás de NAT pueden parecer una botnet si solo miras el número bruto de requests. Por eso necesitas límites, ventanas de tiempo y mecanismos de salida.

La FSF no plantea una defensa ciega. La idea es reaccionar rápido, sí, pero con respuestas temporales y revisables. Bloquear por 30 minutos no es lo mismo que banear para siempre. Un escalado a revisión no es lo mismo que una expulsión definitiva. Esa diferencia te permite ser agresivo sin ser torpe.

También ayuda mucho separar señales de castigo. No todo evento debe terminar en bloqueo. A veces basta con subir el rate limit, exigir un challenge adicional o mover la IP a una lista de observación. Eso reduce el riesgo de cortar tráfico real por una anomalía puntual.

Tres reglas prácticas para no pasarte de agresivo

1. Usa bloqueos temporales antes que permanentes.
2. Exige más de una señal para aplicar castigos fuertes.
3. Mantén una allowlist mínima para orígenes críticos como monitoreo, VPN o socios conocidos.

Si quieres una referencia seria para el manejo de rate limiting y controles de acceso, Cloudflare publica documentación útil sobre mitigación y reglas de firewall en https://developers.cloudflare.com/.

Una implementación simple que sí puedes adaptar

No hace falta copiar la infraestructura de la FSF para aprender del patrón. Puedes montar una versión pequeña en tu entorno con logs, un script y una regla temporal. Lo importante es que el flujo sea claro y auditable. Si mañana alguien pregunta por qué una IP quedó bloqueada, debes poder responder con datos.

Un ejemplo básico podría verse así:

#!/usr/bin/env bash
set -euo pipefail

IP="$1"
DURATION="30m"

# Agrega la IP a una lista temporal administrada por nftables
nft add element inet filter temp_blocklist { "$IP" timeout "$DURATION" }

# Registra el evento para auditoría
logger -t botnet-response "Blocked $IP for $DURATION after repeated auth failures"

Eso no resuelve todo, pero muestra el patrón: detectas, ejecutas y registras. Luego puedes conectar ese script con un detector que lea logs de autenticación o eventos del reverse proxy. Si usas Prometheus, Loki u otra pila de observabilidad, también puedes disparar la acción desde una alerta bien definida.

Lo importante es que no mezcles demasiadas responsabilidades en un solo script. Si el detector falla, no quieres que el firewall quede en un estado raro. Si el logger falla, no quieres perder trazabilidad. Divide el problema en piezas pequeñas.

Qué medir desde el primer día

Si implementas algo así, mide al menos estas cuatro cosas:

• cantidad de bloqueos por día;
• porcentaje de bloqueos que luego resultaron falsos positivos;
• tiempo promedio entre detección y acción;
• reducción de ruido en logs después de la automatización.

Con esos datos ya puedes saber si el sistema está funcionando o solo está generando actividad. Si el número de bloqueos sube, pero el ruido total no baja, probablemente tu umbral está mal ajustado. Si el número de falsos positivos es alto, necesitas más contexto antes de castigar.

Qué lecciones deja el caso de la FSF

La lección más útil no es técnica, sino operativa: una defensa buena no es la que bloquea más, sino la que te permite responder con menos fricción. La FSF muestra que automatizar no significa perder control. Significa mover el control a reglas explícitas, repetibles y revisables.

Eso encaja muy bien con equipos pequeños o medianos que administran servicios públicos, APIs, paneles de acceso o formularios sensibles. Si tienes poco personal, no puedes vivir mirando alertas. Si tienes mucho tráfico, no puedes depender de decisiones manuales para cada evento. La automatización te da un puente entre esos dos extremos.

También hay una idea de fondo que vale la pena copiar: la respuesta debe mejorar con el tiempo. Cada bloqueo, cada falso positivo y cada excepción te enseñan algo sobre tu superficie de ataque. Si documentas bien esos casos, tu sistema se vuelve más fino sin volverse más complejo de lo necesario.

Tabla resumen

Si operas servicios expuestos, no necesitas esperar a una botnet masiva para empezar. Puedes tomar la idea de reacción en cadena, adaptarla a tus logs y empezar con un bloqueo temporal bien medido. Eso ya te da una base más sólida que reaccionar a mano cada vez que un bot decide probar suerte.