La protección contra DDoS sitio web se basa en varias barreras complementarias: filtrado perimetral, cortafuegos de aplicaciones, limitación de solicitudes, servidor de origine oculto, pruebas de carga y plan de continuidad. Para una plataforma de votación o un servicio muy concurrido, aumentar la potencia del servidor no basta. El objetivo es preservar el acceso legítimo sin poner en riesgo las transacciones ya registradas.
¿Qué es un ataque DDoS contra un sitio web?
Un ataque DDoS, o ataque distribuido de denegación de servicio, consiste en saturar un servicio con conexiones o solicitudes procedentes de numerosas máquinas. La protección DDoS de un sitio web busca distinguir el tráfico legítimo del tráfico automatizado antes de que las servidores, bases de datos o mecanismos de autenticación alcancen sus límites.
Un ataque DDoS no implica necesariamente una intrusión. El sitio puede volverse lento o quedar inaccesible sin que el atacante haya modificado su código ni consultado su base de datos. Para un directivo, la diferencia es importante: la indisponibilidad, el robo de datos y la alteración de una transacción son riesgos distintos, aunque puedan producirse durante el mismo incidente.
Los ataques dirigidos a la capa de red buscan sobre todo saturar la conectividad. Los dirigidos a la capa de aplicación solicitan funciones costosas: conexión a una cuenta, búsqueda, generación de un documento o validación de un voto. Unas pocas solicitudes bien elegidas pueden consumir muchos más recursos que un volumen masivo de páginas almacenadas en caché.
Le pilar de una estrategia de ciberseguridad debe, por tanto, separar disponibilidad, confidencialidad e integridad. Esta distinción evita un error de comunicación frecuente: anunciar que no se ha comprometido ningún dato cuando solo se ha analizado la disponibilidad.
¿Qué revela el incidente de la plataforma e-votez?
El incidente de e-votez del 9 de octubre de 2026 muestra que una avalancha automatizada puede perturbar una votación desde el momento de su apertura. A partir de las 08:00, las conexiones simultáneas de bots ralentizaron las páginas y provocaron rechazos de acceso. Los organizadores declararon que las papeletas registradas no se habían visto comprometidas.
Según la información publicada por los organizadores de «Choisir 2027», la interrupción no fue continua. Se mantuvo disponible una asistencia telefónica y se informó a las autoridades judiciales. Responsables gubernamentales también indicaron que se había contactado con la Agencia Nacional de la Seguridad de los Sistemas de Información, o ANSSI.
Le Parisien informó el 9 de octubre de 2026, citando a un miembro no identificado del comité organizador, de que los servidores soportaban aproximadamente 10 000 usuarios y de que la carga había alcanzado alrededor de 20 000 conexiones. Esta cifra procede de una única fuente y no constituye una medición técnica auditada.
Sigue siendo necesario actuar con prudencia. A 10 de octubre de 2026, no había ningún informe técnico público, registro de tráfico, calendario detallado de las medidas de defensa ni auditoría independiente disponible en las fuentes examinadas. No se conocía el origen de los bots y ningún actor había reivindicado públicamente la operación, según Clubic el 9 de octubre de 2026.
El plazo de la primera vuelta se amplió desde el 10 de octubre de 2026 a las 20:00 hasta el 11 de octubre de 2026 a las 18:00. Esta decisión ilustra el coste operativo de una disponibilidad insuficiente: aunque los datos permanezcan intactos, es necesario prolongar el servicio, informar a los usuarios y preservar la igualdad de acceso.
¿Qué arquitectura garantiza la protección DDoS de un sitio web?
Una arquitectura de protección DDoS de un sitio web sitúa una red distribuida y un servicio anti-DDoS delante del servidor de origen. Una CDN, o red de distribución de contenidos, absorbe parte del tráfico. Un WAF, o firewall de aplicaciones, filtra las solicitudes sospechosas antes de que lleguen a la aplicación sensible.
Las recomendaciones de AWS publicadas en 2026 aconsejan disponer de capacidad distribuida en el perímetro, almacenar en caché los contenidos compatibles y prohibir el acceso público directo al servidor de origen. Este último punto suele descuidarse. Si la dirección IP del origen sigue siendo accesible, un atacante puede eludir Cloudflare, AWS CloudFront u otro intermediario de protección.
La defensa debe cubrir varios niveles. Estos son los controles que deben preverse antes de abrir un servicio expuesto:
- una CDN y una mitigación anti-DDoS activada permanentemente cuando el proveedor lo permita;
- un WAF asociado a una detección de bots y a reglas adaptadas a los recorridos legítimos;
- límites diferenciados para la página de inicio, la autenticación, el envío de un código y la validación de una operación;
- almacenamiento en caché de las páginas públicas, sin almacenar en caché las respuestas privadas ni las confirmaciones de voto;
- un servidor de origen accesible únicamente desde las redes de la CDN o del proveedor de seguridad;
- una supervisión que relacione el tráfico de red, las conexiones, la disponibilidad, el procesador y la memoria;
- un procedimiento escrito que especifique los contactos, las responsabilidades y las medidas de continuidad.
Los límites de velocidad, o rate limits, establecen el número máximo de solicitudes autorizadas durante un periodo determinado. Según la documentación de AWS de 2026, deben existir tanto en el WAF como en la aplicación, con umbrales específicos para las funciones sensibles. Una solicitud excesiva puede bloquearse, someterse a un desafío o recibir el código HTTP 429, que significa «demasiadas solicitudes».
Por parte de la agencia, lo primero es comprobar de antemano las rutas que desencadenan el envío de un correo electrónico, un SMS, una solicitud compleja o una escritura en la base de datos. En ocasiones, una página ligera soporta la carga mientras que una simple función de reenvío de códigos agota los recursos de un proveedor externo. Para un sitio bajo WordPressel refuerzo de WordPress completa la protección de red, pero no la sustituye.
Colas, limitación o capacidad adicional: ¿qué elegir?
La elección depende de la operación que se quiera proteger. La caché es adecuada para contenidos idénticos para todos, la limitación ralentiza a los clientes que realizan un uso excesivo y una cola absorbe los procesos aplazables. Añadir servidores ayuda frente a un pico legítimo, pero puede limitarse a aumentar la factura ante un tráfico hostil sin filtrado previo.
| Medida | Uso adecuado | Límites que anticipar | Efecto sobre el proyecto |
|---|---|---|---|
| CDN y anti-DDoS | Absorber y filtrar el tráfico antes del origen | El origen sigue siendo vulnerable si su dirección está expuesta | Configuración de red y DNS que debe prepararse antes del lanzamiento |
| WAF y filtrado de bots | Bloquear comportamientos sospechosos de la aplicación | Una regla demasiado estricta puede rechazar a usuarios reales | Es necesario ajustar y observar los falsos positivos |
| Limitación por endpoint | Proteger la conexión, el código de verificación y la validación | Un umbral global penaliza a las redes empresariales compartidas | Deben definirse umbrales según cada función |
| Almacenamiento en caché | Servir rápidamente las páginas públicas | No es adecuada para datos personales y transacciones | Reducción de la carga con un coste de aplicación moderado |
| Cola de espera | Aplazar un proceso asíncrono | No es adecuada si el usuario exige una confirmación inmediata | Se requiere gestionar reintentos, duplicados y consumidores |
| Capacidad adicional | Absorber un pico legítimo previsto | No distingue entre visitantes y bots | Coste de alojamiento potencialmente variable |
La documentación AWS Well-Architected de 2023 indica que una cola o un flujo puede suavizar las llegadas lorsque el procesamiento acepte un modo asíncrono, es decir, diferido. No obstante, es necesario limitar el número de procesos simultáneos en sortie; de lo contrario, la cola simplemente trasladará la saturación a la base de datos o al servicio de terceros.
En una plataforma de votación, el envío final suele requerir una respuesta inmediata y una prevención estricta de los duplicados. Una cola puede ser adecuada para enviar un recibo o para determinadas tareas secundarias, pero no necesariamente para el registro central. Sinceramente, añadir una cola en todas partes complica el proyecto sin garantizar una mayor disponibilidad.
La elección de la infraestructura también debe tener en cuenta el support de emergencia, la ubicación de los datos y los mecanismos de filtrado disponibles. Una guía sobre la elección de un alojamiento web para una pyme ayuda a distinguir entre proximidad comercial y capacidad técnica real.
¿Cómo probar la resistencia antes de abrir con un fort tráfico?
Una prueba de carga reproduce un volumen progresivo de usuarios para identificar el primer componente que se satura. Para contar con una protección DDoS de sitios web creíble, los umbrales de capacidad deben medirse, documentarse y probarse antes de la apertura. Los procedimientos de defensa y continuidad también deben ensayarse hors situación de crisis.
La prueba debe abarcar un recorrido de negocio completo, no solo la página de inicio. Mide, entre otros aspectos, los tiempos de respuesta, los errores, las conexiones abiertas, el uso del procesador, la memoria, la base de datos y los servicios externos. Además, las recomendaciones de CISA publicadas en 2023 exigen realizar ejercicios de preparación frente a DDoS al menos una vez al año.
En los proyectos que llevamos a cabo, a menudo observamos una diferencia entre el tráfico anunciado y el escenario que se prueba realmente. Una prueba de 10 000 páginas estáticas no demuestra que una plataforma pueda aceptar 10 000 autenticaciones o validaciones simultáneas. El escenario debe reflejar la distribución de las acciones, las recuperaciones tras errores y los picos provocados por una hora de apertura conocida.
El peligro consiste en iniciar una prueba de saturación sin accord del proveedor de alojamiento o de protección. El tráfico puede bloquearse como si se tratara de un ataque real, afectar a un entorno compartido o activar una facturación imprevista. Las reglas, los rangos de direcciones, los horarios y los criterios de parada deben validarse de antemano.
¿Qué debe incluir el plan de respuesta y continuidad?
Un plan de respuesta frente a DDoS asigna las decisiones antes del incidente: modificación de los filtros, activación del proveedor, comunicación pública, asistencia y posible prolongación del servicio. En 2023, CISA recomendaba una mitigación automática lorsque fuera posible, contactos documentados y planes de continuidad y recuperación actualizados.
La supervisión no debe limitarse al servicio atacado. La documentación de AWS de 2026 recomienda correlacionar el tráfico, la disponibilidad de la aplicación, las conexiones, el procesador y la memoria, al tiempo que se supervisan los demás sistemas. Un DDoS visible puede ocultar una actividad secundaria más discreta.
La comunicación merece su propio escenario. Es necesario anunciar qué se está observando, qué sigue siendo accesible y qué medidas se han adoptado, sin atribuir prematuramente el ataque ni confundir una indisponibilidad con una intrusión. Una página de estado alojada por separado y un canal de asistencia reducen la presión sobre la aplicación principal.
El mantenimiento ordinario también sigue siendo necesario: una protección anti-DDoS no corrige ni una extensión vulnerable ni un servidor sin actualizar. Un enfoque de gestión de los correctivos en producción limita los riesgos paralelos mientras un equipo gestiona el incidente visible.
Definir la arquitectura, los umbrales y las responsabilidades antes de la puesta en línea evita la mayoría de las improvisaciones costosas. Una perspectiva externa puede, sobre todo, contrastar las hipótesis de negocio con los límites medidos de la aplicación, el alojamiento y los proveedores asociados.
Preguntas frecuentes sobre la protección contra ataques DDoS
¿Basta con una CDN para detener un ataque DDoS?
Un CDN no basta si el servidor de origine sigue siendo directamente accesible o si las solicitudes costosas atraviesan la caché. La defensa combina CDN, protección anti-DDoS, WAF, limitación a nivel de aplicación y aislamiento de origine.
¿Cloudflare protege automáticamente todos los formularios?
Cloudflare puede filtrar el tráfico en el perímetro, pero cada formulario sensible requiere reglas y umbrales coherentes con su uso. Una configuración demasiado agresiva puede bloquear a usuarios legítimos; una presentación de los mecanismos de protección con Cloudflare permite comprender sus compensaciones.
¿Significa un ataque DDoS que se han robado los datos?
Un ataque DDoS afecta principalmente a la disponibilidad y no demuestra un robo de datos. Sigue siendo necesario realizar un análisis independiente de los registros, los accesos y la integridad, ya que una saturación puede ocultar otra actividad.
¿Es necesario comunicar durante un ataque DDoS?
Una comunicación objetiva reduce la incertidumbre: estado del servicio, funciones afectadas, canal de asistencia y medidas de continuidad. La identidad o el origine supuesto de los atacantes no debe anunciarse sin elementos verificados.