Applies To:

Show Versions Show Versions

Manual Chapter: BIG-IP® Local Traffic Manager version 9.4 Implementations Guide: 21 - Mitigating Denial of Service and Other Attacks
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


21

Mitigating Denial of Service and Other Attacks


Basic denial of service security overview

The BIG-IP® system contains several features and configurations that provide you the ability to create a configuration that contributes to the security of your network. In particular, the BIG-IP system is in a unique position to mitigate some types of denial-of-service (DoS) attacks that try to consume system resources in order to deny service to the intended recipients.

The following features of the BIG-IP system help it resist many types of DoS attacks.

  • Hardened and dedicated kernel
    The BIG-IP kernel has a mechanism built in to protect against SYN Flood attacks by limiting simultaneous connections, and tearing down connections that have unacknowledged SYN/ACK packets after some time period as passed. (A SYN/ACK packet is a packet that is sent as part of the TCP three-way handshake).
  • High performance
    BIG-IP system can handle tens of thousands of Layer 4 (L4) connections per second. It would take a very determined attack to affect either the BIG-IP system itself, or the site, if sufficient server resources and bandwidth are available.
  • Large amount of available memory
    SYN floods, or denial-of-service (DoS) attacks, can consume all available memory. The BIG-IP system supports a large amount of memory to help it resist DoS attacks.

This chapter describes several configurations that help mitigate DoS attacks. The configurations described include:

  • How to configure the adaptive reapers to allow the BIG-IP system to respond to attacks, following.
  • A basic configuration to defend against denial of service attacks.
  • Several examples of iRulesTM syntax you can use to filter out specific known attacks.

Configuring adaptive connection reaping

The BIG-IP system contains two global settings that provide the ability to reap connections adaptively. Connection reaping is when connections are removed from the BIG-IP system when the connection load uses enough memory to trigger the start of aggressive reaping. To prevent denial-of-service attacks, you can specify a low-water mark threshold and a high-water mark threshold:

  • The low-water mark threshold determines at what point adaptive reaping becomes more aggressive.
  • The high-water mark threshold determines when unestablished connections through the BIG-IP system will no longer be allowed. The value of this variable represents a percentage of memory utilization.

Once memory utilization has reached the high-water mark, connections are disallowed until the available memory has been reduced to the low-water mark threshold.

Warning

The adaptive reaper settings do not apply to SSL connections. However, you can set TCP and UDP connection timeouts that reap idle SSL connections. For more information see Setting the TCP and UDP connection timers .

To set the adaptive reapers using the Configuration utility

  1. On the Main tab of the navigation pane, expand System, and click General Properties.
    The General screen opens.
  2. From the Local Traffic menu, choose General.
    The System screen opens.
  3. In the Properties table, set the following values:
    • Set the Reaper High-water Mark property to 95.
    • Set the Reaper Low-water Mark property to 85.
  4. Click Update.

Tip


There is generally no need to change these values as they represent an optimal solution for most BIG-IP deployments.
Important

Setting both the adaptive reaper values to 100 disables this feature.

Logging adaptive reaper activity

You can log adaptive reaper activity by setting the logging levels on the BIG-IP system to a more sensitive level.

When you set this logging level, the system logs a rate-limited message (maximum once every 10 seconds), informing you that the adaptive reaping mode has been entered or exited. This log message has a priority of warning. For more information about the log level, refer to the db man page.

Important

When the adaptive reaper high water limit is reached, the LCD displays the message Blocking DoS Attack.

To set the adaptive reaper logging level from the command line

  1. Open a console on the BIG-IP system.
  2. Type the following command to view the adaptive reaper logging level:
  3. bp db Log.DosProtect.Level list

    The output looks like this:

    db Log.DosProtect.Level "Warning"
  4. Choose the logging level for the adaptive reaper. The following levels display the message Blocking DoS Attack on the LCD when the Reaper High Water Mark is exceeded:
    • Emergency
    • Alert
    • Critical
    • Error
    • Warning
    • The following levels do not display the Blocking DoS Attack message on the LCD.

    • Notice
    • Informational
  5. Type the following command to set the adaptive reaper logging level, where <log level> is the logging level:
  6. bp db Log.DosProtect.Level "<log level>"

