Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

1/26/2016
10:30 AM
Vincent Berk
Vincent Berk
Commentary
Connect Directly
Twitter
RSS
E-Mail vvv
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
Threaded  |  Newest First  |  Oldest First
theb0x
100%
0%
theb0x,
User Rank: Ninja
1/26/2016 | 1:00:57 PM
NetFlow vs SFlow
My experience with either NetFlow or SFlow has been extremely poor with all the Sonicwall NSA series firewalls. Even the highest model such as the NSA 6600, the statistical data gathered is completely inaccurate in terms of internal or external bandwidth consumption. It is not possible to correct the issue due to lack of complete protocol support in the firmware Dell provides. Sonicwall uses incorrect active timeout packets. Even adjusting this timeout does not correct the issue. This applies to both NetFlow v5 and v9. This is because Sonicwall uses different Netflow9-packets which do not fully comply with the standard of Cisco Netflow 9 packets (for which all sensors are developed for). If you or anyone is looking for a reliable enterprise grade firewall that supports NetFlow or Sflow functionallity, do not use Sonicwall. At just under $20,000 dollars for a Sonicwall NSA 6600...lack of NetFlow support makes it complete garbage.
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.
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.
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.
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?
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.
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.
RetiredUser
50%
50%
RetiredUser,
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.    
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?
RetiredUser
50%
50%
RetiredUser,
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:25:19 AM
DDoS Detection?
Thanks, nice article, enjoyed reading it. It is sad that all we can talk about detection.
Sodinokibi Ransomware: Where Attackers' Money Goes
Kelly Sheridan, Staff Editor, Dark Reading,  10/15/2019
Data Privacy Protections for the Most Vulnerable -- Children
Dimitri Sirota, Founder & CEO of BigID,  10/17/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
2019 Online Malware and Threats
2019 Online Malware and Threats
As cyberattacks become more frequent and more sophisticated, enterprise security teams are under unprecedented pressure to respond. Is your organization ready?
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-13545
PUBLISHED: 2019-10-18
In Horner Automation Cscape 9.90 and prior, improper validation of data may cause the system to write outside the intended buffer area, which may allow arbitrary code execution.
CVE-2019-13541
PUBLISHED: 2019-10-18
In Horner Automation Cscape 9.90 and prior, an improper input validation vulnerability has been identified that may be exploited by processing files lacking user input validation. This may allow an attacker to access information and remotely execute arbitrary code.
CVE-2019-17367
PUBLISHED: 2019-10-18
OpenWRT firmware version 18.06.4 is vulnerable to CSRF via wireless/radio0.network1, wireless/radio1.network1, firewall, firewall/zones, firewall/forwards, firewall/rules, network/wan, network/wan6, or network/lan under /cgi-bin/luci/admin/network/.
CVE-2019-17393
PUBLISHED: 2019-10-18
The Customer's Tomedo Server in Version 1.7.3 communicates to the Vendor Tomedo Server via HTTP (in cleartext) that can be sniffed by unauthorized actors. Basic authentication is used for the authentication, making it possible to base64 decode the sniffed credentials and discover the username and pa...
CVE-2019-17526
PUBLISHED: 2019-10-18
** DISPUTED ** An issue was discovered in SageMath Sage Cell Server through 2019-10-05. Python Code Injection can occur in the context of an internet facing web application. Malicious actors can execute arbitrary commands on the underlying operating system, as demonstrated by an __import__('os').pop...