En esta página
Puntos clave
- El ancho de banda no bastaPPS, colas, CPU y estados pueden fallar antes de llenar los Gbps.
- El impacto se propagaUn cliente atacado puede degradar un rack, VLAN o plataforma.
- Filtrar aguas arribaFiltrar demasiado cerca del servidor deja propagarse la saturación.
El problema: el ataque desborda el objetivo
Un DDoS suele apuntar a una IP o servicio, pero los paquetes atraviesan equipos compartidos antes de llegar. Si la saturación ocurre en el enlace, router, firewall, switch o túnel, el impacto alcanza otros servicios.
Muchas ofertas hablan solo de protección de servidor. En realidad importan la capacidad del puerto, PPS procesado, buffers, tablas de estado, ACL, rutas de retorno y aislamiento del cliente afectado.
También importa la dirección del cuello de botella. A veces el problema está en la entrada del tráfico, otras en la devolución, en una cola compartida o en un túnel que no fue dimensionado para incidentes. Sin esta lectura, se cambia el servidor cuando en realidad falla el camino.
Por qué es crítico para hosters y empresas
Para un hoster, un solo cliente expuesto puede generar pérdida para otros si el filtrado llega tarde. Para una empresa, un ataque a una aplicación pública puede afectar VPN, APIs, telefonía o administración. En gaming, un servidor atacado puede degradar varias máquinas si comparten enlace.
El impacto también es económico: soporte, reembolsos, migraciones urgentes y pérdida de confianza. Una buena arquitectura reduce la contaminación absorbiendo o reduciendo el ataque antes de zonas sensibles.
El efecto suele aparecer en cascada: primero sube la pérdida, después aumentan los tiempos de respuesta, luego los sistemas de monitorización muestran síntomas contradictorios. Sin una lectura de red, el equipo puede buscar el problema en el servidor equivocado.
Soluciones para contener el impacto
La primera solución es filtrar aguas arriba: tránsito protegido, scrubbing center, FlowSpec o reglas de alivio que eviten llenar el enlace del cliente. La segunda es segmentar clientes, servicios y retornos.
La tercera es entregar tráfico limpio por túnel, cross-connect, BGP o proxy. Para gaming, el reverse proxy puede aislar superficies concretas. Para redes y hosters, el tránsito IP protegido trata el problema más arriba.
Ejemplo: hoster con varios clientes en un uplink
Un hoster tiene varios servidores dedicados detrás de un uplink. Un cliente recibe un UDP flood fuerte. Si se filtra solo en el servidor, el uplink ya está lleno y otros clientes pierden paquetes.
Con un modelo limpio, el tráfico se atrae o filtra antes y solo lo aceptable vuelve. El cliente atacado queda aislado y los vecinos no sufren el incidente.
Errores frecuentes
El primer error es pensar que un firewall basta. Puede ser bueno para política de seguridad pero saturarse con demasiados paquetes o sesiones. El segundo es mirar solo Gbps: el PPS puede romper equipos antes.
El tercer error es no preparar el retorno. Bloquear no sirve si el tráfico limpio vuelve por un túnel pequeño o inestable. Mezclar todos los clientes sin aislamiento aumenta el riesgo.
Otro error es no documentar el incidente. Sin datos de pico, PPS, rutas afectadas, paquetes bloqueados y clientes impactados, cada ataque vuelve a parecer nuevo y el equipo pierde tiempo en diagnóstico repetido.
FAQ
¿Un DDoS puede afectar a clientes no atacados?
Sí, si satura un enlace, router, firewall o camino compartido.
¿Por qué importa el PPS?
Porque los equipos pueden saturarse por paquetes antes que por Gbps.
¿Un firewall basta contra un gran DDoS?
No siempre; puede ser el punto de saturación.
¿Cómo evitar el efecto dominó?
Filtrar aguas arriba, segmentar caminos y entregar tráfico limpio con capacidad suficiente.
