Netflow
To plagiarize Wikipedia, “NetFlow is a feature introduced on Cisco routers to provide the ability to collect IP network traffic as it enters or exits an interface. By analyzing the data provided by NetFlow, a network administrator can determine things such as the source and destination of traffic, class of service, and the causes of congestion.”
Today, NetFlow is usually associated with metadata collection. It is a very useful way to generate meaningful information that a network administrator will be able to leverage to troubleshoot a network issue. From a monitoring perspective, it is essentially aggregated data samples from the network. This makes it different from packet data, which is a copy of the exact data in a packet. With packet data, you get copies of the actual packet, not high level flow data like you get with NetFlow. Both data formats are necessary as monitoring tools are built for only one of these specific formats, not both.
Purpose of NetFlow
The first version of NetFlow was introduced in 1996 by Cisco as a proprietary protocol. It went through some important milestones like version 5 (in 2009). It was later harmonized with the IETF Internet Protocol Flow Information Export (IPFIX) standard and versions 9 and 10 of NetFlow now support IPFIX. Version 5 and 9 are probably the most ubiquitous versions today. They are used in many network routers and switches. IPFIX, which introduced user defined flow keys, was an important improvement.
NetFlow works by having devices, like network routing equipment and monitoring equipment (e.g. network packet brokers) that are called “exporters or generators”, create the NetFlow data and forward it to other devices, called “collectors” (typically dashboards like Splunk or something), that compile the data into meaningful information.
The following parameters form the basic subset of information contained within NetFlow data:
- Ingress interface (SNMP index)
- Source IP address
- Destination IP address
- IP protocol
- Source port for UDP and TCP (0 for other protocols)
- Destination port for UDP and TCP, type and code for ICMP, or 0 for other protocols
- IP Type of service
Typical Use Cases
A typical monitoring setup using NetFlow consists of three main components:
- The “flow exporter” which aggregates packets into flows and exports flow records toward flow collectors
- The “flow collector” responsible for reception, storage and pre-processing of flow data received from the flow exporter
- And the analyzing application which will complete advanced flow processing to detect intrusion detection for example.
When implemented, these components allow you to enhance the following efforts:
- Reduce network and application troubleshooting time and effort
- Discover indicators of compromise that can help you improve your threat detection process
- Conduct application-level filtering
- Improve regulatory compliance initiatives
- Maximize performance monitoring efforts
Considerations
Here are some things to keep in mind when considering NetFlow-based monitoring solutions.
**What NetFlow versions does your equipment support? **– NetFlow variations occurred as the versions progressed. There are differences between version 5 and version 9 (which supports IPFIX protocol mentioned earlier). Version 9 also introduced user defined flow keys, which was a major enhancement and allows for additional NetFlow information, i.e. extensions to NetFlow to be created by vendors.
For instance, Ixia solutions like the Advanced and Threat Intelligence Processor product, using something called IxFlow (created by Ixia) that supports the following extensions to NetFlow:
- The operating system
- User browser type
- User device type (handheld, laptop…)
- Geo-location information (Country code, client and server city, etc.)
- Application information (name and ID)
- Service provider
Make sure you have the right equipment (infrastructure, packet brokers, and monitoring tools) that supports the NetFlow version you want to use.
Your monitoring needs – What problems are you trying to solve and what data do you need? For instance, do you need flow data or packet data? Do you need both? Do you need geo-location and other additional NetFlow data that are extensions to the basic protocol? These are the questions you need to ask yourself.