使用Scapy捕获不需要的RST TCP包

Question

为了理解TCP是怎么工作的，我尝试自己制作TCP的SYN/SYN-ACK/ACK包（参考了这个教程：http://www.thice.nl/creating-ack-get-packets-with-scapy/）。

问题是，每当我的电脑收到服务器发来的SYN-ACK包时，它就会生成一个RST包，这个包会停止连接的过程。

我在OS X Lion和Ubuntu 10.10 Maverick Meerkat上都试过，结果都是重置了连接。我找到了一些信息：http://lkml.indiana.edu/hypermail/linux/net/0404.2/0021.html，但我不知道这是否是原因。

有没有人能告诉我可能是什么原因？以及如何避免这个问题？

谢谢。

Answer 1

其他回答中提到的博客文章并不完全正确。问题不仅仅在于你没有完成三次握手，而是内核的IP协议栈根本不知道有连接正在发生。当它收到时，会发送，因为这让它感到意外。收到的顺序其实并不重要，关键是接收的协议栈出了问题。

使用IPTables来丢弃发出的数据包是一种常见且有效的方法，但有时候你需要用Scapy发送。一种更复杂但可行的方法是深入底层，生成并响应ARP请求，使用一个与主机不同的MAC地址。这样，你就可以在没有主机干扰的情况下发送和接收任何数据。

显然，这样做需要更多的努力。就我个人而言，只有在我确实需要自己发送时，我才会选择这种方法，而不是简单地丢弃。

Answer 2

我没有非iptables的解决方案，但可以解决重置的问题。与其在过滤表中尝试过滤出去的重置包，不如在原始表中过滤所有来自目标的入站数据包。这样可以防止目标返回的数据包被内核处理，尽管scapy仍然能看到它们。我使用了以下语法：

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

这个解决方案确实让我必须为我的流量使用相同的源端口；你可以根据自己的iptables技巧来识别目标的返回数据包。

Answer 3

你引用的文章说得很清楚……

因为你没有完成完整的TCP握手，所以你的操作系统可能会试图控制这个过程，并开始发送RST（重置）数据包。为了避免这种情况，我们可以使用iptables：

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

其实，问题在于scapy是在用户空间运行的，而Linux内核会先收到SYN-ACK信号。内核会发送一个RST，因为它在相关的端口上没有打开套接字，这样你就没有机会用scapy做任何事情。

解决办法（就像博客提到的那样）是通过防火墙阻止内核发送RST数据包。