Bloquea el tráfico de botnets antes de que llegue a tu base de datos

La mayoría de stacks de aplicación están diseñados para ser educados. Llega una petición, el router la pasa a un controlador, el controlador abre una conexión con la base de datos, ejecuta una consulta y devuelve una respuesta. Para una persona, ese recorrido tiene todo el sentido. Para una botnet, es un regalo.

Una botnet distribuida no necesita explotar una vulnerabilidad para hacer daño. Le basta con que tu aplicación siga diciendo que sí: sí al formulario de login, sí al endpoint de búsqueda, sí al correo de recuperación de contraseña, sí a otra conexión más del pool. Para cuando el tráfico llega a tu ORM, ya has pagado el coste de TLS, la búsqueda de sesión y el viaje de ida y vuelta a la base de datos, multiplicado por miles de nodos por minuto.

La petición más barata es la que nunca llegas a procesar. Esa es la idea de fondo del filtrado de IP en el perímetro.

Qué pinta tiene una botnet en la capa IP

El tráfico de una botnet rara vez llega desde una única dirección. Llega desde muchas, y normalmente encaja en varias categorías bastante reconocibles:

• Equipos residenciales comprometidos. Routers domésticos, dispositivos IoT y ordenadores infectados. Poco volumen por separado, una barbaridad en conjunto.
• Capacidad alquilada en centros de datos. Instancias VPS baratas levantadas en masa. Un cliente humano casi nunca navega por tu checkout desde un rango de AWS, OVH o Hetzner.
• Redes comerciales de proxy. Pools de proxy residenciales y móviles revendidos por gigabytes, precisamente como forma de esquivar bloqueos basados en IP.
• VPN públicas y salidas TOR. Legítimas para usuarios preocupados por su privacidad, pero sobrerrepresentadas en el abuso.

Nada de esto es malicioso por definición. Una IP de centro de datos puede ser una sonda de monitorización que tú mismo has configurado. Una salida VPN puede ser un cliente conectado al Wi-Fi de un hotel. Por eso la decisión debe estar en tus manos, no en una lista de bloqueo indiscriminada: necesitas la clasificación y, a partir de ahí, aplicar tu política.

Bloquear antes de la base de datos, no después

El orden importa más que la precisión de una señal concreta. Pensemos en dos versiones del mismo endpoint de login.

| Stage | Without IP filtering | With IP filtering first | | --- | --- | --- | | Parse request | Yes | Yes | | IP classification | — | ~1 lookup, cached | | Session / user lookup | Yes | Only if allowed | | Password hash verify | Yes (expensive by design) | Only if allowed | | Rate-limit write | Yes | Only if allowed |

El hashing de contraseñas es lento a propósito; esa es su función. En un ataque de credential stuffing contra un login sin protección, tu propio control de seguridad se convierte en el vector de denegación de servicio. Si mueves la decisión sobre la IP por delante, un nodo atacante recibe un 403 al coste de una consulta en memoria, mientras el pool de conexiones de la base de datos sigue disponible para clientes reales.

La misma lógica aplica a endpoints de búsqueda que golpean índices de texto completo, formularios de registro que disparan correos transaccionales y cualquier endpoint que escriba una fila de auditoría por cada intento.

Una política práctica, no un muro

Bloquear en duro todo lo que parezca sospechoso es la receta perfecta para llenar soporte de tickets enfadados. Funciona mejor una respuesta por niveles, y es fácil de expresar cuando tienes una puntuación de riesgo y un tipo para cada dirección:

• Permitir sin hacer ruido. Direcciones residenciales y de ISP empresariales con una puntuación de riesgo baja. Es la inmensa mayoría del tráfico legítimo.
• Añadir fricción. Salidas VPN o TOR solo en acciones sensibles: alta, recuperación de contraseña, cambios de método de cobro. Muestra un reto, exige confirmación por correo o no concedas la prueba gratuita automáticamente.
• Limitar con dureza. Rangos de centros de datos y hosting accediendo a endpoints pensados para humanos. Las integraciones legítimas deben ir a tu API con una clave, no a tu formulario de login.
• Rechazar en el perímetro. Infraestructura de proxy conocida por abuso atacando autenticación, o cualquier IP que ya haya superado su presupuesto por dirección.

