Firewall design rests on a few durable ideas: deny by default, split the network into zones by trust and function, allow only documented flows between them, keep the rule set small and owned, log decisions, and test that the policy blocks what you intend. Technology choice comes after these.
Where do these principles come from?
NIST's SP 800-41 Rev. 1 describes firewalls as devices or programs controlling traffic between networks or hosts with differing security postures, and it makes recommendations for policy, selection, configuration, testing, deployment and management. It surveys technologies from packet filters to application-aware proxies and notes where each fits. Read it for the full picture. The points below apply its themes in a practical order.
Principle 1: start with the policy, not the box
Write what must be allowed in plain terms: which sources reach which services, over which protocols, for which business reason. The rule set is an implementation of that document. If the policy cannot be stated, the rules will be a pile of exceptions.
Principle 2: default deny
Block everything, then add exceptions. The reverse, allowing everything and blocking known bad, fails on the first unknown. Apply it both inbound and outbound. Egress filtering is often skipped, yet it limits what a compromised host can reach and where it can send data.
Principle 3: zones by function and trust
Group assets into zones such as internet-facing services, application servers, databases, user networks, management networks and guest access. Traffic crossing zones passes through enforcement. Keep management interfaces on a separate network reachable by few. Place internet-facing systems in a segment where a compromise does not give direct access to internal networks.
Principle 4: least privilege in rules
Specific beats broad. Name the source, destination and port, not "any". A rule that lets an entire subnet reach an entire subnet on all ports is a hole with a label. Give each rule a comment with owner, reason and ticket.
Principle 5: layer the controls
A firewall is one control. Pair it with host protections, patching, authentication and monitoring. A permitted flow can still carry an attack, so application-layer controls and endpoint defences are needed behind it.
Principle 6: protect the firewall itself
Firewalls are internet-facing software with their own vulnerabilities. Patch promptly, restrict administrative access to the management network, require multi-factor authentication, keep configuration backups, and log every change with the person who made it.
Principle 7: log, review and prune
Send logs to a separate system. Review rules at least quarterly, remove those with no traffic hits after owner confirmation, and expire temporary rules automatically.
A constructed example
A company's web tier needs to call an application tier and nothing else. The design says: internet to web on 443, web to app on 8443, app to database on 5432, and no direct path from web to database. A tester attempts a connection from a web server to the database port and confirms it is dropped and logged. Six months later a rule appears that allows web to database for a "temporary fix", with no owner. The quarterly review finds it and the team reverses it.
How to check or apply this
- Write the allowed flows as a document with an owner and business reason for each.
- Set default deny inbound and outbound, then add rules from the document.
- Define zones and place management interfaces in a restricted one.
- Replace "any" in rules with specific sources, destinations and ports.
- Require a comment, owner and expiry date on each rule.
- Test the policy: attempt flows that must fail and confirm the result and the log entry.
- Patch and harden the firewall, and restrict who can administer it.
- Review and prune rules every quarter.
Quick check
Why filter outbound traffic too?
Egress rules limit what a compromised system can reach, such as command and control servers or places to send stolen data, and make misuse easier to see.
How many rules is too many?
There is no fixed number. When nobody can explain a rule or its owner, the set is too large to manage safely.
Sources
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
- NIST SP 800-207, Zero Trust Architecture
Last reviewed: 18 October 2026.
