Zone Defense Fundamentals in Palo Alto Networks

Palo Alto Networks Next-Generation Firewalls (NGFWs) provide robust mechanisms to protect network zones and critical resources from various Denial-of-Service (DoS) and reconnaissance attacks. This protection is layered, starting from the zone level and extending to specific device protection. A DoS attack aims to disrupt network services by overwhelming the target with traffic or by exploiting vulnerabilities to exhaust its resources.

Understanding the types of attacks is crucial for effective defense planning within the Palo Alto Networks ecosystem:

• Volumetric Attacks: These attacks, such as UDP floods or ICMP floods, attempt to saturate the bandwidth of the target network or device. While Palo Alto Networks firewalls have capabilities to mitigate these, extremely large volumetric attacks are best handled by upstream dedicated DDoS mitigation services. Zone Protection Profiles provide the first line of defense against such floods at the zone ingress.
• Protocol-Based Attacks: These attacks exploit weaknesses in network protocols. A common example is a SYN flood, which attempts to consume all available connection resources on a server. Palo Alto Networks firewalls use SYN Cookies or Random Early Drop (RED) within Zone Protection and DoS Protection profiles to counter these.
• Application-Layer Attacks: These target specific application vulnerabilities to crash or exhaust application resources (e.g., Slowloris, certain HTTP floods). While App-ID™ and Vulnerability Protection profiles (applied via Security Policy) offer significant defense against known application-layer attacks, some highly sophisticated or zero-day application attacks might require dedicated Web Application Firewall (WAF) capabilities, which can be a separate appliance or service. Palo Alto Networks NGFWs focus on network and session-level DoS.

It's important to note that PAN-OS does not ship with pre-configured Zone Protection or DoS Protection profiles/policies that are active by default. Administrators must explicitly configure these defenses. The settings should be meticulously tuned based on the specific traffic characteristics observed in each zone and the criticality of the devices being protected. Default threshold values provided in PAN-OS are often generic and may not be suitable for a production environment without proper baselining and adjustment.

The overall strategy involves a defense-in-depth approach, utilizing multiple features of the Palo Alto Networks NGFW in concert to provide comprehensive protection against a wide array of DoS threats.

Key Defense Layers & Tools in Palo Alto Networks

Palo Alto Networks NGFWs offer a suite of integrated tools that form a multi-layered defense against DoS attacks. These tools operate at different stages of packet processing and provide varying levels of granularity.

• Zone Protection Profiles:
  • PAN-OS Location: Network > Network Profiles > Zone Protection
  • Purpose: Applied to ingress security zones, these profiles provide the first line of defense against aggregate attacks targeting an entire zone. They act early in the new session setup process, before Security Policy evaluation for the new packet.
  • Protection Scope: Defends against floods (SYN, UDP, ICMP, Other IP based on Connections Per Second - CPS), reconnaissance (port scans, host sweeps), packet-based attacks (malformed headers, IP spoofing), and filters non-IP protocols (based on Ethertype).
  • Key Characteristic: Operates on aggregate traffic statistics for the zone.
• DoS Protection Profiles and Policy Rules:
  • PAN-OS Location: Profiles at Objects > Security Profiles > DoS Protection ; Policy Rules at Policies > DoS Protection .
  • Purpose: Designed to protect specific, critical endpoints (e.g., web servers, database servers) against targeted flood attacks and resource exhaustion.
  • Protection Scope: Offers granular control based on traffic destined for or originating from specific IP addresses or services. Can be 'Aggregate' (thresholds for a group of matched devices) or 'Classified' (thresholds per individual matched device). Also includes Resource Protection (max concurrent sessions).
  • Key Characteristic: More targeted than Zone Protection, applied after Zone Protection checks for new sessions.
• Packet Buffer Protection:
  • PAN-OS Location: Global settings at Device > Setup > Session > Session Settings ; Per-zone enablement at Network > Zones > [Zone Name] .
  • Purpose: Protects the firewall's own packet buffer resources from being exhausted by single, high-volume sessions or a rapid influx of new sessions consuming buffer space. This helps maintain firewall stability and prevent legitimate traffic from being dropped due to buffer starvation.
  • Protection Scope: Applies globally to monitor buffer utilization or packet processing latency. Per-zone settings allow for blocking offending sessions/IPs.
  • Key Characteristic: Primarily affects existing sessions but also plays a role in handling rapid new session bursts impacting buffers. Works in conjunction with, but is distinct from, Zone and DoS Protection.
• Security Policy Rules with Security Profiles:
  • PAN-OS Location: Policies > Security ; Security Profiles (e.g., Vulnerability Protection) at Objects > Security Profiles .
  • Purpose: While Security Policy rules primarily define what traffic is allowed or denied, attaching a Vulnerability Protection profile adds a critical layer. Vulnerability Protection profiles contain signatures to detect and block known DoS exploits and other threats that might masquerade as legitimate traffic.
  • Protection Scope: Applied to traffic that has passed Zone Protection and DoS Protection checks and is allowed by a Security Policy rule.
  • Key Characteristic: Signature-based protection against specific, known vulnerabilities that could lead to DoS conditions.

These protections are applied to dataplane traffic. Traffic destined for or originating from the firewall's management interface (MGT) is typically handled by Management (MGT) Interface ACLs and other hardening practices, not by Zone/DoS Protection profiles.

Palo Alto Networks layered defense strategy. External DDoS mitigation handles large volumetric attacks, while the NGFW provides multiple subsequent layers of protection including Zone Protection, DoS Protection, Security Policies with Vulnerability Protection, and ongoing Packet Buffer Protection.

PAN-OS Packet Processing Order for New Sessions

Understanding the sequence in which Palo Alto Networks firewalls evaluate traffic against various protection mechanisms is crucial for effective configuration and troubleshooting. For a new incoming packet (i.e., one that does not match an existing session), the general processing order for DoS-related checks is as follows:

1. Ingress Interface & Basic Sanity Checks: The packet arrives at an ingress interface. Basic L2/L3 sanity checks are performed.
2. Zone Protection Profile Check:
   • The firewall identifies the ingress zone for the packet.
   • The Zone Protection Profile (if configured and applied to that zone) is evaluated.
   • Checks include:
     • Flood Protection: Aggregate CPS thresholds (SYN, UDP, ICMP, Other IP). If thresholds are exceeded, actions like SYN Cookies, RED, or drop may occur.
     • Reconnaissance Protection: Port scan and host sweep detection. If detected, actions like alert, block, or block-IP may occur.
     • Packet-Based Attack Protection: Checks for malformed headers, IP spoofing, etc. Offending packets are typically dropped.
     • Protocol Protection: Filters non-IP protocols based on Ethertype for L2 interfaces.
   • If the Zone Protection Profile denies the packet, it is dropped, and further processing for this packet usually stops. An entry may be made in the Threat log.
