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;
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
Client Server State Create Timeout Mode
184.108.40.206:2262 220.127.116.11:22 SYNRCVD 00:00:10 00:00:04 I
244.215.180.20:2257 18.104.22.168:22 SYNRCVD 00:00:11 00:00:03 I
22.214.171.124:2229 126.96.36.199:22 SYNRCVD 00:00:14 00:00:00 I
252.125.104.173:2266 188.8.131.52:22 SYNRCVD 00:00:10 00:00:04 I
184.108.40.206:2233 220.127.116.11:22 SYNRCVD 00:00:13 00:00:01 I
18.104.22.168:2251 22.214.171.124:22 SYNRCVD 00:00:11 00:00:03 I
126.96.36.199:2323 188.8.131.52:22 SYNRCVD 00:00:03 00:00:03 I
184.108.40.206:2261 220.127.116.11:22 SYNRCVD 00:00:10 00:00:04 I
18.104.22.168:2236 22.214.171.124:22 SYNRCVD 00:00:13 00:00:01 I
126.96.36.199:2269 188.8.131.52:22 SYNRCVD 00:00:09 00:00:05 I
184.108.40.206:2331 220.127.116.11:22 SYNRCVD 00:00:02 00:00:00 I
18.104.22.168:2336 22.214.171.124:22 SYNRCVD 00:00:02 00:00:00 I
126.96.36.199:2206 188.8.131.52:22 SYNRCVD 00:00:16 00:00:14 I
184.108.40.206:2320 220.127.116.11:22 SYNRCVD 00:00:04 00:00:02 I
18.104.22.168:2223 22.214.171.124:22 SYNRCVD 00:00:14 00:00:00 I
126.96.36.199:2199 188.8.131.52:22 SYNRCVD 00:00:17 00:00:13 I
184.108.40.206:2348 220.127.116.11:22 SYNRCVD 00:00:01 00:00:01 I
18.104.22.168:2274 22.214.171.124:22 SYNRCVD 00:00:09 00:00:05 I
126.96.36.199:2211 188.8.131.52:22 SYNRCVD 00:00:16 00:00:14 I
10.233.170.98:2300 184.108.40.206:22 SYNRCVD 00:00:06 00:00:00 I
220.127.116.11:2342 18.104.22.168:22 SYNRCVD 00:00:01 00:00:01 I
22.214.171.124:2307 126.96.36.199:22 SYNRCVD 00:00:05 00:00:01 I
188.8.131.52:2249 184.108.40.206:22 SYNRCVD 00:00:11 00:00:03 I
220.127.116.11:1993 18.104.22.168:22 SYNRCVD 00:00:27 00:00:03 I
22.214.171.124:2325 126.96.36.199:22 SYNRCVD 00:00:03 00:00:03 I
188.8.131.52:2246 184.108.40.206:22 SYNRCVD 00:00:12 00:00:02 I
220.127.116.11:2281 18.104.22.168:22 SYNRCVD 00:00:08 00:00:06 I
22.214.171.124:2317 126.96.36.199:22 SYNRCVD 00:00:04 00:00:02 I
247.19.102.167:2339 188.8.131.52:22 SYNRCVD 00:00:02 00:00:00 I
184.108.40.206:2313 220.127.116.11:22 SYNRCVD 00:00:04 00:00:02 I
252.249.176.142:2278 18.104.22.168:22 SYNRCVD 00:00:08 00:00:06 I
10.164.115.63:2330 22.214.171.124:22 SYNRCVD 00:00:03 00:00:03 I
126.96.36.199:2350 188.8.131.52:22 SYNRCVD 00:00:00 00:00:00 I
184.108.40.206:2243 220.127.116.11:22 SYNRCVD 00:00:12 00:00:02 I
249.147.125.213:2297 18.104.22.168:22 SYNRCVD 00:00:06 00:00:00 I
10.239.19.75:2332 22.214.171.124:22 SYNRCVD 00:00:02 00:00:00 I
126.96.36.199:2288 188.8.131.52:22 SYNRCVD 00:00:07 00:00:07 I
184.108.40.206:2227 220.127.116.11:22 SYNRCVD 00:00:14 00:00:00 I
18.104.22.168:2264 22.214.171.124:22 SYNRCVD 00:00:10 00:00:04 I
126.96.36.199:2343 188.8.131.52:22 SYNRCVD 00:00:01 00:00:01 I
184.108.40.206:2215 220.127.116.11:22 SYNRCVD 00:00:15 00:00:15 I
18.104.22.168:2353 22.214.171.124:22 SYNRCVD 00:00:00 00:00:00 I
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 -S --rand_source -p 80 -p 10255 "victims ip_address or hostname here "
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
Your Freelance Network and Security Engineer
kfelix "at/@" hyperfeed.com