DoS and Zone Protection Best Practices

Deploy DoS and Zone Protection Using Best Practices

• Plan DoS and Zone Protection Best Practice Deployment
• Deploy DoS and Zone Protection Using Best Practices
• Follow Post Deployment DoS and Zone Protection Best Practices

DoS and Zone Protection deployment best practices help to ensure a smooth rollout that protects your network and your most critical servers.

DoS and Zone Protection help defend individual critical servers (DoS Protection) and zones (Zone Protection) against application-based and protocol-based flood attacks. They also provide the next layer of defense against volumetric attacks after your dedicated DDoS prevention device at the internet perimeter.

Measure average and peak connections-per-second (CPS) for critical servers and zones before you begin deployment so that you understand the baseline normal and peak CPS and can set intelligent flood thresholds.

Zone Protection profiles apply to new sessions in ingress zones and protect against flood attacks, reconnaissance (port scans and host sweeps), packet-based attacks, and layer 2 protocol-based attacks.

thresholds to drop traffic to prevent TCP SYN, UDP, ICMP, ICMPv6, and Other IP new session floods from affecting the firewall. Set the

Measure CPU consumption to ensure that the firewall can support DoS and Zone Protection and other features that consume CPU cycles, such as decryption.

and specify the timeframe to measure CPU consumption. If you use SNMP, you can pull the information from your monitoring system.

to control how the firewall drops sessions when flood thresholds are exceeded. There are tradeoffs between the methods:

—SYN Cookies drops traffic when the SYN-ACK handshake is bad. SYN Cookies doesn’t drop legitimate traffic, only traffic that violates handshake protocols, so it is inherently more fair than RED because it only drops bad traffic. SYN Cookies is also easier to deploy because it’s easier to set the flood thresholds. However, SYN Cookies consumes more resources, so when using SYN Cookies, monitor firewall CPU and memory utilization.

(RED)—Drops traffic indiscriminately (not based on threats, so both malicious and legitimate traffic is dropped) on a probability curve based on the

threshold, the firewall begins to drop sessions. As the number of sessions increase, the drop rate increases until it reaches the

session threshold. All new sessions above the Maximum CPS rate are dropped until the CPS rate drops below the Maximum threshold. The greater the difference between the Activate and Maximum CPS thresholds, the slower the drop probability rises as sessions increase from the

Whether to choose SYN Cookies or RED is a matter of available firewall resources, the number of sessions you want a zone to support, and how aggressively you want to drop traffic. Because SYN Cookies doesn’t impact legitimate traffic and RED does, you may prefer to start with SYN Cookies, monitor CPU and memory usage, and switch to RED if SYN Cookies consumes too many system resources.

When you set Zone Protection thresholds for SYN Cookies or RED, set them high enough to allow the normal and peak load of legitimate sessions and low enough to prevent floods. Because you’re protecting the entire zone, set Zone Protection thresholds higher than classified DoS Protection thresholds and slightly higher than aggregate DoS Protection thresholds. This method activates classified DoS Protection first for individual critical targets, aggregate DoS Protection (if used) second for groups of critical targets, and Zone Protection third.

thresholds determine when to start dropping bad SYN handshakes (Activate) and when to stop accepting SYN traffic (Maximum). SYN Cookies thresholds:

—Because SYN Cookies only punishes bad traffic, not legitimate traffic, activate SYN Cookies immediately (0 CPS threshold, which is the default value) so that no traffic with a bad SYN handshake is allowed.

—Because SYN Cookies only punishes bad traffic, set the Maximum to the maximum CPS capacity of the firewall platform, taking into account other active resource-intensive features, so that you don’t unnecessarily block good SYN traffic because of a low threshold. (A lower Maximum doesn’t drop bad traffic more aggressively because SYN Cookies drops bad traffic at the Activate threshold.)

When SYN Cookies reaches the Maximum threshold, the firewall blocks all sessions in the direction of the SYN flood for 5 minutes. Traffic in the other direction is not affected. The SYN Cookie block time is not configurable.

—Set just above the zone’s normal peak CPS rate to begin dropping connections to mitigate floods (don’t start dropping traffic that is within the normal peak activity), which is usually 15-20% above the

—Set the Maximum rate based on the firewall’s CPU utilization. If firewall CPU utilization is above 50%, set the Maximum CPS to twice the

rate. Crossing the Maximum threshold blocks new connections until the CPS rate falls below the threshold.

Firewalls with multiple dataplane processors (DPs) distribute connections across DPs. In general, the firewall divides the CPS threshold settings equally across its DPs. For example, if a firewall has five DPs and you set the

of 4,000 CPS (20,000 / 5 = 4,000), so if the new CPS on a DP exceeds 4,000, it triggers the Alarm Rate threshold for that DP.

