Understanding Firewall Rules

Every packet that reaches your firewall faces a gauntlet. The firewall asks questions: Where are you from? Where are you going? What are you? And based on the answers, it makes a decision: pass or die.

Firewall rules are these questions and their consequences. Writing effective rules requires understanding not just the syntax, but the logic of how questions are asked and why order matters more than most people realize.

The Anatomy of a Rule

A firewall rule has two parts: match criteria and an action.

The match criteria define what traffic the rule applies to:

• Source: Where traffic originates—a specific IP (192.168.1.50), a network range (192.168.1.0/24), or "any"
• Destination: Where traffic is headed
• Port/Service: What type of communication—80 for HTTP, 443 for HTTPS, 22 for SSH
• Protocol: TCP, UDP, ICMP

The action specifies what happens when traffic matches:

• Allow: Let it through
• Deny: Drop it silently—the sender gets no response, just silence
• Reject: Drop it and tell the sender it was rejected

Some firewalls add log (record it but allow it) or rate-limit (allow it but throttle the flow).

First Match Wins

Firewall rules are evaluated top to bottom. The first rule that matches determines the packet's fate. This "first match wins" behavior is the most important—and most misunderstood—aspect of firewall configuration.

Consider these rules:

1. Allow all traffic from 192.168.1.0/24
2. Deny traffic from 192.168.1.50 to port 22

You might expect rule 2 to block SSH from 192.168.1.50. It won't. Rule 1 matches first—192.168.1.50 is part of the /24 network—so the traffic flows through. Rule 2 never fires.

Reverse the order:

1. Deny traffic from 192.168.1.50 to port 22
2. Allow all traffic from 192.168.1.0/24

Now SSH from 192.168.1.50 hits rule 1 and dies. Other traffic from that IP still passes via rule 2.

The firewall doesn't read your intentions. It reads your rules, in order, and stops at the first match.

This means: specific exceptions before broad allowances. Always.

The Default Policy

When no rule matches, the firewall falls back to its default policy. This invisible final rule is a critical security decision.

Default deny: If you haven't explicitly permitted it, it's blocked. This forces you to think about every type of traffic you need. It's the security-conscious choice.

Default allow: If you haven't explicitly blocked it, it passes. This prioritizes convenience over security. It assumes you've remembered to block everything dangerous. You haven't.

Default deny treats the firewall as a locked door where you hand out keys. Default allow treats it as an open door where you try to catch the people who shouldn't enter. One of these is obviously more secure.

Common Rule Patterns

Allowing specific services—the most common pattern:

Allow TCP from any to web-server port 80
Allow TCP from any to web-server port 443

Limiting access by source—restricting who can reach sensitive services:

Allow TCP from 10.0.0.0/8 to servers port 22
Deny TCP from any to servers port 22

Note the order. The specific allowance for the management network comes before the broad denial.

Blocking specific destinations:

Deny all traffic to known-malicious-ips

Logging without blocking—visibility without disruption:

Log traffic from internal to Internet port 25
Allow traffic from internal to Internet port 25

Organization Matters

In complex environments with hundreds of rules, organization becomes crucial.

Group rules by purpose: Internet-to-DMZ, DMZ-to-internal, management access. Use comments:

# Web server public access
Allow TCP from any to web-server port 80
Allow TCP from any to web-server port 443

# Web server database access
Allow TCP from web-server to database port 3306

# Block all other database access
Deny TCP from any to database port 3306

Six months from now, will you remember why you allowed traffic from 192.168.50.0/24 to port 8080? Comments are how rules avoid becoming mysteries that nobody dares touch.

Common Mistakes

Overly broad allow rules: "Allow all traffic from trusted network" defeats the purpose of having a firewall. Even trusted networks should have specific allowed services.

Wrong rule order: Your carefully crafted block rule does nothing if a broader allow rule matches first. Test your rules.

Forgetting return traffic: Less common with stateful firewalls, but if you're working with stateless rules, remember that communication is bidirectional.

No documentation: Rules without comments become rules nobody understands, which become rules nobody removes even when they're obsolete, which become security holes.

Testing Rules

What you intended and what you configured aren't always the same.

Many firewalls offer simulation modes—check whether specific traffic would be allowed or denied before deploying. Use them.

After deploying new rules, test both directions: verify that legitimate traffic works and that blocked traffic stays blocked. Monitor logs for denied connections that should have been allowed.

Dynamic Rules

Modern firewalls support rules that change based on conditions:

• Geo-blocking: Allow or deny traffic based on geographic source
• Threat intelligence: Automatically block known malicious IPs from updated feeds
• Time-based rules: Administrative access only during business hours
• Application-aware rules: Decisions based on the actual application, not just the port—preventing users from running prohibited applications on allowed ports

Rule Optimization

Rulesets grow over time. They accumulate cruft.

Remove obsolete rules when services are decommissioned. That server from 2019 is gone, but its firewall rules live on.

Consolidate related rules where possible.

Reorder for performance: if 90% of traffic matches one rule, that rule shouldn't be number 47 in your list. Every packet checks rules 1 through 46 for nothing.