Ataques de Denegación de Servicio (DoS): Estrategias de Prevención

Introducción

Los ataques de Denegación de Servicio (DoS) no son sutiles. No intentan robar datos ni persistir silenciosamente en un sistema. Su objetivo es contundente: hacer que un servicio no esté disponible para los usuarios legítimos. Para las empresas que dependen de la disponibilidad en línea—plataformas SaaS, comercio electrónico, APIs, sistemas financieros—el tiempo de inactividad es el daño.

A pesar de ser una de las clases más antiguas de ciberataques, los ataques DoS siguen siendo efectivos porque muchos sistemas todavía se diseñan pensando primero en la funcionalidad y después en la resiliencia. Esta publicación desglosa cómo funcionan los ataques DoS, por qué todavía tienen éxito y, lo más importante, cómo prevenirlos utilizando defensas en capas y prácticas.

¿Qué es un ataque DoS?

Un ataque de Denegación de Servicio (DoS) intenta abrumar los recursos de un sistema para que ya no pueda responder a solicitudes legítimas. Esto puede dirigirse a:

• Ancho de banda de la red (tráfico de inundación)
• Recursos del servidor (CPU, memoria, descriptores de archivos)
• Lógica de la aplicación (consultas costosas, abuso de autenticación)

Cuando el ataque se distribuye entre muchas fuentes, se convierte en un ataque de Denegación de Servicio Distribuido (DDoS). El impacto es el mismo; la dificultad de mitigación aumenta.

Tipos comunes de ataques DoS

1. Ataques de inundación a nivel de red

Estos ataques saturan el ancho de banda o las pilas de red.

Ejemplos:

• Inundaciones SYN
• Inundaciones UDP
• Inundaciones ICMP

Su objetivo es agotar las tablas de conexión o abrumar la capacidad de enrutamiento antes de que el tráfico llegue siquiera a la aplicación.

2. Ataques a la capa de aplicación

Estos son más peligrosos porque parecen legítimos.

Ejemplos:

• Inundaciones HTTP GET/POST
• Intentos de fuerza bruta de inicio de sesión
• Abuso de API
• Solicitudes de búsqueda o generación de informes costosas

Los ataques a la capa de aplicación a menudo evaden los cortafuegos básicos porque cada solicitud es técnicamente válida.

3. Ataques de Agotamiento de Recursos

Los atacantes desencadenan deliberadamente rutas de código que consumen excesivamente CPU, memoria o conexiones de base de datos.

Ejemplos:

• Hashing repetido de contraseñas
• Cargas de archivos grandes
• Consultas de paginación sin límite
• Abuso de generación de PDF/imágenes

¿Por qué los ataques DoS siguen funcionando?

Los ataques DoS tienen éxito no porque las defensas no existan, sino porque los sistemas a menudo carecen de:

• Límites de velocidad
• Validación de solicitudes
• Límites de recursos
• Visibilidad del tráfico
• Diseño consciente del costo

Muchas aplicaciones confían en que los usuarios se comportarán de manera razonable. Los atacantes dependen de esa confianza.

Estrategia de Prevención ## : Defensa en Profundidad

No existe una solución única para los ataques DoS. La prevención efectiva requiere controles en capas, cada uno diseñado para fallar de manera segura si otra capa se ve abrumada.

Capa 1: Protección de Red y Periférica

Usa un Proxy Inverso o CDN

Un proxy inverso absorbe el tráfico antes de que llegue a su infraestructura.

Capacidades:

• Filtrado de tráfico
• Mitigación de bots
• Protección contra inundaciones SYN
• Enrutamiento Anycast

Proveedores como Cloudflare o Akamai operan a nivel global y pueden manejar volúmenes que ningún servidor individual puede.

Principio clave: su servidor de origen nunca debe estar expuesto directamente.

Bloquear el abuso evidente en el borde

Incluso sin reglas de WAF pagadas, las protecciones básicas ayudan:

• Bloquear rutas de administración comunes que no existen
• Denegar solicitudes HTTP malformadas
• Aplicar límites de tamaño de solicitud
• Filtrar agentes de usuario que no sean navegadores cuando sea apropiado

El filtrado en el borde reduce la carga antes de que se ejecute la lógica de la aplicación.

Capa 2: Endurecimiento del Transporte e Infraestructura

Límite de velocidad en múltiples niveles

