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
This archive was generated by hypermail 2b30 : Tue Jul 03 2001 - 06:48:00 PDT