TCPの仕組みを理解するために、チュートリアル：http://www.thice.nl/creating-ack-get-packets-with-scapy/に基づいてTCP SYN/SYN-ACK/ACKを偽造しようとしました。Scapyの不要なRST TCPパケット
私のコンピュータがサーバからSYN-ACKを受け取ると、接続プロセスを停止するRSTパケットが生成されるという問題があります。
私はOS X Lionを試しましたが、Ubuntu 10.10 Maverick Meerkatでは両方とも接続をリセットしました。私はこれを見つけた：http://lkml.indiana.edu/hypermail/linux/net/0404.2/0021.html、それは理由がわからない。
誰かが理由を教えてくれますか？そして、この問題を避ける方法は？
ありがとうございます。
あなたが引用した資料では、このかなり明確になり...
あなたは完全なTCPの制御を取るしようとする可能性があり、オペレーティングシステムのハンドシェイクが完了していないとRST（リセット）パケットの送信を開始することができますので、回避するためにこれは我々がiptablesのを使用することができます。
基本的に
iptables -A OUTPUT -p tcp --tcp-flags RST RST -s 192.168.1.20 -j DROP
、問題がscapyユーザ空間で実行され、Linuxカーネルは最初のSYN-ACKを受信することです。 scapyで何かする前に、カーネルは問題のポート番号でソケットを開いていないため、RSTを送信します。
解決策（ブログで言及されているように）は、カーネルがファイアウォールをかけてRSTパケットを送信しないようにすることです。
この便利な追加情報をありがとうございます。 – user1177093
あなたは一番歓迎です –
IPTablesのないソリューションはありますか？私は本当に私のマシン上のiptables設定を変更することはできません。それに加えて、自分の実装からRSTを送信したい（テスト用に独自のTCPフローを作成する） – KillianDS
私はiptables以外の回答はありませんが、リセットの問題を修正できます。フィルタテーブルの送信リセットをフィルタ処理するのではなく、代わりに未加工テーブルのすべての着信パケットをフィルタリングします。これにより、ターゲットからのリターンパケットがカーネルによって処理されることはありませんが、scapyはまだそれを見ています。私は次の構文を使用しました：
iptables -t raw -A PREROUTING -p tcp --dport <source port I use for scapy traffic> -j DROP
この解決策は私のトラフィックに同じソースポートを使用するよう強制します。独自のiptables-fuを使用して、ターゲットの戻りパケットを識別してください。
他の回答に引用されているブログ記事は完全ではありません。 3ウェイハンドシェイクを完了していないだけでなく、カーネルのIPスタックには接続が起こっているとは考えられません。 SYN-ACKを受信すると、予想外のため、RST-ACKを送信します。最初または最後の受信は本当にそれに入っていません。スタックがSYN-ACKを受信することが問題です。
IPTablesを使用してアウトバウンドRSTパケットをドロップすることは一般的で有効な方法ですが、ScapyからRSTを送信する必要があることがあります。より複雑で非常に実行可能なアプローチは、ホストとは異なるMACを使用してARPを生成し、応答することです。これにより、ホストからの干渉なしに何かを送受信できるようになります。
明らかに、これはより多くの労力です。個人的には、自分が実際にRSTを自分で送信する必要があるときにのみ、このアプローチを採用しています（RSTのアプローチを落とす）。
このコードスニペットは、この問題をより明確にしていると思います。 'ans = scapy.all。sr1（generate_tcp_syn_pkt（））; ack_pkt = generate_tcp_ack_pkt（ans）; scapy.all.send（ack_pkt） ' – diabloneo
OS Xのこの問題をどのように解決しましたか？ – user1505986