Proactive steps to prevent DDOS?

Mailman List Mirror (Read Only)
1

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?

2

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.