如何避免在 nftables 中允許臨時埠範圍規則

我正在使用帶有 dnsjava 客戶端庫的 Ubuntu 20.04 作業系統來查詢 DNS 伺服器。

我在這台機器上有 nftables 規則，它阻止埠上的所有流量，除了臨時埠範圍 32768-61000 將被 dnsjava 用來從 DNS 伺服器獲取結果。

table inet tb {

       chain input {
               type filter hook input priority 0; policy drop;
               tcp dport 32768-61000 accept
               udp dport 32768-61000 accept
               ....
               ....
        }  
       chain forward {
               ....
        }
       chain output {
              .....
       }
}

看起來允許 32768-61000 範圍可能是安全漏洞。但是完全阻止這個埠範圍會增加 dns 解析的延遲和由於超時而導致的許多故障。

我們有沒有辦法避免這條規則允許 nftables 中的埠範圍？是否有任何 nftable 功能可以用來避免這種情況而不影響 dns 解析延遲？

使用狀態防火牆規則。有狀態規則的連接狀態由 Netfilter 的conntrack子系統處理，並且可以從nftables中使用。

目標是允許（選擇）傳出數據包，讓它們被conntrack （自動）跟踪，並允許作為傳入數據包返回，只有那些是最初在傳出部分創建的流的一部分。一旦規則引用它（任何表達式） ， conntrack就會自動工作。ct此外，即使沒有規則，它也應該在載入後立即在初始（主機）網路命名空間中自動工作。

由於 OP 沒有提供完整的規則集，我只是替換規則並且不嘗試創建完整的規則集（例如：允許lo介面上的數據包很常見，或者輸出鏈也可能有丟棄策略） . 不嘗試簡化（例如最近的nftables /kernel 允許 TCP 和 UDP 的單一規則）。

這變成：

table inet tb {

       chain input {
               type filter hook input priority 0; policy drop;
               ct state established,related accept
               ....
               ....
        }  
       chain forward {
               ....
        }
       chain output {
              .....
              ct state established accept
              udp dport 53 accept
              tcp dport 53 accept
       }
}

規則集中不再使用臨時埠（甚至不需要指定源埠 53）。將自動接受作為對埠 53 的傳出數據包的回复的傳入數據包。該related部分還允許相關的數據包，例如目的地不可達時的 ICMP 錯誤，也被接受（從而防止在這種情況下超時）。

現在還可以使用這些命令跟踪流狀態（在涉及容器的情況下與應用程序在相同的網路命名空間中執行）：

對於列表：

conntrack -L

對於（準實時）事件：

conntrack -E

或更具體地說，例如使用這兩個命令（在兩個終端中執行）：

conntrack -E -p tcp --dport 53
conntrack -E -p udp --dport 53

當然，關於這一切還有更多。更多文件：

• 狀態防火牆
• 連接跟踪系統
• 匹配連接跟踪狀態元資訊

引用自：https://unix.stackexchange.com/questions/696802