是否对 iptables 中的所有来源接受 RELATED,ESTABLISHED 被认为“过于开放”？

Question

我经常看到这条规则被-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT应用。虽然我不是专家，但那条特别的线路与我有关。很明显，该规则允许所有流量，唯一的例外是连接必须已建立或与已建立的连接相关。

设想

• 我将允许22从子网中的服务器 LAN192.168.0.0/16或其他任何地方连接到默认 SSH 端口。
• SuperInsecureApp®在 port 上公开一些东西1337，我将其添加到我的INPUT链中。
• 我已经添加了conntrack接受ESTABLISHED和RELATED来自所有来源的规则
• 连锁政策是 DROP

所以基本上该配置应该只允许来自 LAN 的 SSH 连接，同时允许来自世界的端口 1337 上的入站流量。

这是我的困惑绽放的地方。是否会conntrack以任何方式暴露一个安全漏洞，允许一个人在 1337 上建立连接（因为它是世界开放的），然后利用该连接访问 SSH 端口（或任何其他端口）？

Answer 1

我不会认为 ESTABLISHED 和 RELATED 流量太开放。您可以省略 RELATED，但绝对应该允许 ESTABLISHED。这两个流量类别都使用 conntrack 状态。

ESTABLISHED 连接已被另一条规则验证。这使得实现单向规则变得更加简单。这仅允许您在同一端口上继续事务。

RELATED 连接也由另一条规则验证。它们不适用于很多协议。它们再次使配置规则变得更加简单。它们还确保它们适用的连接顺序正确。这实际上使您的规则更加安全。虽然这可能使连接到不同的端口成为可能，但该端口应该只是相关进程的一部分，如 FTP 数据连接。允许哪些端口由协议特定的 conntrack 模块控制。

通过允许 ESTABLISHED 和 RELATED 连接，您可以专注于希望防火墙接受哪些新连接。它还避免了旨在允许返回流量但允许新连接的破坏规则。

鉴于您已将端口 1337 上的程序归类为不安全，它应该使用专用的非 root 用户 ID 启动。如果有人设法破解应用程序并获得增强的访问权限，这将限制他们可能造成的损害。

极不可能使用端口 1337 上的连接远程访问端口 22，但有可能使用端口 1337 上的连接代理到端口 22 的连接。

您可能希望确保 SSH 得到深度保护：

• 除了防火墙限制之外，还可以使用 hosts.allow 来限制访问。
• 防止 root 访问，或至少要求使用密钥并限制其在 authorized_keys 文件中的访问。
• 审核登录失败。日志扫描器可以定期向您发送异常活动报告。
• 考虑使用像 fail2ban 这样的工具在重复访问失败时自动阻止访问。

Answer 2

ESTABLISHED 和 RELATED 是“有状态”数据包过滤的特征，其中过滤不仅取决于静态规则集，还取决于考虑数据包的上下文。您需要 ESTABLISHED 才能允许连接工作，并且您需要 RELATED 以获取相关的 ICMP 消息。与静态“无状态”规则相比，有状态过滤允许更精确地过滤。

让我们先看看 ESTABLISHED。例如，考虑端口 22 上的 TCP。发起方（客户端）发送SYN到serverIPaddr:22. 服务器返回SYN+ACK给客户端。现在轮到客户端发送ACK. 服务器上的过滤规则应该是什么样子的，以便只ACK接受“匹配” ？一般的无状态规则看起来像

-A INPUT --proto tcp --port 22 -j ACCEPT

这比相应的有状态规则更自由。无状态规则允许任意 TCP 段，例如ACK或FIN无需先建立连接。端口扫描器可以利用这种行为进行操作系统指纹识别。

现在让我们来看看 RELATED。这用于 ICMP 消息，主要是错误消息。例如，如果从服务器到客户端的数据包被丢弃，则会向服务器发送一条错误消息。此错误消息与先前建立的连接“相关”。如果没有 RELATED 规则，人们要么需要允许传入的错误消息（没有上下文），要么按照许多站点的习惯，完全丢弃 ICMP 并等待传输层超时。（请注意，这对 IPv6 来说是个坏主意；ICMPv6 对 IPv6 的作用比对 IP 传统的 ICMP 更重要。）