How should you write and review firewall rules?

Firewall rules should start from deny by default, allow only traffic with a documented business need, and each carry an owner, a purpose and a review date. Order matters because most firewalls act on the first match, so broad rules placed early can silently override careful ones.

What is a firewall rule?

A rule matches traffic on attributes such as source, destination, protocol and port, then takes an action: allow, deny or sometimes log. NIST SP 800-41 Revision 1 describes firewalls as devices or programs that control traffic between networks or hosts with differing security postures, and it makes recommendations on policy, selection, configuration, testing and management.

Why start with deny by default?

An allow list is a statement of what you expect. Everything else is unexpected and stays blocked. A default allow policy asks you to think of every bad thing in advance, which no team can do. NIST SP 800-53 Revision 5 states the same idea as control SC-7(5), Deny by Default, Allow by Exception: deny network traffic by default and allow it by exception. NIST SP 800-41 supports basing the rule set on a policy that follows the organization's needs rather than on whatever traffic happened to appear.

What makes a rule good?

A good rule is narrow, explained and owned.

Narrow means specific source and destination addresses and the exact ports required, not any to any. Explained means a ticket or comment that says why it exists and what service it supports. Owned means a named team that can say when it is safe to remove it.

Rules that fail those tests build up. A temporary rule for a vendor test that nobody removes becomes permanent access.

How does rule order cause problems?

Most firewalls evaluate rules from top to bottom and stop at the first match. Three failure patterns follow.

A broad allow rule near the top makes later deny rules unreachable, a shadowed rule. Two rules overlap and the result differs from what either author intended. A rule that matches nothing for a year stays in place because deleting feels risky.

Reviewing the order, and testing the set against sample traffic, finds these before an attacker does.

Do outbound rules matter?

Yes, and they are often skipped. Controlling what internal hosts may reach limits the damage when something is compromised, because malware often needs to call out to a server it controls. A server that only needs to reach a database and an update service should not be able to connect to arbitrary internet addresses.

Constructed example: the forgotten test rule

A team opens port 3389 from a vendor's address range to a test server for a one week project. The ticket closes, the rule does not. Two years later the server holds a copy of production data and the rule is still there. A quarterly review that lists rules with no owner and no recent hits would have flagged it. Removing it takes one minute.

How to check or apply this

1. Export the current rule set and confirm the final rule denies everything not allowed.
2. Flag any rule with any in the source, destination or port fields and replace it with specific values.
3. Check every rule for an owner, a reason and a review date. Remove or escalate the ones missing them.
4. Look for shadowed and duplicate rules, and for rules with no hits in the past period you choose, such as 90 days.
5. Keep changes in a ticketed process with a second reviewer, and log rule changes.
6. Review outbound rules for servers, not just inbound ones.

A firewall decides who may connect. It does not know whether an application above it is vulnerable. Application layer flaws still need code and dependency scanning, because traffic that a firewall legitimately allows can carry an exploit.

Quick check

Sources

• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
• NIST SP 800-53 Rev. 5 control catalog, SC-7(5) (OSCAL, NIST GitHub)

Last reviewed: 18 October 2026.