In message <1C2F65D3-1E71-4C08-9A05-BA6536FDBF40@puck.nether.net>, Jared Mauch writes:

On Aug 2, 2013, at 10:38 AM, "Patrick W. Gilmore" <patrick@ianai.net> wrote:

...

On Aug 02, 2013, at 09:37 , sgraun@airstreamcomm.net wrote:

...

I'm curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. Are you completely reactive and block as many addresses as possible or null0 traffic to the effected host until it stops or do you block certain ports to prevent them. What's the best way people are dealing with them?

#1: Ensure your network is BCP38 compliant.

Hard to complain about others attacking you when you are not clear. And if you do not block source-address spoofing, you are not clean.

As for the rest, I'll let others with more recent experience explain what they do.

We have had challenges with deploying BCP38, even on simple connections. We have outstanding defects in IOS-XR that prevent us from deploying it.

Wherever possible we have enabled source address validation (bcp38). I do have a map of some networks that don't do this as a result of the OpenResolverProject.org data.

Here's some top ASNs that can send spoofed packets:

Count ASN --------------- 1006 18747 1004 262824 877 196753 522 29119 516 5617 514 34977 513 47570 513 12615 512 262336 512 12301 372 6739

These ASNs spoof my machine I use to send queries out to 8.8.8.8 and goole responds back to me.

Likely some firewall/CPE/NAT that does this, but the provider lets those spoofed packets reach outside their network to google.

I have many more of these if folks want to see a broader list.

If you look at the ASN relationships involved here, it means either 3491 or 3257 allows these spoofed packets from 18747.

- Jared

Please publish the full list. It is long past the time when operators should be filtering out spoofed source address traffic. This sort of data should be refreshed and published quarterly. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Can anyone recommend a vendor solution for DDOS mitigation? We are looking for a solution that detects DDOS attacks from sflow information and automatically announces BGP /32 blackhole routes to our upstream providers, or a similar solution. Thank You. On 08/05/13 21:09 +1000, Ahad Aboss wrote:

Scott,

Use a DDOS detection and mitigation system with DPI capabilities to deal with traditional DDOS attack and anomalous behaviour such as worm propagation, botnet attacks and malicious subscriber activity such as flooding and probing. There are only a few vendors who successfully play in this space who provide a self healing/self defending system.

Cheers Ahad -----Original Message----- From: sgraun@airstreamcomm.net [mailto:sgraun@airstreamcomm.net] Sent: Friday, 2 August 2013 11:37 PM To: nanog@nanog.org Subject: ddos attacks

I’m curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. Are you completely reactive and block as many addresses as possible or null0 traffic to the effected host until it stops or do you block certain ports to prevent them. What’s the best way people are dealing with them?

Scott

-- Dan White

Dan, If you are using sFlow for your measurements, then you might want to take a look sFlow-RT for DDoS mitigation. The following case study describes how sFlow and null routing are being used to mitigate flood attacks: http://blog.sflow.com/2013/03/ddos.html The analytics engine will detect flood attacks in less than a second and you can use the embedded scripting API to initiate automated responses. The following articles contain basic DDoS mitigation scripts - you just need to replace the block() and allow() functions with calls to expect scripts, OpenFlow rules, or REST API calls - whatever makes sense in your environment. http://blog.sflow.com/search/label/DoS This is a commercial product, but it's free to try out (no registration required): http://inmon.com/products/sFlow-RT.php Cheers, Peter On Wed, Dec 18, 2013 at 8:36 AM, Dan White <dwhite@olp.net> wrote:

Can anyone recommend a vendor solution for DDOS mitigation? We are looking for a solution that detects DDOS attacks from sflow information and automatically announces BGP /32 blackhole routes to our upstream providers, or a similar solution.

Thank You.

On 08/05/13 21:09 +1000, Ahad Aboss wrote:

...

Scott,

Use a DDOS detection and mitigation system with DPI capabilities to deal with traditional DDOS attack and anomalous behaviour such as worm propagation, botnet attacks and malicious subscriber activity such as flooding and probing. There are only a few vendors who successfully play in this space who provide a self healing/self defending system.

Cheers Ahad -----Original Message----- From: sgraun@airstreamcomm.net [mailto:sgraun@airstreamcomm.net] Sent: Friday, 2 August 2013 11:37 PM To: nanog@nanog.org Subject: ddos attacks

I’m curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. Are you completely reactive and block as many addresses as possible or null0 traffic to the effected host until it stops or do you block certain ports to prevent them. What’s the best way people are dealing with them?

Scott

-- Dan White

On Wed, 18 Dec 2013 15:12:28 -0800, "cb.list6" said:

