Re: Proactive steps to prevent DDOS?
So which one of those things do you think any of the victims wasn't doing before, and how will the steps now prevent a future DDOS attack from affecting its servers? If the victims had done all of these things before they were attacked, would it have prevented the attack from affecting their service? Those aren't just rhetorical questions, I'm trying to understand how to approach this. If you view DDOS as a traffic surge, can we use any lessons from other phenomenon involving surges, such as vehicle traffic at rush hour, water runoff from a storm, lightning strike. You can't control the weather, but you can do a lot to mitigate the damages. Methods for handling surges: - Limit the source (e.g. metering lights on freeways) - Divert the surge (e.g. lightning arresters on electric circuits) - Buffer the surge (e.g. detention basins for water runoff) How can we signal uncooperative sources to limit or even cease sending traffic? Preferablly without impacting cooperative sources. Historically, the "nice guys" traffic gets throttled, while the "bad guys" traffic blasts through. If you don't get enough tokens or credits, you don't send. RED and friends work with cooperative sources. How can we identify and drop the excess traffic at the earliest point? Should it be a cascaded system, i.e. you have several stages instead of one big muttha firewall. Do you really want to carry the traffic across the entire Internet, just to drop it on the last link? How can we size the protective systems and the final system so we won't overrun their available resources (requires knowing how large the resources actually are)? Is there anyway to mitigate the slashdot effect for small sites as well as large sites? Larges sites can throw more capacity at the problem to buffer the surge. Its been at least a week since someone suggested putting a bad idea into DNS. How about using the inability to reach the DNS server to rate limit the sources. Every once in a while, the IP stack (protocol layer violation) queries the in-addr.arpa servers for the destination network. The in-addr.arpa servers respond with additional credits, or zero credits (source quench), or don't respond signalling the source to switch to a conservative transmission mode. If you don't trust the end-to-end system to respond to the signals, the upstream edge router could enforce it. Is that idea horrendous enough? On Sat, 27 January 2001, Jeff Ogden wrote:
At 4:15 PM -0800 1/26/01, Sean Donelan wrote: Fine, does this work better for you?
Help me, what proactive steps can I take to protect my network from a DDOS?
There isn't a lot that can be done, but there are a few steps you can take to "get ready" for a DDOS attack.
--Make sure you have monitoring of your routers or firewalls in place so you'll get an early alert of a possible DOS attack. This will at least allow you to start working on the problem (and drafting press releases :-).
--Talk to all of your up stream providers so you know how to contact and work with them if they are a source of a DOS attack against you. If your up stream provider isn't willing to work with you on this, start the process of getting a new up stream provider.
--Look into the systems that are being developed and starting to become available that help automate the work to diagnose DDOS attacks. Encourage your up streams to do the same.
--Make sure you have in place the filtering on your own networks that you wish everyone else had in place on their networks. This won't protect you from being attacked, but it will prevent you and your users from attacking others (or at least using spoofed IP addresses to do so), and that in turn may prevent you from being the target of a retaliatory DOS attack. It can also prevent or limit the spread of a DOS attack that originates within your network or from someone down stream. From your customer's point of view there may not be much difference between you being the source of or the target of a DOS attack--either way performance is likely to be poor and customers are likely to be unhappy.
-Jeff Ogden Merit
Sean, The first step is effective emergency response. I have seen hours pass as secret handshakes and people on the "right list" were located and made the right calls. People start their generators on a planned basis to make sure they work. How many people practice DDOS attack recovery? It's something you can actually do today that will help the most in a real attack. This is a malicious attack designed to cause failure, so I think that any measures of the style discussed will only save you from the small attacks. Not that avoiding some attacks isn't good, it's just not much help in the general case. I think the issue of malice makes it very hard to plan for like storm water or freeway traffic. I have no proof to say that large sites fare better than small ones. They can handle more, but attract much more serious attacks with much more glory for the perpetrators. Many people are pinning their hopes on traffic flow tagging as the way to manage/solve this in the long term. No one knows yet when it can be deployed in a large enough scale to work and what it will take then to handle it. I'm hoping you realize the spectacular failure mode of your DNS propose. You DOS the DNS in-addr servers and the whole site goes away. That should take a lot less traffic than swamping the pipes. DNS has enouh problems digesting all the things it's trying to do now (DNSSEC, v6, large packets...), no need to make it worse. jerry
So which one of those things do you think any of the victims wasn't doing before, and how will the steps now prevent a future DDOS attack from affecting its servers? If the victims had done all of these things before they were attacked, would it have prevented the attack from affecting their service?
Those aren't just rhetorical questions, I'm trying to understand how to approach this.
If you view DDOS as a traffic surge, can we use any lessons from other phenomenon involving surges, such as vehicle traffic at rush hour, water runoff from a storm, lightning strike.
I wonder if viewing it as a surge or natural phenomenon is really the right way, or whether using an electronic warfare model is more appropriate. I'm not current in ECM and ECCM methods, but there seem some parallels -- not a complete one -- between being hit by bistatic or multistatic radar illuminators, and by being hit by DDoS. Remember that stealth isn't a matter of being invisible, but, above all, preventing fire control radar from locking on a target. The more intelligent the DDoS attack, the more likely it is to be adaptive. Radar trackbreakers don't necessarily overpower the emitter, but confuse it. Hypothetically, if we have a clue which sources are sending the attack, giving them the impression they are succeeding may cause them to go elsewhere, or not add more phantoms.
participants (3)
-
Howard C. Berkowitz -
Jerry Scharf -
Sean Donelan