Protección de DDoS para un VPS: capacidad, reglas de aplicación y recuperación

Una ruta de red saturada, una tabla de conexiones agotada y una consulta costosa de aplicación requieren controles diferentes. Reúna contadores de red, tasas de solicitudes y tiempos de respuesta. El primer síntoma es evidencia para investigar, no prueba de un único tipo de ataque.

La velocidad del puerto del servidor, la asignación de transferencia por período y la capacidad de mitigación son especificaciones diferentes. Los valores de mitigación del catálogo preparado van de 10 a 400 Gbps según el plan. Ninguno cambia el tiempo de CPU necesario para responder a una solicitud costosa.

Umbra 1 indica un puerto de servidor de 1 Gbps, 1 TB de transferencia mensual y una especificación de mitigación de 10 Gbps. La primera describe la conexión, la segunda una asignación por periodo y la tercera una envolvente de filtrado propuesta. Ninguna significa que la aplicación pueda responder a 10 Gbps de solicitudes útiles. El comportamiento del filtrado y el tráfico permitido deben validarse en la red de lanzamiento.

El diseño preparado detecta anomalías de tráfico, desvía los ataques al filtrado y devuelve el tráfico permitido. Su objetivo de activación previsto es inferior a 60 segundos, pero el enrutamiento en vivo y los controles en el origen deben probarse antes de que eso sea una promesa. Pregunte qué ocurre más allá del margen incluido y cómo se restaura el tráfico legítimo.

Almacena en caché las respuestas adecuadas, limita la tasa de las rutas costosas y protege el acceso administrativo. Un WAF o proxy inverso debe configurarse y mantenerse como una capa separada. Restringe el acceso web al origen a fuentes de proxy de confianza si eso forma parte del diseño, sin cerrar la ruta de recuperación.

Asigna quién puede cambiar reglas, qué evidencia pertenece a un ticket y cómo los usuarios conocen el estado. Prueba la entrega de alertas y la ruta de reemplazo. Una copia de seguridad funcional y un registro de incidentes sobrio son útiles incluso cuando el evento resulta ser un fallo de la aplicación.

Los incidentes L3/L4 pueden implicar amplificación UDP mediante DNS, NTP o memcached, o inundaciones TCP SYN que presionan el estado de conexión. Los incidentes L7 apuntan al trabajo de la aplicación, como búsquedas repetidas o intentos de inicio de sesión. Compara bits por segundo, paquetes por segundo y solicitudes por segundo por separado. Un filtro de borde, un control de conexiones y una regla de aplicación resuelven partes distintas del problema.

• Cierra o restringe los servicios UDP públicos innecesarios y mantén el acceso al origen de forma deliberada.
• Un diseño anycast geográficamente distribuido necesita retirada de rutas, gestión de estado y pruebas de conmutación por error; no se establece con una cifra de capacidad de mitigación.

Un desafío, CAPTCHA o puerta de prueba de trabajo puede añadir fricción a las solicitudes sospechosas. También puede afectar a visitantes legítimos, clientes automatizados y accesibilidad, así que aplícalo a endpoints adecuados y mide el resultado. Una respuesta lenta o tarpit también ocupa recursos; prueba el coste antes de asumir que es más barato que rechazar la solicitud.

• Mantén una vía de recuperación o soporte accesible cuando un desafío impida la entrada.
• Los límites de solicitudes, el almacenamiento en caché y las correcciones de aplicaciones siguen siendo útiles incluso cuando se habilita un desafío.