Palo Alto Zone Protection & DoS Protection: — Stopping Floods Before They Reach Policy

① Why floods win — the attack on session setup itself

Meet Sneha, an L2 engineer at Flipkart. One morning the Bengaluru edge firewall's dataplane CPU is pinned at 100%, new sessions are timing out, and the helpdesk is on fire. There's no malware alert, no blocked URL — the dataplane is simply drowning. The Threat logs show a single source spraying tens of thousands of SYN packets a second at a public IP. Her security policy has a clean deny rule for that traffic — so why is the firewall on its knees?

Because of when the deny rule runs. A PAN-OS firewall must first create a session for a packet — allocate state, run the slowpath lookup — and only then does the security policy and the Security Profile stack inspect it. A volumetric flood attacks session setup itself. Each junk SYN forces the firewall to start building a session it will never finish. Do that 50,000 times a second and the box runs out of session-setup capacity — legitimate users can't get a session created at all.

That's the whole point of this lesson. Zone Protection and DoS Protection are a separate, earlier layer that sits in front of policy. They count connections-per-second (CPS) and reject a flood at the door — cheaply, before the firewall wastes slowpath cycles on it. They are not in the App-ID/Threat-Prevention path you already know; they're the bouncer before the bouncer.

PAN-OS hands you two tools, and the single most common interview mistake is confusing them. Zone Protection is a profile you attach to an interface zone — it screens every packet entering that whole zone against aggregate flood, scan and malformed-packet checks. DoS Protection is a policy rule plus profile that wraps one specific server (or a small group) with much tighter, per-host connection limits. Zone protection is the perimeter fence around the compound; DoS protection is a personal bodyguard standing next to one VIP.

Four things to lock in before we go deeper

Tap each card — these four facts answer most of the exam and interview questions on this topic.

② Zone Protection — the zone-wide fence (flood, recon, packet, protocol)

A Zone Protection profile has four tabs, and you should know what each one stops. You build the profile at Network > Network Profiles > Zone Protection > Add, then — and this is the step people forget — you attach it to a zone at Network > Zones > (your zone) > Zone Protection Profile. An unattached profile protects nothing.

Tab 1 — Flood Protection. This is the famous one. For each flood type — SYN, ICMP, ICMPv6, UDP and Other IP — you set three new-CPS thresholds: Alarm Rate, Activate Rate and Maximum Rate. The PAN-OS defaults are Alarm 10,000, Activate 10,000 and Maximum 40,000 cps — and those defaults almost never match your real traffic, so you re-baseline them (more on that in section 4).

For a SYN flood only, you also pick a drop Action: SYN Cookies or Random Early Drop (RED). SYN Cookies makes the firewall proxy the three-way handshake, so it drops only packets that never complete the handshake — fairer, but more CPU because the firewall handshakes on the server's behalf. RED just starts dropping new SYNs randomly once you cross Activate — cheap, but it drops legitimate traffic too. For ICMP/UDP/Other floods, RED is the only mechanism.

Tab 2 — Reconnaissance Protection. This catches the attacker's homework: TCP port scans, UDP port scans, host sweeps and IP-protocol scans. You set an Interval (seconds) and a Threshold (events), and an action: allow, alert, block, or block-ip (drop everything from that source for 1–3,600 seconds). A common best-practice starting point is TCP port scan → block-ip, interval 5s, threshold 20; UDP port scan → alert, interval 10s, threshold 20. You can also exclude trusted scanners (your own vuln scanner) via Source Address Exclusions — up to 20 entries.

Tab 3 — Packet-Based-Attack Protection. This drops malformed and spoofed packets: spoofed-IP discard, mismatched-overlapping TCP segments, TCP SYN with data, ICMP fragments, and so on. Tab 4 — Protocol Protection. This is a Layer-2 ethertype allow/exclude list — you permit only the non-IP protocols you expect (e.g. block unexpected ethertypes on a zone). Together these four tabs are your aggregate, zone-wide fence.

admin@PA-VM> show zone-protection zone untrust

Zone untrust:
  Number of zone protection profiles applied: 1
  Profile: ZP-Untrust-Internet
    flood
      tcp-syn   enable: yes  action: syn-cookies  alarm: 18000  activate: 22000  maximal: 40000
      udp       enable: yes  action: red          alarm: 15000  activate: 18000  maximal: 40000
      icmp      enable: yes  action: red          alarm: 10000  activate: 10000  maximal: 40000
    recon
      tcp-port-scan  action: block-ip  interval: 5  threshold: 20
  current syn cps: 142   (well below activate — healthy)

③ DoS Protection — the per-server bodyguard (aggregate vs classified)