Fíjate en que el paso 4 es el cubo más pequeño, no la opción por defecto. El objetivo es encarecer el abuso, no hacer que tu producto sea inaccesible.

Dónde colocar la comprobación en tu stack

Hay tres ubicaciones posibles, ordenadas de mayor a menor eficacia aproximada:

• CDN o reverse proxy. El punto más temprano posible. La petición ni siquiera toca un servidor de aplicación. Es lo mejor para reglas generales sobre rangos claramente hostiles.
• Middleware en tu aplicación. Se ejecuta antes del routing y antes de cualquier llamada a base de datos. Aquí viven las políticas con matices por endpoint: estrictas en /login, más relajadas en /pricing.
• Dentro de la lógica de negocio. Para decisiones que necesitan contexto de cuenta, como marcar un login desde una IP de centro de datos en una cuenta que hasta ahora solo había usado un operador móvil concreto.

La mayoría de equipos necesita empezar por la opción intermedia. Son unas pocas líneas antes del router y protegen todo lo que queda detrás.

Cachea de forma agresiva y falla en abierto

Dos reglas operativas evitan que una comprobación de reputación IP se convierta en su propia caída de servicio:

Cachea por dirección. Las botnets reutilizan nodos. Un TTL corto en memoria —minutos, no días— comprime miles de peticiones en una sola consulta y mantiene la latencia añadida en el rango de microsegundos para reincidentes. Guarda cachea las consultas en el servidor precisamente por este motivo, y la ventana de caché es configurable.

Falla en abierto y registra con claridad. Si el servicio de reputación no está disponible, deja pasar la petición y guárdalo en logs. Un control antiabuso que tumba tu checkout porque un tercero tiene un mal día puede costarte más que el propio abuso. Reserva el fallo en cerrado para acciones realmente críticas, como retiradas de fondos.

Qué medir después

Activa primero el filtro en modo solo registro y compara una semana de tráfico con una semana de bloqueo:

• Peticiones rechazadas antes de llegar a la base de datos, como porcentaje del total.
• Saturación del pool de conexiones de base de datos durante picos de abuso.
• Intentos fallidos de login por hora.
• Tickets de soporte que mencionen "no puedo iniciar sesión": el canario de los falsos positivos.
• Ratio de altas a cuentas verificadas, que suele mejorar con fuerza cuando desaparecen los registros desechables desde centros de datos.

Si las dos últimas métricas se mueven en la dirección equivocada, afloja el nivel en lugar de apagarlo todo.

Límites honestos

La reputación IP es una capa, no un cortafuegos mágico. Los pools de proxy residenciales rotan por direcciones de consumidores reales que pueden parecer indistinguibles de tus clientes. El NAT de grado operador hace que una sola IP móvil represente a miles de personas. Los atacantes con presupuesto siempre encontrarán infraestructura más limpia que los atacantes sin él.

Lo que el filtrado IP sí hace de forma fiable es retirar la mayoría barata y de alto volumen: inundaciones automatizadas sobre servidores alquilados y listas de proxy quemadas. Así, tus defensas más lentas e inteligentes —fingerprinting de dispositivo, análisis de comportamiento, MFA, límites de tasa por cuenta— solo tienen que razonar sobre una población mucho más pequeña y mucho más interesante.

Esa es la victoria realista: no un perímetro impenetrable, sino una base de datos que sigue respondiendo consultas mientras estás bajo ataque.

Puedes clasificar cualquier dirección con las señales de proxy, VPN, TOR, hosting y puntuación de riesgo de Guarda usando la comprobación gratuita de la página principal, y después integrar esa misma llamada en el middleware que va por delante de tus rutas.