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. :-)
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:35:01 PDT