Firewall Administration For Sysadmins Part 2: Key Concepts

This is the second part of a series designed to bridge the communication gap between sysadmins and firewall administrators by helping sysadmins understand firewall administration. In the first part, I discussed firewall policies and the role of firewalls in the enterprise. In this post, I will explain firewall architectures and concepts that are essential to understanding how the firewall team works.

Common Firewall Architectures

Most firewalls are deployed as Layer 3 devices, similar to a network router. When deployed as a Layer 3 device, firewalls have IP addresses that act as the transit points to other network segments (to provide Internet access, for example) or as the default gateways for an internal network segment.

When acting as a default gateway for hosts on a local LAN segment, that segment is usually referred to as a demilitarized zone (DMZ). The point of a DMZ is to severely limit the access DMZ hosts have to other hosts. DMZ hosts are usually exposed to untrusted networks, such as the Internet. Therefore, security professionals assume that they are (or will be) compromised and used as a jump-off point by an attacker to gain deeper access into a network; tight control is required.

I mention a DMZ network specifically because sysadmins responsible for hosts resident in a DMZ are often frustrated by the inability of those hosts to access the rest of the network normally.

Some firewalls can be deployed in a transparent Layer 2 mode. In this model, the firewall is not used as a default gateway, but rather is a "bump in the wire." Hosts on either side of the firewall don't know there's a firewall there. The firewall will permit or deny traffic according to the security policy in the same way as a Layer 3 firewall, but the logical topology is different. The firewall is a pass-through device instead of a routed hop.

Less prevalent in my experience, but still common, is a dual-firewall topology known as a firewall sandwich. In this scenario, one firewall is used to secure traffic coming from an untrusted network into a DMZ and a second firewall is used to secure traffic from the DMZ to the trusted network. This is a key element for a sysadmin to comprehend, as a connectivity issue might require work on the security policy of the firewalls (plural) and not firewall (singular). Understanding the direction of the connectivity problem also is important, since that will likely point to which firewall in the topological sandwich will require a policy update, if not both.

Stateful Firewalls

An important function of firewalls is tracking the state of traffic flows. The terms "stateful firewall" and "stateful packet inspection" are often used when describing a firewall's capabilities. When thinking about state in the context of traffic flows between two hosts, the firewall's job is to monitor the entire flow. A flow includes the start of the conversation, how long the conversation has been ongoing or quiet, and when the conversation ends.

State is a key security element to monitor, as enforcing proper state thwarts a number of basic attacks. Therefore, a firewall must see the beginning of a conversation, or it won't allow traffic that should only show up in the middle. A firewall won't allow a conversation to end that (as far as it knows) never started to begin with. Further, conversations must be started in a timely fashion; if a TCP three-way handshake takes too long to complete, a firewall will terminate the half-open connection. A conversation that has been idle (no one saying anything) for too long will be similarly terminated.

[Read how the National Institute of Standards and Technology sets a strong foundation for an information security program in "Do NIST Information Security Standards Matter? "]

A stateful firewall also allows for bidirectional traffic without requiring bidirectional access list entries in the security policy. When traffic permitted by the security policy is allowed through the stateful firewall, the firewall tracks that outgoing conversation and automatically allows response traffic coming back. When the conversation is terminated, the pinhole created for the response traffic is removed. This doesn't mean that bidirectional traffic is automatically allowed. It means that as long as traffic is initiated in accordance with the security policy, the return traffic will also be permitted without a special entry in the security policy.

Why Directionality Matters

In conversations with sysadmins who need me to massage a firewall security policy, they'll often ask me, "Can you open port X for host Y?" And my response is along the lines of, “Yes, but I need to know from where and to whom.” And while it sounds like the sysadmin already told me the answer to the question, in reality I must comprehend the directionality of the request. Does the application require that hosts outside the firewall access port X on host Y? Or does host Y need to access port X on some remote server?

If I can figure out directionality from context, of course I'll proceed. But the larger point is that when it comes to firewall security policy, which host is initiating traffic to where is very important to understand.

By way of example, let's discuss an SMTP mail relay we'll call "Envelope" that lives in a DMZ. Further, let's assume that the firewall security policy forbids any traffic being forwarded into or out of the DMZ network until explicitly allowed. In this scenario, when the sysadmin spins up Envelope, Envelope will not be able to communicate outside of the DMZ. For the mail application running on Envelope to perform its job, the firewall security policy must therefore be updated in the following ways:

•From Internet hosts (source) to Envelope (destination), destination TCP port 25 must be allowed. The direction is INTERNET -> DMZ.

•From Envelope (source) to Internet hosts (destination), destination TCP port 25 must be allowed. The direction is DMZ -> INTERNET.

•From Envelope (source) to inside mail servers (destination), destination TCP port 25 must be allowed. The direction is DMZ -> INSIDE.

In this scenario, the firewall security policy must be updated in three distinct directions to support Envelope’s inbound and outbound SMTP relay function. Depending on the firewall vendor, a firewall administrator might need to update a global access list or a series of interface-specific access lists. Or in the firewall sandwich topology, access lists spread over multiple security policies might require maintenance.

From a networking perspective, applications are unpredictable, as are application architectures. Therefore, firewall administrators are not trying to be difficult when they push back on an ambiguous firewall change request. Rather, details are absolutely critical to successfully fulfilling the request in a secure manner. This is perhaps the chief source of friction between firewall administrators and sysadmins.

Effective communication goes a long way toward minimizing the policy change lead time and maximizing the firewall's security benefit.