El contexto es equilibradores de carga basados en la red. Sería bueno si alguien pudiera explicar cómo se generan las tormentas TCP ACK en la vida real y las estrategias prácticas de mitigación para ellas.
Editar: Aclaración sobre "estrategias de mitigación". La plataforma consta de servidores web nginx / balanceadores de carga que se ejecutan en Linux. Así que agradecería el cambio relevante para alternar (si existe) para frustrarlo.
Cuando un cliente y un servidor se conectan entre sí, conocen la conexión por sus direcciones IP de origen y dirección, y sus números de puerto (en el cliente y en el servidor). Hay dos números de secuencia para ambas direcciones del flujo de conexión; sus valores iniciales son elegidos al azar. Cada vez que una de las partes envía un paquete, ese paquete puede referirse a ambos números de secuencia: un paquete del cliente puede incluir información sobre el número de secuencia para el flujo cliente-servidor (por ejemplo, un "PUSH"). ") pero también información sobre el número de secuencia para el flujo de servidor a cliente (un" ACK ").
Si el atacante puede hacer que el cliente y el servidor no estén de acuerdo por un amplio margen en ambos números de secuencia, puede ocurrir una tormenta de ACK. Básicamente, el cliente envía un paquete al servidor con un valor de servidor a cliente que el servidor encuentra ridículamente fuera de lugar. El servidor responde con un paquete que dice: "Estimado cliente, está muy equivocado acerca del número de secuencia actual de servidor a cliente, por favor, tenga la amabilidad de modificar sus métodos". Sin embargo (ese es el punto ingenioso), ese paquete también incluirá un ACK del servidor que documenta la noción del servidor del número de secuencia actual de cliente a servidor ... que el cliente encontrará absurdamente válido. Esto le pedirá al cliente que responda con un paquete que diga "querido servidor, está muy equivocado acerca del número de secuencia actual de cliente a servidor, por favor, tenga la amabilidad de modificar sus métodos". Ese paquete también contendrá un ACK. Y el bucle continúa ...
La tormenta continúa hasta que uno de los paquetes ACK se pierde, terminando la partida de ping-pong. Sin embargo, se volverá a iniciar la próxima vez que el cliente o el servidor tengan algo que decir, porque aún están desincronizados.
Las tormentas ACK dependen de la capacidad de desincronizar el cliente y el servidor para los números de secuencia de ambos . Esto se puede hacer con habilidades semi-MitM: por ejemplo, el atacante puede observar los paquetes entre el cliente y el servidor, y también inyectar algunos paquetes falsos, pero no bloquear los paquetes existentes. Este es el modelo de "el atacante está en la misma LAN, y el conmutador es de hecho un concentrador (o ha sido degradado a un comportamiento similar a un concentrador después de haber sido enviado a la basura con paquetes de basura aleatorios del atacante)". Cuando el atacante ve una conexión del cliente al servidor, inmediatamente envía un paquete RST falso (como si el cliente hubiera cerrado la conexión) y luego un nuevo SYN falso supuestamente provenía del cliente, con los mismos números de puerto, pero con números de secuencia muy diferentes. .
Consulte esta presentación para obtener más información.
La defensa es relativamente fácil: cualquiera de los sistemas involucrados en una tormenta de ACK puede detectar que recibe y envía cantidades excesivas de paquetes de error para una conexión dada, y simplemente descartarlos. La tormenta de ACK puede continuar solo mientras ambos sistemas estén listos para responder un ACK para un ACK; En el primer paquete perdido, la tormenta cesa. Si se detecta una tormenta, entonces: 1. el sistema que la detecta puede detenerla al negarse a participar y 2. si la conexión es insalvable, se puede abandonar sin ceremonias.