Enable Reconnaissance Protection on all zones to block host sweeps, different types of scans, and other reconnaissance activities. Keep the default event

packets because source routing allows adversaries to bypass Security policy rules that use the destination IP address as the matching criteria. For internal zones only, drop

so that enabling or editing a Tunnel Content Inspection policy doesn’t cause the firewall to drop existing tunnel sessions.

Enable Protocol Protection to deny protocols you don’t use on your network and prevent layer 2 protocol-based attacks on layer 2 and vwire interfaces.

For vwire interfaces that face the public internet through a layer 3 device positioned in front of the firewall, enable

to allow only the layer 2 protocols that you use and automatically deny all other protocols. (Do not use the

Apply DoS Protection to specific, critical network resources, especially systems users access from the internet that are often attack targets, such as web and database servers.

DoS Protection provides a layer of defense to protect critical individual targets inside a zone. You set Zone Protection CPS thresholds to protect an entire zone, which receives a much higher aggregate CPS rate than most individual devices can handle. An attack that targets a single critical server may not have a high enough CPS rate to activate Zone Protection, which is why you configure DoS Protection for critical targets inside a zone. DoS Protection consists of:

DoS Protection policy rules, which specify the devices, users, zones, and services that define the traffic you want to protect from DoS attacks.

You add a DoS Protection profile to a DoS Protection policy rule. The profile defines the CPS thresholds that the firewall applies to the traffic defined in the policy rule.

Configure classified and/or aggregate DoS Protection profiles and apply one or both to a DoS Protection policy rule (each policy rule can have one of each profile type).

profiles set thresholds that apply to each individual device specified in a rule and leverage the hardware block table on platforms that have one.

profiles set thresholds that apply to the combined group of devices specified in a rule (the combined CPS rate of the group must exceed the threshold to activate DoS Protection) and use the software table.

to SYN Cookies or to Random Early Drop (RED) to control how the firewall mitigates attacks. Also similar, which to choose depends on available firewall resources, the number of sessions you want a zone to support, and how aggressively you want to drop traffic. Monitor system resource usage, and if SYN Cookies consumes too many resources, switch to RED. Always use RED if you don’t have a dedicated DDoS prevention device in front of the firewall.

When you set DoS Protection thresholds, set classified DoS Protection thresholds the lowest so that they activate first to protect critical individual targets. If you use aggregate DoS Protection, set those thresholds higher than classified DoS Protection thresholds and lower than Zone Protection thresholds so that aggregate DoS Protection activates only when classified DoS Protection isn’t sufficient but before Zone Protection.

) for each critical device or set of critical devices you want to protect. Set SYN, UDP, ICMP, ICMPv6, and Other IP flood thresholds and the

for SYN floods. Default threshold values often aren’t appropriate because each network is different—base thresholds on the capacity of the device(s) you’re protecting.

Measure firewall CPU consumption to ensure that the firewall can support DoS and Zone Protection and other features that consume CPU cycles, such as decryption.

—For classified profiles, set 15-20% above the device’s average CPS rate to account for normal fluctuations.

—Classified profiles apply specific CPS limits to individual devices. Base the limits on the capacity of the individual devices, so you don’t need to throttle CPS gradually and can set the

For aggregate profiles, set the threshold just above the normal peak CPS rate for the group to avoid dropping traffic that is within normal activity expectations. This is usually 15-20% above the

to the maximum capacity of the device(s) you’re protecting so they can’t be flooded but can accept their maximum traffic load.

For aggregate profiles, set the threshold to 80-90% of the group’s capacity. When CPS reaches the threshold, the firewall drops new connections for the

—Use the default value (300 seconds) to block the attacking session without penalizing legitimate sessions from the same source for too long a time period.

—For classified profiles, set 15-20% above the device’s average CPS rate to account for normal fluctuations.

—For classified profiles, set the threshold just above the target’s normal peak CPS rate to begin dropping connections and mitigating attacks (don’t set lower thresholds that drop traffic that is within normal peak activity), which is usually 15-20% above the

For aggregate profiles, set the threshold just above the normal peak CPS rate for the group to avoid dropping traffic that is within normal activity expectations. This is usually 15-20% above the

—For classified and aggregate profiles, set the Maximum rate based on the firewall’s CPU utilization. If firewall CPU utilization is above 50%, set the Maximum CPS to twice the

rate. Crossing the Maximum threshold blocks new connections until the CPS rate falls below the threshold.

Set the Maximum rate no higher than the capacity of the individual device (classified) or 80-90% of the group’s capacity (aggregate) to avoid allowing more connections than the target can handle.

—Use the default value (300 seconds) to block the attacking session without penalizing legitimate sessions from the same source for too long a time period.

). Make each rule as specific as possible to protect critical devices while preserving firewall CPU and memory resources. Attach DoS Protection profiles to DoS Protection policies. In the policy rule, set:

