IW: Tools Stunt DoS Attacks

[Adam Shostack]

Folks should take a look at the work Bindview did on the Naptha family 
of dos attacks.  Basicly, they found ways to move up the application
stack, consuming CPU, without a serious comitment of resources on the
client side.  razor.bindview.com/publish/advisories/adv_NAPTHA.html

Adam

On Wed, Feb 07, 2001 at 02:29:56PM -0400, Adam Back wrote:
| 
| So this is the kind of thing I was talking about -- it just moves
| things to the next obvious escalation from which there is no
| obvious way to go further down this dead end route of trace,
| block, track down and prosecute, etc.
| 
| So what if you couldn't send a packet without revealing a
| source address.  There are numerous ways to reveal someone
| else's source address, which is a real source address, just
| not yours.
| 
| I'm not even sure it's a step forward to paint yourself
| into a corner where there is no way to fix the induced
| escalation of attack sophistication.
| 
| Adam
| 
| On Wed, Feb 07, 2001 at 05:16:13PM +0100, Lars Gaarden wrote:
| > 
| > Andrew Alston wrote:
| > 
| > > Basically, people who claim to be able to stop DDOS/trace DDOS/etc etc I
| > > believe are playing on the public, making money out of a situation that
| > > unfortunatly has no end in site, due to the fuckups made in the IP
| > > protocol by the department of defense when they released the RFC.
| > 
| > Spoofed source-addresses can be (and often are) blocked at the
| > access ISP. RFC 2267, Ingress filtering.
| > 
| > DDOS trojans on ISDN/xDSL/Cable home user boxes will have to use
| > their real (or at least same subnet) source addresses on datagrams,
| > or run the risk of having the traffic dropped silently at the first
| > router.
| > 
| > This won't stop DDOS attacks, but it will make it a lot harder to
| > mount an attack without exposing many of the DDOS trojans
| > participating.

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume