Written by Alex Laulhe. With special thanks to Anupam S. & Amogh G. for their contributions.
This guide is designed to help firewall admins effectively understand flood attack prevention and troubleshoot flooding incidents detected by Palo Alto Networks firewalls. Whether the event is triggered by packet buffer protection (PBP), Zone Protection (ZPP), or DoS protection profiles (DoSP), this document provides guidance on how to identify the type of flood, determine the root cause, and take corrective & preventive actions through “Best Practices”.
N.B: Please note that this document is a collection of best practices and knowledge from our PAN Community. It does not replace our official guides.
_________________________________________________________________________________________________
Part 1 - Understanding Flood Prevention and Best Practices
Part 2 - Troubleshooting Flood Attacks: Workflow & CLI Commands!
_________________________________________________________________________________________________
Part 1 - Understanding Flood Attack Prevention on NGFWs
Flood attacks aim to overwhelm network resources by sending large volumes of traffic, typically to exhaust bandwidth or system processing capacity. Palo Alto Networks Next-Generation Firewalls (NGFWs) provide multiple layers of protection to detect and prevent these attacks, including:
Zone Protection Profiles (ZPP): First line of defense, applied at the ingress interface to protect entire zones.
DoS Protection Policies (DoSP): Second layer, applied after session creation to protect specific resources.
Packet Buffer Protection (PBP): Final layer, monitors and protects the firewall's internal resources during active sessions.
_________________________________________________________________________________________________
A. Zone Protection Profiles (ZPP)
Purpose: Zone Protection Profiles are defensive mechanisms applied at the zone level (not individual rules) to protect against network floods, reconnaissance, and protocol-based attacks before a session is even established.
Good to know:
Zone protection will be enforced before DoS policy lookup IF an IP happens to be present in both the profiles:
It can be used as a template configuration for applying similar settings to multiple zones.
These settings apply to the ingress zone (i.e. the zone where traffic enters the firewall).
Zone protection settings apply to all interfaces within the zone for which the profile is configured.
It applies to all traffic passing through the zone and it’s not based per source, destination or source-destination (Aggregate)
Key Protection Mechanisms:
Flood Protection: Mitigates high-volume traffic attacks such as SYN, ICMP, and UDP floods by setting thresholds to detect and drop excessive packets.
Reconnaissance Protection: Detects and blocks scanning activities like TCP/UDP port scans and host sweeps, which are often precursors to more targeted attacks.
Packet-Based Attack Protection: Identifies and discards malformed or malicious packets that could exploit vulnerabilities in network protocols.
Non-IP Protocol Protection: Controls traffic using non-IP protocols, preventing potential abuse of less common communication methods.
Best Practices
Configure Flood Protection under Network > Network Profiles > Zone Protection > Zone Protection Profile > Flood Protection and apply it to the ingress zone of the traffic flood.
Tailored Profiles: Customize Zone Protection Profiles based on the specific needs and typical traffic patterns of each zone (follow best practices)
Monitoring and Adjustment: Regularly monitor the effectiveness of protection mechanisms and adjust thresholds as necessary to balance security and performance.
Complementary Measures: In addition to Zone Protection, implement DoS Protection profiles, PBP and Security Profiles to provide layered defense strategies. References : Zone Protection Profiles & Best Practices
_________________________________________________________________________________________________
B. DoS Protection Policies (DoSP)
Purpose: DoS Protection Profiles are policies that protect specific targets (like critical servers or services - i.e. policies can be configured to match zone, interface, IP address or user information as match conditions) from Denial of Service (DoS) attacks. Unlike Zone Protection Profiles (which protect at the zone level), DoS profiles focus on more granular control and operating after a session is established.
Key Components:
DoS Protection Profile: Defines how to detect and mitigate attacks (thresholds, actions, flood types). It's a reusable set of settings.
DoS Rule: Defines where and to whom the profile applies (zones, IPs, interfaces). It matches traffic and applies a specific DoS profile.
How It Works:
Configured under Objects > DoS Protection and Policies > DoS Protection.It is applied through DoS Policies, which match traffic using criteria like: Source IP / Destination IP / Destination Zone / Service.
It is evaluated after security policy allows traffic.
There is an additional lookup involved in the process. DoS rules are applied before security policy lookup, but after destination Zone determination.
Protection modes:
Aggregate – Controls the total rate of connections to a destination (e.g., to a public web server).
Classified – Controls rate per source IP, per destination IP, or per source-destination pair (useful for blocking distributed or targeted attacks).
Each profile includes:
Alarm Rate – When to log the activity.
Activate Rate – When mitigation begins.
Maximum Rate – When the firewall drops all new connections.
These are measured in:
Connections per second (CPS) for TCP/UDP/ICMP flood protection.
Packets per second (PPS) for packet-based attacks.
Best Practices:
Although DoS Policy runs after Zone Protection, the thresholds should be configured aiming to activate the DoS Rule before Zone Protection – so you can benefit from offloading the attacker IP to the HW Block List.
Always start with a Baseline
Monitor normal traffic (CPS/PPS) to critical systems before applying limits.
Use ACC or logging to analyze patterns and peak usage.
Use Both Aggregate and Classified Profiles
Aggregate to protect servers from total overload.
Classified to stop single or multiple sources from flooding.
Apply Only to Untrusted Zones or Critical Resources
DoS policies are resource-intensive; apply them only where needed (e.g., public-facing services like web/mail servers).
We Recommend to Use SYN Cookies or RED Mechanisms
Enable SYN cookies to handle TCP floods.
Use Random Early Drop (RED) to reduce the chance of false positives.
Tune Thresholds Carefully
Set thresholds above your normal peak traffic, but low enough to catch attacks early.
Start in "monitor" mode, then move to "block" mode once confident.
Log and Alert
Consider log drops and alerts to help refine your tuning.
Consider forwarding logs to SIEM for correlation – or better to XSIAM!
References: DoS Protection & Best practices
_________________________________________________________________________________________________
C. Packet Buffer Protection (PBP)
Overview: What is Packet Buffer Protection?
Packet Buffer Protection (PBP) is a defense mechanism designed to safeguard the NGFWs against single-session Denial-of-Service (DoS) attacks that can overwhelm the firewall's packet buffer, leading to legitimate traffic being dropped. Unlike Zone Protection or DoS Protection policies that primarily focus on new sessions, PBP targets existing sessions and operates both globally and at the zone level.
Key Components:
1. Global Packet Buffer Protection
Function: Monitors overall packet buffer utilization across all zones.
Mechanism: When utilization reaches a configured "Activate" threshold, the firewall employs Random Early Drop (RED) to probabilistically drop packets from sessions consuming excessive buffer resources.
Configuration: Set under Device > Setup > Session Settings.
2. Per-Zone Packet Buffer Protection
Function: Adds a secondary layer of protection by monitoring buffer utilization within specific zones.
Mechanism: If RED is triggered globally and the offending session persists beyond a configured "Block Hold Time," the firewall can block the entire session or the source IP address for a defined "Block Duration."
Configuration: Enabled under Network > Zones
Two (2) Types of Packet Buffer Protection
A. Based on “Buffer Utilization”
Purpose: Triggers protection mechanisms when packet buffer usage exceeds certain thresholds.
Key Settings:
Alert (%): Threshold to generate alert logs (default: 50%).
Activate (%): Threshold to initiate RED (default: 80%).
Block Hold Time (sec): Duration before blocking an offending session (default: 60 seconds).
Block Duration (sec): Time to block the session or IP (default: 3600 seconds.
B. Based on Latency (since PANOS 10)
Purpose: Activates protection based on packet latency, which can indicate congestion even before buffer utilization thresholds are met.
Such packet buffer protection mitigates head-of-line blocking by alerting you to the congestion and performing random early drop (RED) on packets. Packet buffer protection based on latency can trigger the protection before latency-sensitive protocols or applications are affected.
Key Settings:
Latency Alert (ms): Threshold to generate alert logs (default: 50ms).
Latency Activate (ms): Threshold to initiate RED (default: 200ms).
Latency Max Tolerate (ms): Threshold where RED drops nearly all packets (default: 500ms).
Best Practices For PBP:
Configuration: We recommend enabling both PBP “per-zone” and also PBP “globally” (Globally under “Device > Setup> Session Settings and per zone under “Network > Zones” )
Baseline Monitoring: Regularly monitor packet buffer utilization to establish normal operating thresholds.
Threshold Tuning: Adjust Alert and Activate thresholds based on observed traffic patterns.
NAT Considerations: Be cautious when applying IP-based blocking in environments using NAT, as multiple users might share the same IP address
References:
Packet Buffer Protection
Best Practices
_________________________________________________________________________________________________
Part 2 - Troubleshooting Flood Attacks
This second part focuses on providing a high-level workflow that an NGFW Admin can use to troubleshoot Flood Attacks – and at the end, a list of valuable CLI Commands that they can refer to find the root cause and mitigate the impact.
A - “7-Step” Flood Attack Troubleshooting Workflow:
This workflow is a living document, feel free to add extra steps!
1. Identify Symptoms:
Like High CPU usage, elevated session counts, or unusual traffic spikes.
Increased latency or degraded application performance.
Dropped connections or connection resets.
Alerts from Panorama, SNMP monitoring tools, or Strata Cloud Manager.
End users reporting intermittent access or denial of service, etc.
2. Check Counters and Logs (CLI & GUI)
Start setting up basic capture filters: run "show counter global filter delta yes | match drop" to see what's causing packets to be drop; It should look like this:
name value rate severity category aspect description
-----------------------------------------------------------------------------------
flow_dos_red_tcp 1 0 drop flow dos Packets dropped: Zone protection protocol 'tcp-syn' RED
flow_dos_rule_drop 1 0 drop flow dos Packets dropped: Rate limited or IP blocked
flow_dos_rule_drop_aggr 1 0 drop flow dos Packets dropped: due to aggregate rate limiting
flow_dos_rule_ag_red_act 1 0 drop flow dos Packets dropped: Activate aggregate RED threshold reached, random early drop
flow_dos_rule_match 1 0 info flow dos Packets matched DoS policy
On GUI: Monitor > Logs > Threat → filter: (subtype eq flood)
Review type (ZPP, DoS, PBP), action (drop, reset, block)
3. Validate Zone Protection (ZPP) configuration
GUI: Network > Zones > Zone Protection Profile
CLI:
4. Validate DoS Protection (DoSP)
GUI: Policies > DoS Protection & Objects > DoS Protection Profiles
CLI:
5. Validate Packet Buffer Protection (PBP)
CLI:
TIP: Customers can enable PBP in monitor Mode; the FW won’t drop any traffic or block offenders but only monitors the traffic and figuring out aggressive sessions / sources.
i.e. No action is taken, only logging the offender in the “Threat logs” with the action “Alert” instead of “Drop” or “Block”.
6. Identify Sources:
Pinpointing Source IPs in Flood Attacks can be challenging, for many reasons:
Flood attacks may originate from thousands of IPs simultaneously (botnets).
Many flood attacks (e.g. UDP or ICMP floods) are stateless, meaning no session is established.
Since Palo Alto firewalls log most data at the session level, non-session traffic often bypasses visibility unless Zone Protection or custom packet captures are configured (No session = no log = hard to trace back).
If logging is not enabled for flood detection (in ZPP or DoS Profiles), or if packet captures aren’t set up, there may simply be no data to analyze.
If logs still don’t show source IP:
A - Try Spotting “ Traffic Anomalies” with Panorama ACC (or another traffic monitoring tool)
Widgets like "Top Applications," "Top Source IPs," and "Top Sessions" can highlight sudden spikes in traffic: A flood attack might show up as:
One or more IPs with abnormally high session counts
High volumes of UDP, ICMP, or unknown traffic
Traffic to/from a target resource that’s much higher than baseline
B - Perform Packet Captures:
Packet captures are extremely powerful for diagnosing network issues — but in the context of flood attacks, they’re often used as a last resort – for example when Logs are inconclusive or don’t show source IPs or when you suspect internal traffic or east-west floods.
Use basic filters or run unfiltered captures for ~30s to sample traffic
Then, try to identify patterns in flood traffic or sources
How to Take Packet Captures
7. Stopping the Flood:
As an immediate response: once the Source IP/IPs of the Flood have been flagged, apply a Security Policy Rule to block it.
Longer term preventative actions:
Review ZPP, DoSP & PBP profiles and configurations
Review thresholds, best practices and keep monitoring
B - Useful commands during time of Issue
1. Useful Global Counters
flow_dos_pbp_drop
What it Tracks: Increments for each packet dropped by Random Early Drop (RED) due to Packet Buffer Protection.
Use Case: Indicates RED-based PBP is active and throttling sessions based on buffer thresholds.
Interpretation: A high value here means the system is under buffer stress, and RED is actively dropping aggressive session traffic.
_________________________________________________________________________________________________
flow_dos_pbp_block_session (PAN-OS 10.0+ only)
What it Tracks: Increments once per session that is terminated and blocked by PBP.
Use Case: Tracks escalated action where a session exceeded thresholds even after RED, triggering a session block.
Interpretation: Reflects next-tier PBP mitigation beyond simple packet drops.
_________________________________________________________________________________________________
flow_dos_pbp_block_host (PAN-OS 10.0+ only)
What it Tracks: Increments once per host (source IP) that gets placed in the block list due to sustained buffer abuse.
Use Case: Useful for identifying aggressive clients or attackers being temporarily banned.
Interpretation: You’re seeing enforcement of block duration per host at the PBP level.
_________________________________________________________________________________________________
flow_dos_drop_ip_blocked
What it Tracks: Increments for each packet dropped from an IP that is currently blocked (due to Zone Protection, DoS Policies, or PBP).
Use Case: Captures ongoing traffic from IPs that have been blocked.
Interpretation: High values may indicate an attacker persisting even after block rules kicked in.
2. Zone Protection (ZPP) Commands:
> show zone-protection zone <zone-name>
Purpose: Displays the Zone Protection Profile applied to a specific zone.
Use case: Verify which protections (flood, reconnaissance, packet-based) are active for a given zone.
_________________________________________________________________________________________________
> show counter global filter severity drop reason zone-protection
Purpose: Displays global drop counters specific to Zone Protection activity.
Use case: Monitor packet drops caused by flood thresholds, port scans, malformed packets, etc.
_________________________________________________________________________________________________
> show zone-protection flood stats zone <zone-name>
Purpose: Provides detailed statistics for flood protection (SYN, ICMP, UDP) on a zone.
Use case: Identify flood patterns or confirm flood protection is being triggered.
_________________________________________________________________________________________________
> show zone-protection scan stats zone <zone-name>
Purpose: Displays statistics for reconnaissance protection (e.g., port scans, host sweeps).
Use case: Monitor scanning activity and confirm Zone Protection is catching it.
_________________________________________________________________________________________________
> show zone-protection packet-stats zone <zone-name>
Purpose: Displays statistics for packet-based attack protection, such as malformed TCP headers or IP spoofing.
Use case: Investigate dropped traffic due to protocol anomalies or attack signatures.
_________________________________________________________________________________________________
> debug dataplane packet-diag set log feature zone-protection on
Purpose: Enables verbose logging of packets dropped due to Zone Protection.
Use case: Advanced debugging when you need packet-level visibility for drops.
3. DOS Protection (DoSP) Commands:
> show dos-block-table all
Purpose: Shows all current DoS blocked entries (both software and hardware-enforced).
Use case: Identify which IPs or sessions are currently being blocked due to DoS thresholds.
_________________________________________________________________________________________________
> show dos-block-table software
Purpose: Filters to show only software-enforced blocks.
Use case: See which blocks are handled by software (vs. hardware offload).
_________________________________________________________________________________________________
> show dos-block-table hardware
Purpose: Filters to show only hardware-enforced blocks.
Use case: Monitor hardware-accelerated DoS protection (on supported platforms)
_________________________________________________________________________________________________
> debug dataplane show dos block-table
Purpose: Displays detailed, low-level view of the current DoS block table.
Use case: Deep dive into what’s blocked, by what rule, and for how long.
_________________________________________________________________________________________________
> debug dataplane reset dos block-table
Purpose: Manually clears all entries from the DoS block table.
Use case: Useful in lab testing or to quickly reset protections after a false positive.
_________________________________________________________________________________________________
> clear dos-protection zone <zone> blocked all
Purpose: Clears all currently blocked IPs or sessions in a specific zone.
Use case: Reset per-zone DoS blocks without touching the global block table.
_________________________________________________________________________________________________
> clear dos-block-table-all
Purpose: Clears all entries from both software and hardware DoS block tables.
Use case: Emergency cleanup — removes all DoS-enforced blocks.
4. Packet Buffer Protection (PBP) Commands:
> show session packet-buffer-protection
Purpose: Displays current sessions being tracked by Packet Buffer Protection.
Use case: See which sessions are considered aggressive or are causing buffer stress.
_________________________________________________________________________________________________
> show session packet-buffer-protection buffer-latency
Purpose: Shows latency measurements associated with packet buffers.
Use case: Helps understand if latency thresholds are being exceeded (indicates potential congestion).
_________________________________________________________________________________________________
> show running resource-monitor ingress-backlogs
Purpose: Provides statistics on ingress queue backlog in the firewall’s packet processing pipeline.
Use case: Useful to diagnose performance bottlenecks or delays at the ingress interface.
_________________________________________________________________________________________________
> debug dataplane pow performance
Purpose: Displays performance metrics for packet processing in the dataplane.
Use case: General performance debugging — includes metrics related to buffer usage and session load.
_________________________________________________________________________________________________
> debug dataplane pow performance | match pbp
Purpose: Filters output of the previous command to show only Packet Buffer Protection-specific stats.
Use case: Focus on PBP-specific performance metrics for troubleshooting.
... View more
