DDoS protection via tcp intercept ( CISCO )

In my daytime  job, I work for a major cloud based DDoS mitigation provider. Here we have the luxury of cloud based mitigation  services for the major financial and market  dot coms types.

Cloud based mitigation is the ONLY way to fully mitigate  DDoS/DoS  attacks imho. It's smart, correct and superb when compared to legacy mitigation methods and devices ( ACL, IPS,FW-attach thresholds, FW DOS-anomaly engines,etc......)

Attempts at doing this mitigation locally ( at the customer edge )  is doomed to fail in most cases due to any of the following;

•  hardware resources are over taxed
•  even if your local router/firewall/ips blocks the attack traffic, your link is still over utilized and wasted bandwidth
•  more man-power from your IT staff is required ( during the duration of the attack)
•  your ISP links  have no way to distribute the attack traffic 
•  your ISP can only contribute very little to no-Support  in their effort to help you
• and it takes time for your ISP to place filters or policy rate limits
•  you have no way to fully determine if the attack has really subsided until you lift the lid to peek " so-to-speak"

Okay so what's this tcp intercept thing?

Will if you are stuck on a a cisco and have no cloud DDoS mitigation  provider, you have a limited  means to  protect against  TCP- SYN-FLOODS ( aka half-opens )

The router is not the best approach for this,  due to it's limited  cpu/memory and in a hugh sustained attacked, your router could become it's own denial-of-service :). But for low volume or amateurish tcp-SYN floods, you can deploy the tcp intercept feature as provided in most all cisco router codes  starting from  ios12.3 and onwards.

In order to understand the tcp-intercept, we need to re-educated one's self on the 3-way tcp-hand-shake. This hand shakes happens every time & for all tcp-sessions, when a validate tcp-session is being requested.

The  attacker community & underground, uses this knowledge to  launch  half-opens attacks,  by not  completing  the third step of the 3way hand-shake.

Here's the tcp-handshake 3 steps;

1: client  sends a  SYN -------->  to  Server  ( this is the 1st packet for tcp and holds the client  SPORT, server DPORT, MSS value, and any tcp-options )

