As you point out, #3 (suggested as a workaround in some early versions of the advisory) is inadequate. #1 is preferred, and I'm working on it. In the meantime, I've implemented an alternate version of #2 at our borders. Instead of blocking these four classes, I've permitted only the ones we legitimately use: ICMP, UDP, TCP, and for our VPN users, 50 and 51 (ESP and AH, although I can never remember for sure which is which). (Some VPN technologies use 47 (GRE), but so far I don't know of anyone using that on our network.) So far, nobody has stepped forward with a need for any additional protocols to cross our borders.
David Gillett > -----Original Message----- > From: Kurt Seifried [mailto:[EMAIL PROTECTED] > Sent: July 23, 2003 22:11 > To: DOUGLAS GULLETT; Alvaro Gordon-Escobar > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Cisco Workaround > > > No. The attack requires N+1 attack packets. N=size of queue, which by > default is 75. The packets can be any of the four protocols > (i.e. all of one > type, half of one, half of another, etc.). It has also been > reported that > some other protocols work for this attack, but this has not > been confirmed. > Read the Cisco advisory, it's quite clear on this. > > You can either: > > 1) upgrade your software > 2) firewall these four classes of packets > 3) firewall access to the IP's bound to the interfaces (*) > > * it has also been reported that packets that timeout, i.e. > TTL = 0 in the > queue can be used to execute the attack. > > 1 is of course the optimal solution as it _fixes_ the problem. > > Kurt Seifried, [EMAIL PROTECTED] > A15B BEE5 B391 B9AD B0EF > AEB0 AD63 0B4E AD56 E574 > http://seifried.org/security/ > > > > > > -------------------------------------------------------------- > ------------- > -------------------------------------------------------------- > -------------- > --------------------------------------------------------------------------- ----------------------------------------------------------------------------