Zone Protection guards the whole zone with one aggregate budget. But what about one specific server — say a payments API at 10.20.5.10 that you know should never see more than a few thousand CPS from any one client? For that you use DoS Protection, which is two pieces: a profile (the thresholds) built at Objects > Security Profiles > DoS Protection, and a policy rule that points the profile at specific source/destination traffic, built at Policies > DoS Protection.

The DoS profile has a Type that's the heart of the feature: Aggregate or Classified. Aggregate gives the matched group one shared CPS budget. Classified counts per address, using an Address setting of source-ip-only, destination-ip-only, or src-dest-ip-both. The classic choice: protect a server with a classified, source-ip-only profile so a single attacker IP trips its own limit while every other client keeps working. You can apply both an aggregate and a classified profile to one rule — PAN-OS evaluates the aggregate first, then the classified.

Inside the profile, each flood type (SYN/UDP/ICMP/ICMPv6/Other) again gets Alarm, Activate and Maximum rates — but here they're the per-host or per-group limits, set lower than the zone fence because you're protecting one box. There's also a Block Duration (default 300 seconds) — how long an offending IP stays on the Block-IP list once it crosses Maximum. And SYN floods again offer SYN Cookies vs RED.

The policy rule ties it together. At Policies > DoS Protection you match source zone/address and destination zone/address (e.g. dst = 10.20.5.10), then pick an Action: Deny, Allow, or Protect. Protect is the one that activates the profile's thresholds. Match a profile, point it at the server, set action Protect — that's a working per-server DoS defence.

admin@PA-VM> show dos-protection rule "DoS-Payments" 
admin@PA-VM> show dos-protection rule "DoS-Payments" blocked source

Rule: DoS-Payments  (action: protect)
  Aggregate profile:    Classified profile: DoS-Payments-Classified  (source-ip-only)
  tcp-syn   alarm: 2000  activate: 3000  maximal: 5000  action: syn-cookies
  current classified entries: 1

Blocked source addresses (classified):
  source-ip        rule           time-remaining(s)
  203.0.113.77     DoS-Payments   271

④ Tune & verify — baseline CPS, avoid self-drops, exam & career

Here's the trap that catches every new engineer: thresholds set too low cause self-inflicted drops. If your Activate rate sits below your real peak CPS, the flood meter trips on a normal Monday-morning login rush and RED starts dropping your own users — an outage you caused, not the attacker. The PAN-OS guidance is blunt: if the activation threshold is too low for the environment, the firewall needlessly drops legitimate packets even though it has resources to spare.

So the rule is baseline first, set second. Measure your zone's and server's average and peak CPS before you set any number. A simple way: watch show session info over a busy period for the current and peak CPS counters. Then set Alarm ~15–20% above your average CPS (a warning line), Activate just above your true peak CPS (so it only fires under a real flood), and Maximum at roughly 2× the Activate (raise it if dataplane CPU has headroom). Tighter on a per-server DoS profile, looser on the zone fence.

Verify, don't assume. After committing, prove the shields are live and counting. Use show zone-protection zone <name> to confirm the profile is attached and read the current vs Activate CPS. Use show dos-protection rule <name> for per-rule state and the Block-IP list. Use show session info for live and peak CPS. And when you suspect drops, show counter global filter delta yes reveals the exact drop counters (e.g. flow_dos_*) so you can tell a flood-drop from a policy-drop.

admin@PA-VM> show session info
admin@PA-VM> show counter global filter delta yes | match dos

Session info:
  Number of sessions supported:     1048576
  Number of active sessions:        38194
  Packet rate:                      210400/s
  New connection establish rate(CPS): 1760/s   <- average
  Peak: 1980/s

flow_dos_red_syn        2210   drop  Out-of-sync SYN cookies / RED dropped
flow_dos_blk_global      540   drop  Packets dropped: DoS block table

A sober note from 2025: floods aren't the only DoS risk. In CVE-2025-4619 Palo Alto disclosed that an unauthenticated attacker could send a specially crafted packet through the dataplane to reboot the firewall (repeated hits push it into maintenance mode) — on firewalls with URL proxy or a decrypt policy configured. The lesson for you: Zone/DoS Protection meters volumetric floods, but you still must patch PAN-OS for protocol-level DoS bugs. Hardening is layers and patch hygiene, never one or the other.

For your certification, this maps directly onto PCNSE and PCNSA. The exams expect you to: state that Zone Protection is zone-wide and applied to a zone while DoS Protection is rule-based and per-host; choose SYN Cookies vs RED and justify it; explain aggregate vs classified and the source-ip-only/dest-ip-only/src-dest-ip-both options; and recognise self-inflicted drops from thresholds set too low. Get those four ideas crisp and you own this objective. Career-wise, flood and DoS tuning is exactly the kind of hands-on hardening L2/L3 firewall roles hire for in India.