Firewall Administration For Sysadmins: A Primer

I've worked as a member of various IT teams over the years, with firewall administration usually part of my responsibilities. Conversations with other team members about the firewall infrastructure typically revolve around these questions:

•Did you change something on the firewall?

•Why is the firewall blocking my server?

•Can you just open everything up on the firewall for my box?

•Why is the firewall making my app slow?

•Is port X open?

Most of these questions are attempts on the part of system administrators to troubleshoot connectivity, functionality or performance problems with their applications. For sysadmins, working with firewall administrators can be frustrating if the sysadmins don't understand how a firewall works and what the security team's job involves. They don't understand why a firewall administrator pushes back on an ambiguous firewall change request; they just want their applications to work.

To help sysadmins understand how network folks responsible for firewall appliances work, I will provide insight into firewall technology and its administration, based on my experience as both a sysadmin and network engineer. Through this multipart series, my hope is to bridge the communication gap between sysadmins and firewall administrators, and to foster more intelligent and productive conversations between the teams.

In this first post, I will discuss firewall security policies and the role of firewalls in the enterprise. Let's start at the beginning.

What Does A Firewall Do?

Before answering this question, I need to establish some context. While there are virtual firewalls in cutting-edge virtualized data centers and software OS-level firewalls (such as the firewalls integrated in Windows or Mac OS X, or ipchains in *NIX), I'm speaking specifically about the dedicated firewall hardware appliance, found in most enterprise networks of any size. This doesn't mean that software or virtual firewalls necessarily work differently; in fact, they may be very similar overall. But that's not my focus here. I want to address the situation where the person working on the servers and applications needs to talk to the person working on the hardware firewall devices taking up some RUs in a network rack.

So a firewall, in our context, is a purpose-built security appliance that permits or denies traffic flowing into it in accordance with a security policy. The security policy is formed by a combination of many attributes that describe a traffic flow, but the focus of a security policy is almost always one or more access lists.

A traditional access list typically permits or denies traffic based on the source and destination IP addresses (Layer 3 information), as well as destination port (Layer 4 information), although the source port could additionally be used. For example, an access list element could be read like this: "A host with a source IP address of 192.168.100.10 is permitted to communicate with a host whose destination IP address is 100.200.200.100, as long as the destination port is TCP number 80."

Firewall security policies include elements beyond access lists to improve security. Consider the following possible firewall protections:

•Many common applications use TCP for communications. For example, Web servers typically provide unencrypted communications via TCP port 80 and encrypted communications via TCP port 443. TCP communications start with a "three-way handshake," which can be abused if not completed, as this leaves the socket in a half-open state. Firewalls can mitigate half-opens by terminating the connection if the three-way handshake does not complete quickly enough.

•Some firewalls will protect inside hosts by limiting the number of TCP connections that outside hosts can make to them.

•Although not technically a security function, many firewalls are called upon to perform Network Address Translation (NAT). An IP address subjected to NAT will be one address on one side of the firewall and a different address on the other. Application Layer Gateways (ALGs) are closely related to NAT and look deeply inside a packet to see if there's an IP address in the data payload that should also be subject to NAT in order to help an application work properly in a NAT environment.

•Many modern firewalls are referred to as next-generation firewalls. These firewalls combine traditional access lists with deep packet inspection to perform tasks traditionally handled by intrusion detection or intrusion prevention devices. Some next-gen firewalls can go even deeper than that, allowing administrators to govern, say, not just access to Facebook but also to specific Facebook tasks.

[Read more about next-generation firewalls in "4 Tips For Evaluating Next-Generation Firewalls."]]

•Firewalls often act as VPN gateways, building encrypted tunnels to end users with VPN clients or third parties via dedicated IPsec site-to-site tunnels.

This list could go on. However, my goal isn't to provide an exhaustive list of plausible security functions, but rather to share big ideas. A larger point is that firewall configurations can be astonishingly complex. Firewall administrators deserve love and respect, as making the firewall not only pass traffic, but also pass it securely, is no simple task. The more complex the security policy, the harder it is to keep the firewall running properly.

Are Firewalls Really Necessary?

Yes and no. Let me explain. I've seen firewalls deployed where I personally could find no merit for them--where the argument is, "It's always been there!" I've also seen environments screaming for a firewall where there was none. Worse case, I've seen firewalls deployed more or less as routers because there was no meaningful security policy installed.

Despite these anomalous scenarios, firewalls are and forever will be needed to separate trusted networks from untrusted networks. Some might argue that such a definition is too generalized, but I can argue that most firewall use cases boil down to exactly this issue. Firewalls are arbiters in the game of trust. Even in the virtualized data center, where virtual firewalls are moving the network edge instead of acting as a point of central transport, this trusted vs. untrusted perspective is still relevant.

The classic example of a firewall arbitrating trust is when it acts as an Internet gateway. The internal network is trusted. The Internet is decidedly untrusted. The firewall's security policy attempts to keep the peace. Another example is data centers housing sensitive data: The networks containing that data essentially trust no other networks. A firewall usually governs traffic to and from the sensitive data network.

In my next article, I will discuss common firewall architectures and concepts that are key to understanding how firewall teams work.