Re: Why would someone DoS a free-lance writer?

[gabriel rosenkoetter <gr () eclipsed net>]

On Mon, Jul 02, 2001 at 04:39:22PM +0200, Markus Kern wrote:
> The only traffic you get after closing Gnutella are 
> TCP SYN packets from clients trying to open a new connection.
> Looking at the few connection attemps I get on my ISDN line
> when running Gnutella I doubt that this could DoS anything.

Well, seeing as it significantly slows down my 128 up/384 down ADSL
connection at least wrt latency (my ssh'ing to machines elsewhere),
I'm not convinced it has *no* effect on your ISDN.

Does the fact that the client in question is actually "gnut" on a
RedHat 7.1 machine make any difference?

(I think I've seen similar results with gtk-gnutella on my
NetBSD/i386 1.5-current machine, but I don't use gnutella all that
much, so...)

> You wouldn't even have to make the target run Gnutella. It's trivial 
> to inject arbitrary IPs into the Gnutella network. Besides that, if 
> you can get someone to run Gnutella you can make them run a trojaned
> version too.

Both entirely valid points. :^>

> The only posibility I can think of to prevent this kind of DoS 
> (DDoS actually) would be to attach some sort of timeout value to the
> IP and pass it along from client to client and drop the IP when it
> gets too old. This would involve having the internal timers of the 
> clients synced somehow though.

No it wouldn't. It would require implementing a sane TTL system the
same way DNS does. Only cache a given host's IP as available for as
long as it claims you should expect it to be available (based on
when you *receive* the IP), then check with it again before continuing
to redistribute its IP address. The default value probably ought
to be a couple of hours.

Folks that know they're going to run a gnutella "server" (yes, yes,
I know, everything's a "peer"...  whatever) for an extended period
of time can kick this value up to keep from wasting everyone's time
with the double-checks. People who regularly jump on gnutella to
find one file then bail again and don't want to lose bandwidth to
all the SYNs can knock this value down. (Yes, this means that the
latter case still will have to drop some packets, but not so many
as if the fanout was allowed to proceed further after the TTL would
have timed out.)

I don't think that's asking for too much.

On the other hand, neither of these systems does a damn thing for
the "inject fake IPs" DDoS. I've got no bright ideas on how to deal
with that without requiring, say, IPSec authentication of your
gnutella peers (kind of defeats at least part of the purpose, no?).

-- 
       ~ g r @ eclipsed.net


----------------------------------------------------------------------------


This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see:

http://aris.securityfocus.com