☰

私のiptablesログにいくつかのTCPリセットパケットが表示されるのはなぜですか？

tag-icon • tag-icon iptables tcp
私のiptablesログにいくつかのTCPリセットパケットが表示されるのはなぜですか？

私はDebian Jessieサーバーにいくつかの基本的なiptablesルールを追加することから始めました。私の目標は、セキュリティと学習の目的でネットワークトラフィックをフィルタリングして記録することです。 ICMPパケットを無視し、以下は私が使用するルールです。

# INPUT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -j REJECT --reject-with tcp-reset

# OUTPUT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A OUTPUT -m limit -j LOG --log-prefix "UNKNOWN_OUTGOING: " --log-level 5

ポリシーは、INPUTとOUTPUTの両方に対してACCEPTに設定されます。

ログには発信リストが頻繁に表示されます。迅速な回復時間パケットは通常ポート 80 に送信されます。ここで、SRC IPは私のサーバーに属し、ターゲットIPは他の人の活動が公開されないように部分的に編集されました。

Aug 14 11:48:37 reynholm kernel: [81795.100496] UNKNOWN_OUTGOING: IN= OUT=ifext SRC=89.238.65.123 DST=108.162.[edited] LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=3594 DPT=80 WINDOW=0 RES=0x00 RST URGP=0

原因が何であるかを理解できません。 SSH と MTA を除いて実行されるアプリケーションはありません。私の入力のせいですか？拒否するルール？しかし、これらのパケットを出力で処理しないでください。状態ルール？

以下は、パケットの1つとそれをトリガーしたように見える接続試行のキャプチャです。108.162.[edited]以前は、私のサーバー間でパケットは転送されませんでした。

11:48:37.860337 IP (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    108.162.[edited].80 > 89.238.65.123.3594: Flags [S.], cksum 0x79bb (correct), seq 79911989, ack 235561828, win 29200, options [mss 1460], length 0
        0x0000:  4500 002c 0000 4000 3c06 7342 6ca2 0000  E..,..@.<.sBl...
        0x0010:  59ee 417b 0050 0e0a 04c3 5c35 0e0a 6364  Y.A{.P....\5..cd
        0x0020:  6012 7210 79bb 0000 0204 05b4 0000       `.r.y.........
11:48:37.860408 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    89.238.65.123.3594 > 108.162.[edited].80: Flags [R], cksum 0x648e (correct), seq 235561828, win 0, length 0
        0x0000:  4500 0028 0000 4000 4006 6f46 59ee 417b  E..(..@[email protected]{
        0x0010:  6ca2 0000 0e0a 0050 0e0a 6364 0000 0000  l......P..cd....
        0x0020:  5004 0000 648e 0000                      P...d...

答え1

ルールで TCP RST パケットが生成されます。

-A INPUT -p tcp -j REJECT --reject-with tcp-reset

デフォルトポリシー（あなたの場合はACCEPT）は、チェーン内のどのルールとも一致しないパケットにのみ適用されます。パケットがREJECT宛先を持つ上記の規則と一致する場合、デフォルトポリシーは適用されず、ACCEPTの代わりに拒否されます（TCP RST生成）。

このTCP RSTはルールと一致しません。

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

これは、確立された他の接続とは無関係であり、ESTABLISHED接続の一部ではないためです。これはあなたの規則と競争を継続して実施します。

-A OUTPUT -m limit -j LOG --log-prefix "UNKNOWN_OUTGOING: " --log-level 5

そしてログに残ります。これらのRSTパケットが記録されたくない場合は、この規則を一致させないように調整するか、RSTパケットと一致するように古い規則を挿入して、パケットがここに到達する前にいくつかの処理を実行してください。

私が気づいたもう1つの点は、最初に記録したパケットがリモートネットワークサーバーのSYN / ACKパケットであることです。 。ポート80のリモートホスト。最初のSYNを送信していない場合は、接続が「ESTABLISHED」と一致しないと思いますが、SYNを送信した場合は、接続が「ESTABLISHED」と一致する必要があると思います。これにより、RSTが一致するルールが混乱する可能性があります。

答え2

@caseyの優れた回答拡張：その理由は、リモートからのパケットにSYNおよびACKフラグが設定されているためです。これは最初のパッケージには影響しません。 iptables は、リセットパケットが初期パケットに関連付けられているとは見なしません。これは明らかに言葉にならないからです。

次のツールを使用して効果を再現できますhping3。 SYN / ACKパケット送信を使用しますhping3 -c 1 --syn --ack 89.238.65.123。このパケットに対するサーバの応答はACKフラグを設定せず、接続されません。状態ルール（つまり、ping送信には関係ありません）。結果はログエントリをトリガします。

初期要求にACKフラグが設定されていない場合、そのような効果は発生しません。

着信不正なTCPパケットをフィルタリングして破棄してログメッセージを削除しました。

-I INPUT 3 -m state --state INVALID -j DROP

答え3

これはポートスキャンの開始の一部であるようです。~からリモートホストのtcp / 80。リモートホストはサービスtcp / 3594を調査し、システムは「いいえ。今すぐ離れてください（RST）」と正しく表示します。残念ながら、これはインターネットに接続されたシステムではかなり一般的な現象です。

これをインストールすると、fail2banホストが許可されていない方法でシステムに接続しようとする試みをブロックするのに非常に効果的です。しかし、注意することがあります。含まれている例外で構成するのは簡単ではありません。

関連情報