Ethan Banks


Upcoming Events

Where the Cloud Touches Down: Simplifying Data Center Infrastructure Management

Thursday, July 25, 2013
10:00 AM PT/1:00 PM ET

In most data centers, DCIM rests on a shaky foundation of manual record keeping and scattered documentation. OpManager replaces data center documentation with a single repository for data, QRCodes for asset tracking, accurate 3D mapping of asset locations, and a configuration management database (CMDB). In this webcast, sponsored by ManageEngine, you will see how a real-world datacenter mapping stored in racktables gets imported into OpManager, which then provides a 3D visualization of where assets actually are. You'll also see how the QR Code generator helps you make the link between real assets and the monitoring world, and how the layered CMDB provides a single point of view for all your configuration data.

Register Now!

A Network Computing Webinar:
SDN First Steps

Thursday, August 8, 2013
11:00 AM PT / 2:00 PM ET

This webinar will help attendees understand the overall concept of SDN and its benefits, describe the different conceptual approaches to SDN, and examine the various technologies, both proprietary and open source, that are emerging. It will also help users decide whether SDN makes sense in their environment, and outline the first steps IT can take for testing SDN technologies.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up

See more from this blogger

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.

Ethan Banks, CCIE #20655, is a hands-on networking practitioner who has designed, built and maintained networks for higher education, state government, financial institutions, and technology corporations.


Related Reading


More Insights


Network Computing encourages readers to engage in spirited, healthy debate, including taking us to task. However, Network Computing moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. Network Computing further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | Please read our commenting policy.
 
Vendor Comparisons
Network Computing’s Vendor Comparisons provide extensive details on products and services, including downloadable feature matrices. Our categories include:

Research and Reports

Network Computing: April 2013



TechWeb Careers