[c-nsp] Nice EEM applet to protect against certain DDoS situations (sup720)

Dobbins, Roland rdobbins at arbor.net
Sun Aug 8 04:58:03 EDT 2010


On Aug 8, 2010, at 3:25 PM, bas wrote:

> ACL's are manual and not dynamic when we need them. Also ACL's do not
> scale with many (spoofed) source addresses.

Understood, but they don't complete the DDoS for the attacker, unless one is forced to resort to ACLing off the target.  Even then, doing so has no control-plane consequences on hardware-based platforms, so long as ACLs are kept within platform-specific scaling limits.

> 
> S/RTBH does prevent high CPU, but there are a two deal-breakers.
> 1. When source addresses are dropped at the network edge, and the
> attacker uses spoofed source addresses there will be a lot of
> colateral damage when traffic of "real" users, whose IP addresses are
> spoofed, is dropped.

This is where the concept of partial service recovery comes into play; the idea is that being up for any percentage of legitimate users is a 100% improvement over being completely down for all users, as is the case when the defender takes the target offline and completes the DDoS for the attacker.


> 2. Our (dedicated server) customers receive quite a lot of SYN floods.
> There are days that there might be 20 or more. Most of these SYN
> floods are only a couple of mbit/s and do not hurt the network or
> other customers. We do not want to interfere in case the server admin
> battles the SYN floods themselves.

Understood, you take action when a) the customer requests it or b) collateral damage mandates it.  S/RTBH can be a useful tool to have in the toolkit in such circumstances.

> IDMS heh.. I didn't know that acronym.  It seems it is an Arbor concoction?

There's a need for some generic term (like IDS, 'IPS', and so forth) to denote the overall class of devices which perform various forms of traffic interaction in order to defend against DDoS attacks, so Intelligent DDoS Mitigation System (IDMS) seems a logical way to describe them, IMHO.  

Anyways, if folks haven't done so already, they may wish to consider implementing S/RTBH so that they have it in their toolkits when needed.  It's a useful way to leverage existing hardware and gain some more functionality during times of stress.

And best of all, no additional capex is required, just a bit of elbow-grease (aka opex)!

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

    Injustice is relatively easy to bear; what stings is justice.

                        -- H.L. Mencken






More information about the cisco-nsp mailing list