Simple DoS prevention configuration

DoS prevention is a simple configuration you can employ to mitigate the impact of denial-of-service attacks.

The configuration consists of four tasks:

  • Set the global TCP and UDP connection reap times to 60 seconds.
  • Set an IP rate class of 20Mbps, outstanding queue maximum size of 2Mbps.
  • Set the connection limit on the main virtual server to the approximate amount of RAM in KB * 0.8.
  • Set the global variable Memory Restart Percent to 97.

Setting the TCP and UDP connection timers

You can set the TCP and UDP timers in the profile settings for the TCP profile and the UDP profiles. You should set these timers for the services that you use for your virtual servers. For example, 60 for HTTP connections, 60 for SSL connections.

To set the TCP connection reaper time

  1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles.
    The HTTP Profiles screen opens.
  2. From the Protocol menu, choose TCP.
    The TCP profile list screen opens.
  3. Click the name of the profile you want to configure.
    The properties screen for the profile opens.
  4. Set the Idle Timeout to 60.
  5. Click Update.

To set the UDP connection reaper time

  1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles.
    The HTTP Profiles screen opens.
  2. From the Protocol menu, choose UDP.
    The UDP profile list screen opens.
  3. Click the name of the profile you want to configure.
    The properties screen for the profile opens.
  4. Set the Idle Timeout to 60.
  5. Click Update.

Creating an IP rate class and applying it to a virtual server

The next task in setting up a simple configuration for DoS is to create a rate class. You must first create a rate class, and then apply the rate class to a virtual server.

Important

The rate class module requires a license key. If you do not have this functionality and you would like to purchase a license key, contact F5 Networks.

To create a rate class

  1. On the Main tab of the navigation pane, expand Local Traffic, and click Rate Shaping.
    The Rate Shaping screen displays.
  2. Click the Create button to create a new rate class.
    The New Rate Class screen opens.
  3. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a rate class.
  4. Configure the following class properties:
    • In the Class Name box, type the name you want to use for this class.
    • In the Base Rate box, type 2000000 (2 Mbps).
    • In the Ceiling Rate box, type 20000000 (20 Mbps).
    • In the Burst Size box, type 500, and select Megabytes from the list.
    • From the Direction list, select Any.
    • From the Queue Discipline list, select Stochastic Fair Queue.
  5. Click Finished.

After you create a rate class, you can apply it to the virtual servers in the configuration.

To apply a rate class to a virtual server

  1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers.
    The Virtual Servers List screen opens.
  2. On the Virtual Servers List screen, click the virtual you want to modify.
  3. From the Rate Class list, select the rate class you created.
  4. Click Update.

Setting connection limits on the main virtual server

This section describes how to set the connection limits on the main virtual server. The connection limits determine the maximum number of concurrent connections allowed on a virtual server. In this context, the main virtual server is the virtual server that receives the most traffic to your site.

To calculate a connection limit for the main virtual server

Before you set a connection limit, use the following formula to figure out what to set the connection limit value to on the main virtual server:

Connection Limit = Approximate Amount of RAM in KB * 0.8.

For example, if you have 256 MB of RAM, the calculation looks like this:

256,000 * 0.8 = 20480

In this case, you set the connection limit to 20480.

To set the connection limits on the main virtual server using the Configuration utility

  1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers.
    The Virtual Servers List screen opens.
  2. On the Virtual Servers List screen, click the virtual server you want to modify.
  3. In the Connection Limit box, type the number you calculated for the connection limit.
  4. Click the Update button.

Setting the Memory Restart Percent

This section describes how to set the Memory Restart Percent. The value you type, 80 or higher, is the percentage of memory that is in use before the BIG-IP unit automatically reboots. This setting allows the BIG-IP unit to fail-over to a peer unit before all of the unit's memory is consumed.

To set the Memory Restart Percent

  1. On the Main tab of the navigation pane, expand System, and click General Properties.
    The General screen opens.
  2. In the Properties table, set the Memory Restart Percent to 97.
  3. Click Update.