2: Server  sends a SYN/ACK to the --------------> client  ( server sends his tcp MSS, tcp-options in this port back and startng seq# )

3: client   acks the  SYN/ACK with a ack to ---------> the server ( the final steps before we can start sending data )

Step #3 is what  DOES NOT happen when a syn-flood  attack takes place. As a matter of fact, the  sender is probably using a spoof'd & random  addres.

So in this attack, you try to exhaust a server  tcp-session table, which directly impacts memory consumption.  As more and more half-open sessions are being handle, the server can ultimately come to it's knees, drop valid sessions, or worst of all CRASH and Burn :)

Okay so how do we mitigate this on a cisco router?

We use  the tcp intercept feature. Here's the steps;

1: we craft a ACL. It's highly suggestive to always  build a acl to protect just the server(s) and service(s) that you want  DDoS mitigation for.  A  open  "ANY ANY" or all, would cause intercept to take place for ALL tcp-sessions, which can drive the  device  CPU high, during the inspection process.

It's also ideal to place the trusted internal networks into a deny statement,  before the final permits. For example, let's say you have a classic internal/dmz/external interfaces;

internal 172.18.0.0/24
dmz       172.19.0.0/24
external 7.7.7.0/30

You might want to or not want to  inspect traffic from dmz to internal or internal to dmz. So a ACL could be drafted like this;

!
ip access-list extend DDOS-protect
 remark ignore  lan to dmz
 deny tcp  172.18.0.0 0.0.0.255 172.19.0.0 0.0.0.255
 remark ignore dmz to internal lan
 deny tcp  172.19.0.0 0.0.0.255 172.18.0.0 0.0.0.255
 remark  okay now let's protect our servers in the DMZ
 permit tcp any host 172.19.0.10 eq 80
 permit tcp any host 172.19.0.11 eq 80
 permit tcp any host 172.19.0.12 eq 80
 permit tcp any host 172.19.0.13 eq 80
 permit tcp any host 172.19.0.14 eq 80
 permit tcp any host 172.19.0.15 eq 80
 permit tcp any host 172.19.0.16 eq 25
!
!

Okay now on to step #2

Here we need to determine if we want intercept or watch mode.

The latter only watches for the step #3  of the  tcp 3-way handshake,  and if not completed, it jumps in and send a RST ( reset ) to the server by spoof'ing the source address of the attacker that send the invalid SYN to begin with.

tcp intercept mode  intercept | watch 

With intercept mode, the  router is always in the middle and send a SYN/ACK back on behalf of the client  while watching for the final ACK in t he 3rd step of the tcp 3-way handshake. If the client is validate, the  router will allow the sessions to complete. The  Intercept mode, is more proccess intensive on the router/firewall/mitigation gear.

And finally we  monitor the  tcp intercept connection and statistic tables. Here's a snippet of those tables;

ccie01#show tcp intercept connections
Incomplete:
Client                Server                State    Create   Timeout  Mode
212.145.60.80:2262    8.8.8.2:22            SYNRCVD  00:00:10 00:00:04 I
244.215.180.20:2257   8.8.8.2:22            SYNRCVD  00:00:11 00:00:03 I
25.101.177.222:2229   8.8.8.2:22            SYNRCVD  00:00:14 00:00:00 I
252.125.104.173:2266  8.8.8.2:22            SYNRCVD  00:00:10 00:00:04 I
228.17.28.163:2233    8.8.8.2:22            SYNRCVD  00:00:13 00:00:01 I
192.209.96.45:2251    8.8.8.2:22            SYNRCVD  00:00:11 00:00:03 I
205.165.88.134:2323   8.8.8.2:22            SYNRCVD  00:00:03 00:00:03 I
234.143.146.118:2261  8.8.8.2:22            SYNRCVD  00:00:10 00:00:04 I
205.180.125.38:2236   8.8.8.2:22            SYNRCVD  00:00:13 00:00:01 I
17.116.9.244:2269     8.8.8.2:22            SYNRCVD  00:00:09 00:00:05 I
37.36.172.101:2331    8.8.8.2:22            SYNRCVD  00:00:02 00:00:00 I
148.50.177.94:2336    8.8.8.2:22            SYNRCVD  00:00:02 00:00:00 I
163.156.87.76:2206    8.8.8.2:22            SYNRCVD  00:00:16 00:00:14 I
139.219.70.132:2320   8.8.8.2:22            SYNRCVD  00:00:04 00:00:02 I
98.252.142.24:2223    8.8.8.2:22            SYNRCVD  00:00:14 00:00:00 I
148.53.60.231:2199    8.8.8.2:22            SYNRCVD  00:00:17 00:00:13 I
142.30.63.115:2348    8.8.8.2:22            SYNRCVD  00:00:01 00:00:01 I
125.229.73.124:2274   8.8.8.2:22            SYNRCVD  00:00:09 00:00:05 I
224.86.164.142:2211   8.8.8.2:22            SYNRCVD  00:00:16 00:00:14 I
10.233.170.98:2300    8.8.8.2:22            SYNRCVD  00:00:06 00:00:00 I
164.143.165.192:2342  8.8.8.2:22            SYNRCVD  00:00:01 00:00:01 I
19.36.6.77:2307       8.8.8.2:22            SYNRCVD  00:00:05 00:00:01 I
27.143.231.45:2249    8.8.8.2:22            SYNRCVD  00:00:11 00:00:03 I
196.25.239.187:1993   8.8.8.2:22            SYNRCVD  00:00:27 00:00:03 I
48.164.49.213:2325    8.8.8.2:22            SYNRCVD  00:00:03 00:00:03 I
177.164.197.252:2246  8.8.8.2:22            SYNRCVD  00:00:12 00:00:02 I
195.94.219.45:2281    8.8.8.2:22            SYNRCVD  00:00:08 00:00:06 I
200.162.177.58:2317   8.8.8.2:22            SYNRCVD  00:00:04 00:00:02 I
247.19.102.167:2339   8.8.8.2:22            SYNRCVD  00:00:02 00:00:00 I
4.96.45.248:2313      8.8.8.2:22            SYNRCVD  00:00:04 00:00:02 I
252.249.176.142:2278  8.8.8.2:22            SYNRCVD  00:00:08 00:00:06 I
10.164.115.63:2330    8.8.8.2:22            SYNRCVD  00:00:03 00:00:03 I
102.60.7.145:2350     8.8.8.2:22            SYNRCVD  00:00:00 00:00:00 I
211.127.67.63:2243    8.8.8.2:22            SYNRCVD  00:00:12 00:00:02 I
249.147.125.213:2297  8.8.8.2:22            SYNRCVD  00:00:06 00:00:00 I
10.239.19.75:2332     8.8.8.2:22            SYNRCVD  00:00:02 00:00:00 I
152.10.124.67:2288    8.8.8.2:22            SYNRCVD  00:00:07 00:00:07 I
156.223.156.199:2227  8.8.8.2:22            SYNRCVD  00:00:14 00:00:00 I
58.136.190.247:2264   8.8.8.2:22            SYNRCVD  00:00:10 00:00:04 I
12.17.9.234:2343      8.8.8.2:22            SYNRCVD  00:00:01 00:00:01 I
229.63.9.68:2215      8.8.8.2:22            SYNRCVD  00:00:15 00:00:15 I
231.136.194.117:2353  8.8.8.2:22            SYNRCVD  00:00:00 00:00:00 I
         
and



ccie01#show tcp intercept statistics 
Intercepting new connections using access-list DDOS-protect
205 incomplete, 0 established connections (total 205)
141 connection requests per minute










Notice the  counters named  incomplete? That will increase for every sessions that has been mitigated by the router.

Things to keep in mind;

1: the router can only handle so much traffic  ( half-opens ) and could fail-open  if the number of sessions exceed it's hardware limit

2: this is best effort only , and with a high PEAKs based attack and 500K plus  random sources, the router CPU could climb & cause other issues

3: cisco provides very limited tweaking in regards to this imho , once again best-effort


Okay you want to see how easy it is to  launch a tcp syn-flood using 2 of my  favorite attack tools :)

(hping)
hping -S --rand_source -p 80 -p 10255 "victims ip_address or hostname here "

(mausezahn)

mz vic0 -c 0 -d=100msec -A rand -B "victims ip_address|hostname here" -c 0 -t tcp "sp=1233,dp=80, flags=syn"

I hope you found this post useful

Ken Felix
Your Freelance Network and Security Engineer
kfelix "at/@" hyperfeed.com