Re: automatic rtbh trigger using flow data

On Fri 2018-Aug-31 13:35:29 -0500, Aaron Gould wrote: * btw, what can you experts tell me about tcp-based volumetric attacks... please help me to understand... does tcp have an inherent inability to ramp-up to massive speeds/loads with it's sliding window and must-rcv-ack-before sending more

RE: automatic rtbh trigger using flow data

(I think this is all about volumetric attacks btw...it's my belief that slow-and-low attacks are continually occurring and are going largely unnoticed...i'll speak for myself) Few years ago we began seeing certain ports used as attack vectors, thus we began our internet boundary policers for

RE: automatic rtbh trigger using flow data

>many operators doing this have concentrated on common >port-pairs observed in UDP reflection/amplification attacks. Yes, because that's a great starting point. > And when we're using techniques like >QoSing down certain ports/protocols, we must err on the side of caution, Arbor report

Weekly Routing Table Report

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to

RE: automatic rtbh trigger using flow data

> Ryan Hamel wrote : > I also want to make clear to Michel, that colo'ing a router at an ISP is no > different than plugging it into your local router, your uplink will get > saturated beyond what it can physically handle with only the ACLs protecting > the other side, but if your clients are

Re: automatic rtbh trigger using flow data

On 31 Aug 2018, at 23:53, Lotia, Pratik M wrote: Instead of rtbh I would suggest blocking/rate limiting common ports used in DDoS attacks. This isn't an 'instead of', it's an 'in addition to'. And it must be done judiciously; many operators doing this have concentrated on common

RE: automatic rtbh trigger using flow data

Instead of rtbh I would suggest blocking/rate limiting common ports used in DDoS attacks. That will block 90% of the DDoS attacks. We recently open sourced a BGP Flowspec based tool for DDoS Mitigation. It applies Flowspec rules per victim IP Addr.

Re: automatic rtbh trigger using flow data

On 31 Aug 2018, at 22:15, Hugo Slabbert wrote: I would love an upstream that accepts flowspec routes to get granular about drops and to basically push "stateless ACLs" upstream.

Re: automatic rtbh trigger using flow data

On 31 Aug 2018, at 16:33, Ryan Hamel wrote: From experience, sflows are horribly inaccurate for DDoS detection, since the volume could disrupt the control plane and render the process useless, thus not giving data to the external system to act upon it. On the contrary, flow telemetry in

Re: automatic rtbh trigger using flow data

On Fri 2018-Aug-31 06:59:29 +0700, Roland Dobbins wrote: On 31 Aug 2018, at 6:47, Aaron Gould wrote: I'm really surprised that you all are doing this based on source ip, simply because I thought the distribution of botnet members around the world we're so extensive that I never really

Re: automatic rtbh trigger using flow data

I think your experience has to do more with your setup than sflow or influxdb... my sflow data, that i push into influxdb. is 1 on 1 accurate with the interface utilization ( even on group by per source ip ) Arista performs fine with sflow Don't know what brand you used. I'm getting 300

RE: automatic rtbh trigger using flow data

From experience, sflows are horribly inaccurate for DDoS detection, since the volume could disrupt the control plane and render the process useless, thus not giving data to the external system to act upon it. You can't get any better than mirroring your inbound transit, and sampling the output

Re: automatic rtbh trigger using flow data

Most of the solutions mentioned are paid, or fastnetmon is partially paid. And the thing you want is paid i believe Nice tool though, not saying anything against it. However My personal view is, as long as you can store your flow info in a timeseries database (like influxdb and NOT SQL