Deploy DoS and Zone Protection Using 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, and provide the next layer of defense against volumetric attacks after your dedicated DDoS prevention device at the internet perimeter. You must measure average and peak connections-per-second (CPS) to understand the network’s baseline and to set intelligent flood thresholds.
- Create Zone Protection profiles and apply them to defend each zone.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.
- SetAlarm Rate,Activate, andMaximumthresholds to prevent SYN, UDP, ICMP, ICMPv6, and Other IP new session floods from taking down the firewall, and set theActionfor SYN floods.Measure CPU consumption to ensure the firewall can support DoS and Zone Protection and other features that consume CPU cycles, such as decryption.
Alternatively, when you understand the maximum CPS you can support, start by setting theMaximumCPS rate to 80-90% of firewall capacity and derive reasonableActivateandAlarm Ratethresholds based on theMaximumthreshold.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 theAlarm Rateto 20,000 CPS, then each DP has anAlarm Rateof 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.
- Action(SYN flood only)—Start with SYN Cookies, which treats legitimate traffic fairly but consumes more resources, as the drop mechanism for theActivateandMaximumthresholds. Monitor firewall CPU and memory utilization. If SYN Cookies consumes too many resources, switch to Random Early Drop (RED), which randomly drops connections. If you don’t have a dedicated DDoS prevention device in front of the firewall, always use RED.
- Alarm Rate—Set 15-20% above the average zone CPS rate to accommodate normal fluctuations.
- Activate—Set just above the zone’s peak CPS rate to begin dropping connections to mitigate floods.
- Maximum—Set to 80-90% of firewall capacity. Account for other resource-consuming features. Crossing this threshold blocks new connections until the CPS rate falls below the threshold.
- Monitor and adjust the thresholds as needed.
- Enable Reconnaissance Protection on all zones to block host sweeps and TCP and UDP port scans. Keep the default eventThresholdto log a few packets for analysis before blocking the reconnaissance operation. UseSource Address Exclusionto allow internal groups that test for network vulnerabilities.
- Drop suspicious packets to prevent packet based attacks.
- IP Drop—DropUnknownandMalformedpackets. DropStrict Source RoutingandLoose Source Routingpackets because source routing allows adversaries to bypass Security policy rules that use the destination IP address as the matching criteria. For internal zones only, dropSpoofed IP addresspackets to ensure that on ingress, the source address matches the firewall routing table.
- TCP Drop—Retain the default drop selectionsTCP SYN with DataandTCP SYNACK with Data, selectMismatched overlapping TCP segmentandSplit Handshake, and enable the strip optionTCP Timestamp.If you configure Tunnel Content Inspection on a zone and enableRematch Sessions, for that zone only, disableReject Non-SYN TCPso that enabling or editing a Tunnel Content Inspection policy doesn’t cause the firewall to drop existing tunnel sessions.
- ICMP Drop—What to block depends on how (or if) you use ICMP.
- IPv6 Drop—If compliance matters, drop packets with non-compliant routing headers, extensions, etc.
- ICMPv6 Drop—If compliance matters, drop certain packets that don’t match a Security policy rule.
- 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 front of the firewall, enableProtocol Protectionon internet-facing zones.
- For layer 2 zones, enableProtocol Protectionon internet-facing zones. On internal layer 2 zones, enableProtocol Protectionand use theInclude Listto allow only the layer 2 protocols that you use and automatically deny all other protocols. (Do not use theExclude List, which allows all protocols not on the list.) If you don’t configureProtocol Protection, all layer 2 protocols are allowed.
- Attach a profile to each zone () in theNetworkZonesZone Protection Profilefield.
- 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 adds another layer of defense against attacks on individual devices, which can succeed if the Zone Protection profile thresholds are above the CPS rate of the attack on the device (if the aggregate CPS rate for the zone is below the attack rate on the individual device, Zone Protection is not activated). DoS protection consists of:
You add a DoS Protection profile to a DoS Protection policy rule. The profile defines how the firewall applies DoS protection to traffic and the policy defines the traffic to which the firewall applies the profile’s DoS protection. Because DoS Protection is resource-intensive, use it only for critical systems. Configure classified and 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).Classifiedprofiles set thresholds that apply to each individual device specified in a rule.Aggregateprofiles set thresholds that apply to the combined group of devices specified in a rule.
- DoS Protection policy rules, which specify the devices, users, zones, and services that define the traffic you want to protect from DoS attacks.
- DoS Protection profiles, which set flood thresholds for different types of traffic.
- Create a DoS Protection profile () for each critical device or set of critical devices you want to protect. Set SYN, UDP, ICMP, ICMPv6, and Other IP flood thresholds and theObjectsSecurity ProfilesDoS ProtectionActionfor 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.
- Action(SYN flood only)—Set the SYN Cookies or RED drop mechanism forActivateandMax Ratethresholds. Start with SYN Cookies, which treats legitimate traffic fairly but consumes more resources. Monitor CPU and memory utilization. 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.
- Alarm Rate—For classified profiles, set 15-20% above the device’s average CPS rate to account for normal fluctuations. For aggregate profiles, set 15-20% above the group’s average CPS rate.
- Activate Rate—Classified profiles apply exact CPS limits to individual devices and you base those limits on the capacity of the devices, so you don’t need to throttle CPS gradually and can set theActivate Rateto the same threshold as theMax Rate. Set theActivate Ratelower than theMax Rateonly if you want to begin dropping traffic before it reaches theMax Rate. For aggregate profiles, set the threshold just above the peak CPS rate for the group.
- Max Rate—For classified profiles, base theMax Rateon the capacity of the device(s) you’re protecting so they can’t be flooded. For aggregate profiles, set to 80-90% of the group’s capacity. When CPS reaches the threshold, the firewall drops new connections for theBlock Duration.
- Block Duration—For all profiles, 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.
- Monitor and adjust the thresholds as needed.
- Create DoS Protection policy rules (). Make each rule as specific as possible to protect critical devices while preserving firewall CPU and memory resources. Attach DoS Protection profiles and set:PoliciesDoS Protection
- Service—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.Use separate DoS Protection policy rules for critical servers’ unused service ports.
- Action—SelectProtectto apply the rule’s DoS Protection profile(s) to the specified devices.
- Aggregate—Use aggregate profiles to protect critical server groups.
- —Use classified profiles to protect individual or small groups of critical servers.ClassifiedProfile
- —Counters consume firewall resources. For classified DoS Protection profiles, specify whether connections count toward profile thresholds based on matching theClassifiedAddresssource-IP-only, thedestination-IP-only, or both (src-dest-ip-both). 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.Don’t usesrc-ip-onlyorsrc-dest-ip-bothfor internet-facing zones because the firewall can’t store counters for all possible internet IP addresses. Usedestination-IP-onlyin perimeter zones.Usedestination-IP-onlyto protect individual critical devices.Usesource-IP-onlyand theAlarmthreshold to monitor suspect hosts (non-internet-facing zones).The firewall consumes more resources to tracksrc-dest-ip-bothcounters than to track only the source IP or destination IP counters.
- 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 disabled by default, so you must enable it. (Step 4 shows the second phase, per-zone Packet Buffer Protection, which is also disabled 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 (host) 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 you enable per-zone Packet Buffer Protection 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.
How you set Packet Buffer thresholds depends on your network traffic and how you want to treat that traffic:
- Use baseline measurements of packet buffer utilization to understand the firewall’s capacity and ensure that the firewall is properly sized so that only an attack causes a large spike in buffer usage. If the firewall’s capacity is low enough that normal traffic causes spikes in buffer usage, you may need a higher-capacity firewall.
- Set global Packet Buffer Protection thresholds ():DeviceSetupSessionSession Settings
- Alert—Start with the default value (50%), monitor packet buffer utilization, and adjust the thresholds if necessary.
- Activate—The default value (50%) for activating RED may be too low to effectively mitigate high packet buffer utilization when per-zone protection is enabled. This is because the firewall may drop packets too aggressively to reach and remain above the per-zone discard/block countdown threshold, which is a hard-coded value of 80%. If packet buffer utilization is too high, set theActivatethreshold to 80% or 81%. This prevents RED from happening so early that the discard/block threshold is never reached for per-zone protection.
- Set timers () to define when to discard an offending session or block an offending source IP address. The firewall only uses these thresholds and timers if you enable per-zone Packet Buffer Protection. If only global Packet Buffer Protection is enabled, the firewall performs RED on the traffic but doesn’t discard or block it.DeviceSetupSessionSession SettingsBase settings on experiences with and measurements of buffer utilization, your tolerance for packet drop due to buffer congestion, and how aggressively you want to drop traffic to avoid packet buffer consumption that impacts the network and its users.
- Block Hold Time—The amount of time the offending session can remain above the hard-coded discard/block countdown threshold before the firewall discards the session or blocks the source IP address. Start with the default value (60 seconds), monitor packet buffer utilization, and adjust the time if necessary. When theBlock Hold Timereaches 0, the firewall discards the session or blocks the source IP address.
- Block Duration—The amount of time after theBlock Hold Timeexpires that the source IP address is quarantined (blocked). Start with the default value (3600 seconds) or reduce the value if blocking a source IP address for one hour is too great a penalty for your business conditions. Monitor packet buffer utilization and adjust the value if necessary.
- The default settings are conservative and favor allowing packet buffer congestion to continue longer before discarding sessions or blocking source IP addresses (per-zone protection). The firewall doesn’t block potentially legitimate sessions and sources as quickly during periods of congestion, but at the potential cost of slowing down legitimate sessions that aren’t causing packet buffer congestion.
- If the default settings take too long to mitigate packet buffer consumption issues (user complaints about network slowness may indicate an issue), increase theActivaterate, which prevents RED from dropping packets so fast that it doesn’t reach the buffer utilization threshold for discarding an offending session or blocking an offending source IP address. Discarding or blocking offending traffic faster means that legitimate traffic that is not causing packet buffer consumption issues won’t be subject to packet drop issues because of the offending traffic, but the offending traffic is quarantined. However, a legitimate session or source IP address that sends a lot of traffic could be quarantined.For example, setting theActivaterate to 81% means that the buffer utilization rate will exceed the firewall’s hard-coded internal countdown threshold (80% buffer utilization) before applying RED to the traffic. In this scenario, the countdown to discarding or blocking offending traffic continues for theBlock Hold Time. This results in the desired action of mitigating excessive packet buffer utilization, instead of flapping over and under the internal activate and deactivate thresholds, which results in not discarding or blocking offending traffic because theBlock Hold Timenever reaches zero (0).
- If you are concerned that setting theActivaterate higher could block important legitimate traffic, such as DNS or other critical infrastructure traffic, you can increase theBlock Hold Timefrom 60 seconds to a longer value such as 120 seconds or 300 seconds to delay the quarantine action accordingly.
- Tune the Packet Buffer Protection thresholds to achieve the balance of packet loss versus when to discard sessions or block source IP addresses that makes sense for your network.
- The second phase of Packet Buffer Protection protects firewall buffers on a per-ingress-zone basis and is disabled by default. Global Packet Buffer Protection must be enabled or per-zone Packet Buffer Protection does not work. Per-zone Packet Buffer Protection discards offending sessions and blocks offending source IP addresses and is a best practice when you need an extra layer of protection for particular ingress zones.Disable per-zone Packet Buffer Protection when you do not want to block source IP addresses or discard sessions for a particular zone (and enable global Packet Buffer Protection so that the firewall uses RED as a primary layer of protection). Blocking a source IP address blocks all traffic from that address, not just the offending session. If the source IP address is a NAT device, it could represent a large number of user flows originating behind the NAT device.
When you consider enabling or disabling per-zone Packet Buffer Protection, think not only about zones that are vulnerable to attacks from the outside, also think about potential insider threats, accidentally misconfigured internal devices, faulty NIC adapters that generate large amounts of illegitimate traffic, and firewall misconfiguration that denies legitimate traffic from a device that sends a significant amount of traffic to the firewall using the same 6-tuple identifier (source and destination IP, source and destination port, protocol, and ingress zone).
- To enable per-zone protection,, select an existing zone orNetworkZonesAdda zone, and then select or deselectEnable Packet Buffer Protection.
- Attach the best practice Vulnerability Protection profile to all Security policy allow rules.The combination of dedicated, high-volume DDoS protection at the perimeter, Zone Protection profiles, DoS Protection profiles and policy rules, Packet Buffer Protection, and Vulnerability Protection for allowed traffic provides multiple layers of DoS protection for your network and its most critical resources.
Recommended For You
Recommended videos not found.