I am strongly considering having my upstreams to simply rate limit ipv4 UDP. It is the simplest solution that is proactive.

What are the prospects for ipv6 UDP not suffering the same fate?

Dear All We have been using NSFOCUS Anti DDoS hardware both locally within Australia and Internationally for the past 12 months and have been very happy with the platform capabilities and the support provided by their support engineers. For more information have a read on their website ! http://www.nsfocus.com/en/index.html I would highly recommend looking at their ADS, ADS-m and NTA hardware product lines which as a combination provides a complete automatic platform with monitoring, detection and surgical cleaning of Layer 4/7 IPv4 and IPv6 traffic including providing a client platform ! Of course for any form of Anti DDoS hardware to be functional you need to make sure your network can route and pass the traffic so you can absorb the bad traffic to give you a chance cleaning the traffic. Kindest Regards James Braunegg P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 E: james.braunegg@micron21.com<mailto:james.braunegg@micron21.com> | ABN: 12 109 977 666 W: www.micron21.com/ddos-protection<http://www.micron21.com/ddos-protection> T: @micron21 [Description: Description: Description: Description: M21.jpg] This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. -----Original Message----- From: Jon Lewis [mailto:jlewis@lewis.org] Sent: Thursday, December 19, 2013 12:04 PM To: Valdis.Kletnieks@vt.edu Cc: nanog@nanog.org Subject: Re: ddos attacks On Wed, 18 Dec 2013 Valdis.Kletnieks@vt.edu wrote:

On Wed, 18 Dec 2013 15:12:28 -0800, "cb.list6" said:

...

I am strongly considering having my upstreams to simply rate limit ipv4

...

UDP. It is the simplest solution that is proactive.

What are the prospects for ipv6 UDP not suffering the same fate?

Roughly 0%, but there's so little v6 traffic compared to v4, you probably don't have to worry about v6 attack traffic yet...particularly if you're not dual stack yet. :) ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

Hi, You can also take a look at http://www.packetdam.com/ for DDoS protection. Eugeniu On Thu, Dec 19, 2013 at 10:53 AM, Tore Anderson <tore@fud.no> wrote:

* James Braunegg

...

Of course for any form of Anti DDoS hardware to be functional you need to make sure your network can route and pass the traffic so you can absorb the bad traffic to give you a chance cleaning the traffic.

So in order for an Anti-DDoS appliance to be functional the network needs to be able to withstand the DDoS on its own. How terribly useful.

Tore

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm really surprised no one has mentioned Akamai/Prolexic, especially since their recent marriage. If someone has already mentioned it: Apologies. - - ferg On 12/19/2013 4:08 AM, Adrian M wrote:

Hi,

You can also test WANGUARD, http://www.andrisoft.com/ for DDoS detection and BGP triggered blackholing.

On Thu, Dec 19, 2013 at 11:32 AM, Eugeniu Patrascu <eugen@imacandi.net>wrote:

...

Hi,

You can also take a look at http://www.packetdam.com/ for DDoS protection.

Eugeniu

On Thu, Dec 19, 2013 at 10:53 AM, Tore Anderson <tore@fud.no> wrote:

...

* James Braunegg

...

Of course for any form of Anti DDoS hardware to be functional you need to make sure your network can route and pass the traffic so you can absorb the bad traffic to give you a chance cleaning the traffic.

So in order for an Anti-DDoS appliance to be functional the network needs to be able to withstand the DDoS on its own. How terribly useful.

Tore

-----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSs0qFq1pz9mNUZTMRAlHzAJ4snDXa9MSpzSAniMUKcea0L521jQCgxHLH gBUm4ScmJlf5FsC5kJJrmZs= =tLUd -----END PGP SIGNATURE----- -- Paul Ferguson PGP Public Key ID: 0x63546533

On 19/12/2013 13:17, Dobbins, Roland wrote:

This is a base requirement for any network operator, without exception.

in fact, this comes down to cost / benefit / application analysis, without exception. Many hosting profiles don't require this sort of anti-DDoS kit. In many cases it's far cheaper to permanently disconnect a customer who is the subject of continual DoS's rather than fork out loadsamoney for boxes like this. For applications at the higher end of the spectrum, there are many situations where it's more cost effective / resilient / sensible to farm out online content to CDNs, whose infrastructure will be much better equipped to handle several tens of gigs of DDoS traffic than even a reasonably large deployment of local anti-ddos boxes. I'm sure mitigation boxes like this serve well in many situations if the cost / benefit justifies the expenditure, but as with most things, it's a case of applying the best tool for the job rather than blind application of shiny toys. Nick

