☰

iptables、ip6tables、nftables 等是否应始终允许 RELATED 连接？

tag-icon • tag-icon linux iptables firewall nftables
iptables、ip6tables、nftables 等是否应始终允许 RELATED 连接？

在所有配置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 连接，那么这会产生某种安全威胁吗？

答案1

数据包的 RELATED 状态不仅仅用于帮手。以下是iptables-扩展' 男人：

RELATED

数据包正在启动新连接， 但是联系使用现有连接，例如 FTP 数据传输或 ICMP 错误。

例如，当应用程序将 UDP 数据包发送到远程目标 192.0.2.2:4444 并且该远程系统没有服务在那里监听时，它将返回 ICMP 目标端口不可达，因为没有与 UDP 等同的 TCP RST。由于这是另一种协议，它不能成为同一 conntrack 条目的一部分（该协议是 5-uple 的一部分）。此传入 ICMP 数据包的内容仍将由连接跟踪并与现有的 UDP conntrack 条目进行匹配。将创建一个新条目，但其状态为 RELATED 而不是 NEW。如果您的本地防火墙丢弃此类数据包，您的应用程序将不得不等待，直到它选择超时，而不是立即收到有关问题的警告。

我认为不可能更多地了解触发相关流（这里将是单个数据包）的初始流。它之所以存在，只是因为涉及了其他允许的流。虽然它符合 RELATED 规则（如果有的话，会增加它的计数器），但conntrack -E expect它可以在帮助程序发生之前显示预期的流，因为它是动态生成的，所以不会有它。

现在来看看 ALG 助手（通常作为内核模块运行，但那是不是强制性的)，你确实可以选择谨慎一点。如果你不想盲目接受它们创建的 RELATED 流，那就限制如何使用它们吧。

有一些主要贡献者创建了一个关于这个主题的优秀博客网络过滤器：安全使用 iptables 和连接跟踪助手，其中讲述了危险：

该系统依赖于解析来自用户或服务器的数据。因此，它很容易受到攻击，使用连接跟踪助手时必须格外小心。

因此，您应该考虑调整设置（如本博客所述），以限制助手仅用于预期和允许的连接。请注意，自内核 4.7 以来，自动助手激活已默认禁用，除非发行版或特定配置将其重新启用。

为nftables例如，你可以检查我的答案到此相关问答，解释了如何限制一侧的辅助激活，以及如何限制使用有关的当使用带有新显式（“安全”）方法的 FTP 帮助器时，另一端的流程。

相关内容