无状态防火墙的固有缺陷?

网络工程 ip tcp 防火墙 acl aws
2022-03-03 09:47:31

我只是一个涉足在 AWS 中建立网络的低级(软件)开发人员,并且无法理解无状态防火墙或网络 ACL 的基础知识,因为它们也被称为。简而言之,允许 TCP 响应的规则似乎非常宽松,导致安全漏洞大到足以使端口过滤通常无效?

假设我的网络中有两个子网 A 和 B。遵循最小特权原则,我希望将子网之间的流量限制在绝对必要的范围内,这是通过子网之间的无状态防火墙(也称为 AWS VPC 中的 NACL)实现的(作为顶部的额外安全层有状态的安全组)。我知道 A 中的主机必须能够通过 TCP 端口 9000 连接到 B 中的主机。

这意味着需要允许端口 9000 上从 A 到 B 的 TCP 流量。为了让 B 中的主机做出响应,我们还需要在所有 >=1024 的端口上允许从 B 到 A 的流量(因为我知道网络中的设备使用 1024 及以上的临时端口)。

这两个规则现在允许 B 中的任何主机在任何 >=1024 的端口上连接到 A,只要为 TCP 请求选择的临时响应端口是 9000(允许 A 响应)。给定足够的连接尝试(即垃圾邮件连接,直到操作系统随机选择临时端口 9000)或控制较低级别的 TCP 功能,B 中的主机最终将能够在任何 >=1024 的端口上向 A 发出任何 TCP 请求。

我错过了什么吗?允许单个端口上的连接在一个方向上的返回流量导致几乎任何端口上的相反方向的连接都可能产生这种有点灾难性的后果,这似乎几乎使 ACL 中的端口过滤器的整个点无效。

我希望有更多专业知识的人在这里提供一些见解!谢谢。

2个回答

路由在设计上是无状态的——每个数据包都代表它自己进行路由,而不知道以前的流量。(在NAT 路由中可能会看到一个例外,它是有状态的(主要是),依赖于连接会话的概念。NAT 是不属于原始 TCP/IP 概念的一部分。)

ACL是无状态的数据包过滤规则。它们通常与路由无关,但通常应用于路由器(或交换机)。您可以将 ACL 用于防火墙(在某种程度上),但它们是无状态的。ACL 通常使用三元内容寻址存储器(TCAM) 实现,该存储器允许在单个存储器周期中进行查找。

如果您实施无状态防火墙,则必须为两个方向创建策略- 与始终隐含反向方向的有状态防火墙相反。对于客户端-服务器区域边界,例如 192.168.0.0/24 用于客户端(使用临时端口)和 192.168.10.0/24 用于 HTTP 服务器(使用 TCP 端口 80),您将使用 ACL 规则

permit tcp 192.168.0.0 0.0.0.255 gt 1023 192.168.10.0 0.0.0.255 eq 80朝向客户端子网和
permit tcp 192.168.10.0 0.0.0.255 eq 80 192.168.0.0 0.0.0.255 gt 1023朝向服务器子网

您是对的,这不会阻止服务器使用其 TCP 端口 80 来启动与在客户端端口 >=1024 上运行的服务的连接。通常,在这样的端口上没有运行服务,但如果这是一个问题,那么您需要使用状态防火墙。

此外,您指出的“安全漏洞”似乎是指第三个“攻击”主机通过“意外”命中使用的客户端端口连接到已经建立的从客户端到其他地方的连接。

然而,这是不可能的,因为特定传输协议中的每个套接字连接都由sourceIP:sourcePort:destinationIP:destinationPort元组唯一标识。使用与套接字连接不同的源 IP 地址的“攻击”主机不会使其流量成为该连接的一部分。此外,通信中使用的端口会自动侦听新连接。

无状态防火墙是除有状态防火墙之外的旧传统防火墙

对于传入和反向流量访问列表的无状态防火墙需要配置与出站相同,并且需要配置反向流量访问列表以成功完成会话..

无状态防火墙的部署和配置很复杂。由于庞大的 qccess-list 配置策略,它会在 CPU 利用率上产生开销,从而导致 .