On 19/12/2013 14:08, Dobbins, Roland wrote:

My post had nothing to do with 'anti-DDoS kit'.

hmm, re-reading it, your post was contextually ambiguous and I read it in a different way to the way that apparently you meant. but yes, if you're doing onsite ddos scrubbing, you needs lotsabandwidth. Nick

* Dobbins, Roland

Once again, nothing in my post said or referred to bandwidth;

The post of mine, to which you replied, did. Perhaps if you had taken your own advice quoted below when replying to me, Nick wouldn't have been contextually confused. Tore

In future, it might be a good idea to ensure that the points one attempts to make actually apply to the specific post to which one is replying.

On Thu, 19 Dec 2013, Lee Howard wrote:

...

...

...

I am strongly considering having my upstreams to simply rate limit ipv4 UDP. It is the simplest solution that is proactive.

What are the prospects for ipv6 UDP not suffering the same fate?

Roughly 0%, but there's so little v6 traffic compared to v4, you probably don't have to worry about v6 attack traffic yet...particularly if you're not dual stack yet. :)

-1 uninsightful

Can't find any public data showing IPv6 as a percent of total bits, but it's certainly a meaningful percent of hits in many countries and networks.

See also http://tools.ietf.org/html/draft-gont-opsec-ipv6-implications-on-ipv4-nets- 00 which describes risks from IPv6 to people who think they are running an IPv4-only network.

Apparently your humor detector is defective. It was meant as a jab at the poor adoption of IPv6. I'd hope that most people on NANOG would know if they're actually doing any IPv6. I know there's more v6 where I am now, but at a previous employer, out of hundreds of hosting and colo customers, I think the ones who'd even asked about IPv6 could be counted on my fingÂers, and the ones actually doing v6 on one hand. AFAIK, my cable internet provider still isn't offering it...so if I wanted it at home, I'd have to tunnel someplace else. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

On Dec 18, 2013, at 18:12, cb.list6 wrote:

I am strongly considering having my upstreams to simply rate limit ipv4 UDP. It is the simplest solution that is proactive.

Recently it's been said that when a protocol is "query/response" (like DNS), willingly suppressing responses might be as harmful as passing all the traffic. This comes from a presentation at October's DNS-OARC workshop: https://indico.dns-oarc.net//getFile.py/access?contribId=4&resId=0&materialId=slides&confId=1 This is a "what is possible in theory" presentation, said to help you set your expectation whether this is a true threat or not. The underlying message is that while a querier is waiting for a response, there is a window of vulnerability in which a forged response might be accepted. If the responder elects not to respond, they increase the (time) duration of that window. While "smart" rate limiting exhibits benefits I suspect "simple" rate limiting might have some undesirable consequences. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Why is it that people who fear government monitoring of social media are surprised to learn that I avoid contributing to social media?

On Dec 19, 2013, at 6:12 AM, cb.list6 <cb.list6@gmail.com> wrote:

I am strongly considering having my upstreams to simply rate limit ipv4 UDP.

QoS is a very poor mechanism for remediating DDoS attacks. It ensures that programmatically-generated attack traffic will 'squeeze out' legitimate traffic.

During an attack, 100% of the attack traffic is ipv4 udp (dns, chargen, whatever).

Have you checked to see whether you and/or your customers have open DNS recursors, misconfigured CPE devices, etc. which can be used as reflectors/amplifiers on your respective networks? Have you implemented NetFlow and S/RTBH? Considered building a mitigation center? <http://mailman.nanog.org/pipermail/nanog/2010-January/016747.html> Do you work with your peers/upstreams/downstreams to mitigate DDoS attacks when they ingress your network? There are lots of things one can do to increase one's ability to detect, classify, traceback, and mitigate DDoS attacks, yet which aren't CAPEX-intensive. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

On Dec 20, 2013, at 4:39 AM, cb.list6 <cb.list6@gmail.com> wrote:

Not answering any of that. But thanks for asking.

I wasn't asking those questions in order to elicit information from you, but rather as food for thought as you work through these issues.

I think ipv4 udp is just going to become operationally deprecated. Too much pollution. It is really an epic amount of trash / value ratio in ipv4 udp.

This isn't a realistic viewpoint. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

On Dec 20, 2013, at 3:27 PM, Saku Ytti <saku@ytti.fi> wrote:

c) ACL/RPF in significant portion of access ports in whole world - i'm guessing significant portion of access ports are on autopilot with no one to change their configs, so probably not practical.

d) The current state of affairs persists, with no meaningful change in the foreseeable future, except the problem growing worse. My guess is that d) is the most likely outcome. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton