Paquete TCP RST no deseado con Scapy

Question

Para entender cómo funciona TCP, traté de forjar mi propio TCP SYN/SYN-ACK/ACK (basado en el tutorial: http://www.thice.nl/creating-ack-get-packets-with-scapy/).

El problema es que cada vez que mi computadora recibe el SYN-ACK del servidor, genera un paquete RST que detiene el proceso de conexión.

Probé con un OS X Lion y en un Ubuntu 10.10 Maverick Meerkat, ambos restablecieron la conexión. Encontré esto: http://lkml.indiana.edu/hypermail/linux/net/0404.2/0021.html, no sé si es el motivo.

¿Alguien podría decirme cuál podría ser el motivo? ¿Y cómo evitar este problema?

Gracias.

Answer 1

El artículo que ha citado hace que esta bastante claro ...

Puesto que no se está completando el TCP apretón de manos completo su sistema operativo podría tratar de tomar el control y puede comenzar a enviar paquetes RST (reset), para evitar esto podemos usar iptables:

iptables -A OUTPUT -p tcp --tcp-flags RST RST -s 192.168.1.20 -j DROP 

en esencia, el problema es que scapy carreras en el espacio de usuario y el kernel Linux recibirán el SYN-ACK primero. El núcleo enviará un RST porque no tendrá un socket abierto en el número de puerto en cuestión, antes de que tenga la oportunidad de hacer algo con scapy.

La solución (como lo menciona el blog) es proteger el kernel de su firewall para que no envíe un paquete RST.

Answer 2

No tengo una respuesta que no sea de iptables, pero se puede solucionar el problema de restablecimiento. En lugar de intentar filtrar el reinicio saliente en la tabla de filtro, en su lugar, filtre todos los paquetes entrantes del destino en la tabla sin formato. Esto evita que los paquetes de devolución del objetivo incluso sean procesados ​​por el kernel, aunque Scapy todavía los ve. Utilicé la siguiente sintaxis:

iptables -t raw -A PREROUTING -p tcp --dport <source port I use for scapy traffic> -j DROP 

Esta solución me obliga a utilizar el mismo puerto de origen para mi tráfico; Siéntete libre de usar tu propio iptables-fu para identificar los paquetes de devolución de tu objetivo.

Answer 3

El artículo del blog citado en otras respuestas no es del todo correcto. No es solo que no estés completando el enlace de tres vías, sino que la pila de IP del núcleo no tiene idea de que hay una conexión. Cuando recibe el SYN-ACK, envía un RST-ACK porque es inesperado. Recibir primero o el último realmente no entra en él. La pila recibiendo el SYN-ACK es el problema.

El uso de IPTables para colocar los paquetes RST es un enfoque común y válido, pero a veces es necesario enviar un RST de Scapy. Un enfoque más involucrado pero muy viable es ir más abajo, generando y respondiendo al ARP con un MAC que es diferente al del anfitrión. Esto le permite tener la capacidad de enviar y recibir cualquier cosa sin interferencia del host.

Claramente esto es más esfuerzo. Personalmente, solo tomo este enfoque (a diferencia del enfoque de caída RST) cuando realmente necesito enviar un RST.