Inherent flaw in stateless firewalls?

Question

I am but a lowly (software) developer dabbling with setting up a network in AWS and am having trouble understanding the fundamentals of stateless firewalls, or Network ACLs as they're also referred to as. In short, rules meant to allow TCP responses seem to be very permissive, leading to security holes large enough to invalidate port filtering in general?

Say I have two subnets, A and B, in my network. Following the principle of Least Privilege, I am looking to limit traffic between the subnets to what is absolutely necessary, and this is implemented with a stateless firewall in between the subnets (aka NACLs in AWS VPCs) (as an extra layer of security on top of stateful Security Groups). I know that it is necessary for hosts in A to be able to connect to hosts in B on TCP port 9000.

That means TCP traffic from A to B on port 9000 needs to be allowed. In order for hosts in B to respond, we also need to allow traffic from B to A on all ports >=1024 (as I know devices in the network use ephemeral ports from 1024 and upwards).

These two rules now allow for any host in B to connect to A on on any port >=1024, as long as the ephemeral response port picked for the TCP request is 9000 (which allows for A to respond). Given enough connection attempts (i.e spamming connections until the OS randomly picks ephemeral port 9000) or control of the lower-level TCP functionality, a host in B will eventually be able to make any TCP request to A on any port >=1024.

Am I missing something? This somewhat catastrophic consequence of allowing return traffic for connections on a single port in one direction resulting in connections being possible in the opposite direction on almost any port seems like it almost invalidates the whole point of port filters in ACLs.

I would love some insight here from anyone with more expertise! Thanks.

Answer 1

Routing is stateless by design - each packet is routed on its own behalf, without knowledge of previous traffic. (An exception may be seen in NAT routing which is stateful (mostly), relying on a concept of connections or sessions. NAT is hack that isn't part of the original TCP/IP concept.)

ACLs are stateless packet filter rules. They don't usually relate to routing but are often applied on a router (or switch). You can use ACLs for firewalling (somewhat) with the limitation that they're stateless. ACLs are usually implemented using ternary content-addressable memory (TCAM) that allows a lookup in a single memory cycle.

If you implement a stateless firewall you have to create policies for both directions - in contrast to a stateful firewall where the reverse direction is always implied. For a client-server zone border between e.g. 192.168.0.0/24 for the clients (using ephemeral ports) and 192.168.10.0/24 for HTTP servers (using TCP port 80) you'd use ACL rules

permit tcp 192.168.0.0 0.0.0.255 gt 1023 192.168.10.0 0.0.0.255 eq 80 towards the client subnet and
permit tcp 192.168.10.0 0.0.0.255 eq 80 192.168.0.0 0.0.0.255 gt 1023 towards the server subnet

You're correct, this doesn't prevent a server using its TCP port 80 to initiate a connection to a service running on a client port >=1024. Usually, there's no service running on such a port, but if that is a problem then you need to use a stateful firewall.

Also, the "security flaw" you point out seems to be referring to a third 'attacking' host connecting in to an already established connections from the client to elsewhere by 'accidentally' hitting the used client port.

That however isn't possible since each socket connection in a specific transport protocol is uniquely identified by the sourceIP:sourcePort:destinationIP:destinationPort tuple. The 'attacking' host using a different source IP address than the socket connection is using does not make its traffic part of that connection. Additionally, a port used in a communication is automatically listening for new connections.