White Paper Brocade NetIron Denial of Service Prevention This white paper documents the best practices for Denial of Service Attack Prevention on Brocade NetIron platforms.
Table of Contents Brocade NetIron Denial of Service Prevention... 1 Introduction... 3 Overview of Denial of Service (DoS) Attacks... 3 Primary Types of DoS Attacks... 3 Brute Force Flooding Attacks... 4 IPv6 Neighbor Discovery (ND6) Attack Example... 4 1. Rate-Limiting IPv6 Traffic... 4 2. Hardware Based Drop Entry Solution... 5 TCP ACK Attack Example... 6 1. Control Traffic Prioritization Solution... 6 2. Control Plane Resiliency with Hardware Based Scheduling Solution... 6 3. IP Receive ACL (racl) Configuration Recommendation... 7 NetIron Brute Force Flooding Attack Solution Summary... 12 Protocol Based Attacks... 12 SYN Flood Attack Example... 13 1. TCP Rate Limiting Configuration Recommendation... 13 2. TCP ACL Configuration Recommendation... 13 TCP Reset Attack Example... 14 1. TCP Reset Attack Solution... 14 XMAS Tree Attack Example... 14 1. XMAS Tree Attack Solution... 14 SMURF Attack Example... 14 1. SMURF Attack Configuration Recommendation... 14 PING of Death Attack Example... 15 1. PING of Death Attack Solution... 15 TearDrop Attack Example... 15 1. TearDrop Attack Solution... 15 NetIron Protocol Based Attack Solution Summary... 16 Conclusion... 17 Page 2 of 17
INTRODUCTION This is Version 1 of a white paper that will discuss the best practices recommended by Brocade for securing the NetIron platform from Denial of Service (DoS) attacks. It will cover the definition of a DoS attack, the primary types of DoS attacks, and provide the solutions to prevent and mitigate each of the identified DoS attacks. Some of the prevention mechanisms are enabled by default in the hardware and/or software of the system. When that is the case, it will be pointed out. When a prevention mechanism requires configuration of the system, best practice parameters for these configurations are discussed. Version 2 of this white paper will contain more details of example best practice configurations. It is important to realize that the best practices discussed in this paper should be a subset of an overall security strategy to mitigate risk and improve network availability and stability. OVERVIEW OF DENIAL OF SERVICE (DOS) ATTACKS DoS attacks are threats to computer and network systems that aim to exploit known limitations and/or vulnerabilities in the software or hardware of devices in a network. The intended result is to disrupt or terminate services provided by that system, making the service or system unavailable for its intended use. The primary goal of a DoS attack is to crash the services being provided by the targeted system and/or to exhaust the available resources of the targeted system, making the system unstable or unusable. The result is that the service being offered is denied to valid users of the system. One advanced type of DoS attack is a Distributed Denial of Service (DDoS) attack. A DDoS attack occurs when multiple systems are coordinated to attack and exhaust the resources of a targeted system or to deny bandwidth to or from the targeted system. Because the source IP addresses of the attacking hosts can be spoofed, a DDoS attack could come from a limited set of hosts or even from a single specific host while giving the appearance of a distributed attack. These types of attacks are particularly difficult to trace which sources are responsible for the attack. PRIMARY TYPES OF DOS ATTACKS There are two primary categories of DoS attacks that are discussed in this paper. Brute Force Flooding attacks and Protocol Based attacks; both of which have many different variations of attack or exploit. A brute force flooding attack is aimed at consuming a finite resource such as CPU, bandwidth or a limited amount of memory space in the targeted system. A protocol based attack exploits a specific feature or implementation of a protocol installed on the targeted system, in order to consume excess amounts of its resources. Rather than just attacking the system by brute force, a specific protocol feature or implementation is targeted. Both of these types of attacks can cause resources in the targeted system to be excessively consumed; ultimately resulting in a denial of service. Some examples of protocol based attacks are: Attacks on TCP vulnerabilities o SYN flood o ACK flood o Reset attack o XMAS tree attack Attacks on ICMP o Smurf attack o Ping flood o Ping of death Attacks based on fragmentation o Teardrop attack Page 3 of 17
o Ping of death DNS based DDoS attacks o DNS amplification attack BRUTE FORCE FLOODING ATTACKS As previously stated, a brute force flooding attack is intended to consume a finite resource such as CPU, bandwidth or memory available in a targeted system. Doing so causes the system resources to become unavailable for legitimate users. The primary solution against a brute force flooding attack is to ensure there is better protection of all finite resources s in the system and to ensure prioritization ization of legitimate control plane traffic over other types of traffic. IPv6 Neighbor Discovery (ND6) Attack Example One example of a brute force flooding attack is the IPv6 Neighbor Discovery (ND6) DoS attack. IPv6 neighbor discovery is used by nodes on the same link to discover each other s presence, to determine each other s link- layer addresses, to find available routers on the link, and to maintain reachability information about active neighbors on the link. The IPv6 neighbor information is maintained in the ND6 table, which is stored in the routers memory. This type of attack involves a traffic sweep of unused addresses on the system and sending large amounts of traffic to one of the unused addresses. Performing an address sweep of unused directly connected hosts can consume the entire ND6 table, resulting in large numbers of Neighbor Solicitation (NS) messages to be generated. NS messages are sent by the router to determine the link-local local address of a neighbor, or to verify the neighbor is still reachable via a cached link-local local address. When the ND6 table is entirely consumed by this type of attack, the resulting depletion of legitimate ND6 table entries causes legitimate neighbors to become unreachable. Also, sending large amounts of traffic to a single unused IPv6 address can keep the CPU busy doing ND resolution. Both of these attacks can be mitigated by ensuring prioritization of legitimate control plane traffic over other types of traffic. Figure 1: Example of IPv6 Neighbor Discovery (ND6) Brute Force Attack 1. Rate-Limiting IPv6 Traffic As stated, when an IPv6 packet is received that is destined to a subnet address which belongs on the device, the packet is sent to the MP for processing. The MP then sends a neighbor solicitation packet to the neighbor if the neighbor MAC address is not yet resolved. An attacker can initiate a DoS attack in which it can send unsolicited packets to the router, destined for a non-existing address. The CPU on the MP will be using a lot of resources in Page 4 of 17
attempting to resolve the unknown neighbor. Similarly an attacker can do an address sweep of the device to attempt t a DoS attack. Through this feature we are intending to prevent these kinds of DoS attacks. Here is a system level command which will be applicable to all the VRFs on the NetIron device. [no]ipv6 rate-limit subnet policy-map <policy-map > When this command is given, it will set rate limiter parameters based upon the defined policy map. The rate limiter will protect the MP CPU from excessive IPv6 packets destined to the device. If the policy map is not configured then it will configured the rate limiter with line rate values. This command is similar to the arp rate-limit command. It is also possible to view the counters for this command. show rate-limit ipv6 subnet This will show the number of bytes forwarded to MP CPU along with the number of dropped bytes. The output of this command is be similar to show rate-limit arp command. A sample output is shown below. Router# show rate-limit ipv6-subnet Fwd: 252 Drop: 0 bytes Re-mark: 0 Total: 252 bytes 2. Hardware Based Drop Entry Solution The hardware based drop entry feature is a mechanism to drop traffic that is destined to a host entry that is stored in a hardware cache, if that host is pending an ARP/ND resolution. This feature is built into the NetIron platform and requires no additional configuration. Host entries are automatically programmed in hardware to drop traffic destined to a host that is pending an ARP/ND resolution. All pending entries that are over the platform limit are then maintained in software.. During ARP or ND resolution, the drop entry is removed & a CAM entry is added after a successful resolution.. However, it is important to note that when the hardware drop entry limit is reached, the CPU is no longer protected from traffic to new hosts that need resolution. In this scenario, consider using receive ACLs as an additional way to protect the control plane CPU. Figure 2: : Example of Hardware Based Drop Entries Solution Page 5 of 17
TCP ACK Attack Example This type of attack consists of simply sending a high rate of TCP ACK packets to an IP address and TCP Port number of the system. This is done to a well known port that the targeted systems CPU is listening on (for instance, BGP Port 179). The TCP stack of the system needs to process the ACK before it can discard it as illegitimate traffic. This keeps the CPU busy processing the TCP ACKs and sending TCP RST packets back to the source. This is standard behavior for a TCP stack. However, doing so causes the CPU to potentially become unavailable for processing legitimate control and management plane traffic. This type of attack can be mitigated by configuring hardware-level Access Control List (ACL) mechanisms to protect the control plane from receiving traffic from unauthorized sources. Since the ACL is performed by hardware, it will operate at high-performance while preventing these illegitimate packets from ever reaching the systems CPU. Figure 3: : Example of TCP Port 179 Brute Force Attack 1. Control Traffic Prioritization Solution The NetIron platform performs prioritization of control plane traffic so that lower priority traffic cannot overwhelm high priority control plane traffic. The platform also features the use of separate queues for each priority level. This ensures that the critical high priority control plane traffic is not affected by high rates of low priority traffic. The platform also implements a complete separation of the data plane from the control plane,, so that data plane packets and control plane packets do not share same queues in hardware. Additionally, with complete separation of the data and control planes, impacts to the control plane CPU do not impact the packet forwarding performance that is done in hardware in the date plane. 2. Control Plane Resiliency with Hardware Based Scheduling Solution This feature allows prioritization and scheduling mechanisms at a finer granularity to achieve better control plane resiliency. All packets destined to the Line Processor (LP) CPU are put in 32 traffic manager queues that are in hardware. No QoS scheduling of these queues is handled by the LP CPU; all QoS scheduling is done in hardware by the traffic manager (TM) processor. Scheduling & policing applied within these queues guarantee s optimal control packet processing. Additional highlights of this feature: Protocol control packets are prioritized over management traffic (telnet, ping etc). Protocol control packets are prioritized over MAC SA learning, sflow, logging packets etc. Management traffic is prioritized over MAC SA learning, sflow, logging and other packets processed by the CPU Weighted scheduling used to ensure no queue starvation Rate shaping applied to packets to ensure that CPU is not affected by control packet storms Page 6 of 17
Figure 4: Example of Hardware Based Scheduling Solution 3. IP Receive ACL (racl) Configuration Recommendation The IP receive Access-Control List feature (racl) provides a hardware-based filtering capability for IPv4 traffic destined for the CPU in the default VRF.. This protects the management module s CPU from being overloaded due to large amounts of traffic sent to one or more of the platform s IP interfaces. Control and management traffic that have a destination IP address of the device itself is handled by the management module s CPU. These racls will provide hardware based protection for the CPU; to prevent it from being overwhelmed by excessive and/or illegitimate control and management traffic. Figure 5: Example of Receive ACLs Solution Traffic types: Management traffic Used to manage and operate the device itself (Telnet, SSH, TFTP, SNMP etc) Control traffic Used to create and operate the network (ARP, BGP, OSPF etc) Data traffic Transit traffic being forwarded by the device.. Not processed by management module CPU. a. Receive ACLs and IP Inbound ACLs Interaction Normal IP inbound ACLs are applied at the interface level and are the conventional way of controlling access to or through the router. However, using IP inbound ACLs to protect the control plane can become quite cumbersome Page 7 of 17
because they need to be replicated for all interfaces. racls simplify this task, as only a single instance of an racl is needed to protect all the interfaces on the device. In other words, an racl is applied only once and provides protection for all interfaces on the router platform. On the NetIron platform, when both racls and inbound ACLs are configured simultaneously, traffic matching racls will not be subject to inbound ACL filtering. So it is important to have the racl configured appropriately, so that it matches only management and control traffic that is destined to the routers management CPU and the rest of the traffic can be subject to normal IP inbound ACL filtering. For instance, consider the following example An IP inbound ACL has been configured on the interface to deny all traffic to TCP port 80 An racl has also been configured on the same interface with the following clause permit host 10.10.10.10 any. Figure 6: : Example of Receive ACLs and Inbound ACLs Solution Now, if host 10.10.10.10 accesses port 80 on one of the system IP addresses, the traffic will be permitted. If the user does not want this behavior and wants the traffic to be dropped instead, he would have to add an explicit clause to the racl to drop traffic destined to port 80 from host 10.10.10.10. b. racls and L2 Inbound ACLs Interaction L2 inbound ACLs are a way to control access to the network by filtering traffic based on the packet s L2 header information (including MAC addresses and VLAN ID). While, IP inbound ACLs filter traffic based on the packets L3 header information. If there is a requirement to simultaneously support L2 ACLs along with racls, racls are then evaluated in software rather than in hardware. Therefore, rate limiting using racls is not possible in this scenario. Furthermore, when an interface is configured with an L2 ACL, only traffic permitted by the L2 ACL will be processed by the racl. The L2 ACL is processed before any racls are processed. Due to this, it is recommended that racls are used in conjunction with IP ACLs instead of with L2 ACLs. Page 8 of 17
Figure 7: : Example of Receive ACLs and L2 ACLs Solution c. racls and DoS Attack Prevention Policies DoS attack policies protect the CPU from being flooded with attack traffic designed to slow down or stop normal operation. Brocade devices support measures to defend against two of these types of attacks Smurf attacks and TCP SYN attacks. The DoS attack prevention mechanisms are software implementations. However, when racls are configured along with DoS attack prevention, the DoS attack prevention features will act only on the traffic that has been permitted by racls. Figure 8: Example of Receive ACLs and DoS Attack Policy Solution d. racl and Rate Limiting Configuration Recommendation For legitimate control or management plane traffic, it is not possible to deny this traffic as this type of traffic is needed by the system. For this traffic, it is still preferable to protect the CPU from being overwhelmed from processing too much of this traffic. Rate limiting should be used in this case to protect the systems resources. Typical examples of this type of legitimate traffic are: ICMP echo requests to any of the interface IP addresses on the system OSPF control traffic Page 9 of 17
SNMP management traffic Although it is normal to expect a moderate amount of such traffic type, the control plane needs to be protected against possible attacks of sending very large amounts of this type of traffic. Rate limiting is the recommended method to mitigate this type of attack. racls can be used to rate limit such traffic going to the control plane by using a policy-map option. When the policy-map option is used, traffic matching the permit clause is rate limited as defined in the specified policy map and traffic matching the deny clause is permitted without rate limiting. Alternately, the policy-map can be used with the strict-acl option to rate limit traffic matching the permit clause and to drop traffic matching the deny clause. e. racl White vs Black List Configuration Recommendation It is always advisable to only permit specific authorized sources to access the control plane and deny everything else. This would involve the creation of a specific white list with a permit clause, followed by a deny all clause for all other traffic. However, it is risky to construct new racls this way unless all traffic and protocols are known in advance. It might be difficult to know in advance every protocol that might need to be processed by the management modules CPU. Therefore, a suggested approach of creating racls would be the following: Begin constructing racls by permitting known, authorized traffic (i.e. a white list): o List of known peers (eg: sources) for the control plane protocols that are deployed (BGP, OSPF, RSVP etc) o List of known hosts/subnets that are designated to operate in the management plane of the network (telnet, ssh, tftp, snmp, http/https etc) Explicitly deny specific, unwanted traffic (i.e. a black list): o IP fragments o Attack traffic from known hostile networks o Traffic from bogon IP addresses (reserved/unallocated IP space) It is then recommended to have additional clauses at the end of the racl to help classify currently unknown, incoming traffic further. This final clause is meant to identify all other traffic arriving on the device, whether that traffic type is known in advance or not. This allows the customer to determine all traffic types that are directed to the system. The preceding permit and deny clauses can then be updated based on this learned information. It is important to ensure that this last clause has a permit all so as not to inadvertently prevent critical traffic from reaching the management CPU. Over time, as all the traffic reaching the management modules CPU is identified and categorized as desirable or not, the racl can be fine tuned to either permit or deny each traffic class and the permit any at the bottom of the racl can be removed when the associated traffic counter is no longer incrementing. This is one method of identifying all important traffic types, when this is not known in advance. f. racls to Protect Local Services/Open Ports Configuration Recommendation All TCP/UDP ports are closed by default on the NetIron platform. A given port starts to listen for incoming connections only when the corresponding application has been configured and started. For instance, telnet port 23 is opened to listen for incoming telnet requests only when the telnet server is enabled on the device. When using racls, the following guidelines should be used when a new local service is configured: If the racl ends with a deny any any clause (ie, the racl consists only of a white list with explicitly permitted hosts/networks and ends with a deny all), explicit rules need to be added to allow access to the newly opened port. Page 10 of 17
If the racl ends with a permit any any (ie, the racl consists of explicitly denied black list and ends with a permit all), deny statements should be added to block unwanted hosts/networks from accessing the newly opened up port. When access to the port/service cannot be explicitly granted to known hosts, consider rate limiting traffic to the local service/port to avoid full exposure to an attack. An example when configuring BGP on the device: If implementing white lists, add racl clauses to permit access to TCP port 179 from every configured BGP peer. This is needed to bring up BGP, as without allowing explicit access, BGP won t even come up. If implementing black lists, add racl clauses to explicitly deny access to TCP port 179 from known bad hosts/networks. Although BGP would be functional without this step, port 179 can be subject to a DOS attack and this is best prevented by adding a deny clause to the racl. Customers with 100s of BGP peers need to take the following into consideration while using racls. Every racl clause configured with a destination IP as any will be replicated internally in hardware for every IP address defined in the system. For example, on a system with 50 interface IP addresses, an racl clause such as permit ip 20.20.20.20 any tcp any 179 will be replicated internally into 50 hardware entries. To avoid a scaling concern, customers can specify specific the destination IP addresses in their racl definitions, instead of using any. For instance, since every BGP peer will be establishing BGP session(s) with a specific destination IP address in the system, specifying white list clauses that allow those peers to connect to specific IP addresses will avoid hitting scaling issues. g. Changing an Existing racl Configuration Changes in racl configurations are not automatically applied to the systems hardware. Customers need to use the command ip rebind-receive receive-acl all to reapply the racls to the systems hardware. This command should be used in the following situations: Changes are made to an existing racl or a new racl clause is added to an existing set of racls in the system. When a new IP interface is added to the system. When an IP interface is removed from the system, and you want to free up the racl hardware table space allocated for that IP interface. It is advisable to make changes to racl configurations only during a scheduled maintenance window to mitigate the impact to production traffic. h. racl Configuration Considerations Here is a list of considerations that should be kept in mind when configuring racls. racl clauses with a destination IP address that is specified as any are replicated internally for every interface IP address configured on the system. Both the number of IP interfaces as well as the size of the racls needs to be considered while planning capacity for racls. If you are running into a scaling limitation with racls, consider the following: Page 11 of 17
Identify external facing interfaces separately from internal interfaces and apply an IP inbound ACLs per external interface. Convert the destination any in the racl clause to specific destination IP addresses. IPv6 racls are currently not supported. This is coming in a future release. In the meantime, consider using IPv6 interface ACLs to protect the system. racls are evaluated in software when configured simultaneously with L2 ACLs. NetIron Brute Force Flooding Attack Solution Summary The following table lists the NetIron solutions to prevent brute force flooding attacks. Some of these solutions are features that are built into the NetIron platform and some of these solutions require configuration based on best practices. NetIron Feature Problem(s) Addressed Enabling the feature Hardware based drop entry implementation Protects CPU from being overwhelmed due to high rate of spurious traffic to non-existing IPv6/IPv4 hosts needing ARP/ND6 resolution Built in no configuration necessary CPU Prioritization of Traffic Prioritizes critical control plane traffic from being disrupted due to large volume of data plane/attack traffic Built in no configuration necessary Receive ACLs Protects the CPU from being overloaded due to large amounts of traffic sent to one or more of the Brocade device s IP addresses Configuration necessary Many best practices and considerations for configuration of Receive ACLs provided PROTOCOL BASED ATTACKS Protocol based attacks are aimed at targeting protocol specific implementation vulnerabilities of a targeted system. There are various attacks that target different layers of the protocol stack IP, TCP, ICMP, etc. The nature of an attack can vary from having a high rate of traffic that consumes a protocol specific resource to the construction of malformed packets designed to exploit a protocol implementation flaw. Page 12 of 17
SYN Flood Attack Example The goal of a SYN flood attack is to exhaust the targeted systems half open TCP queue, which is a limited resource. For example: An attacker creates a random source address for each packet. The SYN flag is set in each packet so a request to open a new connection from the spoofed IP address is made on the targeted system. The TCP/IP stack of the targeted system responds to the spoofed IP address with a SYN ACK, and puts this connection in a half open queue. This queue is limited in size and much smaller than the established queue. The half open queue fills up waiting for client ACK s that never arrive. At this point, legitimate user requests are ignored as well. This results in denying them access to the targeted system. 1. TCP Rate Limiting Configuration Recommendation The ip tcp burst-normal command allows the user to configure NetIron devices to drop TCP SYN packets when excessive numbers are encountered. Syntax: ip tcp burst-normal <value> < burst-max <value> lockup <sec> Recommended values for the ip tcp burst-normal command The value for burst-normal should be set to the expected number of new TCP connection requests coming into the device. For instance, when there are 50 BGP peers configured, all 50 peers would initiate new connections when the device initializes. So in this scenario, the value of burst-normal should be set to at least 50. The burst-max should be set to a value that is never expected to be reached under normal operating conditions. This threshold should be set to a value that indicates an attack with certainty, as the associated action would be to lock up the system from accepting any new connections, including both legitimate and illegitimate sources. The lockup should be set to a value that will protect the system for the expected duration of the attack. Typical attacks last in the order of minutes. So typical values for the lockup field should be 5 to 10 minutes. 2. TCP ACL Configuration Recommendation In the case where the attacking host or network is identifiable (not random), ACLs (either IP inbound ACLs or racls) can be used to protect the control plane against the SYN flood by using the following clause in the ACL definition: deny tcp tcp-operator syn If the attack is on a specific unsecured external interface which is different from the secure internal interfaces, IP inbound ACLs can be used on the external interfaces to protect against SYN flood attacks. If the attack is coming in on multiple interfaces on the system and directed at the system IP addresses, use racls to protect the control plane from SYN flood attacks Page 13 of 17
TCP Reset Attack Example This type of attack is meant to abnormally terminate legitimate TCP connections by sending a packet with the TCP RST bit set. The attacker tries to guess the sequence number of the RST segment, in order to exploit poor implementations of window checking on the targeted systems TCP stack. 1. TCP Reset Attack Solution The NetIron platform has in-built capabilities to prevent against such an attack, and performs stringent sequence number checks before treating the RST as valid and terminating the connection. XMAS Tree Attack Example A XMAS tree attack is designed to exploit the vulnerabilities of a targeted systems TCP stack implementation. This type of attack works by setting multiple bits in the TCP header (SYN, FIN, URG, PUSH). A XMAS tree attack can be used to scan the system, whereby the response to the XMAS tree packets can help the attacker figure out the underlying operating system. XMAS tree attacks can also be used to cause unpredictable behavior of the targeted systems TCP/IP stack, thereby disrupting the TCP state machine of the system. 1. XMAS Tree Attack Solution The TCP stack of the NetIron platform is hardened against an XMAS tree attack, and discards packets that have conflicting TCP bits set. SMURF Attack Example This type of attack relies on sending a large amount of ICMP echo request (ping) traffic to an IP broadcast address on the targeted system. All of these packets would have a spoofed source IP address that belongs to the targeted system. When a router delivers the IP broadcast to all directly connected hosts, most hosts will respond with an ICMP echo reply, thereby overwhelming the targeted system resources. A Smurf amplifier is a computer network that lends itself to being used in a Smurf attack. Smurf amplifiers act to amplify (worsen the severity of) a Smurf attack because they are configured in such a way that they generate a large number of ICMP replies to a spoofed source IP address (which belongs to the target of the attack). 1. SMURF Attack Configuration Recommendation To protect against Smurf attacks on the NetIron: Avoid being an intermediary in a SMURF attack. A smurf attack relies on an intermediary system to broadcast ICMP echo request packets to hosts on a target subnet. To avoid being an intermediary, you can disable forwarding of directed broadcast packets by using the command no ip directed-broadcast broadcast. Note: ip directed-broadcast is disabled by default on the NetIron platform. Avoiding being a victim of a SMURF attack. You can configure the device to drop ICMP packets when excessive numbers are encountered by using the ip icmp burst-normal command Syntax: ip icmp burst-normal <value> burst-max <value> lockup <seconds> Example: Brocade(config)#ip ip icmp burst-normal 5000 burst-max 10000 lockup 300 Page 14 of 17
Recommended values PING of Death Attack Example The value for burst-normal should be set to the expected number of ICMP packets coming into the device. These could be a mix of legitimate ICMP echo requests directed to the device for management purposes and ICMP diagnostic messages (unreachable messages etc) that need to be processed by the device. The burst-max should be set to a value that is never expected to be reached under normal operating conditions. This threshold should be set to a value that indicates an attack with certainty, as the associated action would be to lock up the system from processing any new ICMP packets including both legitimate and illegitimate. The lockup should be set to a value that will protect the system for the expected duration of the attack. Typical attacks last in the order of minutes. So typical values for the lockup field should be 5 to 10 minutes. This type of attack uses a ping packet of abnormal size, exceeding the TCP/IP specification, to either cause a system crash or to cause control and management plane applications to stop processing on the targeted system. This is usually implemented as a fragmented attack, which exploits vulnerabilities in the reassembly logic of the IP stack. When a targeted system attempts to reassemble a malformed fragment, a buffer overflow may occur, thereby possibly causing a system crash. The attack can be prevented by adding more rigorous checks in the reassembly process, where the length of the resulting IP datagram is pre-computed and checked not to exceed maximum IP datagram length (65535) before performing reassembly. 1. PING of Death Attack Solution On NetIron devices, the reassembly mechanism of the IP stack is hardened against this attack. All necessary checks for fragment length and offset are conducted before attempting to reassemble fragments. Invalid fragments are discarded by the stack. You can also use racls to block all IP fragments. Since legitimate control and management plane traffic is unlikely to be fragmented, you can use racls to block all IP fragments directed to the device. TearDrop Attack Example A Teardrop attack involves sending mangled IP fragments with overlapping, over-sized payloads to the targeted system. This can possibly crash the operating system of a targeted system due to a bug in the TCP/IP fragmentation reassembly logic. The attack can be prevented by placing more stringent checks in the IP reassembly process of the IP stack, to check for overlapping fragments and the resulting length before reassembling IP datagrams. 1. TearDrop Attack Solution On NetIron devices, the reassembly mechanism of the IP stack is hardened against this attack. All necessary checks for fragment length and offset are conducted before attempting to reassemble fragments. Invalid fragments are discarded by the stack. You can also use racls to block all IP fragments. Since legitimate control and management plane traffic is unlikely to be fragmented, you can use racls to block all IP fragments directed to the device. Page 15 of 17
NetIron Protocol Based Attack Solution Summary The following table lists the NetIron solutions to prevent protocol based attacks. Some of these solutions are features that are built into the NetIron platform and some of these solutions require configuration based on best practices. NetIron Feature Problem(s) Addressed Enabling the feature TCP SYN rate limiting Protects against SYN flood attacks Configuration necessary RST attack protection Protects against abnormal termination of legitimate connections Built in no configuration necessary TCP flag checker Protects against malformed TCP control packets Built in no configuration necessary Disabling Ip directed broadcast Protects against being an intermediary in a SMURF attack Built in no configuration necessary ICMP rate limiting Protects against being the victim of a SMURF attack, or any other ICMP flood attack Configuration necessary Strict IP reassembly module Protects against IP fragmentation attacks such as ping of death, teardrop attack Built in no configuration necessary Page 16 of 17
CONCLUSION Brocade NetIron routers support extensive protection mechanisms against Denial of Service (DoS) attacks. In addition, NetIron products have been reliably deployed for many years in many large SP and Enterprise networks. Examples of known attacks and the Brocade recommended solutions have been documented in this paper. Some of the solutions that are discussed are enabled by default in the systems hardware and software. They are explained here for completeness. When a solution requires a specific configuration to be enabled, examples are given on the best practice parameters associated with each type of configuration. Version 2 of this white paper will cover more details of example best practice configurations. The DoS prevention recommendations documented in this paper should become part of every NetIron router configuration template when a system is deployed in any network. As initially stated, this guide is a subset of an overall security strategy to mitigate risk and improve network availability and performance. Additional information regarding NetIron products can be found at www.brocade.com. Page 17 of 17