Un ataque de denegación de servicio distribuida, o DDoS, intenta dejar un sitio o servicio inaccesible al agotar su conexión de red, su capacidad para mantener conexiones o los recursos de la aplicación. En un sitio empresarial, puede impedir que sus clientes consulten productos, inicien sesión, envíen formularios o completen compras.
La preparación comienza por identificar qué necesita proteger. Un filtro de solicitudes web no necesariamente protege una conexión de internet saturada, y un servidor con más capacidad puede seguir teniendo problemas ante solicitudes que exigen demasiado trabajo a la aplicación. Cada defensa debe responder a un riesgo concreto y tener una persona responsable de administrarla.
Distinga las tres familias de ataques
Los ataques DDoS pueden afectar distintas partes de un mismo servicio. Un incidente también puede combinar varios métodos.
| Familia | Qué intenta agotar | Ejemplo |
|---|---|---|
| Volumétrica | El ancho de banda disponible | Una cantidad de tráfico que satura la conexión antes de que las solicitudes legítimas lleguen al sitio |
| De protocolo | Los recursos utilizados para establecer o mantener conexiones | Una inundación SYN que consume capacidad para gestionar conexiones |
| De aplicación | Los recursos necesarios para procesar solicitudes | Solicitudes HTTP repetidas a páginas que ejecutan consultas costosas a la base de datos |
Estas categorías ayudan a identificar dónde ocurre la saturación. La explicación de ataques DDoS de Cloudflare amplía sus diferencias.
Un ataque de aplicación puede causar problemas sin llenar la conexión de red. Por ejemplo, muchas solicitudes a una función de búsqueda pueden consumir los recursos disponibles para atender otras operaciones del sitio.
Revise qué cubre cada defensa
La protección por capas combina controles con funciones diferentes. Antes de elegirlos, revise tanto su cobertura como sus limitaciones.
| Control | Qué puede ayudar a reducir | Qué debe comprobar |
|---|---|---|
| Filtrado de tráfico antes de llegar al servidor | Tráfico que podría saturar la conexión | Qué direcciones y protocolos cubre y cómo se activa |
| Firewall de aplicaciones web, o WAF | Solicitudes HTTP que coinciden con reglas de filtrado | Quién configura las reglas y cómo se corrigen bloqueos de usuarios legítimos |
| Límites de solicitudes | El uso excesivo de determinadas funciones | Cómo se identifica a cada cliente y qué límites permiten el uso normal |
| Caché en una red de distribución de contenido, o CDN | Solicitudes repetidas de contenido que puede almacenarse temporalmente | Qué solicitudes siguen llegando al servidor de origen |
| Límites de recursos de la aplicación | Consultas costosas, solicitudes prolongadas o demasiadas operaciones simultáneas | Si las funciones esenciales siguen disponibles bajo carga |
| Restricciones de acceso al servidor de origen | Intentos de evitar un intermediario de protección y llegar directamente al servidor | Si las restricciones permiten la administración y las integraciones necesarias |
Un WAF instalado en el servidor no recupera el ancho de banda que ya se consumió antes de llegar a él. Una CDN también requiere configuración: las solicitudes que no utilizan caché pueden seguir llegando a la aplicación, y una dirección de origen expuesta puede permitir que el tráfico evite la protección.
Los respaldos y los certificados TLS cumplen otras funciones. Los respaldos permiten recuperar datos; TLS, habitualmente asociado con los certificados llamados SSL, protege las conexiones en tránsito. Ninguno filtra por sí solo un ataque DDoS ni garantiza la disponibilidad del sitio.
Agregar recursos puede ayudar a atender demanda legítima, pero no sustituye la mitigación. Aumentar capacidad automáticamente durante un ataque también puede elevar los costos sin resolver la causa.
Defina qué administra su organización y qué administra el proveedor
La cobertura depende del contrato y de la configuración del servicio. No suponga que cualquier plan incluye todos los controles ni que otra persona ajustará las reglas durante un incidente.
Antes de poner el sitio en producción, asigne responsables para estas tareas:
- Mitigación de red: detectar saturación y coordinar el filtrado antes de que el tráfico llegue al servidor.
- DNS y servicios de protección: mantener los registros y comprobar cuáles servicios pasan por la protección.
- Controles de aplicación: administrar reglas del WAF, límites de solicitudes, caché y funciones que consumen muchos recursos.
- Monitoreo: recibir alertas y verificar que los visitantes puedan completar acciones esenciales.
- Decisiones durante el incidente: autorizar restricciones temporales y comunicar sus efectos.
Documente el procedimiento de escalamiento del proveedor, la disponibilidad de soporte y la información necesaria para investigar. Conserve esas instrucciones y el acceso a las cuentas en un lugar que no dependa del sitio afectado.
Revise también los servicios relacionados. Proteger la página principal no demuestra que exista la misma cobertura para DNS, correo, interfaces de programación o sistemas externos.
Prepare un procedimiento de respuesta
Un sitio lento o inaccesible no necesariamente está bajo ataque. Una actualización fallida, un problema de base de datos o un aumento legítimo de visitantes puede producir síntomas similares.
Utilice un procedimiento que permita identificar la causa y evitar cambios innecesarios:
- Confirme los síntomas. Revise el sitio desde una conexión independiente. Registre los dominios y funciones afectados, los errores y la hora de inicio.
- Revise cambios recientes y dependencias. Compruebe actualizaciones, cambios de DNS, avisos del proveedor y estado de la aplicación junto con los patrones de tráfico.
- Escale con evidencia útil. Comparta fechas y horas con zona horaria, servicios afectados y muestras pertinentes de registros. Excluya contraseñas, credenciales y datos personales innecesarios.
- Aplique controles específicos. Coordine los ajustes de filtrado o límites con el responsable. Compruebe que los usuarios legítimos todavía puedan navegar, iniciar sesión y comprar.
- Registre las acciones y comunique. Mantenga una secuencia de cambios y resultados. Utilice un canal independiente si el sitio está fuera de servicio.
- Revise después de la recuperación. Retire las restricciones temporales cuando corresponda, investigue errores pendientes y actualice el procedimiento.
Evite cambios amplios sin evaluar sus consecuencias. Bloquear una región completa puede impedir el acceso de sus clientes. Retirar un intermediario de protección puede exponer el servidor al tráfico que antes filtraba.
Haga preguntas concretas antes de contratar
La expresión “protección DDoS” no basta para comparar servicios. Solicite respuestas sobre el alcance de la solución propuesta:
- ¿Qué dominios, direcciones, protocolos y servicios están cubiertos?
- ¿La cobertura atiende ataques de red, de aplicación o ambos?
- ¿El tráfico pasa continuamente por la mitigación o es necesario activarla?
- ¿Quién configura y ajusta las reglas de protección de la aplicación?
- ¿Qué límites, exclusiones o cargos adicionales existen?
- ¿En qué circunstancias podría bloquearse todo el tráfico hacia el destino para proteger otros servicios?
- ¿Qué procedimiento de soporte y escalamiento aplica durante un incidente?
Compare las respuestas con las funciones que su negocio necesita mantener disponibles. Una tienda que depende del pago en línea puede tener prioridades distintas de un sitio que publica principalmente información.
Preguntas frecuentes
¿La protección siempre activa garantiza que el sitio no se interrumpa?
No. Mantiene la mitigación en la ruta del tráfico, pero el resultado depende de la cobertura, la capacidad, la configuración y el ataque. En una modalidad bajo demanda, puede ser necesario detectar el incidente y activar la mitigación. Revise esos procedimientos sin asumir que alguna modalidad garantiza disponibilidad absoluta.
¿Una CDN protege todo el sitio?
Depende del servicio y de su configuración. La caché puede reducir solicitudes al servidor de origen y otras funciones pueden filtrar tráfico. Las páginas dinámicas, las direcciones de origen expuestas y los servicios fuera de la protección requieren una evaluación adicional.
¿Debe restaurar un respaldo durante un ataque DDoS?
Un ataque de tráfico por sí solo no justifica restaurar datos. La restauración no detiene las solicitudes entrantes y puede añadir interrupciones. Primero determine si existe un problema independiente de pérdida o corrupción de datos.
¿Qué debe priorizar un sitio pequeño?
Identifique sus funciones esenciales, confirme la protección configurada y documente quién puede hacer cambios. Establezca monitoreo y escalamiento claros; después atienda los servicios sin cobertura y los problemas de capacidad según su impacto.
Elija hospedaje con un alcance de protección claro
Utilice su inventario de servicios y sus requisitos de respuesta al evaluar las opciones de hospedaje web de CR Servers. Confirme qué protección contempla la propuesta, qué controles debe administrar su organización y cómo se escalaría un incidente.
Para comprender mejor los recursos y responsabilidades del servicio, consulte la guía de fundamentos de hospedaje web.