Firewall Guide: First Steps to Securing the Enterprise

When people discuss firewalls, most are still lost in the classic perimeter model of 1990's. Most of us recall the firewall as a single device that sat at our network edge and it kept out all the bad things by looking at source and destination addresses, ports and so on.

That was yesterday and while the classic model is essentially dead, the firewall still has a role in modern network security architectures.

Since we’ve torn down classic network borders, we now find firewalls placed all over our environment, including but not limited to the desktop. Soon you will see the firewall show up on handheld devices most likely with a fancy new name like, "Mobile Anywhere Protection" or whatever marketing folks figure will catch your eye.

This of course will be part of the cloud computing craze coming to an enterprise near you. But enough of that for now. Let’s get down the desktop and have a look at some examples of rules, their impact and if they really are secure.

The Microsoft myth

Many of us enable the Windows firewall thinking that because it’s enabled, we have done something to protect us from the bad things on the Internet or whatever network we happen to be connected to. The problem here is that the Windows firewall only filters traffic coming into your PC, not going out. Most malware that makes it onto your PC will certainly be communicating back out. This means that your Windows firewall is useless to block the outbound connection used to steal data or whatever else the malware is coded to steal. Even with some of the abilities of modern firewalls (application and service filtering) the offering is weak at best.

That said, many firewalls still base their functionality on the classic model, Microsoft being no exception. Let’s take a closer look at why port based firewall >ACLing can’t stand on its own in modern security architectures.

Before the all-in-one total threat protection days of the personal firewall, we used to have to write port based rules such as this:

This allows TCP connections to any port greater than 1023 from 6000 on my host, 10.10.200.50. If I used the rule as described, an attacker could bind their client to port 6000 and connect to port 3306 (it’s greater than 1023) on my server, connecting to the mysql server which was otherwise firewalled.

You quickly realize that this is inherently insecure. Worse, today’s threats hide in allowed traffic streams which render port based security useless.

Today we have firewalls that not only perform the classic filtering but also have the ability to operate at multiple layers of the OSI model. This gives the modern firewall the ability to look at traffic streams and determine if shady connections attempts are taking place.

For network admins looking for a basic setup that won’t bring the enterprise to a screeching halt, I would recommend leaving the malware plug-ins at the defaults until you understand the impact. Many products will identify potentially unwanted applications and give you the choice of allowing them (third party apps are targeted quite often) or keeping them blocked.

Once you have a sense for what really out there, maintaining your exclusion lists will be relatively painless. You can then ratchet down the settings for an even harder stance.

As for classic rules, I always recommend not allowing SMTP traffic outbound from endpoints, except to the approved SMTP gateway. This ACL can be done on edge firewalls or on the desktop depending upon your environment. Most will elect to do this at the network edge. In our example the approved SMTP gateway is 10.10.200.50.

What would this rule look like?

It’s also a good idea to examine NetBIOS traffic. I’m amazed at just how many Slammer infections still exist years after the fact. Even though many of us feel that the old worm propagation model isn’t used much these days, every so often we get a surprise when criminals go "old school" on us because we let our defenses down.

Filter CIFS and NetBIOS ports 445, 137,138 and 139.

I would also look at all privileged ports (1023 and lower) and make a careful note of the services running and determine if inbound connections are really needed. A word of caution, do not block all privileged ports unless you understand the impact. Those who have made the mistake of blocking RPC port 135 can testify to the importance of what I just said.

Also, you’re going to find that many organizations are going to require specific ports to be open inbound in order for enterprise tools to work properly. You may find that your ruleset is very close to a slice of swiss cheese. Because of this, organizations lean on behavioral based technologies to augment the deficiencies introduced with the classic port based firewall technologies.

In our next installment on firewalls in modern security architectures, we’re going to look at internal firewall devices used to segment networks for compliance initiatives.