Trabajo en un servicio web que podría ser objetivo de un ataque de denegación de servicio. Hemos implementado algunas mitigaciones contra ataques de estilo "inundación SYN". Pero existen otros ataques "a nivel de aplicación" contra nuestro servicio, en los que un cliente malicioso o dañado podría indicar repetidamente al servicio web que realice tareas costosas.
Podemos identificar a estos clientes abusivos en la capa de aplicación, es decir, en los procesos de nuestro servidor. Una vez que nuestro proceso haya identificado una conexión de cliente abusiva, nos gustaría reducir nuestro nivel de servicio a ese cliente.
Un método ingenuo sería terminar la conexión TCP con close(2), shutdown(2)o similar. Pero luego el cliente puede volver a conectarse inmediatamente (hasta el límite de conexiones/segundo establecido para mitigar las inundaciones SYN), y esta reconexión es costosa para nosotros debido a los protocolos de enlace TLS y otros costos de configuración de la conexión. Estamos buscando una manera de detener la interacción del cliente con nuestro servicio por un tiempo, pero una terminación limpia de la conexión TCP no logra esto.
Sin embargo, si nuestro proceso pudiera terminar la conexión TCPimpuramente, el cliente abusivo se retrasaría algún tiempo antes de volver a conectarse, proporcionando así un período de "tranquilidad". Por "terminación sucia", me refiero a cerrar la conexión TCP (ambas mitades del full-duplex) en el lado del servidor, sin enviar ningún FINpaquete para notificar al cliente de la terminación y sin enviar más paquetes que hagan referencia a esa conexión. Esto retrasaría al cliente mientras considera que la conexión aún está en el ESTABLISHEDestado (que es de 13 a 30 minutos en Linux).
Sin embargo, no veo ninguna forma de que un proceso UNIX/Linux termine de manera impura una conexión TCP. close(2), shutdown(2)y similares parecen terminar limpiamente la conexión y no ofrecen opciones para una terminación no limpia.
¿Existe alguna opción en UNIX/Linux para la terminación inmediata y sucia de la conexión TCP, como mitigación de los ataques de DOS?
Respuesta1
Lo que deberías considerar es un firewall y fail2ban. iptablessigue siendo prácticamente estándar para las distribuciones de Linux y fail2banfuncionará con la mayoría de los servicios. Lo que querría hacer es configurar fail2banpara monitorear un archivo de registro específico usando un patrón de expresión regular específico para saber cuándo se está conectando uno de estos clientes "problemáticos", luego agregar fail2banautomáticamente la regla de firewall para descartar o rechazar la conexión. fail2ban es configurable sobre cómo dejar la regla del firewall para que puedas bloquear un cliente durante 5 minutos o 5 días, lo que realmente quieras.
También puedes utilizar un firewall de aplicaciones web (WAF) para este tipo de cosas.
En lo que respecta a un ataque DOS, dependiendo de cómo se realice, es posible que no tenga suerte con un firewall local y que tenga que acudir a su proveedor principal para detectar rutas o hosts de agujeros negros que se sabe que son problemáticos y causantes. interrupción importante del servicio. Parece que no se encuentra en este tipo de posición y simplemente tiene problemas potenciales en la capa de aplicación que solucionar, por lo que esto es excesivo.
Respuesta2
Una vez que nuestro proceso haya identificado una conexión de cliente abusiva, nos gustaría reducir nuestro nivel de servicio a ese cliente.
Como ya mencionó que existe un costo asociado para establecer una nueva conexión, le recomendaría que considere un enfoque alternativo al de terminar la conexión. Quizás pueda considerar limitar la velocidad de esa conexión a 1 byte por minuto o algo similar. Con este enfoque aún puedes mantener ocupados los recursos de un atacante a un costo mínimo de tu lado. Si tiene más tiempo y quiere ser creativo, redirija todas esas conexiones a un servidor en su entorno para que otros servidores no desperdicien su límite de archivos abiertos. Como mencionó Andrew, también puedes considerar usar fail2ban una vez que hayas confirmado que la conexión proviene del atacante y que es seguro prohibirla durante unas horas.