DDoS Deflate fue un script popular para contar conexiones desde cada dirección IP y bloquear temporalmente los orígenes que superaban un umbral. Resultó útil frente a ciertos abusos simples, pero no constituye una defensa suficiente contra ataques distribuidos actuales y no recomendamos instalarlo como mecanismo principal en un servidor moderno.
Un ataque de denegación de servicio distribuido puede utilizar miles de dispositivos, redes residenciales, servicios en la nube, proxies o direcciones IPv6. Cada origen puede generar pocas solicitudes y, aun así, el conjunto puede agotar ancho de banda, conexiones, procesos, CPU o recursos de la aplicación.
Cómo funcionaba DDoS Deflate
El script se ejecutaba periódicamente, consultaba las conexiones activas y comparaba la cantidad asociada a cada IP con un límite. Si una dirección lo superaba, agregaba un bloqueo temporal mediante herramientas locales como APF o iptables.
Este enfoque presupone que una cantidad elevada de conexiones desde una sola IP representa un ataque. Esa suposición puede fallar en ambos sentidos: un atacante distribuido puede mantenerse por debajo del umbral, mientras que una red empresarial, un proxy o un proveedor de acceso compartido puede concentrar usuarios legítimos en una misma dirección.
Por qué el bloqueo local puede llegar demasiado tarde
Si un ataque volumétrico satura el enlace de red, los paquetes ya llegaron al datacenter antes de que el firewall del servidor pueda descartarlos. Aunque el equipo bloquee correctamente las IP, el ancho de banda continúa ocupado. Esa clase de incidente debe mitigarse aguas arriba, en la red del proveedor o mediante una infraestructura preparada para absorber y filtrar tráfico.
En ataques HTTP, el volumen puede ser menor pero cada solicitud obliga a ejecutar PHP, consultar la base de datos o generar una página costosa. Allí son útiles la caché, el proxy inverso, las reglas WAF y los límites específicos por ruta.
No todos los ataques DDoS son iguales
- Capas 3 y 4: buscan saturar red, protocolos o estados de conexión.
- Capa 7: envían solicitudes HTTP o API que parecen tráfico de aplicación.
- DNS: atacan la disponibilidad o abusan de resolvers y respuestas.
- Agotamiento de recursos: apuntan a endpoints que consumen CPU, memoria o base de datos.
La guía de CISA sobre DDoS destaca la necesidad de identificar el tipo de ataque y coordinar la respuesta. Una única lista de IP bloqueadas no cubre todas estas capas.
Defensa moderna por capas
Una estrategia razonable combina varios controles:
- Protección de red y capacidad proporcionada por el datacenter o proveedor.
- CDN o proxy inverso para el tráfico web cuando el servicio lo permite.
- Protección DDoS administrada y reglas WAF para la capa de aplicación.
- Rate limiting en rutas sensibles, APIs, búsquedas y accesos.
- Firewall local para abusos que sí alcanzan el servidor.
- Caché y optimización para reducir el costo de solicitudes legítimas.
- Monitoreo, registros y un procedimiento de escalamiento.
Para entender la diferencia entre estas capas, consultá seguridad en servidores de hosting y qué es ModSecurity como firewall de aplicaciones.
Qué puede aportar Cloudflare
Cuando un sitio web utiliza Cloudflare como proxy, las solicitudes HTTP llegan primero a su red. Sus sistemas pueden detectar ataques, aplicar desafíos, reglas administradas y límites antes de que el tráfico alcance el origen. La arquitectura de seguridad documentada por Cloudflare distingue protección DDoS de capa 7, capa 4 y capa 3.
La protección concreta depende del servicio, plan y configuración. La nube naranja para una web no protege automáticamente correo, FTP, cPanel ni cualquier otro protocolo que no pase por ese proxy. Tampoco conviene asumir que el origen está oculto si su IP aparece en registros históricos, servicios directos u otros subdominios.
Si querés utilizar esta capa para una web, revisá cómo activar Cloudflare para un dominio y verificá qué registros deben permanecer sólo como DNS.
Rate limiting sin bloquear usuarios legítimos
Un límite global demasiado estricto puede afectar visitantes, buscadores, APIs y administradores. Es preferible definir reglas sobre recursos costosos: inicio de sesión, recuperación de contraseñas, búsquedas, formularios o endpoints que ejecutan tareas intensivas.
Antes de aplicar una regla, medí el comportamiento normal. Elegí una ventana, un umbral y una acción proporcionales; cuando sea posible, comenzá registrando o desafiando antes de bloquear. Excluí integraciones verificadas sólo cuando puedas identificarlas de manera confiable.
Qué hacer durante un ataque
- Confirmá que se trata de tráfico y no de una falla de aplicación, disco o base de datos.
- Medí ancho de banda, paquetes, conexiones, códigos HTTP y carga del servidor.
- Identificá protocolos, rutas, países, ASN y patrones predominantes.
- Contactá al proveedor si existe saturación de red o pérdida de conectividad.
- Activá controles administrados y límites específicos para el patrón observado.
- Protegé el acceso administrativo y conservá evidencia útil del incidente.
- Comunicá el estado por un canal que no dependa del servicio afectado.
No bloquees continentes completos ni rangos extensos únicamente por una muestra pequeña. Esa acción puede reducir tráfico legítimo sin detener una botnet distribuida. Tampoco reinicies repetidamente el servidor antes de recopilar métricas: un reinicio puede borrar información de diagnóstico y no resuelve el origen del tráfico.
Cómo reducir la exposición del servidor de origen
Si todo el tráfico web debe atravesar un proxy, el firewall del origen puede aceptar HTTP y HTTPS sólo desde los rangos oficiales de ese proveedor. Esta medida requiere mantener la lista actualizada y conservar un acceso administrativo alternativo. Una configuración incorrecta puede dejar el sitio inaccesible.
También conviene evitar publicar la IP en registros que no necesiten acceso directo, separar servicios, mantener software actualizado y deshabilitar endpoints no utilizados. La protección DDoS no reemplaza la seguridad de la aplicación ni corrige contraseñas débiles o plugins vulnerables.
Por qué no conviene instalar scripts abandonados
Copiar comandos desde un tutorial antiguo puede descargar código modificado, sobrescribir reglas existentes o depender de herramientas que ya no utiliza el sistema. Además, dos administradores de firewall compitiendo por las mismas reglas pueden provocar bloqueos inesperados.
Si encontrás DDoS Deflate instalado, no lo elimines sin revisar primero cómo fue integrado y qué tareas programadas o reglas creó. Documentá el estado, prepará la alternativa y realizá el cambio de forma controlada.
La mitigación debe planificarse antes del incidente
Definí contactos del proveedor, umbrales normales, accesos de emergencia, copias de configuración y un canal de comunicación. Después de cada evento, revisá qué capa se agotó y ajustá la defensa correspondiente. DDoS Deflate pertenece a una etapa en la que bloquear una IP con muchas conexiones podía resolver gran parte del problema; los ataques actuales exigen visibilidad y mitigación distribuida en varias capas.
