TCP Flood: LetDown

Acaba de llegar a mis manos un paquete de herramientas llamadas "Complemento" de entre las cuales me ha llamado la atención la herramienta LetDown, basicamente por estar inspirada en el famoso post de Fyodor (desarrollador de nmap): "TCP Resource Exhaustion and Botched Disclosure" en el que intentaba dar su teoría sobre Sockstress y la nueva vulnerabilidad de TCP que esta herramienta explota.

Por lo que se dedujo de los posts intercambiados entre Fyodor y los descubridores de la vulnerabilidad, no parece ser que este LetDown sea idéntico que Sockstress, aunque sí que podría ser algo similar.

La sintaxis de la herramienta es sencilla:

Usage:

Usage:
letdown -d destination ip -p port [options]
Options:
-d destination ip address, target
-p destination port
-s source ip address
-x first source port (default 1025)
-y last source port (default 65535)
-i network interface
-t sleep time in microseconds (default 0)
-a max time in second for waiting responses
-f automagically set firewall rules for blocking
rst packet generated by the kernel
examples: -f iptables, -f blackhole (for freebsd)
-P payload file (see payloads directory...)

Los binarios se distribuyen en código fuente o en .deb ,por lo que resultan muy fáciles de instalar. Si no tienes una distribución basada en debian probablemente tendrás que instalar a mano (o con tu gestor de paquetes) las librerías libnet y su correspondiente paquete de headers si es que no lo tienes instalado.

De momento lo he probado para tumbar una máquina Windows y una Linux y no me ha funcionado, quiero investigar un poco un poco más a ver si es que algo no lo estoy haciendo bien.

Lo que sí que he hecho es capturar los paquetes que salen al lanzar la herramienta y efectivamente vemos esto:

11:44:11.885329 IP 192.168.1.21.1025 > 192.168.1.9.22: S 1:1(0) win 1024
11:44:11.885684 IP 192.168.1.9.22 > 192.168.1.21.1025: S 1683795610:1683795610(0) ack 2 win 5840
11:44:11.885730 IP 192.168.1.21.1025 > 192.168.1.9.22: R 2:2(0) win 0

Como podemos ver, tiene pinta de los ataques de Fyodor y Sockstress, manda un único paquete SYN, al que el host atacado responde con SYN/ACK, para que finalmente el host atacante responda haciendo un RESET de la conexión. Esto no parece tener mucho secreto, donde está la chicha es en el Payload de las conexiones.

Si consigo que funcione haré una ampliación del post y pondré que tal me ha funcionado y cual era "el truco".

¿Si a alguien se le ocurre alguna idea...?