A very late night call last night/this morning was a support ticket for a none responsive LNS (L2TP Network Server). The LNS normally terminates around 1000 VPDN sessions but was dropping just about all the traffic. A cursory glance at the interfaces showed 300Mbits of traffic inbound (from the internet to the end users) which was way over the baseline for 02:00 hrs. It was laos apparent that a single use would not be able to download this kind of data rate as they are all DSL users and 300MBits is way over that limit. The conclusion was that a DOS attack was happening. The difficulty was identifying which ip address was the target. For this, I used netwflow on the LNS itself. I chose the LNS as the router to use netwflow on so as not to add extra load to the border routers which were under reasonable pressure already. Netflow is not ‘free’ interns of CPU and memory overhead so some care must be taken when using it. In an ideal world we would use a collector and have a separate server, however in reality what i needed was a quick and dirty method of finding the busy ip – the target of the attack. On the target router:
int gi0/2 ip flow ingress
Well, that was easy! Now we can collect the data:
show ip cache flow
sh ip cache flow
IP packet size distribution (313671086 total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.001 .279 .039 .024 .030 .006 .022 .004 .003 .004 .003 .002 .008 .005 .002
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.002 .002 .015 .014 .525 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 4456704 bytes
16491 active, 49045 inactive, 9599179 added
27303553 ager polls, 0 flow alloc failures
Active flows timeout in 30 minutes
Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 336520 bytes
6 active, 16378 inactive, 10899 added, 10899 added to flow
0 alloc failures, 0 force free
1 chunk, 1 chunk added
last clearing of statistics never
Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow
TCP-Telnet 19247 0.0 3 49 0.0 0.5 16.9
TCP-FTP 4064 0.0 27 72 0.0 8.3 11.1
TCP-FTPD 4268 0.0 2 153 0.0 0.6 11.6
TCP-WWW 2550446 0.5 41 1254 24.8 4.6 14.6
TCP-SMTP 26033 0.0 58 712 0.3 4.8 9.0
TCP-X 6252 0.0 1 89 0.0 0.0 18.4
TCP-BGP 157 0.0 252 495 0.0 338.9 15.6
TCP-NNTP 3 0.0 1 40 0.0 0.0 15.5
TCP-Frag 7 0.0 3 49 0.0 17.1 13.0
TCP-other 2923216 0.6 30 899 20.5 6.2 14.4
UDP-DNS 8144 0.0 12 84 0.0 1.0 20.7
UDP-NTP 7451 0.0 6 76 0.0 0.5 20.8
UDP-TFTP 82 0.0 8 1167 0.0 0.8 18.7
UDP-Frag 2201 0.0 382 53 0.1 33.7 19.2
UDP-other 3863900 0.8 22 321 20.5 3.8 20.6
ICMP 151892 0.0 12 66 0.4 10.1 20.2
GRE 5747 0.0 2355 448 3.1 183.6 17.2
IP-other 9578 0.0 546 367 1.2 86.1 18.3
Total: 9582688 2.2 31 818 71.3 5.0 17.1
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Gi0/2 X.X.X.X Vi2.797 X.X.X.X 06 0050 8AAA 48
--/snip/--
This is same output of a healthy system. When this was being attacked, from a ground start the target ip showed 300K packets in a couple of seconds. This was identified as the culprit and the /32 was null routed at the border router.
