another option would be a service offered by https://www.neustar.biz/services/ddos-protection On Fri, Jan 9, 2015 at 10:41 AM, Pavel Odintsov <pavel.odintsov@gmail.com> wrote:

I could suggest Voxility.com because they have very good network and can defense any protocol.

And I can recommend qrator.net as best solution agains http/https attacks. We use they for 2 years and got only positive feedback.

And if you need only ability to reroute to antiddos cloud/blackhole specific IP you could try my open source tool FastNetMon: https://github.com/FastVPSEestiOu/fastnetmon

Thank you!

On Thu, Jan 8, 2015 at 8:11 PM, Mel Beckman <mel@beckman.org> wrote:

...

BlackLotus.com looks very good, with GRE tunneling and sensible provider level pricing.

-mel via cell

...

On Jan 8, 2015, at 9:06 AM, "Manuel Marín" <mmg@transtelco.net> wrote:

Nanog group

I was wondering what are are using for DDOS protection in your networks. We are currently evaluating different options (Arbor, Radware, NSFocus, RioRey) and I would like to know if someone is using the cloud based solutions/scrubbing centers like Imperva, Prolexic, etc and what are the advantages/disadvantages of using a cloud base vs an on-premise solution. It would be great if you can share your experience on this matter.

Thank you

-- Sincerely yours, Pavel Odintsov

-- Thanks, Amit.

While it indeed is true that attacks up to 600 gbit/s (If OVH and CloudFlare's data is to be believed) have been known to happen in the wild, it's very unlikely that you need to mitigate anything close. The average attack is usually around the 10g mark (That too barely) -- so even solutions that service up to 20g work alright. Obviously, concerns are different if you're an enterprise that's a DDoS magnet -- but for general service providers selling 'protected services,' food for thought. On 1/11/2015 午後 12:48, Damian Menscher wrote:

On Thu, Jan 8, 2015 at 9:01 AM, Manuel Marín <mmg@transtelco.net> wrote:

...

I was wondering what are are using for DDOS protection in your networks. We are currently evaluating different options (Arbor, Radware, NSFocus, RioRey) and I would like to know if someone is using the cloud based solutions/scrubbing centers like Imperva, Prolexic, etc and what are the advantages/disadvantages of using a cloud base vs an on-premise solution. It would be great if you can share your experience on this matter.

On-premise solutions are limited by your own bandwidth. Attacks have been publicly reported at 400Gbps, and are rumored to be even larger. If you don't have that much network to spare, then packet loss will occur upstream of your mitigation. Having a good relationship with your network provider(s) can help here, of course.

If you go with a cloud-based solution, be wary of their SLA. I've seen some claim 100% uptime (not believable) but of course no refund/credits for downtime. Another provider only provides 20Gbps protection, then will null-route the victim.

On Sat, Jan 10, 2015 at 4:19 PM, Charles N Wyble <charles@thefnf.org> wrote:

...

Also how are folks testing ddos protection? What lab gear,tools,methods are you using to determine effectiveness of the mitigation.

Live-fire is the cheapest approach (just requires some creative trolling) but if you want to control the "off" button, cloud VMs can be tailored to your needs. There are also legitimate companies that do network stress testing.

Keep in mind that you need to test against a variety of attacks, against all components in the critical path. Attackers aren't particularly methodical, but will still randomly discover any weaknesses you've overlooked.

Damian

Seeing a lot of SSDP too, but attacks on scales that large have been rare (at least for us). Have however seen a few 40+ ones, yeah. I suppose it all comes down to how much you actually /need/ to stand up against. For enterprises that can't afford to go down, yeah... :( On 1/11/2015 午後 01:50, Ammar Zuberi wrote:

I'd beg to differ on this one. The average attacks we're seeing are double that, around the 30-40g mark. Since NTP and SSDP amplification began, we've been seeing all kinds of large attacks.

Obviously, these can easily be blocked upstream to your network. Hibernia Networks blocks them for us.

Ammar

...

On 11 Jan 2015, at 8:37 am, Paul S. <contact@winterei.se> wrote:

While it indeed is true that attacks up to 600 gbit/s (If OVH and CloudFlare's data is to be believed) have been known to happen in the wild, it's very unlikely that you need to mitigate anything close.

The average attack is usually around the 10g mark (That too barely) -- so even solutions that service up to 20g work alright.

Obviously, concerns are different if you're an enterprise that's a DDoS magnet -- but for general service providers selling 'protected services,' food for thought.

...

...

On Thu, Jan 8, 2015 at 9:01 AM, Manuel Marín <mmg@transtelco.net> wrote:

I was wondering what are are using for DDOS protection in your networks. We are currently evaluating different options (Arbor, Radware, NSFocus, RioRey) and I would like to know if someone is using the cloud based solutions/scrubbing centers like Imperva, Prolexic, etc and what are the advantages/disadvantages of using a cloud base vs an on-premise solution. It would be great if you can share your experience on this matter. On-premise solutions are limited by your own bandwidth. Attacks have been

On 1/11/2015 午後 12:48, Damian Menscher wrote: publicly reported at 400Gbps, and are rumored to be even larger. If you don't have that much network to spare, then packet loss will occur upstream of your mitigation. Having a good relationship with your network provider(s) can help here, of course.

If you go with a cloud-based solution, be wary of their SLA. I've seen some claim 100% uptime (not believable) but of course no refund/credits for downtime. Another provider only provides 20Gbps protection, then will null-route the victim.

...

On Sat, Jan 10, 2015 at 4:19 PM, Charles N Wyble <charles@thefnf.org> wrote:

Also how are folks testing ddos protection? What lab gear,tools,methods are you using to determine effectiveness of the mitigation. Live-fire is the cheapest approach (just requires some creative trolling) but if you want to control the "off" button, cloud VMs can be tailored to your needs. There are also legitimate companies that do network stress testing.

Keep in mind that you need to test against a variety of attacks, against all components in the critical path. Attackers aren't particularly methodical, but will still randomly discover any weaknesses you've overlooked.

Damian

On Jan 11, 2015, at 11:37 AM, Paul S. <contact@winterei.se> wrote:

Obviously, concerns are different if you're an enterprise that's a DDoS magnet -- but for general service providers selling 'protected services,' food for thought.

Actually, bystander traffic is all-too-often affected by these very large reflection/amplification attacks, because they fill up peering/transit links: <https://app.box.com/s/r7an1moswtc7ce58f8gg> [Full disclosure: I work for a provider of IDMS solutions, but there's no vendor propaganda in the above-linked .pdf preso.] ---------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Equo ne credite, Teucri. -- Laocoön

On Sat, Jan 10, 2015 at 8:37 PM, Paul S. <contact@winterei.se> wrote:

While it indeed is true that attacks up to 600 gbit/s (If OVH and CloudFlare's data is to be believed) have been known to happen in the wild, it's very unlikely that you need to mitigate anything close.

Agree that trusting others' numbers is unwise (there's a bias to inflate sizes), but from personal experience I can say that their claims are plausible. The average attack is usually around the 10g mark (That too barely) -- so

even solutions that service up to 20g work alright.

I'm not sure how to compute an "average" -- I generally just track the maximums. I suspect some reports of 10Gbps attacks are simply that the attack saturated the victim's link, and they were unable to measure the true size. (I agree there are many actual 10Gbps attacks also, of course -- attackers know this size will usually work, so they don't waste resources.) Obviously, concerns are different if you're an enterprise that's a DDoS

magnet -- but for general service providers selling 'protected services,' food for thought.

Even if you're just a hosting provider, your customers may be DDoS magnets. Coincidentally, at the time you pressed "send", we were seeing a 40Gbps attack targeting a customer. Damian On 1/11/2015 午後 12:48, Damian Menscher wrote:

...

On Thu, Jan 8, 2015 at 9:01 AM, Manuel Marín <mmg@transtelco.net> wrote:

...

We are currently evaluating different options (Arbor, Radware, NSFocus, RioRey) and I would like to know if someone is using the cloud based solutions/scrubbing centers like Imperva, Prolexic, etc and what are the advantages/disadvantages of using a cloud base vs an on-premise solution. It would be great if you can share your experience on this matter.

On-premise solutions are limited by your own bandwidth. Attacks have been

I was wondering what are are using for DDOS protection in your networks. publicly reported at 400Gbps, and are rumored to be even larger. If you don't have that much network to spare, then packet loss will occur upstream of your mitigation. Having a good relationship with your network provider(s) can help here, of course.

If you go with a cloud-based solution, be wary of their SLA. I've seen some claim 100% uptime (not believable) but of course no refund/credits for downtime. Another provider only provides 20Gbps protection, then will null-route the victim.

On Sat, Jan 10, 2015 at 4:19 PM, Charles N Wyble <charles@thefnf.org> wrote:

Also how are folks testing ddos protection? What lab gear,tools,methods

...

are you using to determine effectiveness of the mitigation.

Live-fire is the cheapest approach (just requires some creative trolling) but if you want to control the "off" button, cloud VMs can be tailored to your needs. There are also legitimate companies that do network stress testing.

Keep in mind that you need to test against a variety of attacks, against all components in the critical path. Attackers aren't particularly methodical, but will still randomly discover any weaknesses you've overlooked.

Damian

On 11 Jan 2015, at 13:30, Ammar Zuberi wrote:

I've done a lot of research into how these attacks actually work and most of them are done by kids who don't really know what they're doing.

The really sad part is that in a huge of the cases we see, the attacks are hugely disproportionate - so many servers/services/applications/networks are so brittle and fragile and non-scalable that only a fraction of the pps/bps/cps/qps generated by the attackers would take them down, anyways. Even worse, the attackers who don't know what they're doing routinely achieve their goals, anyways, due to the above plus the unpreparedness of the defenders. I've only run across a handful of organizations which proactively took appropriate defensive measures; most only do so in the aftermath of a successful attack. It's easy to be an Internet supervillain. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>

On 11 Jan 2015, at 20:07, Mike Hammett wrote:

but I'd think that if their network's abuse department was notified, either they'd contact the customer about it issue or at least have on file that they were notified.

Just because we think something, that doesn't make it true. ;>

The way to stop this stuff is for those millions of end users to clean up their infected PCs.

You may want to do some reading on this topic in order to gain a better understanding of the issues involved: <https://app.box.com/s/4h2l6f4m8is6jnwk28cg> Some of us have been dealing with DDoS attacks for a couple of decades, now. If it were a simple problem, we would've solved it long ago. Here's a hint: scale alone makes any problem literally orders of magnitude more difficult than any given instance thereof. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>

I agree with lots said here. But I've said for years (despite some people saying I am confused) that BCP38 is the single most important thing we can do to cut DDoS. No spoofed source means no amplification. It also stops things like Kaminsky DNS attacks. There is no silver bullet. Security is a series of steps ("layers" as one highly respected security professional has in his .sig). But the most important layer, the biggest bang for the buck we can do today, is eliminated spoofed source. Push on your providers. Stop paying for transit from networks that do not filter ingress, put it in your RFPs, and reward those who do with contracts. Make it economically advantageous to fix the problem, and people will. -- TTFN, patrick

On Jan 11, 2015, at 08:46 , Mike Hammett <nanog@ics-il.net> wrote:

Well there's going to be two sources of the attack... infested clients or machines setup for this purpose (usually in a datacenter somewhere). Enough people blackhole the attacking IPs, those IPs are eventually going to have a very limited view of the Internet. They may not care of it's a server in a datacenter being used to attack, but an infested home PC would care once they can't get to Google, FaceBook, Instagram, whatever.

If the attacker's abuse contact doesn't care, then just brute force of more and more of the Internet being offline to them, they'll figure it out.

You hit my honeypot IPs, blackholed for 30 days. You do a DNS request to my non-DNS servers, blackholed for 30 days. Same goes for NTP, mail, web, etc. You have more than say 5 bad login attempts to my mail server in 5 minutes, blackholed for 30 days. You're trying to access various web pages known for home router or Wordpress exploitation, blackholed for 30 days.

No point in letting troublemakers (manual or scripted) spend more time on the network than necessary. The more people (as a collective or not) that do this, the better.

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

----- Original Message -----

From: "Roland Dobbins" <rdobbins@arbor.net> To: nanog@nanog.org Sent: Sunday, January 11, 2015 7:24:55 AM Subject: Re: DDOS solution recommendation

On 11 Jan 2015, at 20:07, Mike Hammett wrote:

...

but I'd think that if their network's abuse department was notified, either they'd contact the customer about it issue or at least have on file that they were notified.

Just because we think something, that doesn't make it true.

;>

...

The way to stop this stuff is for those millions of end users to clean up their infected PCs.

You may want to do some reading on this topic in order to gain a better understanding of the issues involved:

<https://app.box.com/s/4h2l6f4m8is6jnwk28cg>

Some of us have been dealing with DDoS attacks for a couple of decades, now. If it were a simple problem, we would've solved it long ago.

Here's a hint: scale alone makes any problem literally orders of magnitude more difficult than any given instance thereof.

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

Is anyone maintaining a list of good, bad and ugly providers in terms of how seriously they take things they should like BCP38 and community support and whatever else that's quantifiable? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Patrick W. Gilmore" <patrick@ianai.net> To: "NANOG list" <nanog@nanog.org> Sent: Sunday, January 11, 2015 7:50:22 AM Subject: Re: DDOS solution recommendation I agree with lots said here. But I've said for years (despite some people saying I am confused) that BCP38 is the single most important thing we can do to cut DDoS. No spoofed source means no amplification. It also stops things like Kaminsky DNS attacks. There is no silver bullet. Security is a series of steps ("layers" as one highly respected security professional has in his .sig). But the most important layer, the biggest bang for the buck we can do today, is eliminated spoofed source. Push on your providers. Stop paying for transit from networks that do not filter ingress, put it in your RFPs, and reward those who do with contracts. Make it economically advantageous to fix the problem, and people will. -- TTFN, patrick

On Jan 11, 2015, at 08:46 , Mike Hammett <nanog@ics-il.net> wrote:

Well there's going to be two sources of the attack... infested clients or machines setup for this purpose (usually in a datacenter somewhere). Enough people blackhole the attacking IPs, those IPs are eventually going to have a very limited view of the Internet. They may not care of it's a server in a datacenter being used to attack, but an infested home PC would care once they can't get to Google, FaceBook, Instagram, whatever.

If the attacker's abuse contact doesn't care, then just brute force of more and more of the Internet being offline to them, they'll figure it out.

You hit my honeypot IPs, blackholed for 30 days. You do a DNS request to my non-DNS servers, blackholed for 30 days. Same goes for NTP, mail, web, etc. You have more than say 5 bad login attempts to my mail server in 5 minutes, blackholed for 30 days. You're trying to access various web pages known for home router or Wordpress exploitation, blackholed for 30 days.

No point in letting troublemakers (manual or scripted) spend more time on the network than necessary. The more people (as a collective or not) that do this, the better.

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

----- Original Message -----

From: "Roland Dobbins" <rdobbins@arbor.net> To: nanog@nanog.org Sent: Sunday, January 11, 2015 7:24:55 AM Subject: Re: DDOS solution recommendation

On 11 Jan 2015, at 20:07, Mike Hammett wrote:

...

but I'd think that if their network's abuse department was notified, either they'd contact the customer about it issue or at least have on file that they were notified.

Just because we think something, that doesn't make it true.

;>

...

The way to stop this stuff is for those millions of end users to clean up their infected PCs.

You may want to do some reading on this topic in order to gain a better understanding of the issues involved:

<https://app.box.com/s/4h2l6f4m8is6jnwk28cg>

Some of us have been dealing with DDoS attacks for a couple of decades, now. If it were a simple problem, we would've solved it long ago.

Here's a hint: scale alone makes any problem literally orders of magnitude more difficult than any given instance thereof.

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

Le 11/01/2015 14:50, Patrick W. Gilmore a écrit :

I agree with lots said here.

But I've said for years (despite some people saying I am confused) that BCP38 is the single most important thing we can do to cut DDoS.

No spoofed source means no amplification. It also stops things like Kaminsky DNS attacks.

There is no silver bullet. Security is a series of steps ("layers" as one highly respected security professional has in his .sig). But the most important layer, the biggest bang for the buck we can do today, is eliminated spoofed source.

Push on your providers. Stop paying for transit from networks that do not filter ingress, put it in your RFPs, and reward those who do with contracts. Make it economically advantageous to fix the problem, and people will.

+1 mh

Le 11/01/2015 14:50, Patrick W. Gilmore a écrit :

I agree with lots said here.

But I've said for years (despite some people saying I am confused) that BCP38 is the single most important thing we can do to cut DDoS.

No spoofed source means no amplification. It also stops things like Kaminsky DNS attacks.

There is no silver bullet. Security is a series of steps ("layers" as one highly respected security professional has in his .sig). But the most important layer, the biggest bang for the buck we can do today, is eliminated spoofed source.

Push on your providers. Stop paying for transit from networks that do not filter ingress, put it in your RFPs, and reward those who do with contracts. Make it economically advantageous to fix the problem, and people will.

+1 mh

To quote a presentation I heard at a conference regarding small routers, "Buy bigger rooters, bitches." (Yes, I know it isn't that simple, but most of the audience at that conference had purchasing authority.) Not all networks are doing what they're supposed to be (I'm on that list), but if no one ever does anything because not everyone else is, then nothing ever gets done. I'm not saying what you're doing is wrong, I'm saying whatever the industry as a whole is doing obviously isn't working and perhaps a different approach is required. Security teams? My network has me, myself and I. If for example ChinaNet's abuse department isn't doing anything about complains, eventually their whole network gets blocked a /32 at a time. *shrugs* Their loss. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Roland Dobbins" <rdobbins@arbor.net> To: nanog@nanog.org Sent: Sunday, January 11, 2015 7:51:59 AM Subject: Re: DDOS solution recommendation On 11 Jan 2015, at 20:46, Mike Hammett wrote:

Enough people blackhole the attacking IPs, those IPs are eventually going to have a very limited view of the Internet.

TCAMs have limits. Not all networks practice anti-spoofing. Not all networks have any visibility whatsoever into their network traffic. Not all networks have security teams. Again, it would probably be advisable to do some reading before you start telling those of us who've been working on this set of problems for the last couple of decades that it's simple, and that we don't know what we're doing. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>

On Sun, 11 Jan 2015 22:29:33 +0700, "Roland Dobbins" said:

On 11 Jan 2015, at 22:21, Mike Hammett wrote:

...

I'm not saying what you're doing is wrong, I'm saying whatever the industry as a whole is doing obviously isn't working and perhaps a different approach is required.

You haven't recommended anything new, and you really need to do some reading in order to understand why it isn't as simple as you seem to think it is.

Sounds like RFC1925, section 4 should be top of the list?

I didn't necessarily think I was shattering minds with my ideas. I don't have the time to read a dozen presentations. Blackhole them and move on. I don't care whose feelings I hurt. This isn't kindergarten. Maybe "you" should have tried a little harder to not get a virus in the first place. Quit clicking on male enhancement ads or update your OS occasionally. I'm not going to spend a bunch of time and money to make sure someone's bubble of bliss doesn't get popped. Swift, effective, cheap. Besides, you're only cut off for 30 days. If in 30 days you can prove yourself to be responsible, we can try this again. Well, that or a sufficient support request. Besides, if enough people did hat, the list of blackholes wouldn't be huge as someone upstream already blocked them. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Roland Dobbins" <rdobbins@arbor.net> To: nanog@nanog.org Sent: Sunday, January 11, 2015 9:29:33 AM Subject: Re: DDOS solution recommendation On 11 Jan 2015, at 22:21, Mike Hammett wrote:

I'm not saying what you're doing is wrong, I'm saying whatever the industry as a whole is doing obviously isn't working and perhaps a different approach is required.

You haven't recommended anything new, and you really need to do some reading in order to understand why it isn't as simple as you seem to think it is.

Security teams? My network has me, myself and I.

And a relatively small network, too.

If for example ChinaNet's abuse department isn't doing anything about complains, eventually their whole network gets blocked a /32 at a time. *shrugs* Their loss.

Again, it isn't that simple. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>

I do love solutions which open larger attack surfaces than they are supposed to close. In the US, we call that "a cure worse than the disease". Send packet from random bot with source of Google, Comcast, Akamai, etc. to Mr. Hammett's not-DNS / honeypot / whatever, and watch him close himself off from the world. Voilà! Denial of service accomplished without all the hassle of sending 100s of Gbps of traffic. Best part is he was willing to explain this to 10,000+ of his not-so-closest friends, in a search-engine-indexed manner. -- TTFN, patrick On Jan 11, 2015, at 14:34 , Phil Bedard <bedard.phil@gmail.com> wrote:

Many attacks can use spoofed source IPs, so who are you really blocking?

That's why BCP38 as mentioned many times already is a necessary tool in fighting the attacks overall.

Phil

On 1/11/15, 4:33 PM, "Mike Hammett" <nanog@ics-il.net> wrote:

...

I didn't necessarily think I was shattering minds with my ideas.

I don't have the time to read a dozen presentations.

Blackhole them and move on. I don't care whose feelings I hurt. This isn't kindergarten. Maybe "you" should have tried a little harder to not get a virus in the first place. Quit clicking on male enhancement ads or update your OS occasionally. I'm not going to spend a bunch of time and money to make sure someone's bubble of bliss doesn't get popped. Swift, effective, cheap. Besides, you're only cut off for 30 days. If in 30 days you can prove yourself to be responsible, we can try this again. Well, that or a sufficient support request.

Besides, if enough people did hat, the list of blackholes wouldn't be huge as someone upstream already blocked them.

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

----- Original Message -----

From: "Roland Dobbins" <rdobbins@arbor.net> To: nanog@nanog.org Sent: Sunday, January 11, 2015 9:29:33 AM Subject: Re: DDOS solution recommendation

On 11 Jan 2015, at 22:21, Mike Hammett wrote:

...

I'm not saying what you're doing is wrong, I'm saying whatever the industry as a whole is doing obviously isn't working and perhaps a different approach is required.

You haven't recommended anything new, and you really need to do some reading in order to understand why it isn't as simple as you seem to think it is.

...

Security teams? My network has me, myself and I.

And a relatively small network, too.

...

If for example ChinaNet's abuse department isn't doing anything about complains, eventually their whole network gets blocked a /32 at a time. *shrugs* Their loss.

Again, it isn't that simple.

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

On Jan 11, 2015, at 15:28 , Colin Johnston <colinj@gt86car.org.uk> wrote:

unfortunately chinanet antispam/abuse email box is always full, after a while people block . always check arin/ripe for known good provider blocks and actively exclude from rules

They aren't the only ones who never reply to abuse@.

ddos protection via careful overview ips rules and active web source ip monitoring works well, the hard part is daily rule updates and blocks until you know most traffic is genuine.

No one is advocating "never block anything". However, automatic blocking based on a single DNS packet to a non-DNS server is .. let's call it counterproductive. Good hygiene is necessary both on outgoing packets and on blocking. Checking ARIN/RIPE (not APNIC, LACNIC, AFRINIC?) is not even the bare minimum you should be doing. -- TTFN, patrick

...

On 11 Jan 2015, at 19:42, "Patrick W. Gilmore" <patrick@ianai.net> wrote:

I do love solutions which open larger attack surfaces than they are supposed to close. In the US, we call that "a cure worse than the disease".

Send packet from random bot with source of Google, Comcast, Akamai, etc. to Mr. Hammett's not-DNS / honeypot / whatever, and watch him close himself off from the world.

Voilà! Denial of service accomplished without all the hassle of sending 100s of Gbps of traffic.

Best part is he was willing to explain this to 10,000+ of his not-so-closest friends, in a search-engine-indexed manner.

-- TTFN, patrick

...

On Jan 11, 2015, at 14:34 , Phil Bedard <bedard.phil@gmail.com> wrote:

Many attacks can use spoofed source IPs, so who are you really blocking?

That's why BCP38 as mentioned many times already is a necessary tool in fighting the attacks overall.

Phil

...

On 1/11/15, 4:33 PM, "Mike Hammett" <nanog@ics-il.net> wrote:

I didn't necessarily think I was shattering minds with my ideas.

I don't have the time to read a dozen presentations.

Blackhole them and move on. I don't care whose feelings I hurt. This isn't kindergarten. Maybe "you" should have tried a little harder to not get a virus in the first place. Quit clicking on male enhancement ads or update your OS occasionally. I'm not going to spend a bunch of time and money to make sure someone's bubble of bliss doesn't get popped. Swift, effective, cheap. Besides, you're only cut off for 30 days. If in 30 days you can prove yourself to be responsible, we can try this again. Well, that or a sufficient support request.

Besides, if enough people did hat, the list of blackholes wouldn't be huge as someone upstream already blocked them.

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

----- Original Message -----

From: "Roland Dobbins" <rdobbins@arbor.net> To: nanog@nanog.org Sent: Sunday, January 11, 2015 9:29:33 AM Subject: Re: DDOS solution recommendation

...

On 11 Jan 2015, at 22:21, Mike Hammett wrote:

I'm not saying what you're doing is wrong, I'm saying whatever the industry as a whole is doing obviously isn't working and perhaps a different approach is required.

You haven't recommended anything new, and you really need to do some reading in order to understand why it isn't as simple as you seem to think it is.

...

Security teams? My network has me, myself and I.

And a relatively small network, too.

...

If for example ChinaNet's abuse department isn't doing anything about complains, eventually their whole network gets blocked a /32 at a time. *shrugs* Their loss.

Again, it isn't that simple.

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

On Jan 11, 2015, at 12:28 , Colin Johnston <colinj@gt86car.org.uk> wrote:

unfortunately chinanet antispam/abuse email box is always full, after a while people block . always check arin/ripe for known good provider blocks and actively exclude from rules

ARIN and RIPE do not provide address reputation information, so I’m not sure what you mean by known good blocks. Anything you can get from ARIN or RIPE, you would also want to check against LACNIC, AfriNIC, and APNIC as each of the 5 RIRs has their own region for which they are responsible. If you merely check ARIN and RIPE, you will permit only North America (exclusive of Mexico), some Caribbean Islands, Antarctica, and Europe. If it is not your intent to completely ignore Asia, Africa, Latin America, and about half of the Caribbean, then your above statement needs adjustment.

ddos protection via careful overview ips rules and active web source ip monitoring works well, the hard part is daily rule updates and blocks until you know most traffic is genuine.

This helps with PPS attacks against web servers and certain web exploits. It does not help with volumetric attacks. The simple fact is that the only way to deal with volumetric attacks is to have them blocked or filtered upstream unless you have sufficient ingress capacity to sink the attack traffic volume. Owen

colin

Sent from my iPhone

...

On 11 Jan 2015, at 19:42, "Patrick W. Gilmore" <patrick@ianai.net> wrote:

I do love solutions which open larger attack surfaces than they are supposed to close. In the US, we call that "a cure worse than the disease".

Send packet from random bot with source of Google, Comcast, Akamai, etc. to Mr. Hammett's not-DNS / honeypot / whatever, and watch him close himself off from the world.

Voilà! Denial of service accomplished without all the hassle of sending 100s of Gbps of traffic.

Best part is he was willing to explain this to 10,000+ of his not-so-closest friends, in a search-engine-indexed manner.

-- TTFN, patrick

...

On Jan 11, 2015, at 14:34 , Phil Bedard <bedard.phil@gmail.com> wrote:

Many attacks can use spoofed source IPs, so who are you really blocking?

That's why BCP38 as mentioned many times already is a necessary tool in fighting the attacks overall.

Phil

...

On 1/11/15, 4:33 PM, "Mike Hammett" <nanog@ics-il.net> wrote:

I didn't necessarily think I was shattering minds with my ideas.

I don't have the time to read a dozen presentations.

Blackhole them and move on. I don't care whose feelings I hurt. This isn't kindergarten. Maybe "you" should have tried a little harder to not get a virus in the first place. Quit clicking on male enhancement ads or update your OS occasionally. I'm not going to spend a bunch of time and money to make sure someone's bubble of bliss doesn't get popped. Swift, effective, cheap. Besides, you're only cut off for 30 days. If in 30 days you can prove yourself to be responsible, we can try this again. Well, that or a sufficient support request.

Besides, if enough people did hat, the list of blackholes wouldn't be huge as someone upstream already blocked them.

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

----- Original Message -----

From: "Roland Dobbins" <rdobbins@arbor.net> To: nanog@nanog.org Sent: Sunday, January 11, 2015 9:29:33 AM Subject: Re: DDOS solution recommendation

...

On 11 Jan 2015, at 22:21, Mike Hammett wrote:

I'm not saying what you're doing is wrong, I'm saying whatever the industry as a whole is doing obviously isn't working and perhaps a different approach is required.

You haven't recommended anything new, and you really need to do some reading in order to understand why it isn't as simple as you seem to think it is.

...

Security teams? My network has me, myself and I.

And a relatively small network, too.

...

If for example ChinaNet's abuse department isn't doing anything about complains, eventually their whole network gets blocked a /32 at a time. *shrugs* Their loss.

Again, it isn't that simple.

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

You are very confused about how the Internet works. Or did you not understand the words "with source of"? Wait, maybe you have some magic to tell the actual source of a packet than the 32/128 bits in the "source" field? Because if you do, you stand to make a few billion dollars, and I'll be one of the first to pay you for it. (I'm specifically excluding things that give hints like TTL & incoming interface. To get paid, you need to tell me the ACTUAL source of a spoofed packet.) While I will admit I do not know which of the above is true, my money is on #1. -- TTFN, patrick

On Jan 11, 2015, at 16:08 , Mike Hammett <nanog@ics-il.net> wrote:

If that were to happen, it'd be for 30 days and it'd be whatever random residential account or APNIC address that was doing it. Not really a big loss.

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

----- Original Message -----

From: "Patrick W. Gilmore" <patrick@ianai.net> To: "NANOG list" <nanog@nanog.org> Sent: Sunday, January 11, 2015 1:42:13 PM Subject: Re: DDOS solution recommendation

I do love solutions which open larger attack surfaces than they are supposed to close. In the US, we call that "a cure worse than the disease".

Send packet from random bot with source of Google, Comcast, Akamai, etc. to Mr. Hammett's not-DNS / honeypot / whatever, and watch him close himself off from the world.

Voilà! Denial of service accomplished without all the hassle of sending 100s of Gbps of traffic.

Best part is he was willing to explain this to 10,000+ of his not-so-closest friends, in a search-engine-indexed manner.

-- TTFN, patrick

On Jan 11, 2015, at 14:34 , Phil Bedard <bedard.phil@gmail.com> wrote:

...

Many attacks can use spoofed source IPs, so who are you really blocking?

That's why BCP38 as mentioned many times already is a necessary tool in fighting the attacks overall.

Phil

On 1/11/15, 4:33 PM, "Mike Hammett" <nanog@ics-il.net> wrote:

...

I didn't necessarily think I was shattering minds with my ideas.

I don't have the time to read a dozen presentations.

Blackhole them and move on. I don't care whose feelings I hurt. This isn't kindergarten. Maybe "you" should have tried a little harder to not get a virus in the first place. Quit clicking on male enhancement ads or update your OS occasionally. I'm not going to spend a bunch of time and money to make sure someone's bubble of bliss doesn't get popped. Swift, effective, cheap. Besides, you're only cut off for 30 days. If in 30 days you can prove yourself to be responsible, we can try this again. Well, that or a sufficient support request.

Besides, if enough people did hat, the list of blackholes wouldn't be huge as someone upstream already blocked them.

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

----- Original Message -----

From: "Roland Dobbins" <rdobbins@arbor.net> To: nanog@nanog.org Sent: Sunday, January 11, 2015 9:29:33 AM Subject: Re: DDOS solution recommendation

On 11 Jan 2015, at 22:21, Mike Hammett wrote:

...

I'm not saying what you're doing is wrong, I'm saying whatever the industry as a whole is doing obviously isn't working and perhaps a different approach is required.

You haven't recommended anything new, and you really need to do some reading in order to understand why it isn't as simple as you seem to think it is.

...

Security teams? My network has me, myself and I.

And a relatively small network, too.

...

If for example ChinaNet's abuse department isn't doing anything about complains, eventually their whole network gets blocked a /32 at a time. *shrugs* Their loss.

Again, it isn't that simple.

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

On Sun, Jan 11, 2015 at 5:07 AM, Mike Hammett <nanog@ics-il.net> wrote:

Blackhole all of the zombie attackers and notify their abuse departments. Sure, most of the owners of the PCs being used in these scenarios have no idea they're being used to attack people, but I'd think that if their network's abuse department was notified, either they'd contact the customer about it issue or at least have on file that they were notified. When the unknowing end-user reached out to support over larger and larger parts of the Internet not working, they'd be told to clean up their system.

Notification to abuse departments is largely a waste of time, but I've tried it anyway. My records indicate that over the past year I sent 3139 emails covering 24054 known-infected machines regarding 16 distinct incidents. A few machines were cleaned, but the attacks continue. Part of the problem is that most network providers don't have the resources to chase down abuse issues. In one case I informed an ISP of ~70k infected customers. They said their support team couldn't possibly handle that, and took no action. In another case, a well-known ISP was unable to receive my list because they bounced emails over a certain size. I try to bypass the ISP where possible by sending notices directly to users ( http://googleblog.blogspot.com/2011/07/using-data-to-protect-people-from.htm... and http://googleonlinesecurity.blogspot.com/2012/05/notifying-users-affected-by...). That has a provable effect, though not as large as one might hope. Your later comment of blackholing is indeed quite effective (I once blackholed 3 IPs at a hosting provider who had ignored 3 abuse complaints over 3 months, and they had the machines cleaned within days), but is a last resort since there can be significant collateral damage (which is, of course, why they suddenly decided to care). I've also encouraged website owners to care by marking their website as infected in Google search results. On Sun, Jan 11, 2015 at 5:50 AM, Patrick W. Gilmore <patrick@ianai.net> wrote:

But I've said for years (despite some people saying I am confused) that BCP38 is the single most important thing we can do to cut DDoS.

Yes, agreed. I've been working on this, but unfortunately nobody is ready to take action, often citing hardware limitations. And since nobody is compliant, there's no way to push others to upgrade. On Sun, Jan 11, 2015 at 6:51 AM, Job Snijders <job@instituut.net> wrote:

On Sun, Jan 11, 2015 at 08:46:40AM -0600, Mike Hammett wrote:

...

Is anyone maintaining a list of good, bad and ugly providers in terms of how seriously they take things they should like BCP38 and community support and whatever else that's quantifiable?

This list sheds some light on antispoofing commitments made by various providers: https://www.routingmanifesto.org/participants/

I have traced spoofed-source attacks to providers on that list. I once considered posting a list-of-shame, but it would be too long (and not win any friends here). On Sun, Jan 11, 2015 at 10:09 AM, Joel Maslak <jmaslak@antelope.net> wrote:

I urge caution in building automatic systems to respond to network abuse, lest you have unanticipated consequences.

I'm always amused at the automation people create. Googlebot is a frequent victim of admins who know perl, but not /robots.txt. Damian

In message <54B31BBE.3000502@tnetconsulting.net>, Grant Taylor writes:

On 01/11/2015 03:22 PM, Mike Hammett wrote:

...

I know that UDP can be spoofed, but it's not likely that the SSH, mail, etc. login attempts, web page hits, etc. would be spoofed as they'd have to know the response to be of any good.

I encourage you to investigate "Triangular Spamming". (http://www.cs.ucr.edu/~zhiyunq/pub/oakland10_triangular_spamming.pdf) The "Triangular..." technique does specifically that, allow the attacker to "...know the responses...".

In short, the bot receives the reply to the spoofed source IP and forwards information on to the attacker so that it can continue the conversation. In effect, three parties are having a one way conversation in a ring.

Just because you can only identify one of the two remotes doesn't mean that you can't report the addresses. It is involved in the communication stream.

...

There's more going on than UDP spoofing\amplification. Frankly the most damaging thing to me has been SMTP hijacking. For you to login to my SMTP server and send e-mail out, there's going to be one hell of a conversation going on.

Yes, there is what appears to you to be be a conversation going on. However, the source of what you are hearing is not where you think it's from.

Actually it is coming from where you think it is coming from, just not directly. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

In message <54B34A12.4000704@tnetconsulting.net>, Grant Taylor writes:

On 01/11/2015 07:42 PM, Mark Andrews wrote:

...

Just because you can only identify one of the two remotes doesn't mean that you can't report the addresses. It is involved in the communication stream.

It is very difficult to make a case that the host with the spoofed IP address is attacking you when it is not even sending any traffic to you.

It is accepting the reply traffic and forwarding it to the originator. It is directly involved.

The ISP will very likely not see ANY traffic originating from spoofed IP destined to your server.

They will see the reply traffic and will see the acks increasing etc.

So what you do know is effectively useless.

...

Actually it is coming from where you think it is coming from, just not directly.

No, not quite.

1 - Spammer (A) sends packets to server (B) spoofing the source address of the relay (C). (A spoofed as) C -> B 2 - Server (B) replies to relay (C) B -> C 3 - Relay (C) sends packets to spammer (A). C -> A

Notice how the relay (C) is never sending packets -to- the server (B). The traffic is NOT coming from the relay (C).

This is not a case of the spammer (A) sending to the relay (C) that is then sending the traffic to the server (B).

There is no traffic originating from the relay (C) going to the server (B). Thus there is nothing to be caught by the relay's ISP ISP filter. You could even use this technique on ISPs that block outbound traffic to TCP port 25. (Like many cable / DSL providers.)

Also notice how the server (B) never knows the spammer's (A) real IP.

This is very similar in concept to a Joe Job, but at the TCP layer, not the SMTP application layer.

----

The point of this is that it is possible, and occurring in the wild, to spoof TCP source IP addresses. - So, don't blindly trust the source IP address used for TCP connections. - It is possible (if not practical) to spoof them and have a successfully transmission.

There is no difference to this than asymetric routing. The address you are presented with is part of the communication path.

-- Grant. . . . unix || die -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Sun, 11 Jan 2015, Mike Hammett wrote:

I know that UDP can be spoofed, but it's not likely that the SSH, mail, etc. login attempts, web page hits, etc. would be spoofed as they'd have to know the response to be of any good.

Okay, so I'm curious. Are you saying that you do not automatically block attackers until you can confirm a 3-way TCP handshake has been completed, and therefore you aren't blocking sources that were spoofed? If so, how are you protecting yourself against SYN attacks? If not, then you've made it quite easy for attackers to deny any source they want. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross

So the preferred alternative is to simply do nothing at all? That seems fair. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Christopher Morrow" <morrowc.lists@gmail.com> To: "Brandon Ross" <bross@pobox.com> Cc: "Mike Hammett" <nanog@ics-il.net>, "NANOG list" <nanog@nanog.org> Sent: Monday, January 12, 2015 3:05:14 PM Subject: Re: DDOS solution recommendation On Mon, Jan 12, 2015 at 3:17 PM, Brandon Ross <bross@pobox.com> wrote:

On Sun, 11 Jan 2015, Mike Hammett wrote:

...

I know that UDP can be spoofed, but it's not likely that the SSH, mail, etc. login attempts, web page hits, etc. would be spoofed as they'd have to know the response to be of any good.

Okay, so I'm curious. Are you saying that you do not automatically block attackers until you can confirm a 3-way TCP handshake has been completed, and therefore you aren't blocking sources that were spoofed? If so, how are you protecting yourself against SYN attacks? If not, then you've made it quite easy for attackers to deny any source they want.

this all seems like a fabulous conversation we're watching, but really .. if someone wants to block large swaths of the intertubes on their systems it's totally up to them, right? They can choose to not be functional all they want, as near as I can tell... and arguing with someone with this mentality isn't productive, especially after several (10+? folk) have tried to show and tell some experience that would lead to more cautious approaches. If mike wants less packets, that's all cool... I'm not sure it's actually solving anything, but sure, go right ahead, have fun. -chris

On 13 Jan 2015, at 4:35, Mike Hammett wrote:

So the preferred alternative is to simply do nothing at all?

Straw man. Nobody's said that. Quite the opposite, in point of fact. As noted previously in this thread, there's a lot of information out there about how operators deal with DDoS attacks. All it takes is the willingness to devote a bit of time to educating oneself. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>

On 13 Jan 2015, at 4:51, Scott Fisher wrote:

The questions should be much more narrow. "How should I mitigate an NTP reflection" or "what are common mistakes people make when mitigating attacks" are questions that more specific that all can glean from.

The answers to a lot of those questions are right here: <https://app.box.com/s/4h2l6f4m8is6jnwk28cg> In fact, they're discussed in this single presentation: <https://app.box.com/s/r7an1moswtc7ce58f8gg> There are lots more resources available elsewhere on the Internet, as well. We all just need to invest the time to learn from the experiences of others, so that we can then make our own contributions starting from a firm foundation. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>

Earlier in the thread you seemed extremely confident in your position that long term blocking of addresses that appeared as source addresses of undesirable traffic is a good thing. Why are you now avoiding answering my question with a strawman? On Mon, 12 Jan 2015, Mike Hammett wrote:

So the preferred alternative is to simply do nothing at all? That seems fair.

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

----- Original Message -----

From: "Christopher Morrow" <morrowc.lists@gmail.com> To: "Brandon Ross" <bross@pobox.com> Cc: "Mike Hammett" <nanog@ics-il.net>, "NANOG list" <nanog@nanog.org> Sent: Monday, January 12, 2015 3:05:14 PM Subject: Re: DDOS solution recommendation

On Mon, Jan 12, 2015 at 3:17 PM, Brandon Ross <bross@pobox.com> wrote:

...

On Sun, 11 Jan 2015, Mike Hammett wrote:

...

I know that UDP can be spoofed, but it's not likely that the SSH, mail, etc. login attempts, web page hits, etc. would be spoofed as they'd have to know the response to be of any good.

Okay, so I'm curious. Are you saying that you do not automatically block attackers until you can confirm a 3-way TCP handshake has been completed, and therefore you aren't blocking sources that were spoofed? If so, how are you protecting yourself against SYN attacks? If not, then you've made it quite easy for attackers to deny any source they want.

this all seems like a fabulous conversation we're watching, but really .. if someone wants to block large swaths of the intertubes on their systems it's totally up to them, right? They can choose to not be functional all they want, as near as I can tell... and arguing with someone with this mentality isn't productive, especially after several (10+? folk) have tried to show and tell some experience that would lead to more cautious approaches.

If mike wants less packets, that's all cool... I'm not sure it's actually solving anything, but sure, go right ahead, have fun.

-chris

-- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross

On 11 Jan 2015, at 23:33, Mike Hammett wrote:

I don't have the time to read a dozen presentations.

Then just read one: <https://app.box.com/s/r7an1moswtc7ce58f8gg> Skip the screenshots entirely, if you want, and just read the textual slides at the beginning and the end. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>

Hi Mike, About trying to hit the mail ports... It is very easy for a domain to set its MX to a random host name. So before you block you might want to check the To-domain in the header of the mail. Otherwise it is too easy to DoS yourself (by planting email addresses in systems, such as mine, and then changing the MX of that domain to your hosts). David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -----Oorspronkelijk bericht----- Van: NANOG [mailto:nanog-bounces@nanog.org] Namens Mike Hammett Verzonden: Sunday, January 11, 2015 2:46 PM Aan: Roland Dobbins CC: nanog@nanog.org Onderwerp: Re: DDOS solution recommendation Well there's going to be two sources of the attack... infested clients or machines setup for this purpose (usually in a datacenter somewhere). Enough people blackhole the attacking IPs, those IPs are eventually going to have a very limited view of the Internet. They may not care of it's a server in a datacenter being used to attack, but an infested home PC would care once they can't get to Google, FaceBook, Instagram, whatever. If the attacker's abuse contact doesn't care, then just brute force of more and more of the Internet being offline to them, they'll figure it out. You hit my honeypot IPs, blackholed for 30 days. You do a DNS request to my non-DNS servers, blackholed for 30 days. Same goes for NTP, mail, web, etc. You have more than say 5 bad login attempts to my mail server in 5 minutes, blackholed for 30 days. You're trying to access various web pages known for home router or Wordpress exploitation, blackholed for 30 days. No point in letting troublemakers (manual or scripted) spend more time on the network than necessary. The more people (as a collective or not) that do this, the better. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Roland Dobbins" <rdobbins@arbor.net> To: nanog@nanog.org Sent: Sunday, January 11, 2015 7:24:55 AM Subject: Re: DDOS solution recommendation On 11 Jan 2015, at 20:07, Mike Hammett wrote:

but I'd think that if their network's abuse department was notified, either they'd contact the customer about it issue or at least have on file that they were notified.

Just because we think something, that doesn't make it true. ;>

The way to stop this stuff is for those millions of end users to clean up their infected PCs.

You may want to do some reading on this topic in order to gain a better understanding of the issues involved: <https://app.box.com/s/4h2l6f4m8is6jnwk28cg> Some of us have been dealing with DDoS attacks for a couple of decades, now. If it were a simple problem, we would've solved it long ago. Here's a hint: scale alone makes any problem literally orders of magnitude more difficult than any given instance thereof. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>

On Sun, Jan 11, 2015 at 5:07 AM, Mike Hammett <nanog@ics-il.net> wrote:

Why does it seem like everyone is trying to "solve" this the wrong way?

Do other networks' abuse departments just not give a shit? Blackhole all of the zombie attackers and notify their abuse departments. Sure, most of the owners of the PCs being used in these scenarios have no idea they're being used to attack people, but I'd think that if their network's abuse department was notified, either they'd contact the customer about it issue or at least have on file that they were notified. When the unknowing end-user reached out to support over larger and larger parts of the Internet not working, they'd be told to clean up their system.

The way to stop this stuff is for those millions of end users to clean up their infected PCs.

1. BCP38 protects your neighbor, do it. 2. Protect yourself by having your upstream police Police UDP to some baseline you are comfortable with. 3. Have RTBH ready for some special case. 4. Sleep better at night. I do all of the above for the last 18 months.

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

----- Original Message -----

From: "Manuel Marín" <mmg@transtelco.net> To: nanog@nanog.org Sent: Thursday, January 8, 2015 11:01:47 AM Subject: DDOS solution recommendation

Nanog group

I was wondering what are are using for DDOS protection in your networks. We are currently evaluating different options (Arbor, Radware, NSFocus, RioRey) and I would like to know if someone is using the cloud based solutions/scrubbing centers like Imperva, Prolexic, etc and what are the advantages/disadvantages of using a cloud base vs an on-premise solution. It would be great if you can share your experience on this matter.

Thank you

I’m stuck trying to find a virtual router environment that I can play with flowspec on. We do have some Juniper routers, but they are in production and I don’t think I want to touch flowspec on them just yet. Does anyone have any experience or any ideas here? Even openbgpd?

On Jan 11, 2015, at 6:58 PM, Roland Dobbins <rdobbins@arbor.net> wrote:

On 11 Jan 2015, at 20:52, Ca By wrote:

...

1. BCP38 protects your neighbor, do it.

It's to protect yourself, as well. You should do it all the way down to the transit customer aggregation edge, all the way down to the IDC access layer, etc.

...

2. Protect yourself by having your upstream police Police UDP to some baseline you are comfortable with.

This will come back to haunt you, when the programmatically-generated attack traffic 'crowds out' the legitimate traffic and everything breaks.

You can only really do this for ntp.

...

3. Have RTBH ready for some special case.

S/RTBH and/or flowspec are better (S/RTBH does D/RTBH, too).

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

There's the Cisco xRV too, should be decent for playing around with. On 1/12/2015 午前 12:08, Dave Bell wrote:

Maybe try the Cisco CSR1000v. In the trial mode it won't give you a decent throughput, but should have all features enabled.

On 11 January 2015 at 15:02, Ammar Zuberi <ammar@fastreturn.net> wrote:

...

I’m stuck trying to find a virtual router environment that I can play with flowspec on. We do have some Juniper routers, but they are in production and I don’t think I want to touch flowspec on them just yet.

Does anyone have any experience or any ideas here? Even openbgpd?

...

On Jan 11, 2015, at 6:58 PM, Roland Dobbins <rdobbins@arbor.net> wrote:

On 11 Jan 2015, at 20:52, Ca By wrote:

...

1. BCP38 protects your neighbor, do it. It's to protect yourself, as well. You should do it all the way down to the transit customer aggregation edge, all the way down to the IDC access layer, etc.

...

2. Protect yourself by having your upstream police Police UDP to some baseline you are comfortable with. This will come back to haunt you, when the programmatically-generated attack traffic 'crowds out' the legitimate traffic and everything breaks.

You can only really do this for ntp.

...

3. Have RTBH ready for some special case. S/RTBH and/or flowspec are better (S/RTBH does D/RTBH, too).

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

On 11 Jan 2015, at 22:07, Job Snijders wrote:

You can also consider adding CHARGEN and SSDP.

People run all sorts of strange things on arbitrary ports - like VPNs, for example. It isn't that simple. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>

* "Roland Dobbins" <rdobbins@arbor.net>

On 11 Jan 2015, at 20:52, Ca By wrote:

...

3. Have RTBH ready for some special case.

S/RTBH and/or flowspec are better (S/RTBH does D/RTBH, too).

But are there any transit providers that support flowspec these days? As I understand it, only GTT used to, but they stopped. I'd love to use flowspec over D/RTBH, but to me it seems like vapourware. Tore

* "Roland Dobbins" <rdobbins@arbor.net>

On 12 Jan 2015, at 16:19, Tore Anderson wrote:

...

I'd love to use flowspec over D/RTBH, but to me it seems like vapourware.

I meant on your own infrastructure, apologies for the confusion.

Right. So if I first need to accept the traffic onto my infrastructure before I can discard it, I'm dead in the water anyway: My uplinks will sit there at 100% ingress utilisation, dropping legitimate traffic. /32 or /128 D/RTBH announcements towards my transits is my only real option at this point. That helps protect against collateral damage, and if the customer's audience is local, it can also restore full operation for the attacked customer's primary markets (which are usually reached via peers instead of transits). For attacks that are conveniently sized smaller than my upstream capacity, I could see that flowspec could be useful, but not in a unique way, as inside my own network I can easily distribute targeted stateless discard ACLs in many other ways too (I use Netconf currently).

Transit providers utilizing Juniper aggregation edge routers could do it now - why they don't, I don't know.

I'd definitively be willing to pay a premium for such a feature. Tore

Hello! But abuse@ contacts is very-very-very hard way to contacting with ASN administrator in case of attack. Big amount of requests to #Nanog about "please contact ASN XXXX noc with me offlist" confirms this. I'm got multiple attacks from well known ISP and I spend about 10-20 hours to contacting they in average. It's unacceptable time We need FAST and RELIABLE way to contacting with noc of attackers network for effective attack mitigation. We need something like RTBH for knocking network admin of remote network. Maybe somebody can create social network for noc's with API ?:) On Sun, Jan 11, 2015 at 11:55 PM, Owen DeLong <owen@delong.com> wrote:

...

On Jan 11, 2015, at 05:07 , Mike Hammett <nanog@ics-il.net> wrote:

Why does it seem like everyone is trying to "solve" this the wrong way?

Because it’s what we CAN do.

...

Do other networks' abuse departments just not give a shit? Blackhole all of the zombie attackers and notify their abuse departments. Sure, most of the owners of the PCs being used in these scenarios have no idea they're being used to attack people, but I'd think that if their network's abuse department was notified, either they'd contact the customer about it issue or at least have on file that they were notified. When the unknowing end-user reached out to support over larger and larger parts of the Internet not working, they'd be told to clean up their system.

The way to stop this stuff is for those millions of end users to clean up their infected PCs.

Agreed… However, let’s look at it from an economics perspective…

The average residential service provider doesn’t have the resources and doesn’t charge enough to build the resources to deal with this onslaught. It won’t be the service provider that the attacker blames for the initial few disconnections, it will be the websites in question.

So, let’s say XYZ.COM <http://xyz.com/> is a really popular site with lots of end-users. Some of those end-users are also unknowingly attacking XYZ.COM <http://xyz.com/>.

XYZ.COM <http://xyz.com/> black holes those customers (along with all the other zombies attacking them).

XYZ.COM <http://xyz.com/> gets angry calls from those customers and has no ability to contact the rest. The rest don’t call their ISP or XYZ.COM <http://xyz.com/> because they don’t know that they are unsuccessfully trying to reach XYZ.COM <http://xyz.com/>, so they don’t see the problem.

Depending on hold times, etc., XYZ.COM <http://xyz.com/> loses some fraction of their customers (who instead of cleaning up their system, move into the second group who don’t care about the problem any more.) The rest may clean up their systems.

So, at the cost of some fraction of their customer base and a substantial burden on their call center, XYZ.COM <http://xyz.com/> has managed to clean up a relatively small percentage of systems, but accomplished little else.

I’m all for finding a way to do a better job of this. Personally, I’d like to see some sort of centralized clearing house where credible reporters of dDOS information could send some form of standardized (automated) report. The clearing house would then take care of contacting the responsible ISPs in a scaleable and useful manner that the ISPs could handle. Because the clearing house would be a known credible source and because they are providing the information in a way that the ISP can more efficiently utilize the information, it MIGHT allow the ISP to take proactive action such as contacting the user and addressing the problem, limiting the user’s ability to send dDOS traffic, etc.

However, this would require lots of cooperation and if such a clearing house were to evolve, it would probably have to start as a coalition of residential ISPs.

Owen

-- Sincerely yours, Pavel Odintsov