帶有 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

你引用的文章很清楚......

由於您沒有完成完整的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數據包。

Answer 2

我沒有非iptables的答案，但可以解決重置問題。 而不是嘗試過濾過濾表中的傳出重置，而是過濾掉原始表中目標的所有傳入數據包。 這可以防止來自目標的返回數據包甚至被內核處理，盡管scapy仍然可以看到它們。 我使用以下語法：

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

這個解決方案迫使我為我的流量使用相同的源端口; 隨意使用自己的iptables-fu來識別目標的返回數據包。

Answer 3

其他答案中引用的博客文章並不完全正確。 這不僅是因為你沒有完成三次握手，而是內核的IP堆棧不知道發生了連接。 當它收到SYN-ACK ，它發送一個RST-ACK因為它是意外的。 接收第一個或最后一個確實沒有進入它。 接收 SYN-ACK的堆棧是個問題。

使用IPTables丟棄出站RST數據包是一種常見且有效的方法，但有時您需要從Scapy發送RST 。 一個更復雜但非常可行的方法是降低，使用與主機不同的MAC生成和響應ARP。 這使您能夠在不受主機干擾的情況下發送和接收任何內容。

顯然，這是更多的努力。 就個人而言，當我真正需要自己發送RST時，我只采用這種方法（而不是RST丟棄方法）。

Answer 4

我在https://widu.tumblr.com/post/43624355124/suppressing-tcp-rst-on-raw-sockets中找到了沒有 IPTables 的解決方案。

要繞過這個問題，只需創建一個標准的 TCP 套接字作為服務器套接字並綁定到請求的端口。 不要接受（）。 只是端口上的 socket()、bind() 和 listen()。 這放寬了 kernel 並讓您進行 3 次握手。