La limitación de velocidad debería existir:

• En el borde
• En el servidor web
• En la aplicación

Límites diferentes para distintos puntos finales:

• Puntos finales de autenticación: muy estrictos
• Páginas públicas: más flexibles
• APIs: cuotas basadas en tokens

La limitación de velocidad no se trata de detener todos los ataques, sino de hacer que los ataques sean costosos y lentos.

Aplicar límites de conexión

A nivel de servidor:

• Limitar las conexiones concurrentes por IP
• Establecer tiempos de espera keep-alive razonables
• Limitar el tamaño de los cuerpos de las solicitudes

A nivel de base de datos:

• Limitar el número máximo de conexiones
• Usar grupos de conexiones
• Fallar rápido en lugar de poner en cola sin fin

Capa 3: Defensas a Nivel de Aplicación

Proteger operaciones de alto costo

Cualquier endpoint que:

• Genere hashes de contraseñas
• Genere informes
• Suba archivos
• Envíe correos electrónicos
• Consulte grandes conjuntos de datos

…debe ser protegido.

Los controles incluyen:

• CAPTCHA o prueba de trabajo
• Cuotas de solicitudes
• Temporizadores de enfriamiento
• Colas de trabajos asíncronos

Nunca permita que los atacantes activen repetidamente trabajo sincrónico costoso.

Fallar Cerrado, No Abierto

Cuando un sistema está bajo estrés:

• Rechaza nuevas solicitudes rápidamente
• Devuelve códigos de error claros
• No reintentes internamente en bucles

La degradación elegante preserva la disponibilidad para los usuarios principales en lugar de colapsar por completo.

Capa 4: Observabilidad y Detección

Monitorea Lo Que Importa

Los ataques DoS a menudo son visibles antes de un corte total.

Rastrear:

• Solicitudes por endpoint
• Fallos de autenticación
• Picos de latencia
• Saturación de CPU y memoria
• Agotamiento de conexiones de base de datos

Las plataformas en la nube como Amazon Web Services proporcionan métricas y alarmas nativas que deben estar habilitadas desde el primer día.

Registrar con Intención

Los registros deben responder:

• ¿Qué endpoint está siendo utilizado?
• ¿Desde dónde?
• ¿A qué ritmo?
• ¿Con qué tamaño de carga útil?

Evita registrar los cuerpos completos de las solicitudes para los puntos finales sensibles, pero siempre registra suficiente metadata para identificar patrones de abuso.

Opciones de Diseño Arquitectónico Que Reducen el Riesgo de DoS

• Los servicios sin estado escalan mejor bajo carga
• El almacenamiento en caché reduce la presión en el backend
• El procesamiento asincrónico previene acumulaciones de solicitudes
• Las API idempotentes reducen la amplificación de reintentos
• Los tiempos de espera en todas partes previenen bloqueos de recursos

La resistencia a DoS tiene tanto que ver con la arquitectura como con las herramientas de seguridad.

Alineándose con los estándares de la industria

La orientación autorizada refuerza estas prácticas:

• NIST enfatiza la disponibilidad como un pilar central de la tríada CIA
• OWASP destaca la limitación de velocidad, los controles de recursos y la validación de entradas como defensas web esenciales

La prevención de DoS no es una higiene opcional, es ingeniería de seguridad básica.

Pensamientos Finales

Los ataques DoS explotan el desequilibrio: solicitudes baratas frente a procesamiento costoso. La solución es reequilibrar el sistema a favor del defensor.

Eso significa:

• Filtrar temprano
• Limitar agresivamente
• Diseñar para el fracaso
• Observar continuamente

La disponibilidad es una propiedad de seguridad. Los sistemas que ignoran esta realidad eventualmente lo aprenden de la manera difícil.

En Evolving Cyber, diseñamos sistemas pensando en la disponibilidad desde el primer día, porque un software seguro que no puede permanecer en línea no es seguro en absoluto.

Referencias

• Ataque de denegación de servicio — Wikipedia
• Resumen de la protección DDoS de Cloudflare
• Mejores prácticas de protección DDoS de Cloudflare
• Mejores prácticas de AWS para la resiliencia frente a DDoS
• Soluciones de protección DDoS de Akamai
• Los diez principales riesgos de seguridad de aplicaciones web según OWASP
• Guía de CISA sobre DDoS