Configure a firewall by denying all traffic that is not expressly permitted, then allowing only documented flows in both directions. Give every rule an owner and a reason, order rules deliberately, and review them often. NIST SP 800-41 Rev. 1 sets out this approach and remains a sound base.
What is the starting position?
NIST says that, generally, all inbound and outbound traffic not expressly permitted by the firewall policy should be blocked. That is a default deny stance. It reverses the common mistake of opening broad access first and blocking the problems later, which leaves holes nobody remembers.
The policy comes before the configuration. NIST SP 800-41 advises writing a firewall policy based on a risk analysis, then implementing rules that follow it. If the rule set is the only record of what is allowed, nobody can say which rules are intentional.
Why filter outbound traffic?
NIST uses the terms ingress filtering for incoming traffic and egress filtering for outgoing traffic, and it says outgoing traffic can be filtered too. Many teams only filter inbound. Outbound control matters because malware that lands on a server needs to call out, and because a vulnerable service often needs outbound access to be exploited. OWASP's own API example of a logging library fetching a remote object depends on a permissive outbound policy.
What does a good rule look like?
A good rule is narrow in source, destination, port and protocol, and has a comment stating who requested it and why. It has an owner and, for temporary access, an expiry date. A rule that reads any to any on any port has no scope to review.
Order matters in most firewalls, because the first matching rule applies. Put specific rules before general ones and end with an explicit deny and logging.
What about ICMP and other special cases?
NIST's guidance gives permitting certain ICMP types and codes as an example of a firewall policy requirement. Blocking all ICMP breaks path discovery and troubleshooting. Allowing everything leaks information. Decide which types you need, and permit those.
Change control deserves the same care as the rules. Every change should have a ticket, a second pair of eyes and a rollback step. Many outages and many holes come from an urgent edit made at night with no record of why. Keep the configuration in a backup and compare it to the running version regularly, so unrecorded edits show up.
How often should you review?
NIST says it is important to review the firewall policy often, and notes that reviewing rule sets and testing periodically helps ensure continued compliance. Reviews find rules for systems that no longer exist, duplicates, and rules that are shadowed by earlier ones and never match.
A constructed example
A company inherits a firewall with 900 rules. An engineer exports hit counts for 90 days and finds 410 rules with no matches. Another 60 are shadowed by earlier rules. She sorts the remaining rules by owner, emails each owner for a reason, and disables rules without an answer in two weeks, keeping them for 30 days before deletion. Outbound access from servers, previously open, is narrowed to a list of update and API hosts. The rule count falls to 280, and the next review takes an afternoon.
How to check or apply this
- Write the policy first: which zones exist and which flows between them are allowed.
- Set the final rule to deny and log.
- Write each allow rule narrowly, with source, destination, port and a comment naming the owner and reason.
- Add egress rules for servers, allowing only what they need.
- Decide which ICMP types you permit.
- Put the management interface on a separate trusted network, with MFA and logging.
- Export hit counts and review the rule base at least quarterly. Remove unused and shadowed rules.
- Test after every change, from both sides.
- Back up configurations and keep a change record.
Quick check
What is default deny?
It means traffic is blocked unless a rule explicitly allows it. NIST recommends this stance for traffic not expressly permitted by policy.
Do I need to filter outbound traffic?
Yes, where practical. NIST describes egress filtering as a standard part of a firewall policy, and it limits what a compromised host can do.
Sources
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
- OWASP API8:2023 Security Misconfiguration
Last reviewed: 18 October 2026.
