A Tangible Example of Stateful Firewalls

If you spend any amount of time with FW you will encounter stateful FW.

The goal for this week's article is too shed some light on a stateful FW in action.  A simple demonstration will help those new to FW or those needing a quick refresher.

Before moving forward lets briefly talk about a tool that every IT professional uses.

PING

The packet internet groper.  This little tool we use so much that we take it for granted.  Ping leverages ICMP and allows for me to send an ICMP packet to a target.  The power of ping is that with ICMP I van can evoke a response from a target.

I always pause here when I say this to students.

Because, think about it, a machine that was not anticipating a packet receives a random packet and then responds to it.

I usually demonstrate this concept by pinging a machine in Asia and observe the response. (I reside in Canada).

So there is the brief history on ping.  Keep this in mind as we continue on.

Above I am showing a simple network managed by a router.  On either side of the router I have separate LANs.  Static routing is already set up, so a machine in 192.168.3.0/24 is able to ping a machine in 192.168.1.0/24 and vice versa.

Above I am showing some rules on the OPT2 interface. These are outbound rules that say this:

- from .3.11 allow tcp/udp and connect to LAN machine 1.101 via port 3389

-block everything coming from OPT2 > LAN

- allow everything from OPT2 out (going to the internet)

Here .3.11 is attempting to ping .1.101.  As you can see the ping hangs and never makes it through.  Thanks FW!!

Here .1.101 is pinging .3.11 and we are getting a response.  I know this picture is boring but something awesome is happening.

Remember in previous picture that .3.11 could not send an ICMP Request packet?  From .1.101 however we saw that .3.11 did in fact send a ICMP reply, an ICMP packet!

This is where the magic of stateful FW comes into play.  In my FW configuration I am allowing all traffic from LAN to OPT2.  

All pings from LAN can get to OPT2.  My FW remembers communications (states) from LAN and because my FW is not stopping this transaction .3.11 is able to respond even though it has a FW that says nothing should go to LAN network.

Why is this useful?  Without this I would have to create separate rules for inbound and outbound.  Stateful FW takes care of this for me!

But don't get to comfy with the rules being "easy."  You have to be mindful of the communication relationship.  What packets are typically responses to certain packets?  If you are not vigilant to craft careful rules you could leave your network wide open for attack.

Thanks Everyone!

Andrew Campbell