netiron dos prevention v2 - brocade community forums · pdf filewhite paper: netiron dos...

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.

White Paper: NetIron DoS Prevention

of 17

Table of Table of Table of Table of ContentsContentsContentsContents

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


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 attackBrute Force Flooding attackBrute Force Flooding attackBrute Force Flooding attackssss and

Protocol Based attackProtocol Based attackProtocol Based attackProtocol Based attackssss; 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


o Ping of death

• DNS based DDoS attacks

o DNS amplification attack

BRUTE FORCE FLOODING ATTACKSAs previously stated, a brute force flooding

bandwidth or memory available in a targeted

unavailable for legitimate users. The primary solution against a brute force

better protection of all finite resources in the system

over other types of traffic.

IPv6 Neighbor Discovery (ND6) Attack

One example of a brute force flooding attack is

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 activ

neighbors on the link. The IPv6 neighbor

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 Solicitatio

NS messages are sent by the router to determine the link

still reachable via a cached link-local address. When the ND6 table is entirely consumed by this type of att

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

of these attacks can be mitigated by ensuring prioritization of legitimate control plane traffic over other types of

traffic.

Figure 1: Example of IPv6 N

1. Rate-Limiting IPv6 Traffic

As stated, when an IPv6 packet is received that is des

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 w

packets to the router, destined for a non

DNS amplification attack

TTACKS flooding attack is intended to consume a finite resource such as CPU

targeted system. Doing so causes the system resources to become

The primary solution against a brute force flooding attack is to ensure there is

s in the system and to ensure prioritization of legitimate control plane traffic

