Home > Articles > Cisco Network Technology > General Networking > Cisco Router Firewall Security: DoS Protection

Cisco Router Firewall Security: DoS Protection

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Oct 22, 2004.

Chapter Description

A Denial-of-Service (DOS) attack can cause immense harm to your business. In this chapter, you can learn how to deal with such an attack, and minimize the damage done.

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 3Figure 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:

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

  2. 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).

  3. The router did not receive an ACK from either request, so the router retransmits the SYN/ACK for the connections.

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

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

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

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

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

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

4. CBAC and DoS Attacks | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.

Overview

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children

This site is not directed to children under the age of 13.

Marketing

Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out

Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020