iptablesは、ポート80と443のトラフィックの一部をブロックするべきではないのにブロックしますか？
私が管理しているWebサーバーは、HTTPSトラフィックが明示的に許可されているにもかかわらず、宛先ポート443のIPv4アドレスからの奇妙なiptables拒否を示しています。ポート80も同じルールで許可されていますが、サイトはHTTPSのみであり、80はnginxによってすぐに443にリダイレクトされます。
事は：サイトを閲覧するworks。すべてのページをロードでき、すべてのリソースが正常に機能します。しかし、ここでは明らかに何かが間違っているため、ページのロードパフォーマンスが低下する可能性があります。
ポート443と80でそれぞれ/var/log/iptables_deny.logに記録されるエラーの例を次に示します。これらは、ログファイルのtail -fから判断して、個別に、またはバーストで発生する可能性があります。大部分はポート443用です。
iptables denied: IN=eth0 OUT= MAC=f2:3c:91:26:1e:1f:84:78:ac:0d:8f:41:08:00 SRC=(redacted IP) DST=(redacted IP) LEN=40 TOS=0x08 PREC=0x00 TTL=53 ID=61266 DF PROTO=TCP SPT=49264 DPT=443 WINDOW=0 RES=0x00 RST URGP=0
iptables denied: IN=eth0 OUT= MAC=f2:3c:91:26:1e:1f:84:78:ac:0d:8f:41:08:00 SRC=(redacted IP) DST=(redacted IP) LEN=40 TOS=0x00 PREC=0x00 TTL=115 ID=11186 DF PROTO=TCP SPT=58445 DPT=443 WINDOW=254 RES=0x00 ACK FIN URGP=0
iptables denied: IN=eth0 OUT= MAC=f2:3c:91:26:1e:1f:84:78:ac:0d:8f:41:08:00 SRC=(redacted IP) DST=(redacted IP) LEN=40 TOS=0x00 PREC=0x00 TTL=116 ID=16941 DF PROTO=TCP SPT=16278 DPT=80 WINDOW=255 RES=0x00 ACK FIN URGP=0
簡単に説明すると、拒否のパケットタイプは、少なくともACK、ACK FIN、ACK RST、ACK PSH、およびRSTである可能性があります。おそらく他の人ですが、彼らは私の目を引きませんでした。
以下に、iptables-nvLからの出力を示します。基本的なパターン（最初に関連して確立されたものをすべて許可し、後で80と443のすべての新しいトラフィックを許可する）は、私が読んだすべてに基づいて堅実である必要があります。 LOG＆DROPルールは、本来あるべきINPUTチェーンの最後のルールです。
Chain INPUT (policy ACCEPT 1 packets, 391 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
8893 770K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * (redacted IP) 0.0.0.0/0 ctstate NEW tcp dpt:22
0 0 ACCEPT tcp -- * * (redacted IP) 0.0.0.0/0 ctstate NEW tcp dpt:22
0 0 ACCEPT tcp -- * * (redacted IP) 0.0.0.0/0 ctstate NEW tcp dpt:22
0 0 ACCEPT tcp -- * * (redacted IP) 0.0.0.0/0 ctstate NEW tcp dpt:22
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
63 3840 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate NEW multiport dports 80,443
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:137
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:138
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:139
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:445
1 40 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 15/min burst 5 LOG flags 0 level 7 prefix "iptables denied: "
1 40 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 1 packets, 65 bytes)
pkts bytes target prot opt in out source destination
7311 19M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
実際の関連ルール（出力後に使用される場合）：
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp -m conntrack --ctstate NEW -m multiport --dports 80,443 -j ACCEPT
明らかなことは、これは概して悪意のあるトラフィックではないということです。いくつかの異なるIPアドレスからサイトを閲覧したところ、サイトは正常に読み込まれたように見えましたが、私のIPは、識別できるパターンもなく、ブラウザーにユーザーに表示されるエラー状態もなく、拒否ログに表示されました。
この背後にある可能性のあるアイデアはありますか？
RSTおよびACK、FINパケットは、TCP接続の最後尾の一部です。
私の理解では、iptablesの接続追跡エンジンは、セキュリティ上の理由から、状態テーブルエントリを削除するために非常に堅牢なアプローチを採用しています。接続の一方の端が閉じようとしているのを確認するとすぐに、（リクエストは、接続の終了を通知します。これは、接続の一方の端が接続がダウンしていると見なすためです）、その接続のトラフィックを許可していた状態テーブルエントリを削除します。
いくつかのother同様のファイアウォールもパスにあり、残りの整頓をブロックしている場合、これを行うのに長く待つことは間違いなく安全ではありません。 -RFCが指定するアップパケット。状態テーブルエントリの取得をそれらが表示されるまで遅らせると、テーブルに無効なエントリが一定期間残るリスクがあり、潜在的な脆弱性が発生する可能性があります。
しかし、RFCは、実行する必要のあるさらにいくつかの整理を指定しており、拒否されているのはそれらのパケットです。はい、これは、接続内のエンドポイントがより多くのメモリを使用し、完全なクローズダウンを確認して接続メモリをはるかに高速に解放できるのではなく、接続が期限切れになるのを待つことを意味します。ただし、セキュリティを強化するにはリソースが必要になることが多く、これはそのトレードオフの1つです。
これらのパケットが通過しないことによる害はないため、ログエントリは無視しても問題ありません。
編集：ログに表示したくない場合は、ログ行の前に処理します。例：
iptables -I INPUT 13 -p tcp -m conntrack --ctstate INVALID --tcp-flags ACK,FIN ACK,FIN -j DROP