すべてのポートですべての発信RSTと着信RSTをドロップしようとしています。私はDebianlinuxを使用しています。インターネットにリストされているコマンドの可能なすべての組み合わせを試しましたが、何も機能しないようです。
たとえば、私は試しました：
iptables -A OUTPUT -o eth0 -p tcp --tcp-flags RST RST -j DROP
iptables -A OUTPUT -p tcp --tcp-flags RST RST -j DROP
iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state RELATED,ESTABLISHED -j DROP
iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP
それでも、カーネルによってRSTパケットが送信され、RSTパケットも受信しているのがわかります。この問題を解決してみてください
インバウンドRSTパケットをドロップする場合は、次のようにします。
iptables -I INPUT -p tcp --tcp-flags ALL RST,ACK -j DROP
iptables -I INPUT -p tcp --tcp-flags ALL RST -j DROP
アウトバウンドRSTパケットをドロップする場合は、次のようにします。
iptables -I OUTPUT -p tcp --tcp-flags ALL RST,ACK -j DROP
なぜRSTACKなのか？ RFCによると、SYNを含むTCPパケットへの応答は、そのシーケンス番号をACKする必要があります。したがって、ポートが閉じていることを示している場合でも、RSTACKで応答します。
なぜアウトバウンドRSTを気にするのですか？ Scapyなどのツールを使用してIPの動作を実験しようとしている場合は、ホストのIPスタックがRSTACKを返送しないようにする必要が頻繁にあります。または、Scapyに疑似スタックを実装し、MACを要求し、IPv6のARPまたはICMP NDに応答し、独自のIPアドレスをバインドすることもできます。これにより、ホストのスタックが応答しなくなります。明らかに、これは単にアウトバウンドRSTパケットをブロックするよりも多くの作業です。
うーん、これはホストマシンで実行しているため、入力チェーンや出力チェーンではなく、フォワードチェーンを経由している可能性があります。
これをデバッグするための秘訣は、iptables -L -vを使用することです。これは、このように大量のパケットを送信するコマンドを設定した場合に、各ルールに送信されるパケット数のカウントを表示します。
watch --interval 0.1 "nc remote.machine CLOSED_PORT"
どのルールがヒットしているかを把握できます。また、直交テーブル（さまざまな状況（たとえば、NAT）で使用されるルールチェーンのセット）があることにも注意する必要があります。NATテーブルを調べる価値があるかもしれません-仮想ホストは、独自のIPアドレスを持っているのではなく、ホストを介してNATを実行している可能性があるためです。
iptables -L -v -t nat
仮想ホストがどのIPアドレスを持っているかを知ることは有益です-これがネットワークのサブネットから切り離されている場合、これはおそらくNATされているでしょう。
リセットパケットでは、RSTフラグとACKフラグがアクティブになっています。したがって、正しいルールは次のとおりです。
iptables -I INPUT -p tcp --tcp-flags ALL RST,ACK -j DROP
それが役に立てば幸い：
echo 0 > /proc/sys/net/ipv4/tcp_rst_retries
echo 0 > /proc/sys/net/ipv4/tcp_rst_timeout