(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

to find available routers on the link, and to maintain reachability information about activ

neighbors on the link. The IPv6 neighbor information is maintained in the ND6 table, which is stored in the routers

sweep of unused addresses on the system and sending large amounts of


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 address of a neighbor, or to verify the neighbor is

local address. When the ND6 table is entirely consumed by this type of att


sending large amounts of traffic to a single unused IPv6 address can keep the CPU busy doing ND resolution. Both

mitigated by ensuring prioritization of legitimate control plane traffic over other types of

Example of IPv6 Neighbor Discovery (ND6) Brute Force Attack

As stated, when an IPv6 packet is received that is destined to a subnet address which belongs on the device, 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

of 17

a finite resource such as CPU,

to become

attack is to ensure there is

ization of legitimate control plane traffic

IPv6 neighbor

discovery is used by nodes on the same link to discover each other’s presence, to determine each other’s link-

to find available routers on the link, and to maintain reachability information about active

information is maintained in the ND6 table, which is stored in the routers

sweep of unused addresses on the system and sending large amounts of


n (NS) messages to be generated.

local address of a neighbor, or to verify the neighbor is

local address. When the ND6 table is entirely consumed by this type of attack, the


the CPU busy doing ND resolution. Both

mitigated by ensuring prioritization of legitimate control plane traffic over other types of

tined to a subnet address which belongs on the device, the


hich it can send unsolicited

existing address. The CPU on the MP will be using a lot of resources in


attempting to resolve the unknown neighbor. Similarly an attacker can do an address sweep of the device to

attempt a DoS attack. Through this feature we are intending to prevent these kinds of DoS attacks

Here is a system level command which wil

[no]ipv6 rate[no]ipv6 rate[no]ipv6 rate[no]ipv6 rate----limit subnet policylimit subnet policylimit subnet policylimit subnet policy

When this command is given, it will set rate

will protect the MP CPU from excessive IPv6 packets destined to the device.

then it will configured the rate limiter with line rate values. This command is similar to

It is also possible to view the counters for this command.

sssshow ratehow ratehow ratehow rate----limit ipv6 subnetlimit ipv6 subnetlimit ipv6 subnetlimit ipv6 subnet

This will show the number of bytes forwarded to

this command is be similar to show rateshow rateshow rateshow rate

Router# show rateRouter# show rateRouter# show rateRouter# show rate----limit ipv6limit ipv6limit ipv6limit ipv6----subnet subnet subnet subnet

Fwd: 252 Drop: 0 bytes

Re-mark: 0 Total: 25

2. Hardware Based Drop Entry Solution

The hardware based drop entry feature

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.

automatically programmed in hardware to drop traffic destined to a host that is pending

pending entries that are over the platform limit are then

drop entry is removed & a CAM entry is

when the hardware drop entry limit is reached,

resolution. In this scenario, consider using receive ACLs as a

Figure 2: Example of Hardware Based Drop Entries Solution


t a DoS attack. Through this feature we are intending to prevent these kinds of DoS attacks

system level command which will be applicable to all the VRFs on the NetIron device.

limit subnet policylimit subnet policylimit subnet policylimit subnet policy----map <policymap <policymap <policymap <policy----map >map >map >map >

it will set rate limiter parameters based upon the defined policy map.

will protect the MP CPU from excessive IPv6 packets destined to the device. If the policy map is not configured

with line rate values. This command is similar to the arp ratearp ratearp ratearp rate

It is also possible to view the counters for this command.

forwarded to MP CPU along with the number of dropped bytes

show rateshow rateshow rateshow rate----limit arplimit arplimit arplimit arp command. A sample output is shown below.

subnet subnet subnet subnet

Fwd: 252 Drop: 0 bytes

mark: 0 Total: 252 bytes

y Solution

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.

he NetIron platform and requires no additional configuration. Host entries

automatically programmed in hardware to drop traffic destined to a host that is pending an ARP/ND

that are over the platform limit are then maintained in software. During ARP or ND resolution, the

is added after a successful resolution. However, it is important to note that

drop entry limit is reached, the CPU is no longer protected from traffic to new hosts that need

In this scenario, consider using receive ACLs as an additional way to protect the control plane

: Example of Hardware Based Drop Entries Solution

of 17


t a DoS attack. Through this feature we are intending to prevent these kinds of DoS attacks.

policy map. The rate limiter

If the policy map is not configured

arp ratearp ratearp ratearp rate----limitlimitlimitlimit command.

bytes. The output of

is a mechanism to drop traffic that is destined to a host entry that is stored

Host entries are

an ARP/ND resolution. All

. During ARP or ND resolution, the

. However, it is important to note that

affic to new hosts that need

way to protect the control plane CPU.


TCP ACK Attack Example

This type of attack consists of simply sending a high rate of TCP ACK packets to a

number of the system. This is done to a well known port that the

instance, BGP Port 179). The TCP stack of the system needs to process t

illegitimate traffic. This keeps the CPU busy processing

source. This is standard behavior for a TCP stack. However, d

unavailable for processing legitimate control and management plane

This type of attack can be mitigated by configuring hardware

the control plane from receiving traffic from

operate at high-performance while prevent

Figure 3: Example of TCP Port 179 Brute Force Attack

1. Control Traffic Prioritization Solution

The NetIron platform performs prioritization of

high priority control plane traffic. The platform also features the use of separate

ensures that the critical high priority control plane

platform also implements a complete separation of

packets and control plane packets do no

of the data and control planes, impacts to the control plane CPU do not impact the packet forwarding

that is done in hardware in the date plane.

2. Control Plane Resiliency with Ha

This feature allows prioritization and scheduling mechanisms at a finer granularity to achieve better control plane

resiliency. All packets destined to the Line

hardware. No QoS scheduling of these queues

the traffic manager (TM) processor. Scheduling & policing applied within these queues guarantee

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

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

simply sending a high rate of TCP ACK packets to an IP address and TCP Port

