Re: Cisco and Nmap Dos

From: Lancashire, Andrew (LancashireAat_private)
Date: Thu Sep 02 1999 - 08:59:03 PDT

  • Next message: David Wagner: "Re: [Linux] glibc 2.1.x / wu-ftpd <=2.5 / BeroFTPD / lynx / vlock"

    Travis,
    
    Thanks for the response, we are running 11.2.  I would also agree with the
    allocation of memory issues that you mention.  One other note, it was told
    to me yesterday a 2500 series in the same time frame over 5 hops away had
    the same problem.  Although this router has much less mem (4Meg) so if the
    scope of received packets was smaller it, could still be enough to take down
    a 2500 (providing the allocation algorithm is the same for 11.1.7).
    
    Thanks for your help
    
    Andrew
    
    -----Original Message-----
    From: Travis Pugh [mailto:tpugh@br20-excha.conres.com]
    Sent: Thursday, September 02, 1999 4:58 AM
    To: 'Lancashire, Andrew'; BUGTRAQat_private
    Subject: RE: Cisco and Nmap Dos
    
    
    I just finished running CyberCop and nmap against a smaller range
    (192.168.0.0) on a cat 5500 w/RSM and didn't notice any memory issues on the
    RSM. Perhaps it is just the traffic generated by scanning the entire /8 at
    once. The Cisco engineer is correct about the small packet issue, though, as
    Cisco doesn't dynamically free memory. If you manage to allocate all of the
    memory in small (64-128k) chunks, as I have seen before when there is a lot
    of route flapping and the rtr is constantly allocating small chunks to
    update the route table, the box has no mechanism to take all of the freed
    memory space once it's done with it and turn it into a larger contiguous
    (sp?) block. This can crash the box. The whole thing 40+Mbps thing should be
    discounted, though, as the RSM should be able to handle much more traffic
    than that.
    
    Also, do you know what version of IOS the RSM is running?
    
    > -----Original Message-----
    > From:	Lancashire, Andrew [SMTP:LancashireAat_private]
    > Sent:	Tuesday, August 31, 1999 8:02 PM
    > To:	BUGTRAQat_private
    > Subject:	Cisco and Nmap Dos
    >
    > I don't know if you've ever seen this before.  We ran nmap with ICMP
    > discover and standard tcp scan.  We ran the scan against the entire
    > 10.0.0.0
    > network range. Although we were only looking for 2 ports, we found that
    > the
    > RSM in our 5500 series (our default route) was  running out of memory and
    > had to be rebooted by our Network Services group multiple times in the 18
    > hour stretch it took to complete. One of the interesting things is that we
    > were only generating about 3-5 Mbs and the 5500 can pass Gigabits.   I
    > have
    > not heard of this problem before.  We contacted Cisco and sent them the
    > details.  Below is the response to one of our engineers.
    >
    > Andrew
    >
    > -----Original Message-----
    > From:	khollis [SMTP:khollisat_private]
    > Sent:	Tuesday, August 31, 1999 7:59 AM
    > To:	wescotdat_private
    > Subject:	Regarding Case Number V44290
    >
    > Hi Dave, as I recall, the symptom we had to work/troubleshoot with was the
    > router consumed lots of memory. Never heard about packets being dropped.
    > So
    > it seems like we forwarded everything nmap sent to us. The thing to keep
    > in
    > mind is that the router will dynamically allocate memory as necessary so
    > that it can keep up with the load provided to it. Although we did not know
    > nmap was running at the time, we noticed the memory consumed by the IP
    > Input
    > process dropped from 40M+ to an acceptable level of (4-5M) after nmap was
    > shut down. This proves that the router need this much memory to process
    > the
    > entire load generated by nmap.
    >
    > I suspect nmap was doing much more than you've been able to calculate.
    > It's
    > obvious that running nmap continuously for 18-19 hours caused this
    > problem.
    > One possible explaination is constantly flooding the router w/64 byte
    > packets for this timeframe could have caused the router's memory to become
    > seriously fragmented. Also, I guess we can't tell, but another question
    > would be how many tcp sessions were requested/open on the router after
    > this
    > timeframe?
    >
    > Port scanners have a reputation of helping identify potential security
    > problems. However, they are also known to cause problems...
    >
    > Hope this helps,
    > KennyH.
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:01:14 PDT