Routers and Firewalls: Stateless Rules vs Stateful Rules

Routers, switches, and firewalls often come with some way of creating rules that flows through them, and perhaps to even manipulate that traffic somehow. These rules may be called firewall filters, security policies, access lists, or something else. Different vendors have different names for the concept, which is of course excellent. Always great to have to remember five words for the same thing!

Regardless of the name, there is a difference between a “stateful rule” and a “stateless rule”. This post is a super-quick description of the definition, just so you can follow along with my Beginners Guide to Junos Firewall Filters post. There are tons of resources online that go into much more detail about the difference between the two, and you should definitely have a Google search for a more thorough definition.

For the time being, the text below should be enough to get you started.

 

STATELESS FILTERS

There are two categories of filtering rule that you can create.

The first is a “stateless” filter. This is a set of rules that you generally apply to an interface, to control traffic coming in or going out of it.

In particular, the “stateless” part means that your network device looks at each packet or frame individually. These rules tend to match only on things in the header – in other words, they don’t look deep into the payload of the packet to see if the application is the same as what the TCP/UDP port claims it is. Nor do these rules keep track of flows, or look for any known threats or attacks in the packet, as part of a wider flow.

Most routers offer some kind of stateless filter. On cheaper or older devices, these stateless filters require traffic to be processed by the main CPU of the router, which can be quite intensive. By contrast, on modern Enterprise-grade devices, these rules are often installed into the router’s dedicated forwarding hardware.

This means that the traffic can be filtered at line rate, with zero* impact to the actual throughput speed of the device.

(*There probably is techically an impact, but it’s so small that you wouldn’t notice it.)

There is an important consequences to the fact that these rules are installed into hardware: you can only have so many rules before you run out of something called TCAM. It stands for Tertiary Content Addressable Memory, but don’t worry about memorising that: the point is that this list of stateless filters should only be relatively short.

As a bonus fun fact, some vendors give you visibility of how much TCAM is used, and how much is available. For example, this Juniper article shows you how to check this in EX and QFX switches. Again though, don’t worry about that if you’re new to this. For now, just be aware that you can do it. You can return to that article when you’re a bit more confident in these concepts.

In Junos, stateless filters can match on pretty much any field in the Ethernet, IP, or layer 4 header.

• Source/destination address? Sure!
• Port number? Sure!
• TCP Syn/Ack status? Sure!
• Quality-of-service markings? Sure!
• ICMP type? Sure!
• Whether or not it’s your birthday? NO. NO OF COURSE NOT. THERE IS NO HEADER FOR THAT. STOP BEING STUPID.

One final thing. Because these rules are not keeping track of state, you will need to make rules for the return traffic. For example, if you allow your LAN to access websites on the Internet, you will also need to create rules that allow all web traffic from the Internet to your LAN. This may, or may not, be exactly what you want to happen.

In short: stateless rules can be found on most devices. Stateless rules should have no impact on transit speeds, on modern decent devices. And stateless rules can only do basic filtering. They are not a substitute for a proper firewall, but they can still be very helpful.

 

STATEFUL FILTERS

it is important to understand that routers are not designed to be security devices. Routers may offer some basic functionality in this area, but a proper firewall will have hardware that can do far more in terms of security.

This is where “stateful” filters come in.

As the name suggests, these rules pay closer attention to the “state” of the traffic. By state, I mean the actual flows.

For example, a stateful firewall will have some kind of session table, where it tracks all the active TCP and UDP (and so on) flows going through it. You can probably view this session table, to see exactly what sessions are going through the firewall in that moment.

The firewall might look into the payload of these sessions, to identify the kind of application in the payload. These devices usually have extensive knowledge of thousands of different applications, and can tell a website from an SSH session, a Facebook chat from a Facebook auction. The firewall might keep on looking at that payload for the duration of the session, to see if the traffic changes from safe to dangerous.

These rules can include URL filtering, virus checks, and much more. It’s difficult to do URL filtering in a stateless rule, because each packet is its own thing. By contrast, if you’re keeping track of sessions, you can use a URL filter to offer the user a webpage telling them that access is blocked.

The actual set of rules might be quite long, and complex. This is fine, because hardware firewalls are designed to process all of this traffic as efficiently as possible. These firewalls will come with hardware powerful enough to cope with many hundreds of detailed rules.

However, all these security checks will inevitably take time to process, and this can cause a delay to the throughput. For example, imagine your firewall is made up of 1Gbps interfaces, and can transit traffic at that rate when there are no security features turned on. In this case, chances are that the firewall will output less traffic per-second than this once you’ve turned on all the shiny features like anti-virus, URL filtering, application inspection, and so on.

One final thing. Because these boxes are keeping track of state, you don’t need to make rules for return traffic. For example, you may have a rule that blocks absolutely everything from the internet into your LAN. However, if you make a stateful rule that allows your LAN to access websites on the internet, then your firewall will automatically allow the return traffic. It will also be able to identify that the traffic genuinely is part of a session. If the session closes, and the web server carries on trying to send traffic to your LAN, it will be rejected.

In short: stateful firewall rules are what you think of when you think of a hardware firewall. They can be extremely powerful – but the more power you give them, the greater chance there is of the total throughput being reduced.

 

And with that knowledge, you’re now ready to return to the post, where I’ll show you why Juniper calls its stateless rules “firewall filters”, and its stateful rules “security policies”. There’s a historical reason for it, and it might seem odd at first – but it’s not such a big deal once you know the reason for it.