32

TCPがどのように機能するかを理解するために、私は自分のTCP SYN / SYN-ACK / ACKを偽造しようとしました（チュートリアルに基づく：http ：//www.thice.nl/creating-ack-get-packets-with-scapy/ ）。

問題は、コンピューターがサーバーからSYN-ACKを受信するたびに、接続プロセスを停止するRSTパケットを生成することです。

OSXLionとUbuntu10.10Maverick Meerkatで試してみましたが、どちらも接続をリセットしました。私はこれを見つけました：http：//lkml.indiana.edu/hypermail/linux/net/0404.2/0021.html、それが理由かどうかはわかりません。

誰かが理由を教えてもらえますか？そして、この問題を回避する方法は？

ありがとうございました。

4

3 に答える 3

34

あなたが引用した記事はこれをかなり明確にしています...

完全な 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 パケットを送信しないようにファイアウォールを設定することです。

于 2012-02-06T02:17:08.617 に答える
6

他の回答で引用されているブログ記事は完全に正しいわけではありません。スリーウェイ ハンドシェイクが完了していないだけでなく、カーネルの IP スタックが接続が発生していることを認識していないということです。を受信するSYN-ACKと、想定外なので を送信しますRST-ACK。最初または最後に受け取ることは、実際には入りません。を受け取るスタックがSYN-ACK問題です。

IPTables を使用してアウトバウンドRSTパケットをドロップすることは、一般的で有効なアプローチですが、Scapy から を送信する必要がある場合もありますRST。より複雑ではありますが非常に実行可能なアプローチは、ホストのものとは異なる MAC で ARP を生成して応答することです。これにより、ホストからの干渉なしに何でも送受信できるようになります。

明らかに、これはより多くの努力です。RST個人的には、実際に自分自身を送信する必要がある場合にのみ、このアプローチを (ドロップ アプローチとは対照的に) 使用しますRST。

于 2016-05-13T06:12:09.820 に答える
6

iptables以外の回答はありませんが、リセットの問題を修正できます。フィルタ テーブルで発信リセットをフィルタリングしようとする代わりに、raw テーブルでターゲットからのすべての着信パケットをフィルタリングします。これにより、ターゲットからの戻りパケットがカーネルによって処理されることさえ防止されますが、scapy は引き続きパケットを認識します。次の構文を使用しました。

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

このソリューションでは、トラフィックに同じ送信元ポートを使用する必要があります。独自の iptables-fu を自由に使用して、ターゲットの戻りパケットを識別してください。

于 2013-12-17T21:30:16.710 に答える