Skip to Content.
Sympa Menu

netsec-sig - Re: [Security-WG] What tools do people use to trigger Zenedge/Oracle Dyn's scrubbing service?

Subject: Internet2 Network Security SIG

List archive

Re: [Security-WG] What tools do people use to trigger Zenedge/Oracle Dyn's scrubbing service?


Chronological Thread 
  • From: David Farmer <>
  • To:
  • Subject: Re: [Security-WG] What tools do people use to trigger Zenedge/Oracle Dyn's scrubbing service?
  • Date: Tue, 20 Nov 2018 16:04:24 -0600
  • Ironport-phdr: 9a23:joPFaR8g+eYjLv9uRHKM819IXTAuvvDOBiVQ1KB40uscTK2v8tzYMVDF4r011RmVBdWds6oMotGVmpioYXYH75eFvSJKW713fDhBt/8rmRc9CtWOE0zxIa2iRSU7GMNfSA0tpCnjYgBaF8nkelLdvGC54yIMFRXjLwp1Ifn+FpLPg8it2O2+557ebx9UiDahfLh/MAi4oQLNu8cMnIBsMLwxyhzHontJf+RZ22ZlLk+Nkhj/+8m94odt/zxftPw9+cFAV776f7kjQrxDEDsmKWE169b1uhTFUACC+2ETUmQSkhpPHgjF8BT3VYr/vyfmquZw3jSRMMvrRr42RDui9b9mRxDmiCgFNzA3/mLZhNFugq1Hux+uvQBzzpTObY2JKPZzfKXQds4aS2pbWcZRUjRMDI2mYIsRDuoOIPtToYnnqFsUqBuxGxOsD/7oxz9GnHD2x6g63Po7EQzdwQwgGtQOvG7Ko9roKacfSOa4x7TLwzXbd/5axDnw5YfSfh0irvyAR698fM7QxEU1CQ/JklSdpZT7Mz+J0ukBqWuW4up6We6xlWIrtRt9rzqyysoql4LHnJgaykre+iV82Is1JcO3SEp8YdO8FZtQqzuVO5JuQs4jWW1ovyc6yqEctZ6meSgKzo4ryADCZPyaa4SI4xTjW/iNITpgmX5odr2yiwyx/EWv0OHwS8253VdQoiZbjtXBt2gB1xnJ5ciGTvt98F2h2TGK1w3L5OFLO1o0la/FJJ472bMwi58TsULZEiDohUr2kbeadl849eiw9+TnfrLmq4eHN4Bqlg7+L74ums2jAeU4KwQPUWeb9P+41L3i5k35XK5KguMsnqnYtpDaOdoUprS/AwBLzoYv9QyzACm739QFzjE7KwdedRmalYn1KhTRL9j5C+uymVKhjG0tyvzbbZP7BZCYAnHdkbupU79n7kNGgF49xMpa6oh8F7QHZv//Rxmi55TjEhYlPlnskK7cA9Jn29ZGVA==

> So did anyone do an actual detection and triggering comparison of Arbor Peakflow Virtual vs Kentik vs FastNetMon? 

In early 2016, we did a head to head evaluation of Arbor Peakflow and FastNetMon (integrated into Radware DefenseFlow).  At the time one of the biggest issues for us was IPv6 support, DefenseFlow supported IPv6, but FastNetMon didn't. I can't recall if this was an issue with FastNetMon itself or the slightly older version of FastNetMon Radware decided to use in their integration. 

We went with PeakFlow integrated with DefenseFlow instead of FastNetMon, besides the IPv6 issue, Peakflow's DDOS detection was better, more reliable, and significantly quicker, allowing mitigations to begin quicker and preventing more of the collateral damage. Further PeakFlow had much better incident reporting capabilities. All in all, Peakflow was a much more mature product.  

We also did a less thorough evaluation of Kentik, their DDOS offering wasn't quite available for Radware at the time, but was available a few months later. In summary, Kentik has many similar capabilities as Peakflow, they were less mature than Peakflow at the time but they were and are catching up quickly. These days my impression is Kentik and Peakflow are head to head with Kentik even taking the lead in several aspects of the product space. We plan to demo Kentik in a few months.

Hope that helps.

On Tue, Nov 20, 2018 at 3:12 PM Magorian, Daniel F. <> wrote:

Thanks Brad and Mark:

 

Having just had a particularly nasty set of false positives autotriggered by RapidBGP, the concern to have a person in the loop is starting to come into focus!

 

So we have no experience with Kentik Detect.  I assume it is a cloud analytics service that you set up vpn tunnels to and send your netflow over; is anyone concerned about sending your netflow to those kind of folks in CA, even tunneled?   Looks easy enough to get started; how much does it cost after the trial period?  

 

I assume folks use it to look at your peering data and a bunch of other analytics off the routers, not just DDoS.

 

So did anyone do an actual detection and triggering comparison of Arbor Peakflow Virtual vs Kentik vs FastNetMon?    Or did everyone get started with one and then stick with that?

 

Dan

 

From: <> On Behalf Of Brad Fleming
Sent: Tuesday, November 20, 2018 3:20 PM
To:
Subject: Re: [Security-WG] What tools do people use to trigger Zenedge/Oracle Dyn's scrubbing service?

 

Here’s the general flow for KanREN..

 

1) We dump IPFIX from our routers to Kentik.

2) Build rules in Kentik which identify traffic patterns we find suspicious.

3) Kentik fires an event to an on-network application we wrote.

           a) It does some basic triage and presents the alarm in a KanREN staff portal.

4) If a human agrees with the alarm we can trigger a scrub route from the web interface.

5) Application does a netconf push to a Juniper vMX trigger box we use for RTBHR, flowspec, sBHR, and scrubbing which then signals to the core network.

 

Releasing the scrub route is currently a manual process. We have to watch the event in the Zenedge dashboard or simply guess when we think the event has passed. Releasing the scrub route is also done via the web interface. We can also add an event via the web interface if a Kentik rule didn’t catch something.

 

All of this could be automated; we’re just worried about false positives in the Kentik ruleset we created. We’re also not 100% we have the API calls correct to get status from the ZE portal. Having a human check it (or communicate with their SOC) provides some degree of final check.

 

We have a few members with /24 assignments from ARIN. For that reason we have to do some routing table tricks to keep those /24s in our internal route table but remove them from all the upstream transit carriers. The attached diagram kinda shows the problem; it was drawn mainly for the internal technical group at KanREN so you might see references to some communities that don’t make sense.

 

And of course we allow BGP-speaking members to signal scrub routes to us directly via community string which makes all the routing messes simpler by a country mile. 

 

If anyone is interested I can share some screenshots of our web interface.

--
Brad Fleming
Assistant Director for Technology
Kansas Research and Education Network
Office:  785-856-9805
Mobile:  785-865-7231
NOC:    785-856-9820

 

 

 

Dan, OSHEAN may be one of those employing Kentik - if you're interested in hearing how OSHEAN integrated Kentik into an automated detection and scrubbing architecture with Akamai let us know. 

 

Attached is an Akamai brief on our implementation, while it does not highlight Kentik, Kentik's analytics engine drives the code we've developed that detects an attack on the OSHEAN network and members.

 

Thanks - Mark

 

Mark Montalto - Vice President

617-827-6928

 



--
===============================================
David Farmer              
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================



Archive powered by MHonArc 2.6.19.

Top of Page