—Specify the services (ports) in use on the server(s) you’re protecting. If you’re protecting web servers, specify HTTP, HTTPS, and other appropriate service ports for the web applications.

—For easier management, forward DoS logs separately from other Threat logs directly to administrators via email and to a log server.

—Use classified profiles to protect critical individual servers. You must use a classified profile to leverage the hardware block table.

—Counters consume firewall resources. For classified DoS Protection profiles, specify whether connections count toward profile thresholds based on matching the

). Your DoS protection goals, what you are protecting, and whether the protected devices are in internet-facing zones determine how to configure the threshold counter.

for internet-facing zones because the firewall can’t store counters for all possible internet IP addresses. Use

to protect individual critical devices. Set the Maximum threshold below the CPS rate that each device specified in the policy can handle.

Enable Packet Buffer Protection globally to protect the firewall buffers from single-session DoS attacks, from attacks from a single source IP address, and from source IP addresses that create many small sessions that combine to consume packet buffers.

Global Packet Buffer Protection is the first phase of a two-phase approach to protecting the firewall buffers and is enabled by default. (Step 4 shows the second phase, per-zone Packet Buffer Protection, which is also enabled by default.) Global Packet Buffer Protection detects individual sessions or source IP addresses that threaten to consume the firewall packet buffer and applies RED to those sessions or packets to drop more packets as buffer congestion increases.

The goal of Packet Buffer Protection is to prevent the firewall from getting into and staying in a high latency, high buffer utilization state by first applying RED to drop offending packets (global protection) and then discarding the offending session or blocking the offending source IP address (session or host blocking) if the attack continues (per-zone protection). The idea is to protect the packet buffers at both the software and hardware levels and at the same time to have low latency and packet loss, and to discard or block offending traffic at the right time.

Packet Buffer Protection also protects the firewall buffers if a host sends a large amount of traffic that the firewall processes and denies serially without setting up a session. This traffic usually has the same 6-tuple identifier (source and destination IP, source and destination port, protocol, and ingress zone). The resources required to process each packet and then deny it consumes firewall resources if you don’t enable Packet Buffer Protection.

If per-zone Packet Buffer Protection is enabled and buffer consumption reaches a high level and is sustained for a configurable amount of time, the firewall discards the offending sessions or hosts only. If per-zone Packet Buffer Protection is disabled, the firewall performs RED but does not discard or block traffic.

Use baseline measurements of packet buffer utilization to understand the firewall’s capacity and to ensure that the firewall is properly sized so that only an attack causes a large spike in buffer usage. Understand the packet buffer utilization during normal peak-hour operation and at which point latency or drop issues occur. If the firewall’s capacity is low enough that normal traffic causes spikes in buffer usage, you may need a higher-capacity firewall.

mode, the firewall monitors packet buffer utilization and alerts on offending sessions and sources, but doesn't block or drop them. The tradeoff is that you can experiment with different

thresholds and see the results in the Threat logs without affecting traffic, but the firewall isn't protected from packet buffer attacks. If you can replicate production traffic in a non-production environment, you can safely experiment with

thresholds to see which sessions are penalized with different threshold settings and what thresholds begin to impact legitimate traffic.

) based on buffer utilization or on CPU processing latency. Packet Buffer Protection based on CPU processing latency responds to sudden large bursts of packets faster than buffer protection based on percentage of buffer utilization.

—Start with the default value (50%), monitor packet buffer utilization, and adjust the thresholds if necessary.

threshold is 80% in PAN-OS 10.0 and later and 50% in PAN-OS 9.1 and earlier. Instead of using the defaults, it's safest to set the activation threshold to 10-20% above your baseline usage and then monitor packet buffer utilization. Adjust the threshold until Packet Buffer Protection activates in time to penalize offending sessions but doesn't penalize normal usage.

setting depends on your environment and available processing resources, so experimentation is usually necessary. The lower the

threshold, the more likely that legitimate traffic is blocked, but attack mitigation begins sooner. The higher the threshold, the longer it takes to begin mitigating an attack, but the less likely that legitimate traffic is impacted.

If the activation threshold is too high for the environment, you experience the impact of the high load and/or latency on legitimate traffic before packet buffer protection activates.

If the activation threshold is too low for the environment, the firewall unnecessarily drops too many legitimate packets even though resources are available to handle the traffic. (This could also occur if there are other network issues.)

If the activation threshold is about right for the environment, very little legitimate traffic is dropped and firewall resources are not stressed. Knowing your baseline packet buffer load is key to adjusting the thresholds properly. For example, if you know that during peak hours, packet buffer utilization can spike to 40-50% of the firewall's capacity and that you experience issues when packet buffer utilization reaches 60-70%, then set the