What's the whitelisting + drop pattern in firewall rules, how is it visible in the Palo Alto default ruleset, and why is the "Allow → Allow → Deny" sequence the standard?

Whitelisting = explicitly allow only what you need; deny everything else. The Palo Alto default ruleset shows this pattern: intrazone-default: Allow, interzone-default: Deny — same-zone is allowed, cross-zone is blocked unless an explicit "Allow" rule above the deny matches.

The default Palo Alto ruleset:

| # | Name              | Type      | Action |
| 1 | <your rules>      | universal | Allow  |  ← your explicit allows
| 2 | intrazone-default | intrazone | Allow  |  ← same-zone, allow by default
| 3 | interzone-default | interzone | Deny   |  ← cross-zone, deny by default

Reading this top-down:

1. Your custom rules (specific allows) match first.
2. If no custom rule matches, traffic within the same zone is allowed (intrazone-default).
3. If still no match, traffic between different zones is denied (interzone-default).

Why this is "Whitelisting + Drop":

The bottom rule (interzone-default Deny) is the drop rule. Your custom rules above it are the whitelist of explicitly-allowed traffic. The whole pattern enforces "explicit permit, default deny" — the universal best practice.

The "shadow rule" trap (revisited for FW rules):

Same as NAT — specific rules must come above broader rules:

Rule 1: Allow any source → any dest → any service              ← shadows everything
Rule 2: Deny Inside_Staff → Internet → bittorrent             ← never reached

A common warning:

"Hält man sich nicht daran, riskiert man, dass eine spezifische Regel im 'Schatten' einer allgemeinen Regel steht und somit nie zum Einsatz kommt."

The "Application" vs "Service" distinction:

You use Service (ports/protocols) for basic firewall rules and Application (App-ID payload inspection) for advanced ones. The difference:

Service-based rules are simpler but easier to bypass (run BitTorrent on port 443 to look like HTTPS). Application-based rules are more accurate but require deep packet inspection.

Tip: When you build a new firewall, the day-1 ruleset should be just the explicit allows you need + intrazone-allow + interzone-deny. Resist the urge to "open everything for now and tighten later" — "later" never arrives.

Go deeper:

• Create a Security Policy Rule (Palo Alto) — the read-only default rules and "specific rules must precede general ones".