The firewall sits at the pinnacle of enterprise networks, deciding what traffic is allowed in and out according to the defined rules.

Some firewall appliances are objectively better than others in terms of how much traffic they can cope with, how fast they process it and what features they are capable of. But ultimately, a firewall is just a set of rules.

It doesn't matter if it's the fastest, most secure firewall in existence; if there is an any/any rule at the top of the policy, it's basically an open door.

Designing secure firewall policies takes thought and discipline. Applying the following five principles when creating rules will ensure configuration is not the weak link in your security posture.

Principle #1 - Default Deny

Firewalls implement policy in a top down approach. They assess each rule in turn, looking for one that matches the source, destination or service of the current packet.

If it doesn’t find a rule, what should it do?

If nothing is configured, it’s left to the firewall internal policy to decide. Most modern firewalls will drop by default, but might not log the event. But why leave it to chance?

At the bottom of your firewall policy should be this rule:

SOURCE: ANY
DESTINATION: ANY
SERVICE: ANY
ACTION: DENY
COMMENT: Deny all traffic by default

Any traffic not covered by other rules will be dropped by this rule. This way, you have peace of mind that unless you have explicitly allowed something, it will be denied.

You should also explicitly deny each network segment as you configure it. For example, configure all the outbound rules for VLAN 1. Then add:

SOURCE: VLAN1
DESTINATION: ANY
SERVICE: ANY
ACTION: DENY
COMMENT: Deny any traffic from VLAN1 not explicitly allowed.

This will stop unwanted traffic getting any further down the policy, potentially hitting misconfigured rules further down that would allow it unintentionally.

Principle #2 - Always Be Explicit

The default deny rule is the only rule that should use ANY. All other rules should explicitly define the source, the destination and the service. Do not use ‘any’.

Let’s look at an example, and build a firewall rule for the following request:

Allow internet traffic from 172.16.1.0/24.

Nice and simple. The request doesn’t define what internet traffic, so it must mean all internet traffic, therefore this should be the rule:

SOURCE: 172.16.1.0/24
DESTINATION: ANY
SERVICE: HTTP, HTTPS
ACTION: PERMIT
COMMENT: Allow internet traffic from VLAN1

Close ticket, feet up.

Except, what if that isn’t the only internal network on the firewall? It’s highly likely that 172.16.1.0/24 is just the range for one VLAN. There could well be VLANs with addresses on 172.16.2.0/24 and 172.16.3.0/24.

Because the destination is ANY, this rule will give access to any HTTP or HTTPS resources on any internal VLANs, as well as the internet, potentially opening a serious security hole.

Let’s look at how to construct the rule securely.

SOURCE: 172.16.1.0/24
DESTINATION: INTERNET
SERVICE: HTTP, HTTPS
ACTION: PERMIT
COMMENT: Allow internet traffic from VLAN1

INTERNET should be a defined group on the firewall containing any public IP ranges - those not included in RFC 1918. Depending on the firewall, it might be easier to define an INTERNAL group containing the private address ranges, and set the destination to NOT INTERNAL. It will achieve the same result.

Whichever way it’s configured, this will mean that HTTP and HTTPS traffic to other internal networks will be denied, while HTTP and HTTPS to the internet will be allowed, which securely meets the requirements.

Principle #3 - Use Groups

Using groups helps keep rules tidy by reducing the need to list multiple sources and destinations continuously. Let’s say you have more than one monitoring server, using SNMP to check the health of the network devices. You would create a group called GROUP-MONITORINGSERVERS, and use that to construct your rule.

This rule allows SNMP access from all monitoring servers to the management VLAN.

SOURCE: GROUP-MONITORINGSERVERS
DESTINATION: VLAN-MANAGEMENT
SERVICE: SNMP
ACTION: PERMIT
COMMENT: Allow SNMP from all monitoring servers to management VLAN

You might also want to control who can access the monitoring servers, restricting it just to IT personnel.

SOURCE: VLAN-IT
DESTINATION: GROUP-MONITORINGSERVERS
SERVICE: HTTPS
ACTION: PERMIT
COMMENT: Allow HTTPS access to all monitoring servers from IT VLAN

The point is, each service can require multiple rules. Ensuring each rule is maintained can be a arduous task, but with a defined group, adding or removing a monitoring server is now straightforward. Simply change the group membership, and every rule that uses that group now has the right information.

Groups help stop deprecated resources being left behind. Suppose a monitoring server on 172.16.0.24 is retired, but never removed from the SNMP rule, then six months later someone spins up an application server and reuses that IP.

That application server would have SNMP access to the management VLAN.

Make your life easier. Use groups.

Principle #4 - Maintain a Logical Structure

Firewalls are logical devices. They implement rules in the order they are given, and make decisions based on those rules. An administrator should be able to read the rules the same way. There should be a clear structure to the policy, using section headers where available.

This also helps when auditing policies. If there is a section header called DNS, auditors immediately know that all DNS related rules can be found there.

High traffic rules should be nearer the top of the policy, to help with CPU load. Imagine the rule to allow DNS is rule 100. Every time there is a DNS request, the firewall has to evaluate 99 rules before it finds the correct one. By moving that rule to number 2, the load on the firewall is reduced by about 99% for each request.

Set regular time aside for auditing rules. If a temporary rule is needed, set a task to delete it in your planner. If an application is deprecated, ensure removing firewall rules is part of the off boarding process.

There are multiple ways of laying out a firewall policy, but whichever you choose, it should be constructed in a logical way.

Principle #5 - Comment All Rules

All of the rules above have one thing in common - a clear comment describing exactly what the rule does.

There's nothing worse than trying to decipher a firewall policy and having to look up IP addresses, determine what services operate on the allowed port. A clear comment saves a lot of time later on.

Some organisations I’ve worked with put a ticket number in the comment field, allowing operatives to look up the request later on. This isn’t a bad idea, but it fell over when we tried to look up a ticket reference for a rule created over 5 years ago and found the ticket no longer existed.

By all means put the ticket reference in, but combine it with a brief statement of what the rule is for. You’ll thank yourself later on.

Conclusion

A next-generation firewall appliance is no good if it is allowing traffic that it shouldn’t, but you can’t blame the firewall for doing it’s job.

By explicitly defining what traffic should be allowed and denying anything else, administrators can gain control over the main entry point into their networks.

Pairing clear policies structures and comments with regular auditing and maintenance allowance administrators to keep that control, ensuring the firewall policy delivers the security that the appliance is capable of.