如何避免允许nftable中的临时端口范围规则

Question

我使用Ubuntu20.04OS和dnsjava客户端库来查询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解析的延迟时间，以及由于超时而导致的许多失败。

我们是否可以避免这种允许在nftable中使用端口范围的规则？我们是否可以在不影响dns解析延迟的情况下使用nftable特性来避免这种情况？

Answer 1

使用有状态防火墙规则。有状态规则的连接状态由Netfilter的连接跟踪子系统处理，可以从nftable中使用。

其目标是允许(选择)传出数据包，让它们通过连接跟踪(自动)被跟踪，并允许返回为传入数据包，只有那些最初在传出部分中创建的流的一部分。连接轨迹一旦规则引用它(任何ct表达式)就会自动工作。此外，它应该在加载后立即在初始(主机)网络名称空间中自动工作，即使没有规则。

由于OP没有提供完整的规则集，所以我只是替换规则，而不是尝试创建一个完整的规则集(例如:允许lo接口上的数据包很常见，或者输出链也可能有一个丢弃策略)。不尝试简化(例如最近的nftable/内核允许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

当然还有更多关于这一切的事情。进一步文件：

• 状态防火墙
• 连接跟踪系统
• 匹配连接跟踪有状态方法