DOS attack fills input queue?

Scott Call scall at devolution.com
Sun Aug 3 19:12:21 UTC 2003


One of my FE interfaces was "stuttering" this morning, and when I 
checked it out, it had an input queue of 76/75 which of course made me 
think of the recent Cisco vulnerability, which we have upgraded IOS and 
added ACLs to counteract.

I checked the ACLs and they hadn't caught any traffic from the "bad 
four" protocols, only TCP and UDP, so I started to investigate. 

The packets (as pulled from the buffer) have headers like:
Buffer information for Small buffer at 0x42561A68
  data_area 0x42561D18, refcount 1, next 0x41C4F394, flags 0xA00
  linktype 7 (IP), enctype 1 (ARPA), encsize 14, rxtype 1
  if_input 0x42E47824 (FastEthernet4/0/0.7), if_output 0x0 (None)
  inputtime 0x1433CC, outputtime 0x0, oqnumber 65535
  datagramstart 0x42561D5E, datagramsize 60, maximum size 260
  mac_start 0x42561D5E, addr_start 0x42561D5E, info_start 0x0
  network_start 0x42561D6C, transport_start 0x42561D78, caller_pc 0x403F5BD4

  source: 71.209.243.3, destination: 163.29.243.5, id: 0x0100, ttl: 128,
  TOS: 0 prot: 6, source port 0, destination port 40

Buffer information for Small buffer at 0x425868E4
  data_area 0x42586B94, refcount 1, next 0x4253BC7C, flags 0xA00
  linktype 7 (IP), enctype 1 (ARPA), encsize 14, rxtype 1
  if_input 0x42E47824 (FastEthernet4/0/0.7), if_output 0x0 (None)
  inputtime 0x96724, outputtime 0x0, oqnumber 65535
  datagramstart 0x42586BDA, datagramsize 60, maximum size 260
  mac_start 0x42586BDA, addr_start 0x42586BDA, info_start 0x0
  network_start 0x42586BE8, transport_start 0x42586BFC, caller_pc 0x403F5BD4
         
  source: 224.209.80.156, destination: 163.29.243.5, id: 0x0100, ttl: 128,
  TOS: 0 prot: 6, source port 0, destination port 40


and so on....

Random sources, same destination, same source/destination port pairs 
(0/40 tcp)

I added:
access-list 111 deny tcp any host 163.29.243.5
access-list 111 deny tcp host 163.29.243.5 any

to the interface and it did not catch any of them, and the input queue 
returned to 76/75 (when the customer is disconnected the queue empties 
back to 0/75, when I re-enable their switchport, it takes 30-60 seconds 
to fill back up).

I'm sure the packets are problably just one of the latest windows worms, 
but what concerns me is that I can't seem to catch them in an ACL before 
they cause damage to the router.

The router is a 7507 with 12.0.25S on it.  Since 12.0.25S has given me 
(unreleated) problems on other boxes, and been pulled by Cisco,  I've 
scheduled a reload to 12.0.21S7 tonight.  I  don't know if that will, 
however, fix this problem, so I wanted to both ask for the advice of, 
and maybe raise a red flag for, the nanog folks out there who might run 
into the same thing.

Thanks
-Scott





More information about the NANOG mailing list