PAN-OS Security Zones and the Basic Security Policy

Palo Alto firewalls do not filter on interfaces the way an ACL-based router does; they
filter on zones, and a packet only ever matches a rule if both its ingress and
egress zone are named in that rule. Engineers coming from Cisco ASA or IOS ACLs lose time here,
because a rule that looks correct but references the wrong zone silently matches nothing. This
article explains the zone model, then builds a first security policy step by step with the
matching criteria that actually decide the outcome.

Zones Are the Primary Match Criterion

A zone is a logical grouping of interfaces that share the same trust level. Every Layer 3
interface is assigned to exactly one zone, and traffic moving between two interfaces in the
same zone is never evaluated against the inter-zone security policy — it is handled by
intra-zone behaviour instead. That single rule explains most "why is my rule not matching"
questions.

• Trust — internal users and servers
• Untrust — the internet
• DMZ — externally reachable services
• Guest / IoT — everything you do not want talking to Trust

Zones are also where user identification and application identification are anchored, so
consistency here pays off later when you add policy based on users or applications rather than
IP addresses.

Step 1: Define the Zones

Network > Zones > Add
   Name:          trust
   Type:          Layer3
   Interfaces:    ethernet1/2, ethernet1/3
   Enable User Identification: yes

Network > Zones > Add
   Name:          untrust
   Type:          Layer3
   Interfaces:    ethernet1/1

Step 2: Address Objects Instead of Raw Subnets

Create named address objects before writing policy. Rules that reference
trust-net-10.10.0.0/16 survive a renumbering; rules that embed a literal subnet do
not.

Objects > Addresses > Add
   Name: trust-net-10.10.0.0/16
   Type: ip-netmask
   Value: 10.10.0.0/16

   Name: any-public
   Type: ip-netmask
   Value: 0.0.0.0/0

Step 3: Build the Security Policy Rule

PAN-OS evaluates rules top down, first match wins, exactly like an ACL. It defaults to
implicit deny at the bottom, and it is good practice to add an explicit
deny-any-with-logging rule so you can see what you are blocking before you need to
debug it.

Policies > Security > Add
   General tab
     Name:        Allow-Trust-to-Untrust-Web
     Rule Type:   universal
     Tags:        baseline
   Source tab
     Zone:        trust
     Addresses:   trust-net-10.10.0.0/16
   Destination tab
     Zone:        untrust
     Addresses:   any
   Application tab
     Application: ssl, web-browsing
   Service/URL Category tab
     Service:     application-default
   Actions tab
     Action:      Allow
     Profile Settings > Profile Type: Profiles
       Antivirus / Anti-Spyware / Vulnerability / URL Filtering / File Blocking
     Log Setting: default

Two settings matter more than everything else on that panel. Typing the actual port instead
of application-default forces the firewall to skip application identification, and
any in the Application field disables the App-ID engine entirely. Take the
defaults: let App-ID decide the port, and let the rule name describe the intent rather than the
five-tuple.

Step 4: Commit

Nothing takes effect until you commit. Validate first, commit with a description, and know
the difference between the two commit types:

# From the CLI
validate full
commit description "baseline trust-to-untrust policy" partial yes

# GUI: Commit > Commit, or Commit > Commit and Push for Panorama-managed devices
show config diff
show jobs processed

A partial commit is faster but only pushes the changed parts; if you are unsure whether a
change is a partial or full push, do the full commit. If you manage firewalls through Panorama,
the commit workflow is two-stage — see Panorama device groups, templates and the commit workflow for how templates and device groups change what gets pushed where.

Step 5: Verify the Rule Is Actually Matching

Never close a change without watching real traffic match the rule.

# Sessions matching your rule
show session all filter rule Allow-Trust-to-Untrust-Web

# Counters
show rule-hit-count vsys vsys1 rule-base security rules all

# Live packet capture when nothing matches — see the packet capture workflow
# at doc-level: Pan-OS packet capture uses a four-stage filter
# (receive / firewall / transmit / drop)
debug dataplane packet-diag set filter match source 10.10.0.5
debug dataplane packet-diag set filter on

If a session shows up with the wrong application, or no session appears at all, check the
zone assignment first. The single most common cause of "my rule is not working" in PAN-OS is an
interface in the wrong zone, and the second most common is a rule above yours that already
matched. Rule ordering is absolute.

Design Habits Worth Adopting Early

• One rule per intent, named for the intent (Allow-DevOps-to-Prod-API), never
  rule1.
• Keep an explicit logging deny at the bottom and read it weekly while you are still
  building out the rulebase.
• Use tags to group rules by project so you can find them later.
• Attach security profiles to every allow rule; an allow without profiles is a visibility
  gap as well as a security one.
• Track rule hits and retire the rules that never match — a dead rulebase is where
  mistakes hide.

If you also run FortiGate, the matching philosophy differs enough to be worth reading side
by side — see FortiGate policy mode vs profile mode and Checkpoint fw monitor packet capture guide for the equivalent investigative workflow on other platforms.

原文链接：https://docs.paloaltonetworks.com/ngfw/getting-started/initial-setup-configuration-ngfws/set-up-a-basic-security-policy