8.5 Improving Your Security beyond Basic Packet Filtering

At this point, your audit may turn up some surprising results, especially if you use Nmap and Nessus to scan your network from the outside. You may even find that despite your allowing only established sessions and limiting ICMP traffic, Nmap is able to scan quite a bit of your network, including your LAN. This is because the type of firewalling we are doing right now is simple packet filtering. From the point of view of the firewall, each packet is an independent entity and no relationship is made between one packet and the next. Therefore, your firewall lacks the logic to associate a packet forged to look like part of an established session with the fact that no out-bound traffic was sent outbound to establish a session in the first place. Decisions are made based solely on the settings of the bits in the packet headers.

If we were to try to make our network rules more complex, we would also notice other failings with our firewall rule set as it is. We know now that we can infer if a TCP header is part of an established session through the use of the control bits. What if we had an application that used UDP? How would we know if the UDP packet incoming from the Internet is in response to a UDP packet being sent out from our LAN or a UDP packet being sent into our network for some nefarious purpose? Because UDP has no way of establishing a session, the fact is that we cannot determine the nature of that incoming UDP packet. So, for UDP, we are stuck with manually configuring ranges of ports to allow traffic in and out of our network just as we had to do with TCP. Even worse for our network security, UDP is commonly used for interactive multimedia applications and these applications use enormous ranges of UDP ports. For example, some VoIP implementations use a range of thousands of UDP ports during normal operation. For these applications to operate properly on our firewall, we would have to allow unrestricted inbound and outbound access on those UDP ports. This is clearly at odds with our restrictive philosophy of firewall configuration.

What we need in our firewall is some logic that keeps track of outbound UDP packets and only allows UDP packets back into the network if they correspond to the IP addresses and ports used by the outgoing UDP traffic. This, of course, is exactly what a stateful packet filter accomplishes for us.

By enabling stateful packet filtering on our router/firewall, we can reduce the complexity of our rule set while at the same time increasing the overall security. These benefits are realized because we no longer need to establish complex rules to allow return traffic and the firewall is able to track traffic other than TCP. With stateful packet filtering, if someone were to generate fake packets in an attempt to circumvent our established connection filter, the process has just gotten a lot more difficult.

Applying stateful packet filtering to our current rule set allows us to eliminate the rule used to watch for established connections. To provide an example of how this occurs in our current rule set, let us consider the example in which a host on the internal network initiates a Telnet session to an Internet host using DNS to resolve the host name.

Our host is configured to forward requests to the internal DNS server using our split DNS configuration. This internal DNS server is then configured to forward requests to the DMZ DNS server, which then forwards the request upstream to either another DNS server run by an ISP or to one of the root DNS servers. With normal packet filtering, we would have to specifically allow UDP DNS responses back into our network segments, because we could not rely on any connection information in the packet header to alert us that this is a response to a recent request. Configuring the router as a stateful firewall, we can simply ask the router to watch for any DNS request from the inside to the DMZ and create a dynamic rule in the rule set that temporarily allows responses from the DMZ DNS server to the inside DNS server.

To ensure that the dynamic access rule is as secure as possible, the stateful filter will remember the IP address and source and destination UDP ports seen in the packet traveling from the inside to the DMZ. Only packets from the DMZ to the inside that match the IP addresses and ports will be allowed through the stateful firewall. The same process is used when the DMZ DNS server makes a request from the upstream DNS server. Only UDP packets that match the IP addresses and the UDP ports used to send traffic outbound will be allowed back into the network.

Depending on the vendor, this process may be hidden from view, but a stateful packet filter essentially has the ability to create temporary, very specific rules. One rule is created for each packet flow initiated from the inside heading out. To prevent rules from utilizing too many resources on the router/firewall, the stateful packet filter is configured to remove these rules when a TCP session is torn down. If UDP, ICMP, or other protocols are being evaluated, then the stateful session simply keeps track of the last time a packet was passed that matched a given rule. After a reasonable time period, say 60 seconds, if no further packets are observed, the rule will be automatically removed from the firewall rule set.

After configuring our firewall to accept stateful filtering, our rule set then becomes:

Watch for new Telnet and ICMP sessions outbound from the LAN. Record the source and destination IP address, protocol, and any ports that are being used, and create a rule allowing return traffic back into the network.
Watch for HTTP proxy traffic from the LAN to the DMZ and create a dynamic rule to allow return traffic from the HTTP proxy server to the DMZ.
Watch for IP traffic sourced from the DMZ. Record the source and destination IP address, protocol, and any ports that are being used to create a rule allowing return traffic back into the network.
Deny any packet from the "outside" with a source that matches our "inside" network.
Deny any packet from the "outside" with a source IP address in the private range of 10.0.0.0/8.
Deny any packet from the "outside" with a source IP address in the private range of 172.16.0.0/12.
Deny any packet from the "outside" with a source IP address in the private range of 192.168.0.0/16.
Deny any packet from the "outside" with a source IP address of 0.0.0.0/32 (an all 0s source address).
Deny any packet from the "outside" with a source IP address of 255.255.255.255 (an all 1s broadcast address).
Allow DNS, UDP destination port 53, from "outside" to "DMZ" 200.1.1.10. Outside to inside tells us that traffic from the Internet is allowed into the server.
Allow SMTP, TCP destination port 25, from "outside" to "DMZ" 200.1.1.20. The rule allows the receipt of e-mail from our mail server.
Allow SMTP, TCP destination port 25, to "outside" from "DMZ" 200.1.1.20. This allows the sending of e-mail from our mail server.
Allow POP3, TCP destination port 110, from "outside" to "DMZ" 200.1.1.30. This rule allows remote user clients to check their e-mail on our POP3 server.
Allow HTTP, TCP destination port 80, from "outside" to "DMZ" 200.1.1.40. Allows Internet hosts to access our Web server.
Allow HTTP traffic from the "inside" network to "DMZ" 200.1.1.50, TCP destination ports 8080 (our proxy server port number). Allow clients from the LAN to connect to the proxy.
Allow HTTP traffic from the proxy on "DMZ" 200.1.1.50, to access the Internet. Because Web sites can theoretically be run on any number of ports, we will only restrict this traffic according to IP addresses instead of ports.
Allow FTP, TCP destination port 21, from "outside" network to "DMZ" 200.1.1.60.

We see at this point a slight reduction in the amount of rules, most notably in the rules surrounding DNS and ICMP access in and out of the network. For connectionless protocols such as UDP and ICMP, stateful firewalling is a great convenience. If we were to complicate our rule set by adding multimedia and voice applications, we would be especially grateful for the services provided by stateful firewalling.

Because we host servers on our DMZ, stateful firewalling did not reduce the number of TCP rules a great deal beyond what connection tracking did by looking at SYN bits. We have, however, increased the security of our network, as another audit would show.

Stateful firewalling used to be the realm of the most expensive and advanced firewall platforms; but like most things in computing, the technology has trickled down quite a bit. Today, even personal firewalls and free operating systems such as Linux can be configured with stateful packet filtering and is enabled on most routers with or those without a "firewall feature set." In short, there is really no reason to consider using a regular packet filter when these tools are available to you.