Una protección que nunca se ha probado es una creencia, no un control. Pero probar defensas DDoS se sitúa cerca de una línea con consecuencias legales reales, y la diferencia entre un ejercicio profesional y un delito es sobre todo papeleo y alcance.
Las reglas
- Prueba solo infraestructura que poseas o para la que tengas permiso por escrito. Por escrito, específico y vigente — un acuerdo verbal no es defensa.
- Avisa a tu proveedor de hosting y al de protección de antemano. Una carga no anunciada parece exactamente un ataque, porque lo es.
- Nunca uses un servicio de stresser o booter. Pagar uno es, en la mayoría de jurisdicciones, el mismo delito que atacar a alguien con él, y además financias el ecosistema que ataca a tus clientes.
- Quédate dentro del límite de tu propia red. Una prueba que atraviesa la red de un tercero sin consentimiento implica sistemas que no estabas autorizado a afectar.
El documento de alcance
Escribe qué vas a probar, desde dónde, a qué intensidad, en qué ventana y quién puede detenerlo. Si algo sale mal, esa página es la diferencia entre una revisión de incidente y una investigación.
Qué vale la pena probar
Los fallos interesantes rara vez van de volumen bruto. Van de qué se rompe cuando el borde cambia de comportamiento: ¿sobrevive el callback del proveedor de pago a una página de desafío, maneja la app móvil un 429, se limita la tasa del health check, alerta el sistema de monitorización antes que un cliente?
- Carga de aplicación: mezclas realistas de peticiones contra endpoints caros, subiendo hasta que algo se degrade. El objetivo es encontrar el punto de inflexión, no romper la máquina.
- Comportamiento del desafío: pon el borde en su modo más estricto en una hora tranquila y usa el sitio como un cliente, en un móvil, con una conexión lenta.
- Resiliencia de integraciones: ejecuta tus clientes de API, webhooks y callbacks de terceros con la protección activa.
- Recuperación: ¿con qué rapidez vuelve todo a la normalidad tras apagar la carga?
Mide lo correcto
Una prueba que reporta una cifra de peticiones por segundo máximas no te dice casi nada útil. Registra el tiempo hasta la detección, el tiempo hasta la mitigación, la tasa de error en el origen durante el evento, si los recorridos de usuario real se completaron y qué alerta saltó primero. Esos son los números que desearás tener durante un incidente real.
Después
Anota los resultados el mismo día, incluyendo lo que te sorprendió. Una prueba que no encuentra nada o es un sistema inusualmente sano o, mucho más a menudo, una prueba demasiado suave para ser informativa.