☰

-m conntrack --ctstate NEW,ESTABLISHED 是否必要？

tag-icon • tag-icon linux iptables
-m conntrack --ctstate NEW,ESTABLISHED 是否必要？

我有这条规则，它允许在三个端口上进行连接：

iptables -A INPUT -p tcp -m multiport --dports 22,80,443 -j ACCEPT

然后在网上我看到的例子包括

-m conntrack --ctstate NEW,ESTABLISHED

然后我将当前规则更改为：

iptables -A INPUT -p tcp -m multiport --dports 22,80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

我已经在线阅读了有关连接状态的信息，但想知道 -m conntrack --ctstate NEW,ESTABLISHED 是否必要，因为它可以在不包含它的情况下完成其工作？

我还想知道为什么有些 iptables 会像这样丢弃 OUTPUT？

iptables -P OUTPUT DROP

我保持对 OUTPUT 保持 ACCEPT 状态，同时对 INPUT 和 FORWARD 进行 DROP 操作。

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

当我删除输出时，我无法获取更新，也无法从 curl 等下载内容。我也应该删除输出吗？您觉得呢？

答案1

这基本上在另一个答案中进行了解释，但我认为另一种解释仍然值得。

在您的设置中，您通常只为已知服务明确启用一些选定的端口，其余的端口则保留-P INPUT DROP。但是当计算机本身创建一些传出连接时，它会使用随机源端口。回复将以该端口为目的地。您是否有允许这些回复的明确规则？我想没有，因为您甚至事先不知道它将使用的源端口。因此回复将被丢弃，您的服务器将无法建立任何连接。例如，DNS 解析将中断。

当你使用连接跟踪器时，Linux 会观察每个你的传出数据包。它有特殊的状态表（可查看/proc/net/nf_conntrack）；它将记录添加到该表中，表明它期望地址和端口反转的数据包，就像回复中那样。当这样的数据包到达时，它会在数据包上设置一个标志，即它属于某个“已知”连接。然后，防火墙-m conntrack --ctstate ESTABLISHED使用该标志，它将匹配任何这些“已知”数据包。这样，您就可以精确地匹配对传出数据包的回复，甚至不需要事先知道它们是什么，但需要保持状态。

是RELATED一个相关概念（双关语）；有些协议不仅响应前一个连接，还可能创建全新的连接，最好也启用它。此类协议的示例是 FTP 和 SIP。如果只使用ESTABLISHED，这些新连接将被拒绝。但 Linux 有帮手为其连接跟踪器，它会更深入地检查第一个连接并从中推断出其他连接的属性；然后助手可能会将其他预期记录安装到状态表中，并设置另一个与--ctstate RELATED此类连接的数据包实际出现时间相对应的标志。因此RELATED基本上允许那些棘手的协议工作。

至于删除OUTPUT，是为了防止机器出现故障。通过-P OUTPUT DROP一些明确的允许规则，您可以建立此服务器可以实际连接的严格策略，这可能有利于安全性。您可能只想启用 DNS 服务器、时间同步服务器、一些用于更新的存储库、监控、备份服务器和其他一些服务器。现在，例如，如果服务器被入侵并感染了某些僵尸网络代理，则该代理将无法连接到其控制服务器（除非它获得 root 权限并消除障碍，但情况并非总是如此）。

即使您不想禁止整个OUTPUT，您的服务器也可能不能直接发送任何邮件，因此值得禁止它：-A OUTPUT -p tcp --dport 25 -j REJECT。这不会禁止它通过典型的 SMTP 身份验证服务发送邮件，因为它经常使用端口 587 或 465；如果不是这种情况，您也可以随时在上面添加另一条规则，允许将数据包发送到智能主机的端口 25。这样，至少它不会发送垃圾邮件（那么容易）。

答案2

简化的Linux netfilter防火墙“iptables”可以在两种模式下运行。

  1. 模式一是作为简单数据包过滤器。

这意味着您按照特定顺序创建一组规则，并根据完整规则库检查每个数据包，一个接一个地检查规则，直到触发提供决定性匹配的规则并确定该单个数据包的命运。

根据您的配置，这可能会导致数据包需要遍历数十条或更多规则，直到被允许或拒绝。

一旦数据包到达链中的最后一条规则，而其命运仍未确定，则将应用链的策略。 （在大多数防火墙配置中，这种情况永远不会发生，因为通常会设置明确的防火墙规则来接受/拒绝/丢弃所有与先前规则不匹配的流量，而不是依赖于策略。）

  1. 模式二是状态防火墙。

在状态防火墙中連接被跟踪。这需要加载一些额外的内核模块，然后 Linux 内核将（在内存中）保存一个连接状态查找表。

假设对于大多数系统来说，大多数流量、大多数数据包都属于一个现存的联系。

在状态防火墙中，大多数数据包只需进行一次检查，而不是检查整个防火墙规则库：如果数据包属于现有连接，则允许该数据包。
完成。
无需进行其他检查。

因此，在状态防火墙中，第一条规则是这样的

 # iptables-save
 -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
 ...

只有不属于现有连接的数据包才需要进一步评估。随后的规则将确定该数据包是否属于应允许的连接。

第一条规则：

 iptables -A INPUT -p tcp -m multiport --dports 22,80,443 -j ACCEPT

不涉及连接状态，并且是适用于简单数据包过滤器和状态防火墙的语法。它完全忽略任何潜在的连接状态信息，并简单地允许任何和所有数据包到达 TCP 端口 22、80 和 443。

第二条规则：

 iptables -A INPUT -p tcp -m multiport --dports 22,80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

仅对启用了连接跟踪的状态防火墙有效。

在状态防火墙中，两条规则通常具有相同的最终结果，即到达端口 22、80 或 443 的数据包被接受，并且防火墙将允许建立连接。

但是第二条规则更为精确，只允许具有特定连接状态的数据包，而例如状态为“INVALID”或其他状态的数据包仍将被拒绝。

--ctstate 的状态：

无效 该数据包与没有已知连接相关。

NEW 该数据包已启动新的连接或与尚未在两个方向上见过数据包的连接相关联。

已建立 该数据包与已在两个方向上看到数据包的连接相关联。

相关数据包正在启动新连接，但与现有连接相关，例如 FTP 数据传输或 ICMP 错误。

未跟踪(UNTRACKED)
数据包根本未被跟踪，如果您在原始表中使用 -j CT --notrack 明确取消跟踪它，就会发生这种情况。

SNAT
虚拟状态，如果原始源地址与答复目的地不同则匹配。

DNAT
虚拟状态，如果原始目的地与答复源不同则匹配。

相关内容