[nsp-sec] Persistent and escalating DDoS against the Norwegian academic library system provider

[Smith, Donald]

Yea what he said:)
Transit acls blocking udp:1900 towards udp:80 would help a lot.
TACLS blocking src udp:1900 towards their cidr block is probably better as original spoofed src port changes (we see lots of spoofed src ports in these attacks udp:80 is the most common but not only src port being spoofed!)
53, 443, ... the list is big but udp:80 does seem to be the most common. I still wouldn't block based on that except in emergency.

Flow-spec can be used to deploy the TACLs but isn't required just ONE method to deploy the acls.

This is EXACTLY the kind of attack I think we should address with ddos peering (inter ASN flow-spec like mitigations) as I have no desire to carry Gigs of attack traffic across my network to deliver to your upstreams only to have you filter it somewhere. I would rather filter it on my network.
We tested flow-spec with our current systems and can do something like 100K rules without impact to the forwarding capacity. But again flow-spec is just the deliver method we could do that many TACLS regardless of deliver method!




(coffee != sleep) & (!coffee == sleep)
 Donald.Smith at centurylink.com



From: nsp-security [nsp-security-bounces at puck.nether.net] on behalf of Roland Dobbins [rdobbins at arbor.net]
Sent: Wednesday, April 08, 2015 3:54 AM
To: nsp-security at puck.nether.net
Subject: Re: [nsp-sec] Persistent and escalating DDoS against the Norwegian academic library system provider


----------- nsp-security Confidential --------


On 8 Apr 2015, at 16:26, Rune Sydskjor wrote:

> Even more rate limiting against 129.241.16.62

Aggregate rate-limiting during an attack is the worst thing you can do -
it simply ensures that the programmatically-generated attack traffic
crowds out the legitimate traffic.

Putting some basic tACLs in place based on the protocols/ports actually
being used will keep out-of-policy stuff like the SSDP off the site.

Since what you're describing doesn't involve spoofed sources at the
target end, posting a list of source IPs by ASN would be helpful.

For the layer-7 stuff, start with a reverse-proxy farm in front of the
Web servers, and some log analysis to block traffic easily identified as
illegitimate.

For the more complex stuff, there are commercial solutions/services
which can be used to deal with that [full disclosure, I'm employed by a
vendor of such solutions].

But if you start with the above, you'll be able to deal with the bulk of
the attack traffic, which will make things easier.

Have a look at the recommendations in this preso:

<https://app.box.com/s/r7an1moswtc7ce58f8gg>

Again, the key to getting assistance from other operators is to post
source IPs with ASNs for the non-spoofed traffic (from the target end;
i.e., the SSDP flooding and the http stuff).

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>


_______________________________________________
nsp-security mailing list
nsp-security at puck.nether.net
https://puck.nether.net/mailman/listinfo/nsp-security

Please do not Forward, CC, or BCC this E-mail outside of the nsp-security
community. Confidentiality is essential for effective Internet security counter-measures.
_______________________________________________
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.