Firewall Best Practices (Part 1)

So you want your data to be secure (who doesn’t?).
You decided to buy (or build) a firewall to protect your servers from intruders.
Good for you…

But are you doing it “right“?

An improperly configured firewall is akin to locking your car door but leaving the window open with the keys in the ignition. A false sense of security is extremely dangerous in the information security game. Here are a few things to keep in mind when configuring your firewall.

1. Object naming and Groups for ease of maintenance.

Most modern firewalls allow a sort of object oriented approach to tracking resources (IPs, networks, port groups, etc). By utilizing this object oriented method, one can greatly simplify the firewall rule-set while making it much easier to maintain. For example, if we have five webservers using five different IP address and we want to allow the world to access port 80 and 443, we could do it with five distinct rules or we could use names and groups.

If we define a group called “WebServers” and define all five IPs as members, we only need one rule allowing the world to access port 80 on the WebServers group. This is much cleaner (especially when working on the command line) and much more human readable which means it is easier to maintain without human error in the future.
The examples below are based on the Cisco ASA firewall. The most popular firewall platform on the market.

Webserver IPs: 10.10.10.5, 192.168.10.13, 10.1.5.27, 192.168.95.85, 10.100.2.45

name 10.10.10.5 www1
name 192.168.10.13 www2
name 10.1.5.27 www3
name 192.168.95.85 www4
name 10.100.2.45 www5

object-group network WebServers

network-object host www1
network-object host www2
network-object host www3
network-object host www4
network-object host www5

access-list OUTSIDE extended permit tcp any object-group WebServers eq http
access-list OUTSIDE extended permit tcp any object-group WebServers eq https

access-group OUTSIDE in interface outside

As you can see, this example only needs two access-list statements to allow two ports on five servers. The traditional method would require 10 rules. This method is much easier to read and maintain. Likewise, if you add more webservers later, you do not need to change the rule-set at all. Simply define another name->IP and add the name to the WebServer group and it will work as the others do.

2. Inside to Out is just as important as Outside to In.

Everyone knows a firewall is meant to stop unwanted incoming (and malicious) connections. However, many network and firewall administrators underestimate the importance of limiting servers (and workstations) outbound internet access. This can be just as important to thwarting attackers as the outside->inside rules. The reason for this is that many attackers realize the
inside->outside path is much more likely to be vulnerable. The MS-SQL “Sapphire” worm is a perfect example of this.

An attacker may install some malicious code on a website, for example, that infects a machine on your corporate LAN. Once that machine is infected, it “phones home” to a machine the hacker controls. Now if your firewall was not restrictive enough, the attacker will have an established connection back into your server. Since the connection is established, most “stateful” firewalls will simply allow the inbound traffic back in, bypassing your inbound firewall rules.
Remeber, Inbound AND Outbound rules should be specific and explicit in what they allow.

3. Deny all, then permit as needed.

Deny ALL traffic except that which you explicitly permit. Starting with this approach, you are much more likely to stop an attack than an explicit deny policy. It is better to err on the side of caution and temporarily block (and subsequently have to fix) a service you need open than to accidentally leave a service that should be protected open. Data breaches can not be undone and can cost millions.

4. BE SPECIFIC

Be as specific as possible. In other words, avoid using “ANY” or wildcards as the source, destination or service (ports) in your firewall ruleset whenever possible.
Permit management of critical infrastructure ONLY from specific hosts.
Utilizing Names and Object-Groups (see example above) you can easily define a list of hosts which should have management level access to various infrastructure. For example:

name 10.10.10.10 Admin1
name 192.168.10.50 Admin2
name 10.45.65.27 Core-Router1
name 192.168.45.92 Core-Router2
name 10.44.20.55 Firewall1

object-group network Admins
network-object host Admin1
network-object host Admin2


object-group network Firewalls
network-object host Firewall1


object-group network Routers
network-object host Core-Router1
network-object host Core-Router2


access-list OUTSIDE extended permit tcp object-group Admins object-group Firewalls eq 22
access-list OUTSIDE extended permit tcp object-group Admins object-group Routers eq 22


Again, if you add another Admin or Firewall, you do not need to change the rulesets. Simply add the appropriate Name and Object-Group entries and the new hosts will inherit the existing ruleset.
Making fewer changes to the

5. Change tracking is vital.

Every change made to a firewall should be documented in a central location. Firewalls can be complex in their configurations. A seemingly simple change can affect something else in an unintended way. By having proper change tracking in place, the new problematic symptom(s) should be easily correlated to the time and date of the offending change. This makes troubleshooting infinitely easier and less prone to introducing more errors.

When was the change made?
Who made the change?
Why was the change made?
How was the change tested and confirmed?

Following these simple rules will help in your quest to build a complete, thorough security policy.

We will cover some more Firewall Best Practices in part 2 of this article.  Stay tuned…