3. DoS Protection Policy Rule Check:
   • If the packet is permitted by the Zone Protection Profile (or if no ZPP is applied), the firewall evaluates DoS Protection policy rules.
   • Rules are matched based on source/destination zone, address, service, etc.
   • If a matching rule has an action of 'Protect':
     • The associated DoS Protection Profile(s) (Aggregate and/or Classified) are evaluated.
     • Flood thresholds (CPS) and Resource Protection (concurrent sessions) limits are checked.
     • If thresholds are exceeded, actions like SYN Cookies, RED, drop, or blocking the source IP may occur. The event is logged in the Threat log.
   • If a matching rule has an action of 'Deny', the packet is dropped.
   • If a matching rule has an action of 'Allow', or 'Protect' and thresholds are not exceeded, the packet proceeds.
4. Security Policy Rule Check:
   • If the packet is permitted by both Zone Protection and DoS Protection mechanisms (or if they are not configured/matched), a Security Policy lookup occurs.
   • The firewall attempts to match the packet against Security Policy rules based on zone, address, user (if User-ID™ is enabled), application (initial App-ID™ based on port/protocol), service, etc.
   • If a matching rule's action is 'Allow', a session is typically created in the session table. Further security profile inspections (Vulnerability, Anti-Spyware, Antivirus, WildFire®, URL Filtering, File Blocking) defined in the rule will apply to this session.
   • If no rule matches (default deny) or the matching rule's action is 'Deny', the packet is dropped and logged in the Traffic log.
5. Session Establishment & Ongoing Checks:
   • Once a session is established, subsequent packets belonging to this session are processed more quickly by matching the existing session state.
   • Packet Buffer Protection monitors buffer usage globally and per-zone for existing sessions. If thresholds are exceeded, it may apply RED or block offending sessions/IPs to protect firewall resources. This is an ongoing check for the life of sessions.

Detailed PAN-OS packet processing flow for a new session, highlighting the evaluation stages of Zone Protection, DoS Protection, and Security Policy, followed by session establishment and ongoing Packet Buffer Protection monitoring.

Firewall Placement & Traffic Baselining for Effective DoS Protection

Proper placement of Palo Alto Networks NGFWs and accurate traffic baselining are foundational to effective DoS/Zone Defense configuration.

Firewall Placement Considerations

Palo Alto Networks firewalls are powerful, session-based security devices, but they are not designed to absorb massive volumetric DDoS attacks (e.g., hundreds of Gbps or millions of Connections Per Second beyond their rated capacity) that are best handled by specialized upstream DDoS mitigation services.

• Behind Dedicated DDoS Mitigation: For internet-facing deployments, always place Palo Alto Networks firewalls *behind* dedicated DDoS mitigation services or ISP-provided scrubbing centers. These upstream services handle large-scale volumetric attacks, allowing the firewall to focus on more sophisticated, stateful threats and application-layer attacks it's designed for.
• Close to Protected Resources: Position firewalls as close as logically possible to the resources they are protecting. This minimizes the attack surface on the network segments before the firewall and ensures traffic to critical assets is inspected.
• Segmentation: Utilize the firewall to create granular security zones (segmentation). This limits the blast radius of an attack originating from a compromised internal segment and forces more traffic to cross zone boundaries, subjecting it to policy inspection, including Zone Protection.
• Capacity Planning: Select PA-Series models with adequate CPS, throughput, and session capacity for the expected legitimate traffic load plus a reasonable buffer for attack traffic that might pass upstream defenses. Consult Palo Alto Networks datasheets for model-specific capacities.

Baseline CPS Measurements for Setting Flood Thresholds

Effective flood protection (in both Zone Protection and DoS Protection profiles) hinges on setting appropriate thresholds. Default thresholds in PAN-OS are often too high for most environments and should be customized based on measured baseline traffic levels.

CPS Measurements to Take:

• For Zone Protection Profiles: Measure average and peak aggregate Connections Per Second (CPS) ingressing each security zone.
• For Aggregate DoS Protection Profiles: Measure the combined average and peak CPS for the group of servers/services being protected by a single policy rule.
• For Classified DoS Protection Profiles: Measure average and peak CPS for *each individual critical device* being protected.

Measurements should be taken over a representative period, ideally at least 5-7 business days, capturing daily, weekly, and monthly peaks (e.g., month-end processing, special promotions).

How to Measure CPS in PAN-OS:

• AIOps for NGFW (Recommended for Zone Protection): If your firewalls are running PAN-OS 10.0+ and you have an AIOps for NGFW subscription, it can provide Threshold Recommendation alerts based on learned traffic patterns from telemetry data. This significantly simplifies baselining for Zone Protection flood thresholds.
• Panorama™ Network Security Management:
  • Navigate to Panorama > Managed Devices > Health . Select a firewall and view metrics like "Session CPS", "Session Utilization". You can adjust the time range to observe trends.
  • The ACC (Application Command Center) tab in Panorama or the firewall GUI can provide session counts for specific source/destination IPs or zones over time. To calculate average CPS: Total Sessions / Time Period in Seconds . This is useful for baselining individual servers for Classified DoS Protection.

    

    

    

• SNMP MIBs: Poll PAN-OS SNMP MIBs frequently (e.g., every 10-60 seconds). Key OIDs include:
  • panZoneActiveTcpCps (OID: .1.3.6.1.4.1.25461.2.1.2.3.1.1.6)
  • panZoneActiveUdpCps (OID: .1.3.6.1.4.1.25461.2.1.2.3.1.1.7)
  • panZoneOtherIpCps (OID: .1.3.6.1.4.1.25461.2.1.2.3.1.1.8)
  • Note: These MIBs provide per-zone CPS.
• PAN-OS CLI Commands:
  • show session info : Provides overall session statistics, including current active sessions and CPS.

    > show session info
    --------------------------------------------------------------------------------
    Sessions          active:        1234
    Sessions          max:           65534
    Sessions          total-created: 10567890
    CPS               avg last 60s:  150
    CPS               max last 60s:  220
    ...
                            

  • show counter global filter aspect session | match cps : Shows overall CPS.
  • show counter interface <interface_name> : Includes packet rates, but be cautious as it might not directly give session CPS. For CPS related to Zone Protection, it's typically based on new session setup attempts.

Once baseline average and peak CPS values are known, set Alarm, Activate, and Max Rate thresholds in Zone/DoS Protection profiles accordingly (e.g., Alarm slightly above average, Activate above normal peak, Max Rate as a safety net below firewall capacity).

Zone & DoS Protection - Key Concepts Summary (Palo Alto Networks)

This section provides a condensed summary of key Palo Alto Networks Zone and DoS Protection concepts, ideal for quick review and memorization, especially for PCNSE certification preparation.

Core Principle: Layered defense against DoS attacks, applied at different stages of PAN-OS packet processing.

1. Zone Protection Profiles (ZPP)
   • Applied To: Ingress Security Zones. ( Network > Network Profiles > Zone Protection )
   • Scope: Broad, aggregate protection for an entire zone.
   • Protects Against:
     • Floods (CPS-based): SYN, UDP, ICMP, Other IP. Actions: SYN Cookies, RED, Drop. Thresholds: Alarm, Activate, Maximum.
     • Reconnaissance: Port Scans, Host Sweeps. Actions: Alert, Block, Block IP. Exclude trusted scanners.
     • Packet-Based Attacks: Malformed IP/TCP/ICMP headers, IP Spoofing, etc. Action: Drop/Strip.
     • Protocol Protection: Filters non-IP protocols (by Ethertype) on L2 interfaces. Use Include List (recommended).
   • Order of Operation (New Session): First line of defense.
   • PCNSE Critical: Apply to every zone. Baseline CPS to set realistic flood thresholds. Understand SYN Cookies vs. RED.
2. DoS Protection (DoS PP - Profiles & Policy Rules)
   • Applied To: Specific critical resources (servers, services) via DoS Protection Policy Rules. (Profiles: Objects > Security Profiles > DoS Protection ; Policies: Policies > DoS Protection )
   • Scope: Granular, targeted protection.
   • Types:
     • Aggregate: Thresholds apply to the *combined* traffic of all resources matching the policy rule.
     • Classified: Thresholds apply *individually* to each resource matching the rule (e.g., per destination IP).
       Gotcha! (Palo Alto Networks): For internet-facing servers, use destination-ip-only classification. Avoid source-ip-only or src-dest-ip-both due to vast number of internet sources.
   • Protects Against:
     • Floods (CPS-based): SYN, UDP, ICMP, etc. Actions: SYN Cookies, RED, Drop, Block. Thresholds: Alarm, Activate, Maximum. Block Duration.
     • Resource Exhaustion: Limits max concurrent sessions to protected resources.
   • Order of Operation (New Session): After Zone Protection, before Security Policy.
   • PCNSE Critical: Differentiate Aggregate vs. Classified. Understand when to use each. Resource Protection for session table exhaustion on servers.
3. Packet Buffer Protection (PBP)
   • Applied To: Protects the firewall's *own packet buffer* globally and per-zone. (Global: Device > Setup > Session ; Per-Zone: Network > Zones )
   • Scope: Firewall health and stability.
   • Triggers:
     • High Packet Buffer Utilization (percentage).
     • High Packet Processing Latency (milliseconds).
   • Actions:
     • Global: Random Early Drop (RED) on offending sessions' packets.
     • Per-Zone (if enabled): Blocks offending session/IP after Block Hold Time expires, for specified Block Duration.
   • Key Point: Primarily for *existing sessions* but can also react to rapid new session setup stressing buffers.
   • PCNSE Critical: Global PBP must be enabled for per-zone PBP blocking to function. Understand Block Hold Time and Block Duration.
4. Security Policy Rules (+ Vulnerability Protection)
   • Applied To: Traffic allowed by ZPP and DoS PP (if configured), or all traffic if ZPP/DoS PP not hit. ( Policies > Security )
   • Scope: Fundamental Allow/Deny based on App-ID, User-ID, Content-ID, etc.
   • DoS Enhancement: Attaching a Vulnerability Protection Profile ( Objects > Security Profiles ) to allow rules adds defense against known DoS exploits (signature-based).
   • Order of Operation (New Session): After Zone Protection and DoS Protection.
   • PCNSE Critical: Understand it's a complementary layer, not a primary DoS flood mitigator, but crucial for exploit prevention.

Zone Protection Profiles: Configuration & Flood Protection

Zone Protection Profiles are configured under Network > Network Profiles > Zone Protection in PAN-OS (both firewall GUI and Panorama). They are then applied to individual security zones under Network > Zones > [Select Zone] > Zone Protection Profile . It is a Palo Alto Networks best practice to apply a tailored Zone Protection Profile to every security zone, including internal zones, not just internet-facing ones.

Flood Protection

This is a primary component of Zone Protection, designed to mitigate volumetric attacks based on Connections Per Second (CPS) attempting to enter the zone. Separate thresholds can be configured for different IP protocols:

• SYN Floods (TCP)
• UDP Floods
• ICMP Floods
• ICMPv6 Floods
• Other IP Floods (for protocols not explicitly listed)

For each flood type, you configure three CPS thresholds:

• Alarm Rate: When the CPS rate for new connections of this type reaches this value, the firewall generates a log in the Threat log with severity 'Informational'. No traffic is dropped solely based on the Alarm Rate. Recommendation: Set ~15-25% above your measured average peak CPS for normal conditions.
• Activate Rate: When CPS reaches this value, the firewall begins taking protective action. Recommendation: Set just above your measured absolute highest legitimate peak CPS, allowing for some growth or unusual spikes. This is a critical threshold.
• Maximum Rate: When CPS reaches this value, the firewall takes its most aggressive action. Recommendation: Set as a safety net, typically significantly higher than Activate but well below the firewall's (or specific DP's) capacity to handle new sessions of that type. Often ~80-90% of perceived capacity for that zone/protocol.

SYN Flood Protection Actions

For SYN floods, PAN-OS provides two primary mitigation actions when the Activate Rate is met:

• SYN Cookies (Recommended Starting Point):
  • When activated, the firewall acts as a proxy for the TCP handshake. It responds to the client's SYN with a SYN-ACK containing a cryptographically generated "cookie" instead of immediately forwarding the SYN to the server or consuming a session table entry.
  • Only when the firewall receives a valid ACK from the client (responding to the cookie) does it establish the connection to the actual server and create a session.
  • Pros: More resilient to SYN floods as it doesn't exhaust session table resources on the firewall or server for spoofed SYNs. Generally less likely to drop legitimate traffic.
  • Cons: More CPU-intensive for the firewall than RED. May not honor certain TCP options from the server during the proxied handshake (e.g., Window Scale, SACK, Timestamps, MSS from server). The firewall uses its own MSS or a common default. This can potentially lead to issues like fragmentation if the path MSS is smaller.
  • PAN-OS Behavior: When SYN Cookies is active, the firewall essentially performs a "half-proxy" for the handshake.
• Random Early Drop (RED):
  • When activated, the firewall starts randomly dropping a percentage of incoming SYN packets. The drop probability increases as the CPS rate moves from the Activate Rate towards the Maximum Rate.
  • At the Maximum Rate, the drop probability approaches 100% for new SYNs.
  • Pros: Less CPU-intensive for the firewall than SYN Cookies.
  • Cons: It's a probabilistic mechanism, meaning it can drop legitimate SYNs along with malicious ones, potentially impacting valid users.
  • When to consider RED: If firewall CPU performance becomes a concern with SYN Cookies under heavy load, or in environments without upstream DDoS mitigation where the firewall faces very high SYN volumes.

Simplified logic for SYN Flood Protection actions (SYN Cookies vs. RED) in a PAN-OS Zone Protection Profile when Activate Rate is triggered.

For UDP, ICMP, ICMPv6, and Other IP floods, the typical action when Activate Rate is met is to start dropping new connections. When Maximum Rate is met, all new connections of that type are dropped.

Ensure appropriate Log Forwarding profiles are configured to send Threat logs generated by Zone Protection (especially flood events) to SIEMs or alert administrators.

Zone Protection Profiles: Reconnaissance Protection

Reconnaissance Protection, configured within a Zone Protection Profile ( Network > Network Profiles > Zone Protection > Reconnaissance Protection ), defends against common network scanning techniques used by attackers to identify live hosts and open ports. This feature should be enabled on all zones, including internal ones, to detect both external and internal reconnaissance activities.

Key configuration parameters include:

• Enable TCP Port Scan / Enable UDP Port Scan / Enable Host Sweep: Checkboxes to enable detection for each type of reconnaissance.
• Action: Determines what the firewall does when a scan/sweep is detected.
  • Alert: Generates a Threat log entry (subtype 'scan') but takes no blocking action. Useful for initial monitoring or in environments where blocking might be too disruptive without careful tuning.
  • Block: Generates a Threat log and blocks the specific packets identified as part of the scan. This is less aggressive than Block IP.
  • Block IP: Generates a Threat log and blocks all further traffic from the source IP address for a configurable duration (Block Duration). This is the most common and effective action but requires careful consideration of the Exclude List.
    • Source and/or Destination: When Block IP is chosen, you can specify whether to block the source, destination, or both. For typical reconnaissance, blocking the 'Source' is appropriate.
    • Block Duration (seconds): Default is 3600 seconds (1 hour). Adjust as needed. Longer durations provide stronger deterrence but increase the risk if a legitimate IP is mistakenly blocked.
• Interval (seconds) & Threshold (events): These define the sensitivity of the detection.
  • A scan is detected if the number of connection attempts (events) from a single source to multiple destination ports (port scan) or multiple destination hosts on the same port (host sweep) exceeds the 'Threshold' within the 'Interval'.
  • Default values (e.g., Interval 3 seconds, Threshold 10 events for TCP Port Scan) are a starting point. Lowering the threshold or interval makes detection more sensitive but can lead to false positives. Baselining scanning activity from legitimate tools can help tune these.
• Exclude List: This is a CRITICAL component.
  • Specify IP addresses, address groups, or FQDN objects (for PAN-OS versions supporting FQDN in ZPP exclusions) that are permitted to perform scanning activities without triggering the configured action.
  • Common Exclusions:
    • Internal vulnerability scanners (e.g., Nessus, QualysGuard)
    • Network monitoring systems
    • Management interfaces of other security tools
    • Panorama IP address (if it polls firewalls)
    • Specific partner or administrative hosts known to perform legitimate checks.
  • Failure to populate the Exclude List accurately can result in legitimate security tools or administrative access being blocked.

Logs for reconnaissance events are found in the Threat log with subtypes like scan , tcp-port-scan , udp-port-scan , or host-sweep .

While Reconnaissance Protection is effective against common scan types, highly sophisticated, slow, and low-profile scans might evade detection if thresholds are not set aggressively enough. It's one layer in a multi-layered defense strategy.

Zone Protection Profiles: Packet-Based & Protocol Protection

Packet-Based Attack Protection

Packet-Based Attack Protection, part of a Zone Protection Profile ( Network > Network Profiles > Zone Protection > Packet Based Attack Protection ), inspects packet headers for various anomalies and malformations that often indicate an attack or misconfigured host. It allows the firewall to drop or sanitize such packets early in the processing flow.

This protection is divided into several categories:

• IP Drop:
  • Malformed IP packet: Drops packets with invalid IP header fields (e.g., incorrect version, header length, total length). (Default: Enabled)
  • Unknown IP protocol: Drops IP packets with an unrecognized protocol number in the IP header. (Default: Enabled)
  • Strict IP address check: Drops packets with invalid source or destination IP addresses (e.g., 0.0.0.0 source on routable interface, multicast source). (Default: Enabled)
  • Loose source routing / Strict source routing: Drops packets that use IP source routing options, which can be abused. (Default: Enabled for both)
  • Spoofed IP address: (Default: Disabled) When enabled, the firewall drops packets if the ingress interface for the source IP address does not match an entry in the firewall's routing table (unicast RPF check based on routing table).
    CRITICAL (Palo Alto Networks): Enabling "Spoofed IP address" is highly recommended for internal zones to prevent hosts from using source IPs not legitimately belonging to their network segment. For internet-facing zones , this check is usually impractical due to asymmetric routing commonly found on the internet. However, if you have strict symmetric routing from your ISP, it might be considered.
• TCP Drop:
  • TCP SYN with data: Drops SYN packets that also contain data, which is non-standard. (Default: Enabled)
  • TCP SYNACK with data: Drops SYN-ACK packets that also contain data. (Default: Enabled)
  • Mismatched overlapping TCP segments: Drops packets where TCP segments overlap in a conflicting way. (Default: Enabled)
  • Split handshake (SYN, FIN): Drops packets where SYN and FIN flags are set simultaneously. (Default: Enabled)
  • Reject non-SYN TCP (if no session match): (Default: Enabled) Drops non-SYN TCP packets that do not match an existing session. This is a crucial stateful check.
    Gotcha! (Palo Alto Networks): Disabling "Reject non-SYN TCP" can break stateful inspection and expose the network. However, in very specific scenarios like Tunnel Content Inspection with "Rematch Sessions" enabled for GRE or other tunnels, you might need to selectively disable this on the zone where tunnel traffic ingresses if issues are observed with re-matched sessions. This is an advanced and rare case.
  • Strip TCP Timestamp option: Removes TCP timestamp options from packets. (Default: Disabled) Useful if timestamps are causing issues with specific legacy systems.
• ICMP & ICMPv6 Drop:
  • ICMP packet too large: Drops ICMP "Packet Too Big" messages that are themselves excessively large. (Default: Enabled)
  • ICMP fragment: Drops fragmented ICMP packets, which are often used in attacks. (Default: Enabled)
  • ICMP Ping ID 0: Drops ICMP echo requests (pings) with an ID of 0, sometimes used by scanning tools. (Default: Disabled) Enable if desired.
  • Similar options exist for ICMPv6.
• IPv6 Drop: Options to drop IPv6 packets with various non-compliant headers or extensions (e.g., Hop-by-Hop extension, Routing Header Type 0). Configure based on your IPv6 deployment needs.

Simplified flow showing how Packet-Based Attack Protection within a Zone Protection Profile inspects packet headers for various anomalies and drops offending packets.

Protocol Protection

Protocol Protection, also part of a Zone Protection Profile ( Network > Network Profiles > Zone Protection > Protocol Protection ), allows control over non-IP protocols traversing Layer 2 interfaces (VLAN interfaces or Virtual Wires) within a zone or between Layer 2 zones. It filters traffic based on the Ethertype value in the Ethernet header.

• Functionality: This feature is relevant only for traffic on interfaces configured for Layer 2 forwarding. It does not apply to Layer 3 interfaces.
• Configuration Modes:
  • Include List (Recommended): This is an "allow list" approach. You specify the Ethertypes of non-IP protocols that are permitted. All other non-IP protocols are blocked. This is more secure as it follows the principle of least privilege.
  • Exclude List: This is a "block list" approach. You specify Ethertypes of non-IP protocols that are to be blocked. All other non-IP protocols are permitted. This is less secure as it might allow unknown or unwanted protocols.
• Implicitly Allowed Protocols: When using an Include List, certain fundamental Ethertypes are always implicitly allowed and do not need to be (and cannot be) added to the Include List. These are:
  • IPv4 ( 0x0800 )
  • ARP ( 0x0806 )
  • IPv6 ( 0x86DD )
  • VLAN-tagged frames ( 0x8100 - the inner Ethertype is then inspected)
  These protocols also cannot be added to an Exclude List.
• Use Cases: Primarily used in environments with specific non-IP industrial control systems (ICS/SCADA protocols), proprietary L2 protocols, or to strictly limit what L2 traffic can pass.
• Limits: PAN-OS supports up to 64 Ethertype entries in an Include or Exclude list per Zone Protection Profile.

An additional related feature is Ethernet SGT Protection , which allows dropping packets based on specific Layer 2 Security Group Tag (SGT) values (Ethertype 0x8909 , typically from Cisco TrustSec environments) if SGT-based policy enforcement is desired at this layer.

Packet Buffer Protection: Mechanism & Configuration

Packet Buffer Protection is a crucial Palo Alto Networks NGFW feature designed to safeguard the firewall's own packet buffer resources. When the firewall's packet buffers become congested or exhausted, it can lead to legitimate traffic being dropped, increased latency, and overall network performance degradation. This feature helps prevent such scenarios, often caused by single abusive sessions (e.g., a host on a very fast link overwhelming a slower server protected by the firewall) or by a rapid influx of new connections that quickly consume buffer space.

Dual-Level Configuration:

Packet Buffer Protection is configured and operates at two levels in PAN-OS:

1. Global Packet Buffer Protection:
   • Location: Device > Setup > Session > Session Settings > Packet Buffer Protection .
   • Function: This is the primary enablement and configuration point. The firewall globally monitors the utilization of its shared packet buffer resources across all dataplanes.
   • When buffer utilization (or latency, if configured) exceeds the global "Activate" threshold, the firewall employs Random Early Drop (RED) . RED starts to probabilistically drop packets from sessions identified as consuming excessive buffer resources. The drop probability increases as utilization or latency further increases towards a "Max" threshold.
   • Important: Global Packet Buffer Protection applies RED; it does not, by itself, block entire sessions or source IPs.
2. Per-Zone Packet Buffer Protection Enablement:
   • Location: Network > Zones > [Select Zone] > Enable Packet Buffer Protection (checkbox).
   • Function: This setting enables more aggressive actions (blocking) at the zone level, but only if Global Packet Buffer Protection is already active and applying RED .
   • When global PBP is applying RED to packets from an offending session ingressing a zone where per-zone PBP is enabled:
     • A Block Hold Time timer starts for that offending session/IP. This is configurable globally (default 60 seconds).
     • If the session continues to cause high buffer utilization (triggering global RED) for the duration of the Block Hold Time, the firewall will then block the entire session (or the source IP, depending on PAN-OS internal logic for identifying the offender).
     • The session/IP remains blocked for the globally configured Block Duration (default 3600 seconds).

The firewall intelligently identifies "offending" sessions based on their contribution to buffer congestion. This could be a single session with a very high packet rate or many sessions from a single source IP rapidly consuming buffers.

It's important to monitor packet buffer utilization regularly using CLI commands (e.g., show running resource-monitor ) or Panorama to ensure the firewall is appropriately sized and that PBP thresholds are tuned correctly for your environment. Consistently high buffer utilization may indicate an undersized firewall or an ongoing attack.

Packet Buffer Protection: Utilization-Based vs. Latency-Based

Palo Alto Networks firewalls offer two distinct methods for triggering Packet Buffer Protection, allowing administrators to choose the most suitable approach based on their network's characteristics and sensitivity to performance variations.

1. Packet Buffer Protection Based on Buffer Utilization (Default)

