«Understanding DoS Protection in PAN- OS Tech Note Revision A ©2013, Palo Alto Networks, Inc. Contents Overview ...»
Revision A ©2013, Palo Alto Networks, Inc. www.paloaltonetworks.com
How does RED work?
How does SYN Cookie work?
Tuning Thresholds – Case Studies
Scenario 1: Maximizing Performance
Scenario 2: Protecting your Session Table
Packets Per Second vs. Sessions Per Second
Packet Based Attacks
IP Spoof Protection
Mismatched Overlapping TCP segment
Reject non-SYN TCP packet
IP Option Drop
ICMP ping ID 0
Suppress ICMP TTL Expired Error
Suppress ICMP NEEDFRAG
Configuration and Troubleshooting
Logs with Random Early Drop
Logs with SYN cookie
End Point Protection (DoS Profile and Rule base)
DoS Protection Rules
DoS Rule Match Criteria
DoS Rule Actions
DoS Protection Profiles
DoS Profile Types
Flood (Behavior-based) Protection
Resource Based Protection
Protection Precedence and Limitations
Configuration and Troubleshooting
©2013, Palo Alto Networks, Inc.  Overview A Denial of Service (DoS) attack is an attempt to disrupt network services by overloading the network with unwanted traffic. PAN-OS DoS protection features protect your firewall and in turn your network resources and devices from being exhausted or overwhelmed in the event of network floods, host sweeps, port scans and packet based attacks. The DoS protection features provide flexibility by varying the granularity of protection and provide usability through a variety of options that cover most of the attacks in the current DoS landscape. In this tech note we will explain the deployment of DoS protection features with the help of best practices and guidelines, analyze threshold parameters using specific scenarios, discuss real-world applications and enable effective end point protection.
DoS Protection in PAN-OS takes a two-pronged approach to mitigate DoS attacks:
1. Zone-Based Protection – A broad-based comprehensive DoS template at the edge to prevent the enterprise network from volumetric DoS attacks. It acts as a first line of defense for the network.
2. End Host Protection (DoS Rule base and Profiles) – A flexible policy rule base that provides a scalpel-like granularity in protecting specific end hosts (web servers, DNS servers, user subnets), which are critical or have been historically prone to DoS attacks. It also protects from attacks originating within the private network by filtering on compromised servers and rogue end hosts.
The above mentioned approaches complement each other and are recommended to be deployed in tandem to achieve the best results against the various DoS attacks observed on the internet today. These are explained in detail in the sections below.
Zone- Based Protection A zone protection profile offers protection against most common floods, reconnaissance attacks and other packet-based attacks. It can be used as a template configuration for applying similar settings to multiple zones. These settings apply to the ingress zone (i.e. the zone where traffic enters the firewall). Zone protection settings apply to all interfaces within the zone for which the profile is configured.
Note: Zone protection is only enforced when there is no session match for the packet. If the packet matches an existing session, it will bypass the zone protection setting.
Flood Protection The Flood Protection sub-tab in the zone protection profile has configuration options to protect against SYN, UDP, ICMP, ICMPv6 and other IP floods. The value set in the Alert, Activate and Maximum fields are the packets per second from one or many hosts to one or many destinations. Flood protection settings are applied to the ingress zone of the traffic. Packets from any host entering the firewall from the zone that has zone protection profile enabled are sampled at an interval of one second. This is to determine if the rate matches the threshold values. Once the thresholds are reached, an appropriate action is taken depending on the type of the threshold. For example an alert log is generated, a flood protection mechanism is activated or the incoming packets are dropped.
SYN Floods Flooding a host or a network with incomplete TCP connections, the attacker can eventually fill up the memory buffers or spike the CPU utilization of the victim device. Once the buffers are full or the CPU is overwhelmed, the host cannot process new TCP connection requests. The flood might even damage the victim's operating system. Either way, the attack disables the victim and its normal operations. PAN-OS supports SYN cookie and Random Early Detection (RED) for protection against such SYN floods.
How does RED work?
An Active Queue Management (AQM) algorithm like Random Early Detection (also known as Random Early Drop or RED) is one of the most common methods to protect against SYN flood attacks. With RED, given a packet rate within one
- If the rate falls between [0 and Activate threshold - 1], packet drop probability is 0.
- If the rate falls between [Activate threshold and Maximum threshold – 1], drop probability linearly increases from 0 to 1.
©2013, Palo Alto Networks, Inc.  You can calculate the number of dropped packets, given rate X in [A to M], where A is the activate threshold, M is the maximum, then roughly (M – A) * sum (1/N, N in [M-X, M-A]) – (X – A).
This means that when X is less than A, the probability of a packet being dropped is 0 and if X is M the probability is 1 (100%). So after you go beyond A, probability linearly grows from point where at A no packets will be dropped to M where all packets will be dropped. If more packets are sent more will be dropped.
The effectiveness of RED depends on the proper calculation of the Activate and Maximum thresholds. If the thresholds are kept very low the algorithm can penalize legitimate traffic thereby being unfair. In contrast if the thresholds are set to very high values, it may not detect Low-rate DoS (LDoS) attacks. Also it requires maintenance of state for malicious traffic, which may lead to CPU and resource overhead.
How does SYN Cookie work?
SYN Cookie is a near stateless SYN proxy mechanism. Unlike traditional SYN proxy mechanisms, when a SYN segment is received SYN cookie does not set up a session or do policy or route lookups. It also doesn’t maintain a connection request queue. This enables the firewall to maintain optimal CPU loads and prevent exhaustion of packet buffers. With SYN Cookie, the firewall acts as man-in-the-middle for the TCP handshake. The figure below shows how a connection is established between an initiating host and a server when SYN Cookie is active on a PAN-OS device. If SYN cookie is activated and the connection is found to be legitimate, the firewall does the sequence number translation for established connections. SYN Cookie is a recommended method as opposed to RED for its obvious advantages of fairness for legitimate traffic and less CPU overhead.
©2013, Palo Alto Networks, Inc.  The intention behind using SYN Cookie is to not use any local resources to remember a SYN packet entering the firewall, because it might be a malicious one. However there are few pieces of information like maximum segment size (MSS), TCP window scaling option (WSOPT), selective acknowledgments (SACK), and so on that we need later on for legitimate connections. Hence some processing and resource overhead is introduced with SYN Cookie, albeit not as much as with other SYN proxy mechanisms or RED.
Tuning Thresholds – Case Studies SYN Cookie protection involves the use of three threshold values, which play an important part in the performance and
effectiveness of the mechanism against various scales of SYN flood attacks:
Alert: The number of SYN packets per second entering the ingress zone after which alarms are generated. Alarms can be viewed under threat logs, or dashboard. SNMP traps and syslog messages can also be sent.
Activate: The number of SYN packets per second entering the ingress zone after which RED or SYN cookie is triggered.
Maximum: The number of SYN packets per second entering the ingress zone after which any new SYN packet to any host in the zone is dropped. All other non-TCP traffic to the zone will pass normally.
The optimal values of these threshold parameters depend on the following factors:
Production traffic flowing through the network • Resources that need to be protected • Scenario 1: Maximizing Performance In this scenario a major online retail company, BayZon, has deployed Palo Alto Networks firewall(s) to secure its corporate network; the deployment topology is shown in the figure below. The corporate network has been segmented into three ©2013, Palo Alto Networks, Inc.  Zones: Untrust (External facing), Trust (Internal corporate users and servers) and DMZ (guest application and web servers).
Being in online retail business, BayZon has a security initiative to protect its web servers from malicious DoS attacks, which overrun the memory buffers, and spike up the server loads almost every other month. The security admin also observes that the firewall packet buffers and resource utilization increases to critical levels during these attacks. The security admin wants to have a broad-based protection mechanism from such external attacks without adding to the performance overhead of the firewall.
packet descriptor (on-chip):
Solution: Traffic Profiling During a typical weekday/weekend the retail website traffic should be profiled using the Alert threshold knob. We can start tuning upwards from 10,000 pps, which is the default value. It is set to a value whereby you do not receive an alert log under the Monitor tab. After that we set the Activate threshold to match the Alert threshold or slightly above. To further improve the performance, bring down the maximum threshold from a default of one million pps to a value above the Activate threshold. This would ensure that additional sessions that cannot be handled by SYN cookie mechanism do not overwhelm the data plane CPU. A good rule of thumb is to put the Alert threshold approximately 10% above the average peak traffic, Activate to 10% above alert and finally Maximum to 20% to 30% above Activate.
Can we set Activate=0?
Yes we can and in some scenarios we should which will be discussed in the next section. However as we mentioned before there is some processing involved with SYN cookie as we have to wait for the ACK to come back from the receiver and then send back a packet to the sender. Setting a blanket value to a conservative minimum will activate SYN Cookie right away and will affect the CPU, packet buffers and packet descriptors utilization levels. This will negate the advantage of using SYN cookie in the first place. Instead a threshold value tuned to match the traffic profile of production traffic will protect the resources by activating SYN cookie at the appropriate incoming SYN rate. Yes it will allow some malicious connections to come in and increase the session table utilization before SYN cookie mechanism kicks in, but that is trade-off we need account for when setting the threshold values.
' ' ' '
Scenario 2: Protecting your Session Table BayZon like most online retail companies sees its sales shoot up during the Thanksgiving weekend (or any other holiday weekend). Their website experiences enormous traffic for Black Friday and Cyber Monday deals. Any network downtime or traffic loss during these business-critical holidays will translate into losses of millions of dollars in sales. Due to the heavy traffic seen by the website, the firewall resources may be running with high levels of resource utilization. It may see a lot of new connections coming in and hence high session table utilization. It is imperative to protect the session table from being overrun by any DoS attack during this critical passage of time.
©2013, Palo Alto Networks, Inc.  Solution: Conservative Minimum (Activate Threshold = 0) During business-critical hours of operation where the website sees a lot of traffic, we need to set the Activate threshold to 0.
This means that SYN Cookie is activated instantly thereby protecting the session table from brimming over the maximum session capacity of the firewall. Remember it might add a bit of CPU overhead since SYN cookie requires some processing for properly sending an ACK back to the original sender. To further improve the performance, bring down the Maximum threshold from the default of one million pps to an appropriate value above the Activate threshold but less than the maximum session rate supported by the firewall.
Tradeoff To summarize our discussion above, there exists a tradeoff relationship between performance optimization and session utilization, which is depicted by a spectrum below.
ICMP Floods ICMP flood protection applies to any type of ICMP packet.
Alert: The number of ICMP packets per seconds entering the ingress zone after which alarms are generated. Alarms can be viewed under threat logs or dashboard. SNMP traps and syslog messages can also be sent.
Activate: The number of ICMP packets per seconds entering the ingress zone after which RED is triggered.
©2013, Palo Alto Networks, Inc.  Maximum: The number of ICMP packets per seconds entering the ingress zone after which any new ICMP packets to any host in the zone is dropped. All other non-ICMP traffic to the zone will pass normally.
UDP Floods Alert: The number of UDP packets per seconds entering the ingress zone after which alarms are generated. Alarms can be viewed under Threat logs or Dashboard. SNMP traps and syslog messages can also be sent.