This is really cool feature on Cisco router not usually mentioned until you dig a little deeper inside Cisco IOS. But first a bit of theory…
What is TCP SYN flood attack
TCP 3-way handshake
SYN flood DoS attack happens when many sources start to send a flood of TCP SYN packets usually with fake source IP.
This attack uses TCP 3-way handshake to reserve all server available resources with fake SYN requests not allowing legitimate users to establish connection to the server. SYN packet is the first step in TCP 3-way handshake. This is the step where client sends connection synchronization request to the server. Server receives TCP SYN from client, the server replies back with SYN ACK. SYN ACK acknowledges synchronization request.
In that moment server is waiting the client to complete the handshake by sending an ACK back to server to acknowledge the SYN ACK. With this third step, TCP session is successfully established and communication between server and client begins.
If the ACK is not received from the client side, server will wait for it for some time and then the session will timeout and get dropped. When the server deletes the session, his resources will be released.
TCP SYN flood attack
TCP SYN flood attack sends first packet of 3-way handshake SYN packet to server many times to cause the server to allocate resources for sessions that will never become established. It means that client who is attacking will never respond to server SYN ACK and the session will remain on the second step of 3-way.
Sending thousands of TCP SYN packets per second to the server with fake source IP and even from different locations is making the server really busy. Server will not know which SYN packets are real and which are fake. He will reply with SYN ACK to every SYN packets and allocate resources for the anticipated TCP session.
SYN Flood
After huge number of SYN packets, server will run out of resources to allocate additional TCP sessions. Server is keeping thousands of half-open TCP sessions waiting to timeout after failing to receive the ACK from the client. Because most of resources of the server are used to reply to the SYN packets, legitimate users will not be able to establish a TCP session with the server.
Server will work but it will appear to be down. Website running the application which clients are trying to access will not work at all.
TCP Intercept
In small networks where you don’t have a dedicated DDoS box or some outside DDoS protection service, TCP Intercept is a great and simple tool to use directly on the router. If you are experiencing DoS attack to some of your internal equipment this is the fastest way to get rid of it.
TCP Intercept is easy to configure and works really good against simple SYN flood attacks. It can basically just help you to get rid of some simple flood attacks towards you network without implementing fancy and costly DDoS defense solution.
Here is as complicated as it gets:
access-list 101 permit ip any 192.168.11.0 0.0.0.255 ip tcp intercept list 101 ip tcp intercept connection-timeout 15 ip tcp intercept max-incomplete low 100 high 200 ip tcp intercept one-minute low 60 high 120 ip tcp intercept drop-mode random
In the config above, the router will be configured to:
Protect web servers on subnet 192.168.11.0/24 from a SYN flood attack by intercepting connections and close them after 15 seconds if inactive. An access-list is used to restrict “watched” host to only one subnet. Without ACL, the router will track all traffic for TCP SYN flood.
In our example, line 4 is showing that maximum number of semi-established connections threshold is set to 200 and they are dropped down to 100 when the threshold is crossed. On line 5, router is configured to start dropping half-open sessions when they cross the rate threshold of two connection per second (120 connections in one minute = 2 connections per 1 second). The router should not stop until the average rate is under one per minute. On line 6, router should not take into account connection age when deciding which connections to drop first. It needs to do it randomly in our case. Otherwise, it can be configured to drop packets by dropping older connections first.
TCP Intercept mode
You can configure TCP intercept in two modes: Intercept mode and Watch mode.
Intercept mode actively intercepts the TCP sessions and is acting like a proxy. Intercept mode is default so we didn’t use “Router(config)#ip tcp intercept mode intercept” in the example above.
In watch mode, router only monitors TCP sessions. When a session doesn’t reach established state within 30 seconds by default or 15 seconds in our case (config above, line 3), router will send an RST to the server. Server will then release allocated resources for that connection by closing it.
If we wanted to use watch mode, it was because we wanted TCP sessions to be tracked and not proxied, we would use a simple config as this below to enable watch mode:
ip tcp intercept mode watch ip tcp intercept watch-timeout 20
With watch mode, router will only monitor TCP sessions and it will not proxy them. Using TCP RST packet sent to internal server for TCP sessions that do not become established within 15 seconds flood protection is still possible.
Watch mode is better. Router in Intercept mode needs to terminate all connections and it will then become the weak link in SYN flood attack. It happens because router with limited resources is not able to handle all SYN requests in a flood which he needs to terminate and then proxying them to server.
With Watch mode you will not take the DoS attack and terminate it on the router itself like you would do in Intercept mode. With Intercept mode you are risking to get your router resources drained and cause router reboot. In that way you are actually making SYN flood attack successful.