This is the traditional and default method. Protection mechanisms are triggered based on the percentage of the firewall's packet buffer currently in use.

Global Configuration Settings ( Device > Setup > Session > Session Settings ):

• Enable Packet Buffer Protection: Master toggle for the feature.
• Red Exceeding Threshold (%):
  • Alert: The buffer utilization percentage at which an Alert log (System log) is generated. Default: 50%. Recommendation: Monitor normal peak utilization. If it's consistently above 30-40% on a correctly sized firewall, investigate. Set Alert slightly above your normal highest peak.
  • Activate: The buffer utilization percentage at which the firewall starts applying Random Early Drop (RED) to packets from offending sessions. Default: 80%. Recommendation: This should be significantly above normal peak but low enough to provide a buffer before exhaustion. If your firewall frequently hits this, it may be undersized or under attack.
  • Max: The buffer utilization percentage at which RED becomes most aggressive (approaching 100% drop probability for new packets from offending sessions). Default: 95%.
• Block Hold Time (sec): The duration (default: 60 seconds) an offending session can continue to trigger global RED (due to exceeding Activate threshold) before the per-zone PBP (if enabled on the ingress zone) blocks the entire session/IP. This timer resets if buffer usage by the session drops below the Activate threshold.
• Block Duration (sec): The duration (default: 3600 seconds) an offending session/IP remains blocked by per-zone PBP after the Block Hold Time expires.

To view buffer utilization via CLI:

> show running resource-monitor ingress-backlogs
# For a more detailed view over time:
> show running resource-monitor [ second | minute | hour | day | week ]
# Look for 'core_pkt_buff_used_percent' or similar metrics.
        

2. Packet Buffer Protection Based on Latency

As an alternative to utilization percentage, PBP can be triggered based on packet processing latency within the firewall. High latency is often an early indicator of congestion, potentially even before buffers are critically full. This mode can be more beneficial for latency-sensitive applications.

Global Configuration Settings ( Device > Setup > Session > Session Settings ):

To use latency-based PBP, you would typically uncheck the utilization-based "Red Exceeding Threshold (%)" options and configure the "Red Latency Threshold (ms)" options:

• Red Latency Threshold (ms):
  • Alert: Packet processing latency (in milliseconds) at which an Alert log is generated.
  • Activate: Latency at which the firewall starts applying RED to offending sessions.
  • Max Tolerate: Latency at which RED becomes most aggressive.
• Block Hold Time (sec) and Block Duration (sec) function similarly as with utilization-based PBP, but are triggered by sustained high latency causing global RED.

Choosing between utilization-based and latency-based PBP depends on the specific network environment and performance requirements. For most general use cases, utilization-based is common. However, if maintaining low latency is paramount (e.g., financial trading, VoIP), latency-based PBP might offer earlier intervention against congestion-inducing sessions.

Regardless of the trigger type, the per-zone PBP enablement ( Network > Zones > [Zone Name] > Enable Packet Buffer Protection ) is still required for the firewall to take blocking actions (session/IP block) after the Block Hold Time expires.

Packet Buffer Protection: Operational Flow & Impact

The operational flow of Packet Buffer Protection (PBP) in PAN-OS involves interaction between global settings and per-zone enablement to mitigate the impact of buffer-exhausting sessions.

Operational flow of Palo Alto Networks Packet Buffer Protection. Global PBP applies RED when activate thresholds (utilization or latency) are met. If per-zone PBP is also enabled, sustained offending behavior leads to session/IP blocking after the Block Hold Time.

Explanation of the Flow:

1. Packet Arrival (Existing Session): PBP primarily scrutinizes packets belonging to established sessions, though rapid new session setup can also stress buffers and trigger PBP.
2. Global PBP Enabled Check: If Global PBP ( Device > Setup > Session ) is not enabled, no PBP actions occur.
3. Trigger Method (Utilization/Latency): The firewall checks if the configured global "Activate" threshold (either buffer utilization percentage or packet processing latency in milliseconds) is exceeded by traffic patterns, particularly from one or more "offending" sessions.
4. Global RED Application: If an "Activate" threshold is crossed, the firewall begins applying Random Early Drop (RED) globally to packets from the identified offending session(s). This is a probabilistic drop mechanism intended to signal congestion and reduce the session's rate.
5. Per-Zone PBP Enabled Check: The firewall then checks if "Enable Packet Buffer Protection" is ticked for the ingress zone of the offending packet(s).
   • If No (per-zone PBP not enabled): Packets from the offending session continue to be subject to Global RED but no further blocking action (session/IP block) will occur from PBP for that zone. The packet is forwarded if not dropped by RED.
   • If Yes (per-zone PBP enabled): The flow proceeds to blocking logic.
6. Existing Block Check: If the offending session or its source IP is already under a "Block Duration" due to a previous PBP event, new packets from it are dropped immediately.
7. Block Hold Timer: If not currently blocked, the global "Block Hold Time" timer starts (or continues) for the offending session/IP. During this time, the session's packets are still subject to Global RED.
8. Block Hold Timer Expiration:
   • If the session stops offending (i.e., its contribution to buffer/latency issues drops below "Activate" levels) before the Block Hold Timer expires, the timer resets, and no session/IP block occurs.
   • If the Block Hold Timer expires and the session is still offending (still triggering Global RED), the firewall then blocks the entire session or the source IP address associated with it.
9. Block Duration: The session/IP remains blocked for the globally configured "Block Duration". After this period, the block is lifted, but if the offending behavior resumes, the process can restart.

Impact and Considerations:

• Legitimate Traffic Impact: While PBP aims to protect the firewall, Global RED can cause some legitimate packet drops. The more aggressive per-zone blocking can impact legitimate users if an IP is shared (e.g., NAT gateway) or if thresholds are too sensitive.
• Identifying the Offender: PAN-OS uses internal algorithms to pinpoint the session(s) or source IP(s) most responsible for buffer congestion. This typically involves looking at high packet rates or high buffer occupancy per session.
• Logging:
  • Global PBP RED actions (when Activate thresholds are hit) generate System logs (e.g., "Global packet buffer protection RED is active").
  • Per-zone PBP blocking actions (session/IP block) also generate System logs indicating the block and its reason.
• Tuning: Proper tuning of Activate thresholds, Block Hold Time, and Block Duration is essential to balance protection with minimizing impact on legitimate traffic. Baselining normal buffer usage and latency is key.

