Bugtraq mailing list archives

Re: A DDOS proposal.


From: dr () DURSEC COM (Dragos Ruiu)
Date: Sat, 12 Feb 2000 01:10:58 -0800


Thank you all for your kind comments, offers of help and input about my
attack signalling system proposal. Here are some comments to the comments:

Re: In-band vs. Out of band signalling

In our tests so far, though we've found some pretty devastating attacks, none
of the host targeted attacks has succeeded in producing 100% saturation/failure
to the point where an outbound connection with some determined re-try and
process priority could be completely defeated.  My hypothesis at this point is
that an in band notification or signalling that would survive DoS could be
built. If not with TCP certainly with an aggressive UDP re-transmitter. You
will likely be able to squeak out that alarm packet eventually (even with TCP I
think). If anyone has some evidence to contradict this I would love to hear
about it. I estimate that out-of-band signalling is -very- expensive
(perhaps prohibitively). Let's save that for the big e-commerce sites.

Having avoided the temptation (:-) to take out a whole bunch of systems and
try a test with a massive number of nodes our tests have been limited to the
small number (<10) of links we could cobble up with our employee's home
cablemodem/adsl links and other scrounged systems and T1's from friends, but
there seemed to be little effect difference as we increased the number of
nodes.  DDOS seems to be a bandwidth game, and he/she with the most bandwidth
wins.  If some people would like to volunteer to set up a massive number of
systems in a testbed, we're game. We can even play target, but I may have to
talk to my ISPs and warn them. :-) C'mon, this is way more fun than Seti@Home.

Re: DoS the victim and the relay Defenders simultaneously

One of the theoretical side effects of this "Defender" system is that there
will be a big bull's eye painted on the Defender node - they will likely
become a target of choice so that you can get past them and do some mischief.
This is both good and bad, good because the obvious target can be fortified and
watched appropriately, bad because it's, well.... a target.  However DoSing the
Defender will hardly qualify as a stealth maneouver... when you see all that
traffic to it you will pretty much know that -something- is going down. (And
you -should- be watching.) I would be worried much more about the stealthy
clean up the complaints penetration.

Re: AI-driven attack sensing

There are a huge number of ways to wire this into advanced IDSes and the like.
I think there will be a lot of vendors who may wish to differentiate themselves
or improve their features in this way.  I was only proposing a rudimentary human
operated triggering - you'd think that only server operators would care enough
about ddos and uptime to go to the trouble of getting themselves wired into
such a system at first. I'm sure there will be lots of other clever ideas here.

Re: Coding trivial

I didn't mean to downplay the difficulty of really securing an app. But the
effort here still seems dwarfed to the policy and political issues to be
overcome to make this work. A prototype is not a long reach, I maintain.

Re: InterNIC whois as a contact instead.

First of all, for small companies they might work, but I've -tried- on many
occasions with more mundane portscans and attacks to contact operators of
servers attacking us to warn them about potential compromises.  My success rate
is less than 10%.  And you would be surprised at the number of sites that are
seemingly unreachable by telephone (even some big ones). Then let's consider the
language and geography issues of attacks from different countries....

Another issue if you get attacked by forlorn.subgroup.megacorp.com and you
contact the whois for megacorp.com in likely a different city is that it may
take you a long time to reach the operator of the attack system - if you can
at all (sysadmins for large companies seem to have developed the best telephone
call avoidance technologies around :-).

The other point here is that the ISPs Defender daemon would be able to contact
many sites en-masse (this is for -distributed- attacks) if the other ISPs have a
server listening for such requests. When was the last time you tried to contact
100 server operators nevermind 1000? (Guys from Yahoo need not answer. :-)
The idea is to distribute the contact work to the ISPs responsible rather than
saddling the victim with the burden as we do now.

When I used to chase down attacks on our servers to warn sysops (I don't
anymore, declaring it futile), it would take me on the average of a day per
system if it worked, and I used to time out on it after more than a day - which
led to the abysmal success rate. Normally it would take at least four phone
calls before you got to someone who understood what you were talking about.
Maybe things are better now with all this DDOS visibility, but I doubt it.

Re: RTBL and blocking

Yes, some extension may be feasible.... but the issue here is not some
voluntary opt in filtering, but squelching and securing the origin of the
attacks.  Say I took over an address numerically just below ddos poster
child yahoo's dns server and another just above it and installed my favorite
super-nasty ddos tools. Most current filtering facilities would likely have to
block out a whole range of addresses due to limits in the number of filters
runnable with reasonable performance, thereby making yahoo unreachable to your
users as well, sandwiched between those addresses.  One of the points of my
proposal was to avoid blocking by going to a root of the attack - the
vulnerable attack relays - and notifiying their ISPs automatically.

Then further you have to provide some incentive for them to care about
their security - another surprise to me was how often I contacted sysadmins who
really couldn't care less that their box was broken into and attacking my
system as long as their app was still running,  or,  even more frequently, who
didn't believe the info or understand attack technology. Hopefully with my
proposal, their ISP upon receiving complaints about the user, will be able to
have some leverage on the user - otherwise one bad apple who doesn't care about
security could get a whole address range blocked off, in a way giving another
kind of DoS attack as that entire ISPs customer base may be made unreachable
to/from a chunk of the net.  Without some notification system, the ISP will
never know the attack happened and that they are being blocked - to them it
will look like a whole chunk of the net that is filtering them went
mysteriously 404. (The revenue loss implications of blocked customers are large
for e-commerce.)  Blocking and filtering by itself will make the already flaky
net more so.

IMHO Though I do think an RTBL-like or derived blocking solution would be a good
incentive generator for ISPs that would choose to ignore hypothetical inbound
Defender complaints from other net users, it doesn't strike me as a good
solution in general. And there will always be a few ISPs that ignore the
guidelines is my bet - for evidence I point to the difficulties of getting
routing BGP announcements to follow guidelines and the always-needed NANOG
tutorials. I doubt that we will ever completely mitigate DDOS - the best we
can hope for is to dramatically reduce the ridiculous ease with which it can be
done today. (Make'em work for their hack I say. They have it so easy now. Why
when I used to have to walk through two miles of snow to hack on a 110 baud
teletype...:-) Unfortunately, I surmise this will require the tough road of
securing the obvious targets that will get taken over the most and do the most
damage. It would be interesting to see what wins the gets hacked the most
award....

Unless someone finds the magic silver bullet on this one, it's not pretty, but I
would still suggest we roll up our sleeves and start getting to it. Sigh....

Again, thank you all for the valuable feedback,
--dr

--
dursec.com / kyx.net - we're from the future                      http://www.dursec.com
learn kanga-foo from security experts: CanSecWest - April 19-21 Vancouver

Speakers: Ron Gula/NSW, Ken Williams/E&Y, Marty Roesch/Hiverworld, Fyodor/insecure.org,
          RainForestPuppy/wiretrip.net, Theo de Raadt/OpenBSD, Max Vision/whitehats.com

p.s. I really did walk through two miles of snow to use a 110 baud teletype for a while. :-)



Current thread: