This chapter is from the book
This chapter is from the book
This chapter is from the book
TCP Intercept
One option for dealing with TCP SYN flood attacks is to implement the Cisco IOS TCP Intercept feature. TCP Intercept enables you to deal with DoS attacks that attempt to take advantage of the weakness in the way that TCP connections establish a session with the three-way handshake. This was discussed in Chapter 1, "Security Threats." This section focuses on how to use TCP Intercept to limit the effectiveness of a TCP SYN food attack that is perpetrated by an attacker.
TCP SYN Flood Attacks
As you recall from Chapter 1, a TCP SYN flood attack is an easy attack to initiate. The attacker sends a flood of TCP SYN segments with no intention of completing the three-way handshake for each of these connections. Typically, the hacker combines this with an IP spoofing attack in which the source addresses in the packet are either invalid or someone else's address. Because these addresses cannot be reached (or, if they are someone else's address, are not responded to), the TCP server being attacked hangs in limbo with these half-open (commonly called embryonic) connections. In this situation, the server must wait until the TCP timeout expires for the connection before removing the connection from its local connection table. This creates a problem because it uses up resources on the TCP server, which might deny legitimate TCP connections.
TCP Intercept Modes
TCP Intercept is a Cisco IOS feature that is used to protect TCP services from TCP SYN flood attacks. TCP supports two modes of protection: intercept and watch. The following two sections discuss how these modes operate when dealing with TCP SYN attacks.
Intercept Mode
Intercept mode takes a proactive approach to TCP SYN flood attacks. Figure 17-3 shows an example of a router using intercept mode with TCP Intercept. In intercept mode, the router intercepts all TCP connection requests, as shown in the figure. In this example, an external user is trying to access an internal server using a TCP connection. The router intercepts this request and pretends to be the internal server, completing the connection to the external user. Only upon a successful three-way handshake with the external user (Steps 1 through 3 in Figure 17-3) does the router set up a second TCP connection to the server (Steps 4 through 6). The router then binds the two connections, creating a single connection (Step 7).
)
Figure
17-3 TCP Intercept Using Intercept Mode
For the most part, this process is transparent to the two devices that make up the final TCP connection. With this approach, if a TCP SYN flood attack is occurring, the router provides a buffer to the internal servers using TCP because they are not affected by the flood: The router deals with the half-open connections, which eventually time out and are removed from the router's TCP connection table. Basically, the router sends an RST to the requesting source device. In the mean time, valid requests are permitted as long as the router successfully can complete the three-way handshake with the external user.
NOTE
One limitation of intercept mode is that any TCP options that are negotiated between the external user and the router (which normally are to the end-server device), such as RFC 1323 window scaling, are not passed from the router to the internal TCP server. This is because the router does not know these options until the first three-way handshake completes with the external user and the router begins the second three-way handshake with the internal TCP server. Typically, this is not a problem because TCP allows for the dynamic negotiation of these parameters during the normal operation of the session.
Watch Mode
Whereas intercept mode takes a proactive approach to dealing with TCP SYN flood attacks, watch mode takes a reactive approach. One of the main advantages of intercept mode is that it removes the processing load of TCP SYN floods from the internal server. However, this a double-edged sword because, in most time periods, a TCP SYN flood is not occurring, but the router still is performing the intercept process, placing a heavy burden on it.
To alleviate this problem, you can use TCP Intercept in watch mode. Watch mode takes a passive, or reactive, approach to TCP SYN flood attacks. In watch mode, the router passively watches the setup of TCP connections from users to servers. It monitors these connections, keeping track of embryonic connections that remain in this limbo state. Then it compares this value to a preconfigured timeout value (which defaults to 30 seconds). If a TCP connection does not complete the three-way handshake in this period, the Cisco IOS sends a TCP reset to the server to remove the connection. For an attack that is directed at an internal server using TCP, this removes the half-open connections, thus reducing the load on the server and allowing legitimate connection attempts to be processed.
TCP Intercept Configuration and Verification
Enabling TCP Intercept on your router is a simple process. Only one command is required, but typically you will tune some of the parameters to ensure that TCP Intercept functions smoothly in your environment. The following sections discuss the configuration and verification of TCP Intercept.
Enabling TCP Intercept
The first step in setting up TCP Intercept is to specify which TCP sessions should be intercepted in intercept mode or monitored in watch mode. This is done by using the ip tcp intercept list command:
Router(config)# ip tcp intercept list extended_ACL_#
A couple of important things should be pointed out about this required command. First, this command enables TCP Intercept. Notice that the command is executed at global configuration mode, not on an interface.
Second, you must use an extended ACL to specify which traffic is to be examined by TCP Intercept. As an example, if you want to monitor all TCP setup connections, you would configure something like this:
Router(config)# access-list 100 tcp permit tcp any any Router(config)# ip tcp intercept list 100
Typically, this configuration is a bad idea because the router basically would act like a proxy for all inbound and outbound connections.
TIP
When you are setting up TCP Intercept, use it to deal with TCP SYN flood attacks from external users. This is accomplished by configuring an extended ACL for TCP Intercept that refines the traffic that should be monitored. For example, if you have only two servers in your DMZ that use TCP, such as an e-mail server and a web server, set up TCP Intercept to monitor only port 25 traffic to the e-mail server and port 80 traffic to the web server. This greatly reduces the number of TCP connections that the router has to monitor. Because you typically do not know the IP address of the source device, leave it as any.
Defining the Mode
The rest of the TCP Intercept configuration commands are optional. For example, the default mode for TCP Intercept is intercept. If this creates too much of a burden on your router's CPU, you can switch the mode to watch with the following command:
Router(config)# ip tcp intercept mode {intercept | watch}
Note that you cannot use a mixture of both intercept and watch modes for TCP Intercept, for example, based on the destination address. With TCP Intercept, the mode that it operates in is a global value.
Changing the Timers
You can tune three timers with TCP Intercept: an embryonic timer, a connection reset timer, and a connection idle timer. These can be configured with the three following commands:
Router(config)# ip tcp intercept watch-timeout seconds Router(config)# ip tcp intercept finrst-timeout seconds Router(config)# ip tcp intercept connection-timeout seconds
The ip tcp intercept watch-timeout command specifies the maximum length of time that the router will wait, in watch mode, for a TCP connection to complete the three-way handshake. This value defaults to 30 seconds. If the connection is not reached in this time period, the router sends a reset to the server (destination).
When a router with TCP Intercept enabled monitors a connection that is in the process of being torn down, it expects the connection to be torn down within 5 seconds, by default, from the receipt of a reset or FIN exchange. When this time period is reached, the router ceases to manage the connection. You can change this value with the ip tcp intercept finrst-timeout command.
When the TCP Intercept is managing TCP connections, it manages a connection only up to 24 hours, by default, for an idle connection. After this, the router drops the connection. You can modify this with the ip tcp intercept connection-timeout command.
Changing the Thresholds
In addition to the intercept and watch modes, TCP Intercept uses threshold values to deal with an excessive number of TCP connection attempts during a time of a TCP SYN flood attack. TCP Intercept supports two thresholds: one based on the total number of embryonic connections, and one based on the number of connection requests during the last 1-minute period. You can tune both of these threshold values.
During a time of attack in which your router is seeing an excessive number of connections and one of the two threshold values is reached, the router begins dropping the oldest embryonic connections first (this can be changed with the drop-mode parameter, discussed in the next section). For intercept mode, the router reduces the initial retransmission timeout for SYN segments by half. For watch mode, the router reduces the watch time automatically to half of the configured value (if you were using the default of 30 seconds, it becomes 15 seconds).
Aggressive operation of TCP Intercept begins when either of the two thresholds is reached. To specify the values for the maximum embryonic connection threshold, use the following two commands:
Router(config)# ip tcp intercept max-incomplete high number Router(config)# ip tcp intercept max-incomplete low number
The high parameter specifies when aggressive mode should begin. When this threshold is reached, the router, by default, begins deleting the oldest half-open connections first until it drops enough of these connections to fall below the threshold value specified in the low parameter. The default threshold values are 1100 for the high parameter and 900 for the low parameter.
To specify the values for the expected total number of half-open connection requests in a 1-minute period, use the following two commands:
Router(config)# ip tcp intercept one-minute high number Router(config)# ip tcp intercept one-minute low number
The high parameter specifies when aggressive mode should begin. When this threshold is reached in a 1-minute measurement period, the router, by default, begins deleting the oldest half-open connections first until it drops enough of these connections to fall below the threshold value specified in the low parameter. The default threshold values are 1100 for the high parameter and 900 for the low parameter.
CAUTION
Be careful about adjusting the threshold values with the ip tcp intercept max-incomplete and one-minute commands. If you set these values too low, the router might take aggressive action to prevent legitimate connections. This is especially true of the web servers, in which lots of connections are expected when downloading the contents of a web page. Each situation and network is different; you need to establish a baseline before determining what values you should use for the high and low threshold numbers.
Changing the Drop Method
In aggressive mode, the default drop method is to drop the oldest half-open connections first until the number of remaining half-open connections falls below the configured minimum threshold (either total half-open connections or half-open connections in a 1-minute interval). You can change the drop method with the following command:
Router(config)# ip tcp intercept drop-mode {oldest | random}
The default is oldest; by changing it to random, TCP Intercept causes the router to randomly drop half-open connections until the number of remaining half-open connections falls below the configured minimum threshold.
Verifying Your Configuration
After you have configured TCP Intercept, you can use two show commands and one debug command to verify and troubleshoot your configuration. If you want to see general statistics about the operation of TCP Intercept, use the show tcp intercept statistics command. Example 17-10 displays sample output of the show tcp intercept statistics command.
Example 17-10 Using the show tcp intercept statistics Command
Router# show tcp intercept statistics intercepting new connections using access-list 100 12 incomplete, 5 established connections (total 17) 1 minute connection request rate 2 requests/sec
In this example, there are currently 12 half-open connections and 5 established ones. Notice that ACL 100 is used to restrict the traffic that TCP Intercept monitors.
To see the connections that TCP Intercept is monitoring, use the show tcp intercept connections command. Example 17-11 displays sample output of the show tcp intercept connections command.
Example 17-11 Using the show tcp intercept connections Command
Router# show tcp intercept connections
Incomplete:
Client Server State Create Timeout Mode
201.1.1.1:33772 200.1.1.30:80 SYNRCVD 00:00:09 00:00:05 I
201.1.1.1:33773 200.1.1.30:80 SYNRCVD 00:00:09 00:00:05 I
Established:
Client Server State Create Timeout Mode
201.1.1.2:33771 200.1.1.2:23 ESTAB 00:00:08 23:59:54 I
The output of this command is broken into two sections: Incomplete refers to connections that are in an embryonic state; established refers to connections that have completed the three-way handshake. The Client column indicates the source of the connection and the Server column indicates the destination. The connection can be in one of three states:
SYNSENT—The client is attempting to establish a TCP session.
SYNRCVD—The server is responding with a SYN/ACK to the client.
ESTAB—The TCP session has been established, and both devices now can pass data.
The Create column indicates how long it has been since the connection was created. The Timeout column indicates how long the connection has before it times out. Note that the idle times for the two sets of information in this output will be different: The top half is for embryonic connections, and the bottom half is for established idle TCP sessions. The exception to the timeout for established sessions is that, when the session is in the process of being torn down, the idle timer defaults to 5 seconds. The Mode column indicates the mode for TCP Intercept: I is for intercept mode, and W is for watch mode.
For more detailed troubleshooting, you can use the debug ip tcp intercept command, which displays the TCP Intercept events occurring on the router. Example 17-12 shows a simple example of the output of this command, with the router in intercept mode.
Example 17-12 Using the debug ip tcp intercept Command
Router# debug ip tcp intercept
INTERCEPT: new connection (192.1.1.1:33884) => (200.1.1.2:23) (1)
INTERCEPT: 192.1.1.1:33884 <- ACK+SYN (200.1.1.2:33884)
INTERCEPT: new connection (192.1.1.1:33885) => (200.1.1.2:23) (2)
INTERCEPT: 192.1.1.1:33885 <- ACK+SYN (200.1.1.2:33885)
INTERCEPT: retransmit 2 (192.1.1.1:33884) <- (3)
(200.1.1.2:23) SYNRCVD
INTERCEPT: retransmit 2 (192.1.1.1:33885) <-
(200.1.1.2:23) SYNRCVD
INTERCEPT: new connection (192.1.1.2:32790) => (200.1.1.2:23) (4)
INTERCEPT: 192.1.1.2:32790 <- ACK+SYN (200.1.1.2:32790)
INTERCEPT: retransmit 4 (192.1.1.1:33884) <- (5)
(200.1.1.2:23) SYNRCVD
INTERCEPT: retransmit 4 (192.1.1.1:33885) <-
(200.1.1.2:23) SYNRCVD
INTERCEPT: retransmit 2 (192.1.1.2:32790) <-
(200.1.1.2:23) SYNRCVD
INTERCEPT: 1st half of connection is established (6)
(192.1.1.2:32790) => (200.1.1.2:23)
INTERCEPT: (192.1.1.2:32790) SYN -> 200.1.1.2:23
INTERCEPT: retransmit 2 (192.1.1.2:32790) ->
(200.1.1.2:23) SYNSENT
INTERCEPT: 2nd half of connection established (7)
(192.1.1.2:32790) => (200.1.1.2:23)
INTERCEPT: (192.1.1.2:32790) ACK -> 200.1.1.2:23
INTERCEPT: retransmit 8 (192.1.1.1:33884) <- (8)
(200.1.1.2:23) SYNRCVD
INTERCEPT: retransmit 8 (192.1.1.1:33885) <-
(200.1.1.2:23) SYNRCVD
INTERCEPT: retransmit 16 (192.1.1.1:33884) <-
(200.1.1.2:23) SYNRCVD
INTERCEPT: retransmit 16 (192.1.1.1:33885) <-
(200.1.1.2:23) SYNRCVD
INTERCEPT: retransmitting too long (192.1.1.1:33884) => (9)
(200.1.1.2:23) SYNRCVD
INTERCEPT: 192.1.1.1:33884 <- RST (200.1.1.2:23)
INTERCEPT: retransmitting too long (192.1.1.1:33885) =>
(200.1.1.2:23) SYNRCVD
INTERCEPT: 192.1.1.1:33885 <- RST (200.1.1.2:23)
The following is an explanation of this output, with reference to the numbering on the right side:
A new connection arrives from 192.1.1.1 to 200.1.1.1. The router intercepts the connection and responds with a SYN/ACK to 192.1.1.1.
A second connection arrives from 192.1.1.1 to the same destination. The router again intercepts this connection and responds with a SYN/ACK to the source (192.1.1.1).
The router did not receive an ACK from either request, so the router retransmits the SYN/ACK for the connections.
192.1.1.2, a different device, requests a connection to the 200.1.1.2 server. The router intercepts the connection request and responds with a SYN/ACK.
The router has not received an ACK from any of the TCP connections, so it retransmits the SYN/ACK for each session request to each source device.
The router has received the ACK from the second device, completing the three-way handshake, so the router begins to build a separate connection to the server (200.1.1.1) on behalf of this client.
The server responds to the router's connection request with a SYN/ACK, and the router responds with an ACK, completing the three-way handshake.
The router still has not received an ACK response for the first two TCP connection requests from 192.1.1.1, so it retransmits the SYN/ACK for these connections.
For the two connections request from 192.1.1.1, the connection attempt has exceeded the configured timeout, so the router sends an RST to the source for both of these connection attempts.
TCP Intercept Example
To help you understand TCP Intercept's configuration, reexamine Figure 17-1. In this network, the administrator is concerned about TCP SYN flood attacks against the web server and the e-mail server located in the DMZ. To deal with TCP SYN flood attacks, the administrator has decided to use TCP Intercept in watch mode to monitor connections. Example 17-13 shows the router's configuration for TCP Intercept.
Example 17-13 Using TCP Intercept to Protect Internal Servers
Router(config)# access-list 100 tcp permit tcp any host 192.1.1.1 eq 80 Router(config)# access-list 100 tcp permit tcp any host 192.1.1.2 eq 25 Router(config)# ip tcp intercept list 100 Router(config)# ip tcp intercept mode watch Router(config)# ip tcp intercept watch-timeout 20 Router(config)# ip tcp intercept connection-timeout 120 Router(config)# ip tcp intercept max-incomplete high 600 Router(config)# ip tcp intercept min-incomplete low 500 Router(config)# ip tcp intercept one-minute high 800 Router(config)# ip tcp intercept one-minute low 600
In this example, TCP Intercept is set up for only the DMZ web and e-mail servers. The mode was changed from intercept to watch, and the watch timeout for connections was changed from 30 to 20 seconds. If a connection is not set up within the 20 seconds, the router sends a reset (RST) to the DMZ server. The idle timeout for TCP connections was changed from 1 day (86,400 seconds) to 2 minutes (120 seconds). This is a more appropriate value, based on the fact that e-mail and especially web server connections are brief and are typically not idle unless there is a connection problem.
Based on the monitoring performed on this network, the administrator chose more appropriate threshold values for the aggressive mode process. Remember, though, that setting these too low can cause half-open legitimate connections to be dropped; setting them too high can allow invalid half-open connections to use up resources on the two DMZ servers. As you can see from this example, setting up TCP Intercept is a simple process.