Re: DDOS solution recommendation

>> 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. I have encountered where they are willing to offer 100% sla for *their* DDOS mitigation equipment in the cloud. Not for your

Re: DDOS solution recommendation

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

Re: DDOS solution recommendation

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 bei

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 s

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

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

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

Re: DDOS solution recommendation

On Sun, Jan 11, 2015 at 5:07 AM, Mike Hammett 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 t

Re: DDOS solution recommendation

On 11 Jan 2015, at 20:50, Patrick W. Gilmore wrote: 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. Concur 100%. Unf

Re: DDOS solution recommendation

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 -

Re: DDOS solution recommendation

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 antispoofin

Re: DDOS solution recommendation

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 polic

Re: DDOS solution recommendation

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, a

Re: DDOS solution recommendation

On Sun, Jan 11, 2015 at 09:58:12PM +0700, Roland Dobbins wrote: >> 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 traf

Re: DDOS solution recommendation

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 wrote: > I’m stuck trying to find a virtual router environment that I can play with > flowspec on. We do have some Juniper router

Re: DDOS solution recommendation

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

Re: DDOS solution recommendation

On Sun, Jan 11, 2015 at 6:58 AM, Roland Dobbins 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 acces

Re: DDOS solution recommendation

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 wrote: I’m stuck

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

Re: DDOS solution recommendation

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

Re: DDOS solution recommendation

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 Kam

Re: DDOS solution recommendation

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 Kam

Re: DDOS solution recommendation

Hello! If you speaking about ISP "filtering" you should check your subnets and ASN here: https://radar.qrator.net I was really amazed amount of DDoS bots/amplificators in my network. On Sun, Jan 11, 2015 at 6:47 PM, Michael Hallgren wrote: > Le 11/01/2015 14:50, Patrick W. Gilmore a écrit : >>

Re: DDOS solution recommendation

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 ha

Re: DDOS solution recommendation

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

Anyone from EPOCH Internet/MegaPath?

Hi, The AS number we were assigned by ARIN (AS14558) was previously owned by DANDY and was in the EPOCH routing registry. We get conflicting route generations from IRR due to this, is there anyone that can contact me off-list and get this done or does anyone have any suggestions on how I can go

Re: DDOS solution recommendation

On Sun, Jan 11, 2015 at 6:46 AM, Mike Hammett wrote: > 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, blackho

Re: DDOS solution recommendation

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" wrote: >I didn't necessarily think I was shattering minds with my ide

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

Re: Anyone from EPOCH Internet/MegaPath?

I'm seeing what appear to be old route objects with origin AS14558 on several other registries. I would recommend you review those and reach out to those registries while you are trying to find a Megapath contact. Maybe theres should be a world 'clean up IRR' day. Getting ARIN to wipe the ob

Re: DDOS solution recommendation

On Jan 11, 2015, at 15:28 , Colin Johnston 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@.

Re: DDOS solution recommendation

> On Jan 11, 2015, at 05:07 , Mike Hammett 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 department

Re: DDOS solution recommendation

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" To:

Re: DDOS solution recommendation

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 noc with me offlist" confirms this. I'm got multiple attacks from well known ISP and I spend about 10-20 hours to contactin

Re: DDOS solution recommendation

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

Re: DDOS solution recommendation

peeringdb.com is usually quite accurate. -- Stephen On 2015-01-11 4:11 PM, Pavel Odintsov wrote: 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 noc with me offlist" co

Re: DDOS solution recommendation

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. There's more going on than UDP spoofing\amplification. Frankly the most damaging thing to me has been SMTP hi

Re: DDOS solution recommendation

On Sun, Jan 11, 2015 at 5:07 AM, Mike Hammett 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 d

Re: DDOS solution recommendation

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: Skip the screenshots entirely, if you want, and just read the textual slides at the beginning and the end. -

Re: DDOS solution recommendation

On 11 Jan 2015, at 23:09, valdis.kletni...@vt.edu wrote: > Sounds like RFC1925, section 4 should be top of the list? Indeed - as well as section 8. ;> --- Roland Dobbins

Re: DDOS solution recommendation

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

Re: DDOS solution recommendation

In message <54b31bbe.3000...@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

Re: DDOS solution recommendation

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 wh

Recommended L2 switches for a new IXP

Dear Nanog community We are trying to build a new IXP in some US Metro areas where we have multiple POPs and I was wondering what do you recommend for L2 switches. I know that some IXPs use Nexus, Brocade, Force10 but I don't personally have experience with these switches. It would be great if you

Re: DDOS solution recommendation

In message <54b34a12.4000...@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