DoS Protection: Aggregate vs. Classified Protection

Palo Alto Networks DoS Protection policies and profiles provide targeted defense for specific critical resources (e.g., web servers, database servers, critical applications) against flood attacks and session exhaustion. Unlike Zone Protection which applies broadly to an entire ingress zone, DoS Protection is more granular. A key concept within DoS Protection is the distinction between Aggregate and Classified protection.

DoS Protection Policies are configured under Policies > DoS Protection , and they reference DoS Protection Profiles configured under Objects > Security Profiles > DoS Protection .

Aggregate DoS Protection

• Concept: An Aggregate DoS Protection profile defines a single set of thresholds (for CPS floods and concurrent sessions) that applies to the combined traffic of all resources matching the criteria of the DoS Protection Policy rule it's attached to.
• How it Works: The firewall sums up the traffic (CPS or sessions) for all unique destination IP addresses (or source IPs, or source-destination pairs, depending on rule scope) that match the DoS policy rule. This sum is then compared against the thresholds in the Aggregate profile.
• Example:
  • DoS Policy Rule: Source ANY, Destination Web-Farm-DMZ-Zone, Service HTTP/HTTPS, Action: Protect.
  • Attached Aggregate DoS Profile: SYN Flood Max Rate: 10,000 CPS.
  • If the Web-Farm-DMZ-Zone contains 5 web servers, the firewall monitors the total SYN CPS destined for all 5 servers combined. If this total exceeds 10,000 CPS, the Aggregate profile's action (e.g., SYN Cookies, RED, Block) is triggered for new connections to that group.
• Use Case: Useful for protecting a group of similar servers that share a common traffic load characteristic, or when you want to enforce an overall capacity limit for a service delivered by multiple hosts.

Classified DoS Protection

• Concept: A Classified DoS Protection profile defines thresholds that apply individually to each unique resource (IP address) that matches the DoS Protection Policy rule and the specified classification criteria.
• How it Works: The firewall tracks traffic (CPS or sessions) for each unique IP address identified by the "Address" classification setting in the DoS Protection Policy rule. Each of these individual IP traffic flows is then compared against the thresholds in the Classified profile.
• Address Classification (in DoS Policy Rule - critical for Classified Profiles):
  • destination-ip-only (Most Common for Server Protection): The profile's thresholds apply individually to each unique destination IP address matched by the rule. This is the standard choice for protecting a group of servers from external attacks.
  • source-ip-only : Thresholds apply individually to each unique source IP address. This can be used to limit abusive internal clients but is generally NOT recommended for internet-facing rules due to the vast number of potential source IPs (would create too many classified instances).
  • source-destination-ip-both : Thresholds apply individually to each unique source-destination IP pair. This is highly granular and can create many instances.
• Example:
  • DoS Policy Rule: Source ANY, Destination Web-Farm-DMZ-Zone, Service HTTP/HTTPS, Action: Protect, Classification: destination-ip-only .
  • Attached Classified DoS Profile: SYN Flood Max Rate: 2,500 CPS.
  • If the Web-Farm-DMZ-Zone contains 5 web servers, the firewall monitors SYN CPS for *each server individually*. If Server A exceeds 2,500 SYN CPS, action is taken against new SYNs to Server A. If Server B exceeds 2,500 SYN CPS, action is taken against Server B, independently of Server A or the aggregate load.
• Use Case: Ideal for protecting individual servers within a group, especially if they have different capacities or if you want to prevent one compromised/attacked server from impacting others by consuming a shared aggregate limit. Provides more granular protection.

Using Both Aggregate and Classified Profiles in One Policy Rule

A single DoS Protection Policy rule can have both an Aggregate profile AND a Classified profile attached.

• Order of Evaluation: If both are present, the Aggregate profile is evaluated first . If the aggregate traffic exceeds the Aggregate profile's thresholds, action is taken.
• Combined Effect: Even if aggregate traffic is below the Aggregate profile's limits, an individual IP (based on classification) could still exceed the Classified profile's limits, triggering action for that specific IP. Conversely, the aggregate limit could be hit before any single classified IP hits its individual limit.
• Example:
  • Aggregate Profile: Max 10,000 total SYN CPS for a group of servers.
  • Classified Profile ( destination-ip-only ): Max 2,500 SYN CPS per server.
  • If total SYNs hit 10,001, Aggregate action triggers.
  • If total SYNs are 8,000, but one server gets 2,501 SYNs, Classified action triggers for that server only.

Decision logic for DoS Protection when Aggregate and/or Classified profiles are used. Aggregate checks total group traffic first, then Classified checks individual member traffic.

DoS Protection Profile Settings

DoS Protection Profiles are configured under Objects > Security Profiles > DoS Protection in PAN-OS. These profiles define the specific thresholds and actions for mitigating DoS attacks and are then attached to DoS Protection Policy rules. Each profile can be configured as either 'Aggregate' or 'Classified'.

Profile Type:

• Type: The first crucial setting when creating a profile.
  • Aggregate: Thresholds apply to the combined traffic of all resources matched by the DoS policy rule using this profile.
  • Classified: Thresholds apply individually to each resource, as defined by the 'Address' classification in the DoS policy rule using this profile.
  This choice dictates how all subsequent thresholds within the profile are interpreted and enforced.

Flood Protection Settings:

Similar to Zone Protection, DoS Protection profiles allow configuring flood protection against various IP protocols based on Connections Per Second (CPS). These settings are granular per protocol type (SYN, UDP, ICMP, ICMPv6, Other IP).

• Alarm Rate (CPS): When CPS for the specified protocol (either aggregate or per classified IP) reaches this value, an informational Threat log is generated. No blocking action is taken.
• Activate Rate (CPS): When CPS reaches this value, the firewall begins the configured mitigation action (e.g., SYN Cookies, RED, or simple drop for non-TCP floods).
• Maximum Rate (CPS): When CPS reaches this value, the firewall takes its most aggressive action, typically dropping all new connections of that protocol type.
• Block Duration (seconds): If the action taken due to exceeding Activate/Maximum rates involves blocking (e.g., source IP block after repeated offenses), this specifies how long the block remains in effect. Default is often 0 (no block duration beyond immediate packet drop), but can be configured.
  Gotcha! (Palo Alto Networks): The "Block Duration" in DoS Protection Profiles behaves differently than in Packet Buffer Protection or Reconnaissance Protection. For DoS flood protection, if an action like "Block IP" is implicitly part of the mitigation strategy (e.g., for persistent offenders after RED), this duration applies. Often, for SYN Floods, the primary actions are SYN Cookies or RED on packets, not immediate long-term IP blocks from this setting alone. Explicit source blocking features are more tied to Classified profile actions after sustained attacks. Consult PAN-OS documentation for specific version behavior.
