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.
  1. Create and apply a Zone Protection profile 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.
    • Set
      Alarm Rate
      , and
      thresholds to prevent SYN, UDP, ICMP, ICMPv6, and Other IP new session floods from taking down the firewall, and set the
      for 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.
      • Action
        (SYN flood only)—Start with SYN Cookies, which treats legitimate traffic fairly but consumes more resources, as the drop mechanism for the
        thresholds. 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.
      Alternatively, when you understand the maximum CPS you can support, start by setting the
      CPS rate to 80-90% of firewall capacity and derive reasonable
      Alarm Rate
      thresholds based on the
      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
      Alarm Rate
      to 20,000 CPS, then each DP has an
      Alarm Rate
      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.
      • 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 event
      to log a few packets for analysis before blocking the reconnaissance operation. Use
      Source Address Exclusion
      to allow internal groups that test for network vulnerabilities.
    • Drop suspicious packets to prevent packet based attacks.
      • IP Drop
        packets. Drop
        Strict Source Routing
        Loose Source Routing
        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
        Spoofed IP address
        packets to ensure that on ingress, the source address matches the firewall routing table.
      • TCP Drop
        —Retain the default drops, drop
        Mismatched overlapping TCP segment
        Split Handshake
        packets, and enable the strip option
        TCP Timestamp
        If you configure Tunnel Content Inspection on a zone and enable
        Rematch Sessions
        , for that zone only, disable
        Reject Non-SYN TCP
        so 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.
      • Enable
        Protocol Protection
        on internet-facing zones.
      • Use the
        Include List
        to allow the layer 2 protocols you use and deny all other protocols (the
        Exclude List
        allows all protocols not on the list). If you don’t configure
        Protocol Protection
        , all layer 2 protocols are allowed.
    • Attach a profile to each zone (
      ) in the
      Zone Protection Profile
  2. 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.
    A DoS attack that targets an individual system can succeed if the aggregate CPS rate doesn’t exceed the Zone Protection profile’s thresholds, so you also need DoS protection. DoS Protection profiles set flood thresholds and DoS Protection policy rules define the devices, users, zones, and services to which DoS Profiles apply. 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).
    profiles set thresholds that apply to each individual device specified in a rule.
    profiles set thresholds that apply to the combined group of devices specified in a rule.
    • 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 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.
      • Action
        (SYN flood only)—Set the SYN Cookies or RED drop mechanism for
        Max Rate
        thresholds. 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 the
        Activate Rate
        to the same threshold as the
        Max Rate
        . Set the
        Activate Rate
        lower than the
        Max Rate
        only if you want to begin dropping traffic before it reaches the
        Max Rate
        . For aggregate profiles, set the threshold just above the peak CPS rate for the group.
      • Max Rate
        —For classified profiles, base the
        Max Rate
        on 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 the
        Block 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:
      • 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
        to apply the rule’s DoS Protection profile(s) to the specified devices.
      • —For easier management, forward DoS logs separately from other Threat logs directly to administrators via email and to a log server.
      • Aggregate
        —Use aggregate profiles to protect critical server groups.
      • Classified
        —Use classified profiles to protect individual or small groups of critical servers.
      • Classified
        —Counters consume firewall resources. For classified DoS Protection profiles, specify whether connections count toward profile thresholds based on matching the
        , the
        , or 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 use
        for internet-facing zones because the firewall can’t store counters for all possible internet IP addresses. Use
        in perimeter zones.
        to protect individual critical devices.
        and the
        threshold to monitor suspect hosts (non-internet-facing zones).
        The firewall consumes more resources to track
        counters than to track only the source IP or destination IP counters.
  3. Apply Packet Buffer Protection to each zone to protect the firewall buffers from single-session DoS attacks.
    • 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.
    • Set global Packet Buffer Protection thresholds:
      • Alert
        —Use the default value (50%), monitor packet buffer utilization, and adjust the thresholds if necessary.
      • Block Hold Time
        —Use the default value (60 seconds) for the amount of time the offending session can continue before the firewall blocks it. Monitor packet buffer utilization and adjust the time if necessary.
      • Block Duration
        —Use the default value (3600 seconds) for the amount of time after the
        Block Hold Time
        expires to block every session from the offending IP address, or reduce the value if blocking an IP address for one hour is too great a penalty for your business conditions. Monitor packet buffer utilization and adjust the value if necessary.
    Network Address Translation (NAT) can increase packet buffer utilization because of IP address translation activity. If this affects the utilization thresholds, reduce
    Block Hold Time
    to block individual sessions faster and reduce
    Block Duration
    so other sessions from the underlying IP address aren’t unduly penalized.
  4. 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