Network Security Firewall Rules

A firewall is only as strong as the rules programmed into it. A firewall with poorly written rules either blocks legitimate traffic (causing outages) or allows malicious traffic through (causing breaches). Writing and maintaining firewall rules is one of the most critical and most error-prone tasks in network security.

Anatomy of a Firewall Rule

Every firewall rule contains the same core elements. Think of each rule as a sentence that says: "If traffic matches these conditions, take this action."

Rule Structure:
┌────────┬─────────────┬──────────────┬──────────┬──────────┬──────────┐
│ Rule # │ Source      │ Destination  │ Port     │ Protocol │ Action   │
├────────┼─────────────┼──────────────┼──────────┼──────────┼──────────┤
│ 1      │ 192.168.1.0 │ ANY          │ 443      │ TCP      │ ALLOW    │
│ 2      │ 10.0.0.50   │ 10.0.0.100   │ 3306     │ TCP      │ ALLOW    │
│ 3      │ ANY         │ 10.0.0.200   │ 22       │ TCP      │ DENY     │
│ 4      │ ANY         │ ANY          │ ANY      │ ANY      │ DENY ALL │
└────────┴─────────────┴──────────────┴──────────┴──────────┴──────────┘

Rule 1: Any device on 192.168.1.x can browse HTTPS
Rule 2: Specific app server can reach the database on port 3306
Rule 3: Nobody can SSH to the payment server directly
Rule 4: Everything else is blocked (implicit deny)

Rule Processing Order

Firewalls read rules from the top down and stop at the first match. This makes rule order critical. A rule higher in the list that accidentally matches traffic overrides all rules below it.

Traffic: Source 192.168.1.5 → Port 22 (SSH)

Firewall reads top to bottom:
Rule 1: Source = 192.168.1.0/24, Port = 443 → NO MATCH, continue
Rule 2: Source = 10.0.0.50, Port = 3306     → NO MATCH, continue
Rule 3: Source = ANY, Port = 22             → MATCH! Action: DENY ← STOPS HERE

Rule 4 (deny all) never even gets checked.

Common Rule Order Mistake

WRONG ORDER:
Rule 1: ANY → ANY, Port 22, DENY      ← blocks everyone
Rule 2: 10.0.0.5 → Server, Port 22, ALLOW ← this never runs!

CORRECT ORDER:
Rule 1: 10.0.0.5 → Server, Port 22, ALLOW ← specific allow first
Rule 2: ANY → ANY, Port 22, DENY           ← general deny second

Inbound vs Outbound Rules

Firewalls inspect traffic in both directions. Inbound rules control what enters the network. Outbound rules control what leaves. Outbound rules matter because malware on infected machines tries to call home to attacker-controlled servers — outbound filtering catches this.

INBOUND (external → internal):
Allow: TCP port 443 from ANY (web browsing incoming)
Allow: TCP port 25 from ANY (email incoming)
Deny:  All other inbound traffic

OUTBOUND (internal → external):
Allow: TCP port 443 to ANY (web browsing outgoing)
Allow: TCP port 53 to DNS servers (DNS queries)
Deny:  TCP port 4444 to ANY (common malware port)
Deny:  All unusual ports not needed for business

The Principle of Least Privilege in Firewall Rules

Each rule should allow only the minimum traffic necessary. A rule that says "allow all TCP from accounting subnet to the internet" is too broad. A rule that says "allow TCP port 443 from accounting subnet to specific banking sites" is specific and safer.

Common Firewall Rule Mistakes

Mistake                         | Risk
--------------------------------|--------------------------------------------
"Allow ANY to ANY" rule present | Defeats the purpose of the firewall
No implicit deny at the end     | Undefined traffic flows through unexamined
Outdated rules never removed    | Shadow rules create confusion and gaps
Rules too broad (ANY source)    | Attackers masquerade as permitted source
Logging disabled on deny rules  | Blocked attacks go undetected
No review or audit schedule     | Rules accumulate and contradict each other

Firewall Rule Lifecycle

Rules should not be created and forgotten. A healthy firewall rule lifecycle includes:

1. Request and Justification

Any new rule requires a documented business reason. Who needs the access, what system they need to reach, which port is required, and why it cannot be achieved with existing rules.

2. Review and Approval

A security team reviews the request to check it follows least privilege and does not conflict with existing rules.

3. Implementation

The rule is added to the firewall. In production environments, changes follow a change management process with rollback capability.

4. Monitoring

Logs show whether the rule is being used. A rule that has never matched any traffic in six months is probably unnecessary.

5. Periodic Audit

At least annually, every rule gets reviewed. Rules with no documented business need are removed. Overly broad rules get tightened.

Logging Firewall Events

Every deny event should be logged. Logs reveal attack patterns, scanning activity, and internal machines trying to reach suspicious external addresses. Without logs, a firewall stops attacks silently with no record of what happened or how often.

Sample firewall log entries:
2024-03-15 09:14:22 DENY TCP 185.220.101.5 → 10.0.0.5:22 [known Tor exit node]
2024-03-15 09:14:23 DENY TCP 185.220.101.5 → 10.0.0.5:3389 [RDP attempt]
2024-03-15 09:14:24 DENY TCP 185.220.101.5 → 10.0.0.5:445 [SMB attempt]

Three attempts in two seconds from same IP → port scan detected!
→ Add this IP to blocklist, alert security team