The TCP Intercept feature is configured to prevent SYN flood attacks whereby a malevolent client (or a vast number of ghost clients under its control) individually opens a vast number of TCP connections to a victim host without going to full connection establishment, therefore keeping a vast number of half open sessions. This results in the host’s TCP stack being overloaded with incomplete TCP sessions also known as half-open or embryonic sessions. These sessions are open not to be used to transmit data but to keep the TCP stack busy and fully provoke a Denial of Service or Distributed Denial of Service by the sheer number of half open connections on the victim host.

Note: While CBAC is an advanced feature that will prevent SYN flood attacks and more, the TCP Intercept feature is fully integrated into CBAC and ZBPF to make a Cisco IOS stateful firewall and does not need to be configured when either is implemented.

There are two possibilities to prevent this kind of attack or exploit:

1. We can monitor sessions open to the hosts we want to protect (for example a web or mail server) and use TCP RST flagged packets to close or reset any 3-way handshake that takes too long (threshold) to complete. This cleans the host’s precious TCP stack before it gets clogged with useless, probably malevolent, half open or embryonic sessions that are not intended to complete or close unless someone does something.

2. We can have a third party system serve as a proxy whereby all three steps of the 3-way handshake are completed between the client and the third party system and then let the client connect to the intended server only after 3-way handshake completion.

For the first option (passive monitoring and TCP RST use), modern operating systems like Linux and its many flavors can be set on the destination host to close half open sessions after a certain number (threshold) is reached or after a certain amount of time is exceeded and the half open session did not get completed. The good news is this can be achieved by a Cisco router between the client and the server.

The second option (the proxy method) can also be implemented with a router. A router is best suited to this scenario exactly because it is seated between the client and the server and would thus reduce the number of routing hops involved if the proxy was a dedicated host.

Another reason the router is our preferred device to control this unwanted traffic is that if we implement this solution at the edge of our network we will be reducing the amount of bandwidth eaten away by a DDoS attack at the same time.

The Cisco feature to implement one of these two methods is the TCP Intercept feature, the subject of today’s tutorial. The TCP Intercept feature operates in two different modes: the appropriately named Intercept mode (proxying all the connections) and the Watch mode (passively monitoring and issuing TCP RSTs when needed).

The choice of operation mode can be influenced by the capacity of our router. If we implement the TCP Intercept feature to operate in intercept/proxy mode, the DDoS attack is now directed to the router since all the three-way handshake processes are handled by the router before the session between the client and the server can proceed. We may chose this method only if we are confident in our router’s CPU and memory capacity.

When confronted with a router’s resource insufficiency for the intercept/proxy mode, the other method, Watch mode, can be chosen.

The TCP RST in Watch mode are sent with a spoofed source IP address so that the server sees the reset as coming from the offending client to close the half open session. The logs on the server might indicate a suspicious client resetting handshake sessions before they are completed. The server administrator should correlate these logs to the fact that he/she knows there is a TCP Intercept feature deployed at the edge and will account these resets to the intercepting router.

TCP Intercept Configuration

To configure the TCP Intercept feature a few commands are available to us. The base command syntax for Cisco IOS Intercept is:

Ip tcp intercept [option1 , option2, …]

We are going to go through the following steps to configure TCP Intercept.

  1. Define the host to be protected against SYN flood attacks.
  • The protected hosts can be put in a list with access control lists. There seems to be no way to configure the desired IP address directly in the command without putting it in the access control list.

    An extended access list is used so we can specify the TCP protocol since we are doing TCP intercept. UDP doesn’t need the SYN-flood protection we are implementing:

We add in the access list the IP addresses of the loopback1 and the LAN interface on the inside router:

We then tell the TCP Intercept feature to use the access-list 101 as a source of IP addresses to monitor the three-way TCP handshake:

  1. Configure the Interception mode.

    Here we configure the TCP Intercept feature to operate in Watch mode:

  2. Configure Thresholds.

    There are two types of threshold-ing. The one minute threshold keeps track of how many half open sessions there are per minute and the absolute number threshold keeps track of the absolute number of half open connections.

    Whatever the threshold-ing type, two values [HIGH, LOW] will determine the IOS behavior. By default the HIGH value is set by the IOS to 1100 and the LOW value is set to 900. To manually change the values of these thresholds we use the following commands:

    If we decide to threshold by the number of half open connections per the last one minute, we would have to use the one-minute keyword instead like this:

    In my configuration here (TCP Intercept, Watch mode, max-incomplete threshold):

    – When the absolute number of incomplete connections are higher that the HIGH value (1099), a TCP RST flagged packet is sent by the INTERCEPT router to the victim server (inside router).

– When the absolute number of incomplete connections is between HIGH and LOW, the INTERCEPT router drops the oldest half open connection (by default) for every new connection.

– When the absolute number of incomplete connections is below LOW, the INTERCEPT router will stop dropping the oldest half open connections.

If we decide to configure both threshold-ing, the one-minute and the max-incomplete threshold-ing, the IOS would then adapt its behavior on a “whichever comes first” basis. This means that if the max-incomplete HIGH is reached before the one-minute HIGH, the INTERCEPT router will start dropping the stalled handshakes. The same is true if the one-minute HIGH is reached before the max-incomplete. Note that the HIGH mark and LOW mark can be set with different values for the one-minute threshold-ing and the max-threshold-ing when these threshold-ing are configured together.

When dropping the connection, dropping the oldest half open connections is a default behavior for the IOS. It can be configured to not drop the oldest half open session and instead drop a random half open connection.

I will tell the INTERCEPT router to keep dropping the oldest when dropping is needed.

Since the “drop-mode oldest” is the default, even if it is entered at the command line it will not appear in the running configuration with the show running-config command.

  1. In addition to dropping based on configured thresholds, the IOS also decides dropping based on timers. The administrator can configure the timeout in seconds for the interception in Watch mode to tell the router when to drop half open sessions.

By default:

– IOS waits for 30 seconds for a watched connection to reach EST and will otherwise send RST to the server, causing session termination.

To manually change this default behavior and lower it to 15 seconds:

– IOS drops the connection 3 seconds after receiving FIN.

To manually change this default behavior and lower it to 3 seconds:

– IOS keeps open a connection for 24 hours of idleness.

The following command changes that timer and lowers it to 1 hour (3600 seconds):

These three last commands tell my INTERCEPT router that even when the thresholds are not exceeded:

  • No TCP Handshake should take more than 15 seconds. Always send TCP RST to end such stalled handshakes.
  • The INTERCEPT router should always drop the connection 3 seconds after FIN/RST.
  • Never keep alive a connection after one hour of idleness.

The combination of timers and thresholds as shown in the sections above can tell the IOS how to efficiently manage the sessions that are left half open by misconfigured clients, networks or malevolent hosts such as in case of a heavy DDoS attack on one or many of our servers.

Monitoring TCP Intercept

We have the usual monitoring tools like show tcp intercept connections and show tcp intercept statistics for troubleshooting sessions.

Their output will be displayed in the form of a table:

And a number of statistical figures from our intercept engine:

We have reached the end of our TCP Intercept tutorial. I hope this article was helpful for you to understand the TCP Intercept feature and how to configure it on your Cisco IOS router.