Chapter 10. Testing Your Firewall Rules (for Security)

Chapter 10. Testing Your Firewall Rules (for Security!)

Firewalls work both ways. You can use them to keep bad traffic from the outside coming in, as well as keeping bad traffic from the inside going out. Worms, mail connections, and X11 sessions are just a few examples of "bad traffic" depending on your security policy. But how do you test this quickly and consistently? Many times a change in the rules in one area can affect rules in other.

This is perhaps a good moment to talk about the concept of firewalls in general (we promise to be brief!) and why the very first diagnostic procedure we talk about is specifically the most important. A firewall is not a router; nor is it a gateway. It's a compartmentalization tool. If the whole reason you picked up this book is to make sure you can get your traffic out of your network, then this is probably the most important section for you to read. There are three types of firewalls:

1. Application Layer (proxy servers such as squid, reaim, or the TIS firewall toolkit)

2. Packet Filtering (routers, switches, and so on)

3. Stateful Inspection (netfilter/iptables)

Routers and other network gateways generally fall into the "packet filtering" category, which means that they look at the first packet in a session, match it to a rule, and then let the rest go with no further inspection. That means they are trivial to beat (and we'll show you how later in the chapter) using some very simple methods. Stateful inspection firewalls look at every packet as it goes by to ensure it conforms to the firewall policy you have created on the system. The methods used here may work on a stateful inspection firewall but generally only if you've done something horribly, horribly wrong.

So how do you beat packet filtering firewalls? Simplefragment the packets. There are many ways to do this, either with userspace tools such as nmap, changing the MTU on your network card, or my personal favorite, a tool called fragrouter from the nidsbench toolkit (http://packetstorm.widexs.nl/UNIX/IDS/nidsbench/nidsbench.html) by Thomas Ptacek and T. Newsham. We will look at fragrouter later in the chapter to demonstrate weaknesses in packet filtering systems.

There are two types of tests you should perform on every firewall: an external scan against inside systems (OUTSIDE->IN), and an internal scan against systems on the outside (INSIDE->OUT). The first test is useful in occasions where you're dealing with address space reachable from outside your network through your firewall, such as on a DMZ network, or if you are in an environment where potential intruders can set your firewall as the gateway (think wireless networks or conference rooms if you put them in DMZs).

The INSIDE->OUT test verifies what kinds of traffic from your internal or DMZ networks can get across your firewall. This is a useful verification test if you are attempting to filter what types of traffic your DMZ systems can get through your firewall. If your DMZ hosts web servers, there really is no point in allowing them to send traffic out on the X11 port, SMTP, or frankly any traffic that is not coming from the source port of the web server itself (TCP ports 80 and 443, respectively). This is valuable from a security standpoint in that in the event the web server is compromised (through port 80just because you have a firewall doesn't mean that your web server cannot be exploited on the ports you allow in!), it cannot be used as a platform to attack other systems through your firewall.

A good example of an INSIDE->OUT test discovering a weakness in firewall rules was when we were initially setting up IPSEC VPNs to secure our wireless networks (see Chapter 19, "Virtual Private Networks," for more information on this). Our firewalls were configured also to provide transparent proxies on web and IM traffic, so even though the firewalls were configured to block all outbound traffic not coming through the IPSEC VPN networks, the transparent proxy servers were redirecting the traffic outbound. This was discovered and corrected quickly by using an INSIDE->OUT scan.