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

bas kilobit at gmail.com
Sun Aug 8 15:47:29 EDT 2010


Hi,

On Sun, Aug 8, 2010 at 10:58 AM, Dobbins, Roland <rdobbins at arbor.net> wrote:
>
> 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.

I ran the "tool" synk4 for 100 seconds against a test target.
It generated 8.000.000 syn packets with random generated spoofed
source addresses.
Out of those 8.000.000 only 50 source addresses occurred twice and
only 9 occurred three times.
So both ACL and S/RTBH would have had zero effect.
If I had kept the tool running for an hour it would probably have
caused a network with S/RTBH to drop packets from >200.000.000
Internet addresses. And now imagine if I were a bad guy that has
control over 50 compromised servers in networks that do not filter
outbound spoofed traffic.

Nearly 25% (estimated) of all ASN's allow spoofed traffic so it it a
real threat. (ref. http://spoofer.csail.mit.edu/summary.php)

> 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.

I agree completely, however imho it



More information about the cisco-nsp mailing list