Applies To:
Show VersionsBIG-IP versions 1.x - 4.x
- 4.5.14, 4.5.13, 4.5.12, 4.5.11, 4.5.10
21
Mitigating Denial of Service and Other Attacks
- Basic denial of service security overview
- Configuring adaptive connection reaping
- Simple DoS prevention configuration
- Filtering out attacks with BIG-IP rules
- How the BIG-IP system handles several common attacks
Basic denial of service security overview
The BIG-IP software 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 platform help it resist many types of DoS attack:
- 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 unacknowledged SYN/ACK after a period of time. - 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 fairly large amount of memory to help it resist DoS attacks.
This chapter describes several configurations that help mitigate DoS attacks. The configurations described include:
- A basic configuration to defend against denial of service attacks
- How to configure the adaptive reapers to allow the BIG-IP system to respond to attacks
- Several examples of rule 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. Used to prevent denial-of-service attacks, you can specify a low-watermark threshold and a high-watermark threshold.
- The low-watermark threshold determines at what point adaptive reaping becomes more aggressive.
- The high-watermark 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-watermark, connections are disallowed until the available memory has been reduced to the low-watermark threshold.
The adaptive reaper settings do not apply to SSL proxy 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 reaper .
You can set up the BIG-IP system to log connections affected by adaptive connection reaping.
To set the adaptive reapers using the Configuration utility
- In the navigation pane, click System.
The Network Map page opens. - Click the Advanced Properties tab.
The Advanced Properties screen opens. - In the BIG-IP table, set the following values:
- Set the reaper hiwater to 95.
- Set the reaper lowater to 85.
To set the adaptive reapers from the command line
Use the following syntax to set the adaptive reapers from the command line:
bigpipe global reaper lowat <%>
bigpipe global reaper hiwat <%>
For example, you can set the reaper lowat setting to 85, and the reaper hiwat setting to 95 with the following commands:
bigpipe global reaper lowat 85
bigpipe global reaper hiwat 95
Setting 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 particular level. When this logging level is set, a rate-limited message (maximum once every 10 seconds) is logged informing you that the adaptive reaping mode has been entered or exited. This log message is logged with a priority of LOG_ALERT.
Simple DoS prevention configuration
This 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 filter of 20Mbps, outstanding queue maximum size of 256K.
- Set the connection limit on the main virtual server to the approximate amount of RAM in KB * 0.8.
- Set the global variable memory_reboot_percent to 97.
Setting the TCP and UDP connection reaper
You can set the TCP and UDP timeouts using either the Configuration utility or the command line. You should set these timeouts for the services that you use for your virtual servers. For example, 80 for HTTP connections, 443 for SSL connections.
To set the TCP and UDP connection reaper times in the Configuration utility
- In the Navigation pane, click Virtual Servers.
The Virtual Server properties screen opens. - Click the virtual server you want to configure.
The properties screen for the virtual server opens. - Click the Virtual Service Properties tab.
The Global Virtual Service screen opens. - Choose the service you want to configure. For example, 80 for HTTP connections, 443 for SSL connections.
- Set the Idle Connection Timeout TCP (seconds) to 60.
- Set the Idle Connection Timeout UDP (seconds) to 60.
- Click the Apply button.
To set the TCP and UDP connection reaper times from the command line
Use the following commands to set the TCP and UDP timeouts for port 80 to 60 seconds.
b service 80 timeout tcp 60
b service 80 timeout udp 60
Use the following commands to set the TCP and UDP timeouts for port 443 to 60 seconds.
b service 443 timeout tcp 60
b service 443 timeout udp 60
Creating an IP rate filter
The second step in setting up a simple configuration for DoS is to create an IP rate filter in the Configuration utility. To create a rate filter, you must first create a rate class, and then create a rate filter that references the rate class.
To create a class and an IP rate filter using the Configuration utility
- In the Navigation pane, click Filters.
The IP Filters screen opens. - Click the Rate Filter tab.
The Rate Filter properties screen opens. - Click the Add Class button.
The Add Rate Class screen opens. - Configure the following class properties:
- In the Class Name box, type the name you want to use for this class.
- In the Bits per Second Allowed box, type 20000000 (20 Mbps).
- In the Minimum Number of Bits Outstanding box, type 2000000 (2 Mbps).
- In the Queue Length (in Packets) box, type 256.
- Click the Done button.
- On the Rate Filter screen, click the Add Rate Filter button.
The Add Rate Filter screen opens. - Configure the following rate filter properties:
- In the Name box, type the name you want to use for this class.
- from the Rate Class list, select the rate class you configured.
- In the Source Service box, type 80.
- Click the Done button.
Setting connection limits on main virtual server
This section describes how to set the connection limits on the main virtual server. You can do this either using the Configuration utility or from the command line. 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
- In the navigation pane, click Virtual Servers.
The Virtual Servers properties screen opens. - Click the name or IP address of the main virtual server in your configuration. In this case, the main virtual server is the one that receives the most traffic.
The properties screen for the virtual server opens. - In the Connection Limit box, type the number you calculated for the connection limit.
- Click the Apply button.
To set the connection limits on the main virtual server from the command line
Use the following syntax to set the connection limit on the main virtual server. In this case, the main virtual server is the one that receives the most traffic:
b virtual <virtual addr>:<port> limit <connection limit>
For example, if the IP address/port combination of the main virtual server was 192.168.10.25:80, and the connection limit you calculated was 20480, you type the following command:
b virtual 192.168.10.25:80 limit 20480
Setting the global variable memory_reboot_percent
This section describes how to set the global variable memory_reboot_percent. You can do this using either the Configuration utility or from the command line. 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 global variable memory_reboot_percent using the Configuration utility
- In the navigation pane, click System.
The Network Map screen opens. - Click the Advanced Properties tab.
The Advanced Properties screen opens. - In the memory_reboot_percent box, type 97.
- Click the Apply button.
To set the global variable memory_reboot_percent from the command line
Use the following command to set the global variable memory_reboot_percent.
b global memory_reboot_percent 97
Filtering out attacks with BIG-IP rules
You can create BIG-IP rules to filter out malicious DoS attacks. Once you identify a particular attack, you can write a rule that discards packets that contain the elements that identify the packet as malicious.
For additional rule syntax and examples, see the BIG-IP Reference Guide, Chapter 5, iRules.
Filtering out a Code Red attack
The BIG-IP system is able to filter out the Code Red attack by using a rule to send the HTTP request to a dummy pool. For example, the following figure illustrates a rule that discards Code Red attacks.
if (http_uri contains "default.ida") { discard } else { use (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, a rule can be written as below.
if (http_uri matches_regex ".*cmd.exe*." or http_uri matches_regex ".*root.exe*." or http_uri matches_regex ".*admin.dll*.") { discard } else { use (RealServerPool) } |
How the BIG-IP system handles several common attacks
This section describes 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 most common attacks are listed, along with how the BIG-IP system functionality handles the attack.
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
The SYN flood is simply a flood of SYN packets. SYN packets are the first packet in a TCP connection. TCP protocol requires that these packets are answered with a SYN-ACK to begin the conversation. A SYN flood attack is designed to fill up all available connections with spoofed connections and cause the site to be unavailable.
The BIG-IP system is a port-deny device by default, so floods to closed ports do not affect the BIG-IP system. SYN floods are not passed on to back-end servers. However, if the flood consumes enough bandwidth, the SYN flood can fill the pipe into the site.
If the attack focuses on a simple virtual server on the BIG-IP system, the SYN packets are load balanced to the back-end nodes. However, the BIG-IP system has a reaper that keeps watch on connections, and if they are idle for longer than the configured time out, the system reaps the connection and sends RST packets to the back-end node and the client. In this way, the reaper is cleaning up the SYN flood as it is happening.
If the SYN flood attack is targeted at a virtual server that uses delayed binding, such as a rule or cookie persistence, then the BIG-IP system itself answers the SYN packets, and reads the connections as needed.
Setting the TCP idle connection timeout as low as possible (2 seconds if applicable) is the best way to defend against an attack such as this. However, when setting the reaper that low, there is a risk that slower applications cannot respond fast enough and real connections are reaped as well. You should adjust this setting for each application.
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 only answers 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 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 rule examples for thwarting two common data attacks, see Filtering out attacks with BIG-IP rules .
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.