• SYN Flood Action (for SYN Flood type only):
  • SYN Cookies: Firewall proxies the TCP handshake. More resource-intensive for the firewall but better preserves legitimate connections.
  • Random Early Drop (RED): Firewall randomly drops incoming SYNs. Less resource-intensive but can drop legitimate SYNs.

Resource Protection Settings:

This unique feature within DoS Protection Profiles helps defend protected resources (primarily servers) against session table exhaustion attacks or from being overwhelmed by too many concurrent connections.

• Enable Resource Protection: Checkbox to activate this feature.
• Limit (Concurrent Sessions): Defines the maximum number of concurrent sessions allowed to the protected resource(s).
  • For Aggregate Profiles: This limit applies to the total number of concurrent sessions for *all resources combined* that match the DoS policy rule.
  • For Classified Profiles: This limit applies *individually* to each unique resource (e.g., each destination IP if using destination-ip-only classification).
• Alarm Rate (% of Limit): (Optional) A percentage of the 'Limit'. When concurrent sessions reach this percentage, an informational Threat log is generated.
• Action:
  • Protect: When the 'Limit' is reached, new connection attempts to the protected resource(s) are typically dropped or subject to mitigation. This is the standard protective action.
• Block Duration (seconds): If blocking occurs due to exceeding the session limit, this defines how long the block (e.g., preventing new sessions from a source) might last.

Example Scenario for Resource Protection (Classified):

• A Classified DoS Profile with Resource Protection Limit set to 500 concurrent sessions.
• Applied to a DoS Policy Rule protecting three web servers (ServerA, ServerB, ServerC) using destination-ip-only classification.
• ServerA can have up to 500 concurrent sessions. ServerB can have up to 500. ServerC can have up to 500. These limits are independent. If ServerA reaches 501 sessions, new connection attempts to ServerA will be dropped, but ServerB and ServerC are unaffected by ServerA's limit being hit.

Careful baselining of both CPS and normal concurrent session loads for critical applications is essential before configuring thresholds in DoS Protection Profiles. Using default values is strongly discouraged.

DoS Protection Policy Rules

DoS Protection Policy rules, configured under Policies > DoS Protection in PAN-OS, are what activate DoS Protection Profiles. These rules define the specific traffic flows that will be subject to the DoS mitigation measures outlined in the attached profiles. DoS Protection policy rules are evaluated after Zone Protection checks and before Security Policy rules for new sessions.

Key Components of a DoS Protection Policy Rule:

1. Name & Description: Standard identification fields.
2. Tags: For organization and filtering.
3. Match Criteria (Source):
   • Source Zone: The zone(s) from which the traffic originates.
   • Source Address: Specific source IP addresses, address groups, regions, or FQDNs. Often set to 'Any' for protecting servers from internet traffic.
   • Source User: (If User-ID is integrated) Specific users or user groups. Less common for typical server DoS protection, more for internal abuse cases.
4. Match Criteria (Destination):
   • Destination Zone: The zone(s) where the protected resources reside.
   • Destination Address: Specific IP addresses or address groups of the critical resources you want to protect (e.g., your web server farm IPs). This is a primary matching criterion.
5. Match Criteria (Service/Application):
   • Service: Defines the TCP/UDP ports or ICMP types to protect (e.g., service-http, service-https, custom service objects).
     CRITICAL (Palo Alto Networks): It is a best practice to specify the exact services running on the protected destination IPs. Avoid using 'Any' for the service if possible, as this makes the DoS protection less targeted and could inadvertently affect legitimate non-standard services.
   • Application: While you can specify an application, DoS Protection typically acts earlier than full App-ID identification for new sessions. Service-based matching is more common here.
6. Action:
   • Protect: This is the most common action. It enables DoS protection for matching traffic using the specified DoS Protection Profile(s).
   • Allow: Explicitly allows matching traffic to bypass DoS protection checks defined by this rule. This traffic would still be subject to Zone Protection and Security Policy. Useful for creating exceptions for trusted traffic that might otherwise trigger DoS thresholds.
   • Deny: Blocks matching traffic outright, without applying any DoS profile thresholds. Useful for proactively blocking known malicious sources or unwanted services from reaching critical assets.
7. Profile Settings (If Action is 'Protect'):
   • Aggregate DoS Protection Profile: Select an Aggregate DoS profile to apply its thresholds to the combined traffic matching this rule.
   • Classified DoS Protection Profile: Select a Classified DoS profile to apply its thresholds individually based on the 'Address' classification.
     • Address (Classification): If a Classified profile is chosen, you MUST select the basis for classification:
       • source-ip-only
       • destination-ip-only (Recommended for server protection)
       • source-destination-ip-both
   • A rule can have an Aggregate profile, a Classified profile, or both. If both, the Aggregate profile is checked first.
8. Scheduling: (Optional) Apply the DoS Protection policy rule only during specific time periods, allowing for different protection stances (e.g., more aggressive thresholds during off-peak hours).
9. Log Forwarding: (Highly Recommended) Specify a Log Forwarding Profile to ensure that Threat logs generated by this DoS Protection rule (e.g., when thresholds are breached) are sent to relevant destinations like Panorama, a SIEM, or email notifications for security administrators.

Example DoS Protection Policy Rule for Web Servers:

• Name: Protect_Web_Servers_DMZ
• Source Zone: [Internet_Zone]
• Source Address: Any
• Destination Zone: [DMZ_Zone]
• Destination Address: Web_Server_Group (Address Group containing IPs of web servers)
• Service: service-http, service-https
• Action: Protect
• Classified DoS Protection Profile: Web_Server_Classified_DoS_Profile (with appropriate CPS flood and Resource Protection limits per server)
• Address (Classification): destination-ip-only
• Log Forwarding: SIEM_and_Admin_Alerts_Log_Forwarding_Profile

This rule would provide individualized DoS protection for each web server in the Web_Server_Group against HTTP and HTTPS based flood and resource exhaustion attacks originating from the internet.

PCNSE Knowledge Check: Palo Alto Networks Zone & DoS Protection