A firewall can hold a perfectly written rule that never runs. Put a deny-everything rule one line too high, or a broad allow above a narrow exception, and the rule below it is dead. Many real firewall failures are mistakes of exactly this kind: rules in the wrong order, the wrong address range or the wrong port column, not a missing product.
On the CompTIA Security+ SY0-801 exam this falls under objective 4.1, which expects you to apply mitigating controls in a scenario, and a rule table is the kind of material a performance-based question can ask you to fix. This lesson teaches you to read a rule table, trace a packet through it, spot shadowed rules and overlapping address ranges, handle return traffic and DMZ traffic, and repair a broken rule set step by step. It finishes with the same logic in iptables and a cloud security group.
A rule table is read from the top, and the first match decides
A rule table lists one rule per row. The usual columns are a rule number, source, destination, protocol, port and action; some tables add the interface or zone and a logging flag. "Any" is a wildcard. Unless a table labels it otherwise, the port column means the destination port.
| # | Source | Destination | Protocol | Port | Action |
|---|---|---|---|---|---|
| 1 | 10.1.1.0/28 | 10.1.2.10 | TCP | 3389 | Allow |
| 2 | Any | 10.1.2.10 | TCP | 3389 | Deny |
| 3 | 10.1.0.0/16 | Any | TCP | 443 | Allow |
| 4 | Any | Any | Any | Any | Deny |
The firewall compares each new packet with rule 1, then rule 2, and so on. At the first rule where every condition matches, it applies that rule's action and stops; nothing below is consulted. Every condition must match. A rule with the right source and destination but the wrong port is skipped.
Trace three packets. An admin at 10.1.1.7 opens Remote Desktop to 10.1.2.10: rule 1 covers 10.1.1.0 through 10.1.1.15, so it matches and the connection is allowed. A user at 10.1.5.20 tries the same: rule 1 doesn't match the source, rule 2 matches, and the connection is denied. That user browsing to 203.0.113.80 on TCP 443 skips rules 1 and 2 because the destination differs, and rule 3 allows it.
Swap rules 1 and 2 and the admins are blocked too, because the broad deny would catch them first. That is the core principle of rule ordering: specific rules above general ones.
In a performance-based question, write the packet down first (source, destination, protocol, destination port), then walk the table from the top and stop at the first full match. Guessing from the rule that looks most relevant is how points are lost.
Anything no rule allows falls to the implicit deny
Nearly every firewall and ACL ends with an invisible final rule that denies everything. Cisco ACLs have it, cloud security groups have it, and host firewalls set to block inbound by default have it. In a default-deny design you write allow rules only for the traffic the business needs, and everything else is blocked without another line.
The implicit deny catches people in two ways. First, an ACL made only of deny statements blocks all traffic, because whatever the denies don't catch falls to the implicit deny. If the goal is to block a few things and allow the rest, the list needs an explicit allow at the end. Second, the implicit deny usually doesn't log, so many administrators add an explicit "deny any any" with logging as the last rule. When a question's table ends in a row of Any values with a Deny action, that is the explicit version.
Two placement errors are classic. A deny any any placed anywhere above the last row kills every rule beneath it. An allow any any at the bottom quietly replaces default deny with default allow, and the firewall becomes little more than a router.
Default deny is the allow-list approach: only listed traffic passes. The opposite, allowing everything and blocking known-bad traffic, is a block list. When the exam asks for the more secure policy, it is the allow list.