|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: nanog@nanog.org From: Ammar Zuberi <ammar@fastreturn.net> In-Reply-To: <CABSP1OefmB250hVOt=i0knTHC-1vrtLVwHrQOidi8JoF80TaSA@mail.gmail.com> Date: Sun, 11 Jan 2015 10:30:22 +0400 To: Damian Menscher <damian@google.com> Cc: NANOG mailing list <nanog@nanog.org> Errors-To: nanog-bounces@nanog.org You'd notice that most people don't really know how big the attack that they= 're sending is. I've done a lot of research into how these attacks actually w= ork and most of them are done by kids who don't really know what they're doi= ng. To them an attack is something that will take their target down (usually a h= ome connection or a game server). If this doesn't happen, they fire off comp= laints to the person that runs the DDoS service. Its a whole industry out there, and they're generally far ahead of us. Ammar > On 11 Jan 2015, at 9:43 am, Damian Menscher <damian@google.com> wrote: >=20 >> On Sat, Jan 10, 2015 at 8:37 PM, Paul S. <contact@winterei.se> wrote: >>=20 >> 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 wil= d, >> it's very unlikely that you need to mitigate anything close. >=20 > 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. >=20 > The average attack is usually around the 10g mark (That too barely) -- so >> even solutions that service up to 20g work alright. >=20 > 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.) >=20 > 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. >=20 >=20 > 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. >=20 > Damian >=20 >> On 1/11/2015 =E5=8D=88=E5=BE=8C 12:48, Damian Menscher wrote: >>=20 >>> On Thu, Jan 8, 2015 at 9:01 AM, Manuel Mar=C3=ADn <mmg@transtelco.net> w= rote: >>>=20 >>> 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 th= e >>>> advantages/disadvantages of using a cloud base vs an on-premise solutio= n. >>>> It would be great if you can share your experience on this matter. >>>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>> On Sat, Jan 10, 2015 at 4:19 PM, Charles N Wyble <charles@thefnf.org> >>> wrote: >>>=20 >>> Also how are folks testing ddos protection? What lab gear,tools,methods >>>> are you using to determine effectiveness of the mitigation. >>>=20 >>> 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 t= o >>> your needs. There are also legitimate companies that do network stress >>> testing. >>>=20 >>> 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. >>>=20 >>> Damian >>=20 >>=20
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |