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. 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.
  1. Create Zone Protection profiles (
    Network
    Network Profiles
    Zone Protection
    ) 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.
    • Set
      Alarm Rate
      ,
      Activate
      , and
      Maximum
      thresholds to drop traffic to prevent TCP SYN, UDP, ICMP, ICMPv6, and Other IP new session floods from affecting the firewall. Set the
      Action
      for SYN floods.
      Measure CPU consumption to ensure that the firewall can support DoS and Zone Protection and other features that consume CPU cycles, such as decryption.
      If you have Panorama, use Health Monitor (
      Panorama
      Managed Devices
      Health
      ) to check CPU and memory consumption over a specified time period. If you don’t have Panorama, run
      show running resource-monitor
      and specify the timeframe to measure CPU consumption. If you use SNMP, you can pull the information from your monitoring system.
      For TCP SYN floods, set the
      Action
      to
      Random Early Drop
      or to
      SYN Cookies
      to control how the firewall drops sessions when flood thresholds are exceeded. There are tradeoffs between the methods:
      • SYN Cookies
        —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.
      • Random Early Drop
        (RED)—Drops traffic indiscriminately (not based on threats, so both malicious and legitimate traffic is dropped) on a probability curve based on the
        Activate
        and
        Maximum
        CPS thresholds that you set. When CPS reaches the
        Activate
        threshold, the firewall begins to drop sessions. As the number of sessions increase, the drop rate increases until it reaches the
        Maximum
        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
        Activate
        threshold to the
        Maximum
        threshold.
      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.
      SYN Cookies drops traffic that presents bad SYN handshakes. The
      Activate
      and
      Maximum
      thresholds determine when to start dropping bad SYN handshakes (Activate) and when to stop accepting SYN traffic (Maximum). SYN Cookies thresholds:
      • Alarm Rate
        —Set 15-20% above the average CPS rate of the zone to accommodate normal fluctuations.
      • Activate
        —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.
      • Maximum
        —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.
      RED thresholds:
      • Alarm Rate
        —Set 15-20% above the average CPS rate of the zone to accommodate normal fluctuations.
      • Activate
        —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
        Alarm Rate
        .
      • Maximum
        —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
        Activate
        rate. If firewall CPU utilization is below 50%, set the Maximum CPS to three times the
        Activate
        rate and monitor CPU usage. If CPU usage is too high, reduce the Maximum to twice the
        Activate
        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
      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
      Logs
      Threat
      and filter for
      Log Type
      flood
      to view alarms.
      • 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
      Threshold
      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
        —Drop
        Unknown
        and
        Malformed
        packets. Drop
        Strict Source Routing
        and
        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 drop selections
        TCP SYN with Data
        and
        TCP SYNACK with Data
        , select
        Mismatched overlapping TCP segment
        and
        Split Handshake
        , 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.
      • For vwire interfaces that face the public internet through a layer 3 device positioned in front of the firewall, enable
        Protocol Protection
        on internet-facing zones.
      • For layer 2 zones, enable
        Protocol Protection
        on internet-facing zones. On internal layer 2 zones, enable
        Protocol Protection
        and use the
        Include List
        to allow only the layer 2 protocols that you use and automatically deny all other protocols. (Do not use the
        Exclude List
        , which 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 (
      Network
      Zones
      ) in the
      Zone Protection Profile
      field.
  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.
    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.
    • DoS Protection profiles, which set flood thresholds for different types of traffic.
    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).
    Classified
    profiles set thresholds that apply to each individual device specified in a rule and leverage the hardware block table on platforms that have one.
    Aggregate
    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.
    Similar to Zone Protection, you can set the
    Action
    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.
    • Create a DoS Protection profile (
      Objects
      Security Profiles
      DoS 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
      Action
      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.
      When you configure SYN Cookies as the
      Action
      for SYN floods:
      • 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 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
        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 normal peak CPS rate for the group to avoid dropping traffic that is within normal activity expectations. This is usually 15-20% above the
        Alarm Rate
        .
      • Max Rate
        —For classified profiles, set the
        Max Rate
        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
        Block Duration
        .
      • Block Duration
        —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.
      When you configure RED as the
      Action
      :
      • 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
        —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
        Alarm Rate
        .
        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
        Alarm Rate
        .
      • Max Rate
        —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
        Activate
        rate. If firewall CPU utilization is below 50%, set the Maximum CPS to three times the
        Activate
        rate and monitor CPU usage. If CPU usage is too high, reduce the Maximum to twice the
        Activate
        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.
        When the CPS rate reaches the threshold, the firewall drops new connections for the
        Block Duration
        .
      • Block Duration
        —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 (
      Policies
      DoS Protection
      ). 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:
      • 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
        —Select
        Protect
        to apply the rule’s DoS Protection profile(s) to the specified devices. Protect is the only
        Action
        that applies DoS Protection.
      • —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
        Profile
        —Use classified profiles to protect critical individual servers. You must use a classified profile to leverage the hardware block table.
      • Classified
        Address
        —Counters consume firewall resources. For classified DoS Protection profiles, specify whether connections count toward profile thresholds based on matching the
        source-IP-only
        , the
        destination-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 use
        src-ip-only
        or
        src-dest-ip-both
        for internet-facing zones because the firewall can’t store counters for all possible internet IP addresses. Use
        destination-IP-only
        in perimeter zones.
        Use
        destination-IP-only
        to protect individual critical devices. Set the Maximum threshold below the CPS rate that each device specified in the policy can handle.
        Use
        source-IP-only
        and the
        Alarm
        threshold to monitor suspect hosts (non-internet-facing zones).
        The firewall consumes more resources to track
        src-dest-ip-both
        counters than to track only the source IP or destination IP counters.
        To use the hardware block table on platforms that support it, you must use either
        source-ip-only
        or
        src-dest-ip-both
        .
        Destination-ip-only
        uses the software table.
  3. 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. 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 (
      Device
      Setup
      Session
      Session Settings
      ) 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.
      Packet Buffer Protection based on percentage of buffer utilization is enabled by default:
      • Alert
        —Start with the default value (50%), monitor packet buffer utilization, and adjust the thresholds if necessary.
      • Activate
        —Start with the default value of 80% (PAN-OS 10.0 and later; if you run PAN-OS 9.1 or earlier, change the default setting of 50% to 80%), monitor packet buffer utilization, and adjust the thresholds if necessary.
      To measure packet buffer utilization, use the Panorama Health Monitor and also the following CLI operational commands:
      • > show running resource-monitor ingress-backlogs
      • > show session packet-buffer-protection
      Latency Based Activation
      of Packet Buffer Protection is disabled by default. Latency based protection cannot defend against DoS attacks where a source constantly sends packets that the firewall denies, which consumes resources but is not seen as latency because the firewall never sets up a session for the denied traffic. (However, Packet Buffer Protection based on buffer utilization prevents these types of attacks.)
      Latency Based Activation
      is the best method to mitigate high on-chip descriptor consumption because descriptors may be consumed when high buffer utilization isn’t high. For example, if sessions are denied on firewall slow-path processing, the firewall never creates a session for the traffic and therefore never discards offending sessions, so buffer consumption remains low while descriptor consumption may spike during an attack. In this case, latency based protection activates before buffer based protection.
      Select
      Latency Based Activation
      to base protection on CPU processing latency instead of on a percentage of buffer utilization. The following three settings replace the utilization-based
      Alert
      and
      Active
      settings:
      • Latency Alert
        —Start with the default value (50 milliseconds), monitor latency, and adjust the thresholds if necessary.
      • Latency Activate
        —Start with the default value (200 milliseconds), monitor latency, and adjust the thresholds if necessary.
      • Latency Max Tolerance
        —Start with the default values (500 milliseconds), monitor latency, and adjust the thresholds if necessary. When traffic reaches the
        Latency Activate
        threshold, the firewall uses RED to begin dropping traffic and increases the drop rate until latency reaches the
        Latency Max Tolerance
        . At
        Latency Max Tolerance
        , the drop rate probability is close to 100%.
      Measure latency on each firewall:
      • fw-1> debug dataplane pow performance | match pbp
        operational command.
      • Enable logging when the dataplane load is high to receive notifications and view the log information (
        Device
        Setup
        Management
        Logging and Reporting
        and
        Enable Log on High DP Load
        ). Check the dataplane load using the operational CLI command
        show running resource monitor
        . You can also create a Technical Support File and go through the dataplane log in text format.
    • Set thresholds and timers (
      Device
      Setup
      Session
      Session Settings
      ) 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.
      Base settings on experiences with and measurements of latency and buffer utilization, your tolerance for latency and packet drop due to buffer congestion, and how aggressively you want to drop traffic to avoid latency and packet buffer consumption that impact the network and its users.
      • Block Countdown Threshold
        —The buffer utilization percentage or latency threshold in milliseconds that starts the countdown to discard or block offending traffic. When buffer congestion or latency reaches the
        Block Countdown Threshold
        threshold,
        Block Hold Time
        begins to decrement. (When the block hold time runes out, the firewall blocks sessions based on your DoS configuration.)
        Set the
        Block Countdown Threshold
        10% lower than the
        Activate
        or
        Latency Activate
        threshold, monitor packet buffer utilization, and adjust the value as needed. This method blocks offending IP addresses faster than the default setting (80% or 500ms for latency). The lower the
        Block Hold Time
        value, the sooner the firewall begins to mitigate buffer congestion. The higher the value, the longer a packet buffer attack can continue before the firewall mitigates it.
      • Block Hold Time
        —The amount of time the offending session can remain above the
        Block Countdown Threshold
        before the firewall discards the session or blocks the source IP address. The lower the value, the sooner the firewall activates Packet Buffer Protection and leverages the hardware block table to protect the packet buffers.
        Start with a value of 30 seconds, monitor packet buffer utilization, and adjust the time if necessary. This method blocks offending IP addresses faster than the default setting (60 seconds). The higher the time value, the longer a packet buffer attack can continue before the firewall mitigates it.
        Block hold time decrements as long as congestion remains above the
        Block Countdown Threshold
        value. When
        Block Hold Time
        reaches 0, the firewall discards the session or blocks the source IP address.
      • Block Duration
        —The amount of time after the
        Block Hold Time
        expires 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.
    How you set the Packet Buffer thresholds depends on your network traffic and how you want to treat that traffic:
    • The default settings are conservative and favor allowing packet buffer congestion to continue longer before discarding sessions or blocking source IP addresses. 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. This is why the best practice is to start with lower, more aggressive thresholds.
    • User complaints about network slowness may indicate that the packet buffer thresholds are too conservative. To address these complaints, lower the
      Activate
      rate and the
      Block Countdown Threshold
      to start RED packet drop sooner. Lower the
      Block Hold Time
      so that the firewall starts blocking IP addresses or discarding sessions faster after the buffer consumption rate reaches the
      Block Countdown Threshold
      .
      Discarding or blocking offending traffic faster means legitimate traffic that is not causing packet buffer consumption issues won’t be subject to latency or packet drop issues due to 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 faster as well.
    • If you are concerned that setting the
      Activate
      rate and
      Block Countdown Threshold
      lower could block important legitimate traffic, such as DNS or other critical infrastructure traffic, increase the
      Block Hold Time
      to a higher value to delay the quarantine action and monitor packet buffer usage.
    • Tune the Packet Buffer Protection thresholds to achieve the balance of latency and packet loss versus when to discard sessions or block source IP addresses that makes sense for your network.
  4. The second phase of Packet Buffer Protection protects firewall buffers on a per-ingress-zone basis and is enabled by default in PAN-OS 10.0 and later (disabled by default in PAN-OS 9.1 and earlier), but global Packet Buffer Protection must also 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 (by default, the firewall also applies RED globally so the packet buffers still have 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.
    • To disable or enable per-zone protection,
      Network
      Zones
      , select an existing zone or
      Add
      a zone, and then select or deselect
      Enable Packet Buffer Protection
      .
    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 the internal network. Consider potential insider threats, accidentally misconfigured internal devices, faulty NIC adapters that generate large amounts of illegitimate traffic, and firewall misconfiguration.
    All of these can deny traffic from any legitimate source that also sends a significant amount of traffic to the firewall because the firewall identifies all significant traffic sources by their unique 6-tuple identifiers (source and destination IP, source and destination port, protocol, and ingress zone). During periods of packet buffer congestion, RED affects legitimate sources that send a significant amount of traffic along with offending sources.
    Network Address Translation (NAT) can increase packet buffer utilization because of IP address translation activity.
  5. 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