python - español - scapy sniff
Paquete RST TCP no deseado con Scapy (3)
El artículo del blog citado en otras respuestas no es del todo correcto. No solo no está completando el protocolo de enlace de tres vías, sino que la pila de IP del kernel no tiene idea de que está ocurriendo una conexión. Cuando recibe el SYN-ACK , envía un RST-ACK porque es inesperado. Recibir primero o último realmente no entra en ello. La pila que recibe el SYN-ACK es el problema.
El uso de IPTables para eliminar paquetes RST salientes es un enfoque común y válido, pero a veces es necesario enviar un RST desde Scapy. Un enfoque más complejo, pero muy práctico, es ir más bajo, generar y responder a ARP con un MAC diferente al del host. Esto le permite tener la capacidad de enviar y recibir cualquier cosa sin ninguna interferencia del host.
Claramente esto es más esfuerzo. Personalmente, solo tomo este enfoque (a diferencia del enfoque de reducción de RST ) cuando en realidad necesito enviar un RST .
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é un OS X Lion y 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 la razón.
¿Alguien podría decirme cuál podría ser la razón? ¿Y cómo evitar este problema?
Gracias.
El artículo que citaste deja esto bastante claro ...
Como no está completando el protocolo completo de TCP, su sistema operativo podría intentar tomar el control y comenzar a enviar paquetes RST (restablecer), para evitar esto podemos usar iptables:
iptables -A OUTPUT -p tcp --tcp-flags RST RST -s 192.168.1.20 -j DROP
Esencialmente, el problema es que scapy ejecuta en el espacio de usuario, y el kernel de Linux recibirá primero el SYN-ACK. El kernel 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 su kernel contra el envío de un paquete RST.
No tengo una respuesta que no sea iptables, pero se puede solucionar el problema de reinicio. En lugar de tratar de filtrar el restablecimiento saliente en la tabla de filtros, filtre todos los paquetes entrantes del destino en la tabla sin procesar. Esto evita que los paquetes devueltos desde el destino 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 usar el mismo puerto de origen para mi tráfico; siéntase libre de usar su propio iptables-fu para identificar los paquetes de devolución de su objetivo.