Filtering out attacks with iRules

You can create BIG-IP rules to filter out malicious DoS attacks. Once you identify a particular attack, you can write an iRule that discards packets that contain the elements that identify the packet as malicious.

Note

For additional iRule syntax and examples, see the Configuration Guide for BIG-IP® Local Traffic Management.

Filtering out a Code Red attack

The BIG-IP system is able to filter out the Code Red attack by using an iRule to send the HTTP request to a dummy pool. For example, the figure 21.1 illustrates an iRule that discards Code Red attacks.

Figure 21.1 A sample iRule for filtering out a Code Red attack
when HTTP_REQUEST {
  if {string tolower [HTTP::uri] contains "default.ida" } {
     discard
  } else {
     pool RealServerPool 
 }
}

 

Filtering out a Nimda attack

The Nimda worm is designed to attack systems and applications based on the Microsoft® Windows® operating system. For Nimda, an iRule can be written as shown in Figure 21.2 .

Figure 21.2 Sample iRule syntax to discard Nimda worm
when HTTP_REQUEST {
  set uri [string tolower [HTTP::uri]]
  if { ($uri contains "cmd.exe") or ($uri contains 
"root.exe") or ($uri contains "admin.dll") } {
     discard
  } else {
    pool ServerPool
 }
}

 

How the BIG-IP system handles several common attacks

You might want to know how the BIG-IP system reacts to certain common attacks that are designed to deny service by breaking the service or the network devices.

The following sections list the most common attacks, along with how the BIG-IP system functionality handles the attack.

Warning

Take care any time you lower the idle session reaping time outs. It is possible that valid connections will be reaped if the application cannot respond in time.

SYN flood

A SYN flood is an attack against a system for the purpose of exhausting that system's resources. An attacker launching a SYN flood against a target system attempts to occupy all available resources used to establish TCP connections by sending multiple SYN segments containing incorrect IP addresses. Note that the term SYN refers to a type of connection state that occurs during establishment of a TCP/IP connection.

More specifically, a SYN flood is designed to fill up a SYN queue. A SYN queue is a set of connections stored in the connection table in the SYN-RECEIVED state, as part of the standard three-way TCP handshake. A SYN queue can hold a specified maximum number of connections in the SYN-RECEIVED state.

Connections in the SYN-RECEIVED state are considered to be half-open and waiting for an acknowledgement from the client. When a SYN flood causes the maximum number of allowed connections in the SYN-RECEIVED state to be reached, the SYN queue is said to be full, thus preventing the target system from establishing other legitimate connections. A full SYN queue therefore results in partially-open TCP connections to IP addresses that either do not exist or are unreachable. In these cases, the connections must reach their timeout before the server can continue fulfilling other requests.

Alleviating SYN flooding

The BIG-IP system includes a feature designed to alleviate SYN flooding. Known as SYN Check, this feature sends information about the flow, in the form of cookies, to the requesting client, so that the system does not need to keep the SYN-RECEIVED state that is normally stored in the connection table for the initiated session. Because the SYN-RECEIVED state is not kept for a connection, the SYN queue cannot be exhausted, and normal TCP communication can continue.

The SYN Check feature complements the existing adaptive reaper feature in the BIG-IP system. While the adaptive reaper handles established connection flooding, SYN Check prevents connection flooding altogether. That is, while the adaptive reaper must work overtime to flush connections, the SYN Check feature prevents the SYN queue from becoming full, thus allowing the target system to continue to establish TCP connections.

You can configure the BIG-IP system to activate the SYN Check feature when some threshold of connections has been reached on one or all virtual servers. To set the threshold on an individual virtual server, you use the bigpipe virtual command. To set the threshold on all virtual servers, you use the bigpipe global command.

ICMP flood (Smurf)

The ICMP flood, sometimes referred to as a "Smurf" attack, is an attack based on a method of making a remote network send ICMP Echo replies to a single host. In this attack, a single packet from the attacker goes to an unprotected network's broadcast address. Typically, this causes every machine on that network to answer with a packet sent to the target.

