Re: Is there a line of defense against Distributed Reflective attacks?
In message <20030117062954.GK61038@lcs.mit.edu>, "David G. Andersen" writes:
On Fri, Jan 17, 2003 at 01:11:14AM -0500, David G. Andersen mooed:
b) Ioannidis and Bellovin proposed a mechanism called "Pushback" for automatically establishing router-based rate limits to staunch packet flows during DoS attacks. [NDSS 2002, "Implementing Pushback: Router-Based Defense Against DDoS Attacks"]
I should have been a bit more accurate here. The proposal for pushback is actually earlier than the implementation paper I cited above:
"Controlling High Bandwidth Aggregates in the Network. Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John Ioannidis, Vern Paxson, and Scott Shenker. July, 2001."
and it also included an internet-draft:
http://www.aciri.org/floyd/papers/draft-floyd-pushback-messages-00.txt
I believe that Steve Bellovin gave a talk about it at NANOG 21:
Here are the citations to the published papers: # Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John Ioannidis, Vern Paxson, and Scott Shenker, Controlling High Bandwidth Aggregates in the Network, Computer Communications Review 32:3, July 2002, pp. 62-73. http://www.research.att.com/~smb/papers/pushback-CCR.ps # John Ioannidis and Steven M. Bellovin, "Implementing Pushback: Router-Based Defense Against DDoS Attacks", NDSS, February 2002. http://www.research.att.com/~smb/papers/pushback-impl.ps The publication dates notwithstanding, Mahajan et al. came first. As for the I-D -- we haven't had the cycles to work on it. There's reason to hope that activity will pick up. Re: I'm not sure its all that practical. I don't see that its helpful if it turns off services 'automatically' In theory, it doesn't turn off the service to all comers; it turns off the service along pipes from which the attack is coming. Just how good a job it will do at stopping collateral damage will depend on how far back there are pushback-enabled routers. If an ISP deployed it, but didn't speak pushback to its neighbors, clients on that same ISP's network should be able to access the service, as could peers who weren't the source of the garbage. But if some peer is sending an OC-12's worth of DDoS packets -- yes, all clients (or transit users) of that peer would be shut out. ICMP traceback is the subject of the IETF itrace working group. draft-ietf-itrace-03.txt just came out yesterday. The SPIE hash-based traceback is a much cooler idea, but it has some practical limitations, including the need to do the trace in more or less real-time (once the hash table fills up, it becomes useless), and the need for very large amounts of very fast memory on the tracing routers. There was an IETF BoF on it, but the folks behind it haven't been pushing it much. (Randy, do you know the status of it?) Both itrace and hash-based trace have some technical issues. itrace can handle only DoS-type attacks, since it's statistical in nature; hash-based traceback can, in theory, trace a single packet. But the real problem with either idea is this: suppose that you know, unambiguously and unequivocally, that 750 zombies are attacking you. What do you do with that information? --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)
On Sat, 18 Jan 2003, Steven M. Bellovin wrote:
theory, trace a single packet. But the real problem with either idea is this: suppose that you know, unambiguously and unequivocally, that 750 zombies are attacking you. What do you do with that information?
The reality is its not 750 zombies, its generally one person controlling 750 zombies attacking you. The firefighter approach is not a complete solution. Putting out the fire is only part of the answer. You also need to stop the arsonist from setting more fires and improve the building codes to reduce the risk. We need to do more than just waiting for complaints and putting in more and more null routes all over the network. On the other hand, ingress filtering is not a complete solution either. There are some things some networks can do easier than other networks. But there isn't just one fix which will work for everyone, or which will solve the problem. Null routes alone didn't solve the spam problem, and I doubt it will solve the DDOS problem. So how do we 1) Make end-user systems less vulnerable to being compromised 2) Track and stop DDOS quickly when it does happen 3) Find and convict the true attacker
SD> Date: Sat, 18 Jan 2003 21:22:14 -0500 (EST) SD> From: Sean Donelan SD> 1) Make end-user systems less vulnerable to being compromised With consumers, "cheap and easy" usually wins. More often than not, I hear "I don't care if someone breaks into my computer or my email, because I don't have anything private". One of our customers knowingly had the ILOVEYOU virus for I can't remember how many months. (Gotta love the rejected mail logs on _that_ one.) With essentially one desktop OS, there's not a huge amount of pressure to make a better product. How many known bugs were in the fraction of Windows source code involved in the antitrust case? My memory fades, but it seems code quality in the most popular OS is not the highest priority. SD> 2) Track and stop DDOS quickly when it does happen Is it TCP/80 DDoS, or did you just get slashdotted? (I suppose that goes along with #3, below.) SD> 3) Find and convict the true attacker IOW, find the "magic packet" someone used to bring 10,000 zombies to life. Question: Just how often do people need end-to-end IP traffic? I'm not suggesting blocking it; that would be bad. But look at AOL's proxied Web and email service... most people are none the wiser. Perhaps end-to-end traffic should be blocked at the edge until <???>. And, oh yeah, "shut off the malicious and clueless" has worked just great for stopping spam, hasn't it? As Chris Morrow and others so often and aptly mention -- technical problem or social malady? Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
participants (3)
-
E.B. Dreger -
Sean Donelan -
Steven M. Bellovin