是否應該在 iptables、ip6tables、nftables 等中始終允許相關連接？

在配置 Linux 防火牆規則的所有範例中，我看到有必要允許狀態為 RELATED 的連接。

nftables（連結：https ://wiki.nftables.org/wiki-nftables/index.php/Simple_ruleset_for_a_workstation ）：

table ip filter {
    chain input {
         type filter hook input priority 0;

         # accept traffic originated from us
         ct state established,related accept

iptables：

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

到處都說這是 FTP 工作所必需的。但是現在FTP在現實生活中遇到的越來越少了。我不明白為什麼仍然需要這樣做。最近，我不允許遍歷具有 RELATED 狀態的數據包，並且所有系統都可以正常工作，但是可能我的案例還不夠指示性。

所以我有兩個問題：

1. 什麼時候真的需要允許這種連接？
2. 如果我總是允許 REALTED 連接，那麼這會造成某種安全威脅嗎？

數據包的 RELATED 狀態不僅與helpers一起使用。這是來自iptables-extensions的定義：

RELATED

數據包正在啟動新連接，但與現有連接相關聯，例如 FTP 數據傳輸或 ICMP 錯誤。

因此，例如，當應用程序將 UDP 數據包發送到遠端目標 192.0.2.2:4444 並且該遠端系統沒有在那裡偵聽的服務時，它將發回無法訪問的 ICMP 目標埠，因為沒有特定的等價物TCP RST 與 UDP。由於這是另一個協議，它不能是同一個 conntrack 條目的一部分（該協議是 5-uple 的一部分）。這個傳入的 ICMP 數據包的內容仍將由conntrack分析，並與現有的 UDP conntrack 條目進行匹配。將創建一個新條目，但狀態為 RELATED 而不是 NEW。如果您的本地防火牆丟棄了此類數據包，您的應用程序將不得不等到它選擇超時，而不是立即收到有關問題的警告。

對於這種情況，我認為不可能更多地了解觸發相關流（此處將是單個數據包）的初始流。只是它存在是因為涉及其他允許的流。雖然它匹配 RELATED 規則（如果有的話，會增加它的計數器）conntrack -E expect，它可以在助手發生之前顯示預期的流，但不會有它，因為它是動態生成的。

---

現在對於 ALG 助手（通常作為核心模組執行，但這不是強制性的），您確實可以選擇謹慎。如果您不想盲目接受他們創建的 RELATED 流，只需限制如何使用它們即可。

netfilter的一些主要貢獻者創建了一個關於這個主題的優秀部落格：安全使用 iptables 和連接跟踪助手，其中講述了危險：

該系統依賴於解析來自使用者或伺服器的數據。因此它很容易受到攻擊，在使用連接跟踪助手時必須非常小心。

因此，您應該考慮調整您的設置（如本部落格中所述）以限制助手僅用於預期和允許的連接。請注意，從核心 4.7 開始，預設情況下已經禁用了自動幫助程序啟動，除非發行版或特定配置將其重新啟用。

對於nftables範例，您可以查看我對這個相關 Q/A 的回答，其中解釋瞭如何在使用 FTP 助手時限制一側的助手啟動，以及如何限制另一側的相關流程的使用新的顯式（“安全”）方法。

引用自：https://serverfault.com/questions/1037091