Attacks/Breaches
1/26/2016
10:30 AM
Vincent Berk
Vincent Berk
Commentary
Connect Directly
Twitter
RSS
E-Mail
50%
50%

NetFlow Or sFlow For Fastest DDoS Detection?

It's still not an easy choice, but combined with the faster NetFlow exporters that have recently come to market, the speed advantage of sFlow is starting to fade.

Successful distributed denial of service (DDoS) triage and mitigation depend on two things: speed of detection and accuracy of detection. When users are considering a DDoS solution, I am often asked if it is best to use NetFlow or sFlow. To understand what is best, we must first take a brief look at the differences between the two types of flow data.

NetFlow (and the very closely related cFlow, JFlow, and IPFIX) is a summary record format, where a router or other exporting device tabulates the statistics on each flow of packets flying by. A flow is typically defined as the 5-tuple of sending IP and port, receiving IP and port, and the protocol. Each packet is tabulated and added to the appropriate row in the table: 1 more packet, X more bytes. State is kept on every flow that the exporter observes, and when a flow is 60 seconds old, the record is sent to the collector, which has the task of detecting the denial of service attack.

sFlow takes a slightly different approach, keeping no state at all. Instead sFlow randomly grabs one in every N packets flying by and immediately sends it to the collector. Although this approach may appear somewhat less accurate than the NetFlow tabulation, it is actually very good for fast DDoS detection. As the flood or amplification attack starts to ramp up, the rate of packets flowing by the exporter starts to increase very rapidly. This means that the number of packet samples going to the collector (which is responsible for the DDoS detection) starts to increase immediately.

Although the NetFlow approach ensures that no packet is missed, which is great for accurate network forensics, the nature of the export timer may result in much slower detections. If the NetFlow exporter has sufficient memory to keep state on all the attack traffic, it may take up to 60 seconds before the detecting collector sees any evidence of the attack! Thankfully though, many newer NetFlow-capable devices can be tuned to export at higher rates, resulting in improved detection times.

Detection accuracy is another matter. Since both sFlow and NetFlow transmit information on sending and receiving port and both transmit information on flag combinations and IP addresses, it is really up to the collector to make an accurate detection. Distinguishing a DNS or NTP amplification attack from a SMURF, or a FRAGGLE attack from a SynFlood, is key in performing effective mitigation. Most triage scenarios (whether using a scrubbing device or manually mitigating) rely on knowing a couple of key factors:

  1. What are the targets being hit?
  2. Are the bit/packet rates sufficiently high to impact the service?
  3. What is the specific type (or types) of attack?

Both NetFlow as well as sFlow provide sufficient detail to accurately make that determination if the detection logic is present in the collector software.

In practice, I have seen both sFlow and NetFlow variants deployed very successfully in DDoS detection. Although I have seen sFlow deployments detect DDoS attacks in as little as 3 seconds, the nature of the Internet has made it such that it can take some time before the attack reaches full strength.

Combined with the faster NetFlow exporters that have recently started to reach the market, the speed advantage of sFlow is starting to fade. Also, keep in mind that many environments will not have a choice, as the exporting hardware is already in place, supporting only a single type of export. So the choice may not be yours, and both approaches can be used to tune and finesse for detection speed and accuracy. Most importantly, if you have both, then use both. The better the visibility, the better your defense.

Dr. Vincent Berk is CEO of FlowTraq with 15 years of IT security and network management experience. He is a member of ACM and the IEEE. View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
Christian Bryant
50%
50%
Christian Bryant,
User Rank: Ninja
1/28/2016 | 10:27:54 AM
Re: SLAC List of Network (both LAN and WAN) Monitoring Tools
I think the value of that list as a general reference is more historical and evolutionary in nature.  For what folks prefer, SANS Institute papers and any one of the reputable security news websites (DR comes to mind) will have a breakdown of what is currently in popular use (or not popular, but recommended by respected InfoSec engineers).
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/27/2016 | 10:37:40 AM
Re: SLAC List of Network (both LAN and WAN) Monitoring Tools
"... you search Stanford(dot)edu for "Monitoring Tools" you'll quickly find it." I like open source option. I just checked it there are two many of them. Is there not any outstanding people use most often than others?
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/27/2016 | 10:31:51 AM
Re: NetFlow vs SFlow
"Sonicwall NSA does not support sFlow or even "netflow". It supports IPFIX, which is the IETF Standard"

Ok. This answers my previous question. Makes sense.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/27/2016 | 10:30:29 AM
Re: Neither of the two for enterprices
"To me an inline DDOS solution that can inspect each and every packet up to the max. bandwidth of the environment is a much better solution. .."

