[nsp-sec] CloudFlare DDoS

[Hank Nussbacher]

On Mon, 25 Mar 2013, Eric Ziegast wrote:

> ----------- nsp-security Confidential --------
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm posting this on behalf of Jamie Tomasello at CLoudFlare,
> <jamie at cloudflare.com>.  You may use the information internally for
> network investigation and mitigation and discuss on the list, but not
> forward any information to third parties or other mailing lists.
>
>
> As you may have read in the news or blogs, SpamHaus came under a DDoS
> and as one of the few large DDoS mitigation providers, Cloudflare
> stepped in to help.  CludFlare is used to handling 30-100bps DDoS
> attacks, and for a while, it was looking good:  http://ars.to/Yca4bG .
>
> The attacks have grown to 300Gbps or more, and have moved beyond
> CloudFlare's anycast infrastructure to routing resources at exchange
> points and upstream providers.  The DDoS method is DNS amplification
> using both authority nameserver and open recursive nameservers.
>
> Please coordinate with CloudFlare (jamie at cloudflare.com) before
> acting independently with law enforcement.
>
> The attack is on and off.  You may see only 1-10Gbps, and it may not
> be setting your network on fire, but it does add up.
>
> The following would be helpful steps for network operators to take:
>
> 1) Inspect any telemetry for traffic SOURCED from:
>
>   195.66.224.0/22 (or more specifically 195.66.225.179)
>   202.40.160.0/23 (or more specifically 202.40.160.246)

Perhaps Team Cymru could add these to the DDOS-RS so that dozens of ISPs 
amd ASN would be auto-filtering?

Thanks,
Hank

>
>   Look to see where this traffic is entering your network and
>   coordinate.  If you can email or cc jamie at cloudflare.com,
>   that would be helpful.
>
> 1b) Filter it.
>
>
> 2) Filter at their borders any traffic destined to IXP Networks:
>
>   AMS-IX 195.69.144.0/22
>   DE-CIX 80.81.192.0/22
>   Equinix HK: 119.27.63.0/24
>   Equinix Paris: 195.42.144.0/24
>   Equinix Singapore: 202.79.197.0/24
>   Equinix Sydney: 202.167.228.0/24
>   Equinix Tokyo: 203.190.230.0/24
>   HKIX: 202.40.160.0/23
>   LINX Juniper: 195.66.224.0/22
>   LINX Extreme: 195.66.236.0/22
>   NOTA: 198.32.124.0/23
>
> The second one is best practices.  If you're at an exchange point,
> only your routers should be talking to the other routers across the
> exchange.  Your customers and peers shouldn't really be able to route
> traffic through your network to reach the exchange addresses directly.
>
> - --
> Eric Ziegast
> ziegast at isc.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
>
> iEYEARECAAYFAlFQ29cACgkQzQiY1gvQ1X2hzQCeKHlriUymvkco4HkWmZE+ovbQ
> R9wAoLL7JJUqVEkteHOIln/WSjExIHXH
> =4DzN
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> 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.
> _______________________________________________
>