Detecting the source of a DOS attack with Cisco Netflow

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.

This entry was posted in Cisco and tagged , , , . Bookmark the permalink.

Leave a Reply