Plan DoS and Zone Protection Best Practice Deployment
Table of Contents
Expand all | Collapse all
Plan DoS and Zone Protection Best Practice Deployment
Plan DoS protection against different attack types, take a layered approach, and understand normal and peak CPS rates of individual devices you want to protect.
This section discusses best practices for what you need to know and plan for before you implement DoS and Zone Protection, including:
- How to understand the average normal and peak baseline connections-per-second (CPS) of zones and critical devices you want to protect and its effect on CPU consumption.
If your platform supports a hardware block table, plan to use classified DoS Protection as much as possible to protect critical individual servers. Classified DoS Protection leverages the hardware block table to store blocked IP addresses, which saves system software resources and improves performance. These platforms support the hardware block table:
- PA-3200 Series firewalls
- PA-5200 Series firewalls
- PA-5400 Series firewalls
- PA-7000 Series firewalls
To use hardware block table for DoS Protection, in addition to platform support:
- The DoS Protection policyActionmust beProtect.
- The DoS Protection profile must be a classified profile.
- You must use RED as the drop mechanism.
- You must usesource-ip-onlyorsrc-dest-ip-bothas the classifiedAddressin the DoS Protection policy.
- Plan your defense against each type of DoS attack.
- Volumetric Attacks—High-volume attacks that attempt to overwhelm the available network resources, especially bandwidth, and take down the target to prevent legitimate users from accessing its resources. An example is a UDP flood attack. These attacks can originate from a single source IP (DoS attack) or many source IPs (DDoS attack; source IP addresses may rotate and the attack may come as a high CPS rate and/or high volume of traffic).
- Plan a layered approach to preventing DoS attacks.The firewall provides visibility into application traffic that dedicated DoS protection devices don’t provide. Combine high-volume DDoS protection at the network perimeter with layers of DoS Protection for individual devices and Zone Protection for the entire zone as needed to defend your network and critical individual devices from DoS attacks:
Threshold Planning for Using Zone Protection and DoS Protection Together—If your platform supports a hardware block table, plan to set classified DoS Protection thresholds lower than Zone Protection thresholds so DoS Protection activates first and Zone Protection provides an extra layer of defense, if needed. If you want to maximize protection for a group of critical devices, for example, web servers or internet-facing file servers, add aggregate DoS Protection with thresholds set higher than the classified DoS Protection thresholds and lower than Zone Protection thresholds. (This causes classified DoS Protection to activate first, aggregate DoS Protection to activate second, and Zone Protection to activate third, if needed.)If you platform does not support a hardware block table, the same methodology still applies, but you don’t get the added benefit of offloading to the hardware block table.
- Use a dedicated, high-volume DDoS protection device or a perimeter router, switch, or other hardware-based packet drop device with appropriate access control lists (ACLs) as the first layer of defense at the internet-facing network perimeter. Position the dedicated high-volume DDoS devices in front of perimeter firewalls to defend them against high-volume attacks, which the session-based firewall isn’t designed to handle.
- Apply classified DoS Protection profiles and policies to protect individual or small groups of high-value targets (DoS Protection profiles and policy rules):
- Protect critical internet-facing servers by limiting the CPS to each server.
- Prevent misconfigured or compromised internal hosts from carrying out a DoS attack by limiting the CPS either from the suspect source (internally-facing zones only, not internet-facing zones) or to the affected destination.
- Monitor a particular source (internally-facing zones only) and alert you if the CPS from that source reaches a certain threshold, which may indicate a compromised or misconfigured host.
- Defend specific devices inside a zone if the firewall supports using the hardware block table.
- Gain visibility into IP addresses associated with the attack in the logs regardless of whether the firewall supports using the hardware block table or the software block table.
- Aggregate DoS Protection profiles and policies provide another extra layer of broad protection for groups of critical servers, if needed. In most cases, classified DoS Protection for individual critical servers and Zone Protection for the entire zone is sufficient and avoids configuration complexity. In addition, aggregate DoS Protection logs don’t show IP addresses associated with an attack and policies don’t leverage the hardware block table. To gain visibility into attacking IP addresses, use classified DoS Protection.Aggregate DoS Protection differs from Zone Protection in that Zone Protection defends an entire zone from attacks while aggregate DoS Protection protects a small group of critical devices inside a zone. Aggregate DoS Protection differs from classified DoS Protection in that classified DoS Protection sets a CPS threshold for each individual device while aggregate DoS Protection sets a CPS threshold for a group of devices.
- Position firewalls as close as possible to the resources they protect.Firewalls don’t scale to millions of CPS because they are session-based. The closer you place firewalls to resources you’re protecting, the fewer sessions and firewall resources the traffic consumes.
- Position perimeter firewallsbehinddedicated, high-capacity perimeter DDoS devices or perimeter routers or switches that use ACLs to drop DoS traffic. This protects the firewalls that segment the enterprise network into zones and protect the devices in those zones. The closer a firewall is to the perimeter, the greater its capacity must be to handle the higher volume of traffic.
- Examine your network zone segmentation. If it isn’t granular enough, consider creating smaller zones. Smaller zones increase security in many ways, including better prevention of lateral movement of malware, increased visibility into traffic, and reduced potential scope of internal DoS attacks.
- Take average and peak CPS baseline measurements for the individual critical devices and for the zones you want to protect, and understand the capacity of your firewalls so flood thresholds don’t inadvertently throttle traffic or allow DoS attacks. Measure CPS with other normal resource-consuming features such as decryption, URL Filtering, and GlobalProtect running during peak and normal peak traffic times.
- For Zone Protection profile thresholds, if you run PAN-OS 10.0 or later, use the Zone Protection profile Threshold Recommendation alerts from the AIOps cloud service, which uses system telemetry to provide accurate estimates of average and average peak CPS values. Sign up firewalls and Panorama for the service. (With PAN-OS 10.2.1 or later, you can install the AIOps plugin for Panorama to proactively enforce security checks on configurations before you push them to managed firewalls.)If you can’t use AIOps, use the firewall ACC and other tools to take baseline CPS measurements for each firewall zone over at least one business week, during business hours. The longer the data collection time span, the more accurate the measurements. Measure normal and peak CPS for each individual zone to set appropriate Zone Protection flood thresholds for each zone.
- For DoS Protection, take baseline measurements of average and peak CPS for critical devices (potential targets). Use the same tools to examine buffer utilization.
Understanding the normal peak CPS of the zones and individual devices is crucial for setting appropriate threshold values in Zone Protection and DoS Protection profiles. If you’re too aggressive (set thresholds too low and allow too few CPS), you may inadvertently throttle legitimate traffic during peak activity. If you’re too passive (set thresholds too high and allow too many CPS), it may not be enough protection to mitigate a DoS attack and the resources that you’re trying to protect may be affected.
- Take baseline CPS measurements for critical internet-facing devices over at least one business week, during business hours. The longer the data collection time span, the more accurate the measurements.
- Work with application teams to understand the normal and peak CPS to their servers and the maximum CPS those servers can support.
- Filter firewall Traffic and Threat logs for the destination IP addresses of critical devices to baseline normal and peak session activity.
- Take into account special events, quarterly events, and annual events that may increase traffic, change traffic patterns, or use applications that aren’t usually on the network.
- Understand the capacity of your firewalls and the resources (CPU and memory) other features consume so you know the capacity available for DoS Protection. Measure CPS with other normal resource-consuming features running during peak and normal traffic times.
- If you use Panorama to manage firewalls, use Device Monitoring to measure CPS values. Device monitoring can also show you a 90-day trend line of CPU average and peak usage to help you understand the typical available capacity of each firewall.If you can’t use Panorama’s Device Monitoring and you use SNMP, you can use your management tools to poll the following three MIBs to gather historical CPS data: PanZoneActiveTcpCps, PanZoneActiveUdpCps, and PanZoneOtherIpCps.The MIBs show twice the actual CPS value because the MIBs count the C2S and S2C session segments separately instead of as a single session. For example, if a MIB shows a CPS value of 10,000, the true CPS value is 5,000.
- Use third-party tools such as Wireshark or NetFlow to collect and analyze network traffic.
- Consider using scripts to automate CPS information collection and continuous monitoring, and to mine information from the logs.
- Configure a Log Forwarding trigger (traffic match criteria) to automatically make an upstream device such a switch, a router, or a dedicated DDoS device perform additional filtering and blocking when the firewall is under attack and to protect firewall resources.When youconfigure a Log Forwarding trigger and the trigger conditions occur, the firewall automatically sends an API call to the upstream device to take action against the attack.Specify the upstream device or devices and the API call (the action for the upstream device or devices to take) in an HTTP Server profile (). Specify the upstream device(s) in theDeviceServer ProfilesHTTPServerstab and specify the API call in thePayloadfield in thePayload Formattab.Specify the traffic match conditions that trigger the API call in a Log Forwarding profile () match list filter.ObjectsLog Forwarding
- To trigger on a particular type of attack, use the Filter Builder to create a filter that matches the Threat logs for the traffic you want to filter or block. For example, the following filter specifies three threat IDs that correspond to FTP Brute Force Login, HTTP Request Brute Force Attack, and Apache Benchmark Brute Force DOS Attack threat IDs:
Configuring Log Forwarding to trigger on these threat signatures enables the firewall to send the API call that asks the specified upstream device(s) to filter or block the offending traffic.
- (threatid eq 40001) or (threatid eq 39290) or (threatid eq 35075)
- To protect firewall resources from attacks, especially on platforms with smaller block tables, use the Filter Builder in the Log Forwarding profile to create a filter that triggers under DoS attack conditions so that the upstream device blocks offending traffic instead of allowing that traffic to consume firewall block list resources.Check the capacity of the upstream device to ensure that it can handle the traffic load.Configuring Log Forwarding to trigger on DoS traffic conditions enables the firewall to send an API call that asks the specified upstream device(s) to send the traffic to a null route and silently discard the traffic, thus saving firewall block table resources.