Configure AntiDDoS Protection on a Palo Alto Firewall

Before you run this

This guide configures two related Palo Alto features: a Zone Protection profile (broad, per-zone flood defence applied at the edge, before a session is even created) and a DoS Protection profile + policy rule (granular defence for specific servers). Their whole job is to drop traffic once a rate threshold is crossed. That is the point — and also the danger. Set a Max Rate too low and you will drop legitimate production traffic; enable a block action and you will hold that drop for the block duration.

• Privileges: You need a firewall administrator account with commit rights (a superuser or a custom admin role that can edit Network/Objects/Policies and commit) on the web UI reachable via the MGT interface. This is not a shell script — there is no sudo here. Panorama-managed shops push the same objects from a template/device group, but this guide assumes a standalone firewall.
• Keep out-of-band access open: Have a console/serial session or a separate MGT connection open the entire time. A wrong threshold or a Zone Protection profile bound to the wrong zone can silently starve production traffic, and you do not want your only way back in to be the link you just broke.
• Back up first: Before touching anything, go to Device → Setup → Operations and Save named configuration snapshot and Export named configuration snapshot (download it off-box). That saved snapshot is your rollback.
• Rollback path: PAN-OS has no timed auto-rollback like Junos commit confirmed. To undo, either Config → Revert Changes (before you commit) or Device → Setup → Operations → Load named configuration snapshot (the one you saved), then commit.
• Test first: Do this in a maintenance window, and if you possibly can, on a lab firewall or VM-Series first. Baseline your real traffic rates before you pick numbers — see the baseline step below. Do not paste in someone else's thresholds and commit blind.

Assumptions for this guide: PAN-OS 11.1 (10.2/11.0 are almost identical), web UI, an Internet-facing zone I'll call untrust and a server zone I'll call dmz. Replace those zone names with yours.

Step 0 — Baseline before you pick numbers

Every threshold below is only as good as your knowledge of "normal". PAN-OS pre-fills example numbers in a new flood profile — treat them as placeholders, not defaults you should keep.

Look at the ACC tab and Monitor → Logs → Traffic, and from the CLI check current session and connection rates:

show session info

Note the connections-per-second and max sessions figures during a busy period. Your Zone/DoS thresholds should sit comfortably above legitimate peaks but below what would exhaust the box. If you don't have a baseline, start high (alarm-only) and tighten later.

Step 1 — Create a Zone Protection profile

Zone Protection guards a whole zone against flood, reconnaissance, and packet-based attacks.

1. Network → Network Profiles → Zone Protection → Add.
2. Name it something like zp-untrust.
3. On the Flood Protection tab, enable the flood types you want to defend: SYN, UDP, ICMP, ICMPv6, Other IP. For each, you set three rates in connections/packets per second:
   • Alarm Rate — log an alarm, drop nothing.
   • Activate Rate — begin the protective action (e.g. Random Early Drop).
   • Maximum Rate — hard cap; traffic above this is dropped.
4. For SYN Flood, choose the Action: Random Early Drop or SYN Cookies. On an Internet-facing zone fronting real listeners, SYN Cookies validates the handshake and is gentler on legitimate clients; RED simply drops a rising fraction of SYNs. Pick one deliberately — both are valid, and the trade-offs are in the admin guide under "SYN Flood".
5. (Optional) The Reconnaissance Protection and Packet Based Attack Protection tabs block port scans, spoofed/malformed packets, etc. These are safe to enable but read each option — they are described in the PAN-OS Admin Guide section on Zone Protection.
6. OK.

Now bind it to the zone:

1. Network → Zones → click untrust.
2. Set Zone Protection Profile to zp-untrust.
3. OK.

Zone Protection is aggregate for the entire zone — it cannot single out one source. That is what DoS Protection policy is for.

Step 2 — Create a DoS Protection profile

This protects named servers and can count per-source (classified) as well as in aggregate.

1. Objects → Security Profiles → DoS Protection → Add.
2. Name it dos-web-servers.
3. Set Type:
   • Aggregate — the thresholds apply to all traffic matched by the policy rule combined.
   • Classified — thresholds apply per the classification you choose in the policy rule (per source IP, per destination IP, or per source-and-destination).
4. On Flood Protection, enable the relevant flood types (SYN, UDP, ICMP, etc.) and set Alarm / Activate / Max Rate and a Block Duration as above. Same units, same meaning.
5. On Resources Protection, tick Maximum Concurrent Sessions and set a ceiling to stop one target (or one source) from exhausting the session table.
6. OK.

Step 3 — Write the DoS Protection policy rule

The profile does nothing until a policy rule references it.

1. Policies → DoS Protection → Add.
2. General: name it, e.g. dos-protect-web.
3. Source: set the source zone (untrust) and, if you want, source addresses.
4. Destination: set the destination zone (dmz) and the specific server addresses/address group you're protecting.
5. Option/Protection:
   • Action: Protect (this applies the profile's thresholds; Allow/Deny bypass or block outright).
   • Under Aggregate, select dos-web-servers. If your profile is Classified, also enable Classified, select the profile, and choose the Address classification (source-ip-only, destination-ip-only, or src-dest-ip-both).
6. OK, then order the rule sensibly — DoS rules are evaluated top-down.

Step 4 — Commit

Commit (top right). Watch for validation warnings. If anything looks wrong, Config → Revert Changes before committing rather than after.

Verify it worked

• Threat log: flood and DoS events land in Monitor → Logs → Threat. Filter for flood-type threats and confirm you see alarms when you expect them (e.g. during a controlled load test), not against normal traffic.
• ACC: the Threat Activity widgets show DoS/flood counts.
• CLI operational check: the current state of Zone and DoS protection counters is visible from the CLI. Palo Alto exposes these under the show operational commands and the global counters (show counters global, filtered for flood/DoS). The exact keyword for the per-zone and per-rule status is listed in the PAN-OS CLI Quick Start / Admin Guide under "Monitor DoS Protection" — check there rather than guessing a subcommand.
• Sanity test: from a lab host, generate a controlled SYN burst against a test destination and confirm the Threat log fires and legitimate connections still succeed. Never run a flood tool against production.

Undo / roll back

• Remove without deleting objects: unbind the Zone Protection profile (Network → Zones → clear the profile) and set the DoS policy rule's action away from Protect or disable the rule, then commit. Fastest way to lift protection if it's dropping good traffic.
• Full rollback: Device → Setup → Operations → Load named configuration snapshot, pick the snapshot you saved in Before you run this, and commit.

If you tightened a threshold and legitimate traffic started dropping, the quickest safe move is to raise the Max Rate (or switch a SYN action back to alarm-only) and commit — you rarely need a full config restore for a rate tweak.