to a well known port that the targeted systems’ CPU is listening on (for

The TCP stack of the system needs to process the ACK before it can discard

eeps the CPU busy processing the TCP ACKs and sending TCP RST packets

This is standard behavior for a TCP stack. However, doing so causes the CPU to potentially become

control and management plane traffic.

tigated by configuring hardware-level Access Control List (ACL) mechanisms

receiving traffic from unauthorized sources. Since the ACL is performed by hardware, it will

preventing these illegitimate packets from ever reaching the systems’ CPU.

: Example of TCP Port 179 Brute Force Attack

Solution

rioritization of control plane traffic so that lower priority traffic cannot overwhelm

traffic. The platform also features the use of separate queues for each priority

control plane traffic is not affected by high rates of low priority traffic

omplete separation of the data plane from the control plane, so that data plane

packets do not share same queues in hardware. Additionally, with complete separation

impacts to the control plane CPU do not impact the packet forwarding

that is done in hardware in the date plane.

cy with Hardware Based Scheduling Solution

eature allows prioritization and scheduling mechanisms at a finer granularity to achieve better control plane

ine Processor (LP) CPU are put in 32 traffic manager queues

of these queues is handled by the LP CPU; all QoS scheduling is done in hardware

Scheduling & policing applied within these queues guarantee

tional 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

Weighted scheduling used to ensure no queue starvation

Rate shaping applied to packets to ensure that CPU is not affected by control packet storms

of 17

and TCP Port

listening on (for

he ACK before it can discard it as

RST packets back to the

to potentially become

mechanisms to protect

performed by hardware, it will

these illegitimate packets from ever reaching the systems’ CPU.

control plane traffic so that lower priority traffic cannot overwhelm

queues for each priority level. This

not affected by high rates of low priority traffic. The

, so that data plane

re same queues in hardware. Additionally, with complete separation

impacts to the control plane CPU do not impact the packet forwarding performance

eature allows prioritization and scheduling mechanisms at a finer granularity to achieve better control plane

in 32 traffic manager queues that are in

scheduling is done in hardware by

Scheduling & policing applied within these queues guarantee’s optimal control

Protocol control packets are prioritized over MAC SA learning, sFlow, logging packets etc.

Flow, logging and other packets processed

Rate shaping applied to packets to ensure that CPU is not affected by control packet storms


Figure 4: Example of Hardware Based Schedu

3. IP Receive ACL (rACL) Configuration Recommendation

The IP receive Access-Control List feature (rACL) provides

destined for the CPU in the default VRF. This p

to large amounts of traffic sent to one or more of the

have a destination IP address of the device itself

provide hardware based protection for the

illegitimate control and management traffic

Figure 5

Traffic types:

• Management traffic – Used to manage and

• Control traffic – Used to create and operate the network (ARP, BGP, OSPF etc)

• Data traffic– Transit traffic being forwarded by the device

a. Receive ACLs and IP

Normal IP inbound ACLs are applied at the interface level

through the router. However, using IP inbound ACLs to protect the control plane can be

Example of Hardware Based Scheduling Solution

Configuration Recommendation

ist feature (rACL) provides a hardware-based filtering capability for IPv4 traffic

. 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

the device itself is handled by the management module’s CPU. These

n for the CPU; to prevent it from being overwhelmed by excessive and/or

control and management traffic.

Figure 5: Example of Receive ACLs Solution

Used to manage and operate the device itself (Telnet, SSH, TFTP, SNMP etc)

Used to create and operate the network (ARP, BGP, OSPF etc)

Transit traffic being forwarded by the device. Not processed by management module CPU.

Receive ACLs and IP Inbound ACLs Interaction

applied at the interface level and are the conventional way of controlling access to

However, using IP inbound ACLs to protect the control plane can become quite cumbersome

of 17

based filtering capability for IPv4 traffic

’s CPU from being overloaded due

Control and management traffic that

These rACLs will

ive and/or

operate the device itself (Telnet, SSH, TFTP, SNMP etc)

. Not processed by management module CPU.

controlling access to or

quite cumbersome


because they need to be replicated for all interfaces

is needed to protect all the interfaces on the device

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.

matches only management and control traffic

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

10.10.10.10 any.

Figure 6: Example of Receive ACLs and Inbound ACLs

Now, if host 10.10.10.10 accesses port 80 on one of the system IP addresses, the traffic will be permitted

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

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)

header information. If there is a requirement to

evaluated in software rather than in hardware

Furthermore, when an interface is configured with an L2 ACL, only traffic permitted by the L2 ACL

by the rACL. The L2 ACL is processed before any rACLs are processed.

are used in conjunction with IP ACLs instead of

they need to be replicated for all interfaces. rACLs simplify this task, as only a single instance of an rACL

on the device. In other words, an rACL is applied only once and provides

the router platform.

ACLs 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

inbound ACL filtering.

For instance, consider the following example –

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

: 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


drop traffic destined to port 80 from host 10.10.10.10.

Inbound ACLs Interaction

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

f there is a requirement to simultaneously support L2 ACLs along with rACLs, rACLs are

rather than in hardware. Therefore, rate limiting using rACLs is not possible in this scenario.

an interface is configured with an L2 ACL, only traffic permitted by the L2 ACL

The L2 ACL is processed before any rACLs are processed. Due to this, it is recommended t

with IP ACLs instead of with L2 ACLs.

of 17

rACLs simplify this task, as only a single instance of an rACL

In other words, an rACL is applied only once and provides

ACLs and inbound ACLs are configured simultaneously, traffic matching rACLs

configured appropriately, so that it

and the rest of the

inbound ACL has been configured on the interface to deny all traffic to TCP port 80

permit host

Now, if host 10.10.10.10 accesses port 80 on one of the system IP addresses, the traffic will be permitted. If the


ACLs are a way to control access to the network by filtering traffic based on the packet’s L2 header

While, IP inbound ACLs filter traffic based on the packets L3

support L2 ACLs along with rACLs, rACLs are then

ACLs is not possible in this scenario.

an interface is configured with an L2 ACL, only traffic permitted by the L2 ACL will be processed

t is recommended that rACLs


Figure 7: Example of Receive ACLs and L2 ACLs Solution

c. rACLs and DoS Attack

DoS attack policies protect the CPU from being flooded with attack traffic d

operation. Brocade devices support measures to defend against two

TCP SYN attacks. The DoS attack prevention mechanisms are software implementations.

are configured along with DoS attack prevention, the Do

has been permitted by rACLs.

Figure 8: Example of Receive ACLs and DoS Attack Policy Solution

d. rACL and Rate Limiting

For legitimate control or management plane traffic,

needed by the system. For this traffic, it is still preferable to protect the CPU from being overwhelmed

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

• ICMP echo requests to any of the interface IP addresses

• OSPF control traffic

: Example of Receive ACLs and L2 ACLs Solution

rACLs and DoS Attack Prevention Policies

S attack policies protect the CPU from being flooded with attack traffic designed to slow down or stop

Brocade devices support measures to defend against two of these types of attacks – Smurf attacks and

S attack prevention mechanisms are software implementations. However, w

red along with DoS attack prevention, the DoS attack prevention features will act only on the traffic that

Example of Receive ACLs and DoS Attack Policy Solution

imiting Configuration Recommendation

For legitimate control or management plane traffic, it is not possible to deny this traffic as this type of traffic is

it is still preferable to protect the CPU from being overwhelmed

Rate limiting should be used in this case to protect the systems’ resources.

legitimate traffic are:

the interface IP addresses on the system

of 17

to slow down or stop normal

Smurf attacks and

However, when rACLs

S attack prevention features will act only on the traffic that

type of traffic is

it is still preferable to protect the CPU from being overwhelmed from

Rate limiting should be used in this case to protect the systems’ resources.


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 policypolicypolicypolicy----mapmapmapmap option. When the

policypolicypolicypolicy----mapmapmapmap option is used, traffic matching the permitpermitpermitpermit clause is rate limited as defined in the specified policy map

and traffic matching the denydenydenydeny clause is permitted without rate limiting. Alternately, the policypolicypolicypolicy----mapmapmapmap can be used

with the strictstrictstrictstrict----aclaclaclacl option to rate limit traffic matching the permitpermitpermitpermit clause and to drop traffic matching the denydenydenydeny

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 permitpermitpermitpermit clause, followed by a deny alldeny alldeny alldeny 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 allpermit allpermit allpermit 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 permitpermitpermitpermit or denydenydenydeny each traffic class and the permit anypermit anypermit anypermit 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 anydeny any anydeny any anydeny 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.


of 17

• If the rACL ends with a permit any anypermit any anypermit any anypermit 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 anyanyanyany 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 permitpermitpermitpermit ip ip ip ip

20.20.20.20 any tcp any 17920.20.20.20 any tcp any 17920.20.20.20 any tcp any 17920.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 anyanyanyany....

• 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 rebindip rebindip rebindip rebind----receivereceivereceivereceive----acl allacl allacl allacl 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 anyanyanyany 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:


of 17

• Identify external facing interfaces separately from internal interfaces and apply an IP inbound

ACLs per external interface.

• Convert the destination anyanyanyany 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 NetIron Feature NetIron Feature NetIron Feature Problem(s) Addressed Problem(s) Addressed Problem(s) Addressed Problem(s) Addressed Enabling the feature Enabling the feature Enabling the feature 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


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.


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 burstip tcp burstip tcp burstip tcp burst----normalnormalnormalnormal command allows the user to configure NetIron devices to drop TCP SYN packets when

excessive numbers are encountered.

• Syntax: ip tcp burstip tcp burstip tcp burstip tcp burst----normal <normal <normal <normal <value> burstvalue> burstvalue> burstvalue> burst----max <value> lockup <sec>max <value> lockup <sec>max <value> lockup <sec>max <value> lockup <sec>

• Recommended values for the ip tcp burstip tcp burstip tcp burstip tcp burst----normal normal normal 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 tcpdeny tcp tcpdeny tcp tcpdeny tcp tcp----operator synoperator synoperator synoperator 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


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 directedno ip directedno ip directedno ip directed----broadcastbroadcastbroadcastbroadcast.... Note: ip directedip directedip directedip directed----broadcastbroadcastbroadcastbroadcast 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 burstip icmp burstip icmp burstip icmp burst----normalnormalnormalnormal command

• Syntax: ip icmp burstip icmp burstip icmp burstip icmp burst----normal <value> burstnormal <value> burstnormal <value> burstnormal <value> burst----max <value> lockup <seconds>max <value> lockup <seconds>max <value> lockup <seconds>max <value> lockup <seconds>

• Example: Brocade(config)#ip icmp burstip icmp burstip icmp burstip icmp burst----normal 5000 burstnormal 5000 burstnormal 5000 burstnormal 5000 burst----max 10000 lockup 300max 10000 lockup 300max 10000 lockup 300max 10000 lockup 300


of 17

• Recommended values

• 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.

PING of Death Attack Example

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.


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 NetIron NetIron NetIron

Feature Feature Feature Feature

Problem(s) Addressed Problem(s) Addressed Problem(s) Addressed Problem(s) Addressed Enabling the feature Enabling the feature Enabling the feature Enabling the feature

TCP SYN

rate

limiting

Protects against SYN flood attacks Configuration necessary

RST attack

protection

• Protects against abnormal

termination of legitimate

connections


necessary

TCP flag

checker

• Protects against

malformed TCP control

packets


necessary

Disabling

“Ip

directed

broadcast”

• Protects against being an

intermediary in a SMURF

attack


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


necessary


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.

netiron dos prevention v2 - brocade community forums · pdf filewhite paper: netiron dos...

Documents