[LINK] Distributed Denial of Service attacks

[richard@auscoms.com.au]

Grant, 

We're thinking differently here. I agree 100 per with your technical outline.
I'm thinking that since Amazon dropped 4-5% share price in the wake of the
attack, it would be fair to know what action it had taken in response to the
advisories last year. 

Did it quiz its own upstream providers about their readiness, for eg? Did it get
that readiness stated in writing? Is it in Amazon's service level agreement with
its ISP that the provider has to stay current with all security advisories?

Yes, some attacks distribute their threat beyond any reasonable defence at the
periphery (which is where the server lies) but without disclosure, we get a
situation where someone can do nothing and get away with it!

>It's a tough one, but if the companies would co-operate a little more,
>it might be actually possible to deal with it first and foremost and
>secondly trace it back to the attackers/saboteurs.

Indeed. part of that co-operation lies in the telecomms infrastructure, though,
and we're dealing with a supply chain stack that won't be made to co-operate
easily.

That comes back to the ability of an Amazon to coerce its supplier to co-operate
with the next chain in the link. The say to do that is through service level
agreement penalties: if I lose service, you suffer as well. But there's no
imperative to do *that* unless the company at the end of the chain suffers (say)
a depressed share price because the market didn't like what was disclosed. 

Without disclosure, there will always be a temptation that I can ignore a
theoretical future threat rather than spending money on it now.

Richard Chirgwin

____________________Reply Separator____________________
Subject:    Re: [LINK] Distributed Denial of Service attacks
Author: "Grant Bayley" <gbayley@ausmac.net>
Date:       11/02/00 13:56

Richard,

They could all disclose their security defenses, but in the case of the
current attacks (which may consist of any mix of smurf, trin00, TFN,
stacheldracht, TFN2k etc), the best they can hope for is co-operation with
all their upstream providers and their providers upstream providers.

We experienced a smurf attack at one point last year at the hands of a 16
year old with a grudge and the best we could hope for was Telstra placing
a block on the type of traffic the single compromised machine from Canada
was generating.

In the case of something like this where we might as well presume there's
multiple traffic sources, all the upstream carriers can do is trace
abnormal amounts of traffic entering their network at some point.  Once
they've done this, they need to work out if it's a machine (or machines)
acting as passive amplifiers of traffic or actual machines generating the
traffic themselves. If the machine itself is compromised in any case, take
it off the network.  If the machine is merely acting as an amplifier, 
they'll need to surveil the traffic entering the network for packets
likely to trigger such responses.  If it's a smurf attack, they'll be
either ICMP or UDP packets going to a broadcast address.  If it's trin00
or TFN or some variant, they'll need to be watching for control packets
coming in (ie packets instructing it to do certain things)...

The BIG problem in tracing it back is that if it's an amplifier scenario,
the trigger packets will have their source address forged to be that 
of the intended victim and aren't going to be in any sort of volume that's
easily able to be tracked back to the sender, co-operation or not.

It's a tough one, but if the companies would co-operate a little more,
it might be actually possible to deal with it first and foremost and
secondly trace it back to the attackers/saboteurs.

It still gets back to companies being somewhat paranoid about the
security of their machines (making sure people can't use them as
passive amplifiers of traffic and making sure people can't break into
them to load things such as trin00/TFN or others onto them).  The way
things are these days, expect it to get worse before it gets better.

Grant

-------------------------------------------------------
Grant Bayley                         gbayley@ausmac.net
-IT Manager @ Batey Kazoo            (www.kazoo.com.au)
-Admin @ AusMac Archive, Wiretapped.net, 2600 Australia
 www.ausmac.net   www.wiretapped.net   www.2600.org.au
-------------------------------------------------------

On Fri, 11 Feb 2000 richard@auscoms.com.au wrote:

> The first advisories about the two tools involved, trin00 and
TribeFloodNetwork,
> went out last year. It was given the "no story" treatment because nobody had
> been attacked. 
> 
> The advisories weren't hidden away on hacker-only sites. Some of them were
from
> security companies like PacketStorm, there was stuff on CERT, there was stuff
> released by the FBI last year. By January, the Tribe Flood tool had been
around
> long enough to spawn progeny based on its code. 
> 
> Seems to me that publicly listed companies should be disclosing the state of
> their security defences, especially when they're dotcoms.