That makes sense, what comes to my mind how this would impact the overall network performance.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/27/2016 | 10:27:36 AM
Re: NetFlow vs SFlow
"My experience with either NetFlow or SFlow has been extremely poor with all the Sonicwall NSA series firewalls. .." Is this about Sonicwall I wonder?
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/27/2016 | 10:25:19 AM
DDoS Detection?
Thanks, nice article, enjoyed reading it. It is sad that all we can talk about detection.
Christian Bryant
50%
50%
Christian Bryant,
User Rank: Ninja
1/26/2016 | 11:21:50 PM
SLAC List of Network (both LAN and WAN) Monitoring Tools
I've only ever used Free and Open Source (FOSS) NMTs, and NetFlow and sFlow were never in my list of apps to review.  However, there are a large number of them out there and I highly encourage people seriously researching what is best for them to take a trip to the SLAC (Stanford Linear Accelerator Center) list of Network (both LAN and WAN) Monitoring Tools.  I've referenced this page for years and there is a nicely organized format ordered by year from 1996 to 2015 (as of my last visit) of over a hundred app, most with live links to the project pages.  I can't add the URL here, but if you search Stanford(dot)edu for "Monitoring Tools" you'll quickly find it.

Now, toward the question, I don't have to have used either to have an opinion; just based on experience with many of the soft solutions out there, I knew I wanted something more.  If you are attacking any major network analysis project, in-line monitoring is the only way to go.  Google it for plenty of good information on in-line bandwidth meters and network interface chips.  I've seen maker projects that built inexpensive in-line setups that would serve the purpose functionally, if not attractively!  Remember, full-duplex is ubiquitous...  Spend wisely and your network tap could become your best friend.    
MikeK103
50%
50%
MikeK103,
User Rank: Apprentice
1/26/2016 | 8:30:15 PM
Re: NetFlow vs SFlow
Sonicwall NSA does not support sFlow or even "netflow". It supports IPFIX, which is the IETF Standard. It is fully compliant with the IPFIX standard. V9 is the precursor to the standard and has been the "de facto standard", but is missing some features like enterprise elements and variable length strings. Initially the exports did not have a proper active timeout, but this has since been remedied in more recent releases. This is NOT a limitation from sonicwall. This is a limitation of the collector you are using. Plixer's Scrutinizer fully supports all Sonicwall IPFIX exports and provides accurate bandwidth and L7 DPI reporting. Any collector that supports their enterprise elements should be accurate. As far as I know, Plixer is the only one with full support... This is the case with many IPFIX exports from other vendors as well. Full disclosure, I work for Plixer. If you have any questions, call Plixer and ask for me "mike k" and I'd be happy to go over it.
MikeK103
50%
50%
MikeK103,
User Rank: Apprentice
1/26/2016 | 8:30:06 PM
Re: NetFlow vs SFlow
Sonicwall NSA does not support sFlow or even "netflow". It supports IPFIX, which is the IETF Standard. It is fully compliant with the IPFIX standard. V9 is the precursor to the standard and has been the "de facto standard", but is missing some features like enterprise elements and variable length strings. Initially the exports did not have a proper active timeout, but this has since been remedied in more recent releases. This is NOT a limitation from sonicwall. This is a limitation of the collector you are using. Plixer's Scrutinizer fully supports all Sonicwall IPFIX exports and provides accurate bandwidth and L7 DPI reporting. Any collector that supports their enterprise elements should be accurate. As far as I know, Plixer is the only one with full support... This is the case with many IPFIX exports from other vendors as well. Full disclosure, I work for Plixer. If you have any questions, call Plixer and ask for me "mike k" and I'd be happy to go over it.
mduijm
50%
50%
mduijm,
User Rank: Apprentice
1/26/2016 | 1:26:29 PM
Neither of the two for enterprices
My experience with DDOS attacks so far is that the detection of SFLOW or NetFlow + the time to redirect the traffic to a cloud based solution is way too long for the environment to sustain, making the DDOS effective immediatly.


To me an inline DDOS solution that can inspect each and every packet up to the max. bandwidth of the environment is a much better solution. This is fast (< 5 sec. detection and blocking). When the attack becomes bigger then you can think of redirection of traffic into the cloud for mitigation over there. Some DDOS cloud providers now offer API's for on-premise DDOS boxes to send them an alert. Then they can start the redirection of traffic towards the cloud.

My believe this is the way forward for Enterprises and smaller ISP's to move forward. For bigger ISP's and Carriers I guess the above story is true.
Page 1 / 2   >   >>
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
DNS Threats: What Every Enterprise Should Know
Domain Name System exploits could put your data at risk. Here's some advice on how to avoid them.
Flash Poll
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7445
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

CVE-2015-4948
Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

CVE-2015-5660
Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

CVE-2015-6003
Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

CVE-2015-6333
Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio

The cybersecurity profession struggles to retain women (figures range from 10 to 20 percent). It's particularly worrisome for an industry with a rapidly growing number of vacant positions.

So why does the shortage of women continue to be worse in security than in other IT sectors? How can men in infosec be better allies for women; and how can women be better allies for one another? What is the industry doing to fix the problem -- what's working, and what isn't?

Is this really a problem at all? Are the low numbers simply an indication that women do not want to be in cybersecurity, and is it possible that more women will never want to be in cybersecurity? How many women would we need to see in the industry to declare success?

Join Dark Reading senior editor Sara Peters and guests Angela Knox of Cloudmark, Barrett Sellers of Arbor Networks, Regina Wallace-Jones of Facebook, Steve Christey Coley of MITRE, and Chris Roosenraad of M3AAWG on Wednesday, July 13 at 1 p.m. Eastern Time to discuss all this and more.