Eskimo North


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Network Outage



On Mon, 11 Sep 2000, Phillip Remaker wrote:
> 
> Which attack was this?  Can you give a reference?  We can better pressure
> Cisco to fix things if you refer to the specific problem, or a pointer on
> the web site.
> 
> Is this http://www.cisco.com/warp/public/770/nifrag.shtml?  Or something
> else?

     Yes, this is the one, and the paragraph:

 -----
The possibility of IP fragmentation attacks against packet filters, from Cisco
and other vendors, has been widely known for a very long time. However,
exploitation does not seem to be increasing. Therefore, Cisco does not believe
that the majority of its customers are critically exposed by this
vulnerability. Cisco is, however, prepared to support any customers who suffer
actual attacks, or who have specific reason to think that they are likely to be
attacked in this way. 
 -----

     Is completely unacceptable.  We have two T1's to Sprint, and we have two
IRC servers, several shell machines, e-mail, virtual domain hosting, dial-ups,
etc.

     From time to time, someone gets upset and decides to flood the IRC
servers, usually in an attempt to take over a channel.  We have an access list
in place upstream at Sprint that is supposed to block all UDP and ICMP to the
machines that are frequently targeted.  However; do to this horrid flaw in
Cisco's IOS, the attackers can get past the access lists.

     Our 3Com Netbuilder II router does not have this flaw and does stop the
packets from reaching the hosts; however, the attackers can still saturate our
links from Sprint because the upstream access lists on the Cisco 7000 series
router does not work under this kind of attack. 

     This isolates all of our hosts effectively from the Internet and we and
Sprint are both completely powerless to do anything about it until Cisco feels
inclined to actually fix this bug which has been known at least since last
November.  Since this bug is not present in 3Com Netbuilder II equipment, it is
obviously not an inherent flaw in TCP/IP protocol and is fixable with proper
coding.