The BIG-IP system is hardened against these attacks because it answers only a limited number of ICMP requests per second, and then drops the rest.

On the network inside the BIG-IP system, the BIG-IP system ignores directed subnet broadcasts, and does not respond to the broadcast ICMP Echo that a Smurf attacker uses to initiate an attack.

You do not need to make any changes to the BIG-IP system configuration for this type of attack.

UDP flood

The UDP flood attack is most commonly a distributed denial-of-service attack (DDoS), where multiple remote systems are sending a large flood of UDP packets to the target.

The BIG-IP system handles these attacks similarly to the way it handles a SYN flood. If the port is not listening, the BIG-IP system drops the packets. If the port is listening, the reaper removes the false connections.

Setting the UDP idle session timeout to between 5 and 10 seconds reaps these connections quickly without impacting users with slow connections. However, with UDP this may still leave too many open connections, and your situation may require a setting of between 2 and 5 seconds.

UDP fragment

The UDP fragment attack is based on forcing the system to reassemble huge amounts of UDP data sent as fragmented packets. The goal of this attack is to consume system resources to the point where the system fails.

The BIG-IP system does not reassemble these packets, it sends them on to the server if they are for an open UDP service. If these packets are sent with the initial packet opening the connection correctly, then the connection is sent to the back-end server. If the initial packet is not the first packet of the stream, the entire stream is dropped.

You do not need to make any changes to the BIG-IP system configuration for this type of attack.

Ping of Death

The Ping of Death attack is an attack with ICMP echo packets that are larger than 65535 bytes. Since this is the maximum allowed ICMP packet size, this can crash systems that attempt to reassemble the packet.

The BIG-IP system is hardened against this type of attack. However, if the attack is against a virtual server with the Any IP feature enabled, then these packets are sent on to the server. It is important that you apply the latest update patches to your servers.

You do not need to make any changes to the BIG-IP system configuration for this type of attack.

Land attack

A Land attack is a SYN packet sent with the source address and port the same as the destination address and port.

The BIG-IP system is hardened to resist this attack. The BIG-IP system connection table matches existing connections so that a spoof of this sort is not passed on to the servers. Connections to the BIG-IP system are checked and dropped if spoofed in this manner.

You do not need to make any changes to the BIG-IP system configuration for this type of attack.

Teardrop

A Teardrop attack is carried out by a program that sends IP fragments to a machine connected to the Internet or a network. The Teardrop attack exploits an overlapping IP fragment problem present in some common operating systems. The problem causes the TCP/IP fragmentation re-assembly code to improperly handle overlapping IP fragments.

The BIG-IP system handles these attacks by correctly checking frame alignment and discarding improperly aligned fragments.

You do not need to make any changes to the BIG-IP system configuration for this type of attack.

Data attacks

The BIG-IP system can also offer protection from data attacks to the servers behind the BIG-IP system. The BIG-IP system acts as a port-deny device, preventing many common exploits by simply not passing the attack through to the server.

For information about iRule examples for thwarting two common data attacks, see Filtering out attacks with iRules .

WinNuke

The WinNuke attack exploits the way certain common operating systems handle data sent to the NetBIOS ports. NetBIOS ports are 135, 136, 137 and 138, using TCP or UDP. The BIG-IP system denies these ports by default.

On the BIG-IP system, do not open these ports unless you are sure your servers have been patched against this attack.

Sub 7

The Sub 7 attack is a Trojan horse that is designed to run on certain common operating systems. This Trojan horse allows the system to be controlled remotely.

This Trojan horse listens on port 27374 by default. The BIG-IP system does not allow connections to this port from the outside, so a compromised server cannot be controlled remotely.

Do not open high ports (ports above 1024) without explicit knowledge of what applications will be running on these ports.

Back Orifice

Back Orifice is a Trojan horse that is designed to run on certain common operating systems. This Trojan horse allows the system to be controlled remotely.

This Trojan horse listens on UDP port 31337 by default. The BIG-IP system does not allow connections to this port from the outside, so a compromised server cannot be controlled remotely. Do not open high ports (ports above 1024) without explicit knowledge of what will be running on these ports.




Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)