Network flow information, via Cisco’s Netflow, Juniper’s Jflow, or more recently, the standards-based IPFIX, is perhaps the most powerful tool for detecting and responding to network attacks. I once attended a security conference, and asked a panel of defense and intelligence security experts (the people who really need to care about security) what was the most important tool to have in their arsenal. They unanimously agreed that Netflow was the most important.
Why?
Netflow allows you to analyze network traffic – not at the packet level, like Ethereal – but at the conversation level. With Netflow, you can easily determine which hosts communicated with each other, on what ports, and for how long. With this information, you can recreate network activity to analyze it for unusual behavior.
How it Works
The Netflow process on a router (or L3 switch) generates a Netflow record for every data flow that passes through the device. Like a phone bill, each call (data flow) that passes through the router is logged in a Netflow record. The record contains the source and destination addresses and ports, the number of bytes transferred, the date, time and duration of the flow, among other info. In this way, Netflow acts much like your cell phone bill: it shows whom you talked to, when, and for how long.
Your router generates these Netflow records, but you will also need a device to collect the records. Netflow collectors are software applications that run on workstations or servers and receive the Netflow records from your router. There are both commercial and open-source Netflow applications that will collect the records and let you search through them. Essentially, they all create a searchable database of flow events. You can search by source IP or port, destination IP or port, number of bytes transferred, time of day, etc. Some collectors provide analytical capabilities that can alert you to anomalies.
Here are a few collectors worth looking at:
- Scrutinizer (Plixer International)
- Lancope
- flowd
What Do I Do With it?
Netflow complements other security tools like IDS or syslog, and allowing you to confirm or refute alerts. For example, let’s say your IDS alerts you that a workstation downloaded a Java exploit. When you look at the alert signature, you see that it is rated at only 60% accurate. In other words, the alert is a true alert only 6 out of 10 times. The rest of the time it is a false alarm. So how do you determine if the workstation really downloaded an exploit?
You could analyze that workstation, examining the files, processes, etc. – a lengthy and disruptive process. Or, you could look at Netflow records to gather corroborative information such as:
- What Internet site did that workstation connect to before and after the exploit was downloaded, and how much data was transferred?
- After that event, did the workstation initiate a connection out of the internal network? To where?
- After that event, did the workstation exhibit suspicious behavior, such as scanning the internal network or making odd DNS requests?
The answer to these questions will help you confirm or refute the IDS alarm and allow you to take appropriate action. Forensically analyzing a user’s workstation is a time consuming process, not to mention disruptive to the user. Netflow data can more easily tell you when further action is necessary.
Here’s another example:
You are concerned that large amounts of data are being exfiltrated from your organization. With Netflow, you can rank hosts by the amount of transferred data. Your mail servers might be at the top of that list, but any other workstations that rank high ought to be investigated.
Unlike full packet capture, Netflow records have the advantage of being relatively small. Capturing full packets is a powerful tool, but in a busy network the amount of data stored can be enormous. Most organizations only capture data for the last week or two. Netflow, by contrast takes up little space. This means storage and retrieval of large amounts of Netflow data are usually not a big issue, so months or years of data are not at all unreasonable.
Setting up Netflow
Setting up Netflow is pretty simple. You need to enable Netflow collection on interfaces and tell the router where to send the records. Here’s a sample configuration for Cisco devices:
! enable Netflow on an interface ! interface GigibitEthernet 0/0 ip route-cache flow exit ! ! Send the Netflow records to a collector at IP address 1.2.3.4. !Port 2055 is the standard UDP port. ! ip flow-export 1.2.3.4 2055 version 5
That’s all you need to do.
Where To Enable Netflow
While you could enable Netflow on every capable device, that would just generate a lot of duplicate information, making it harder to find useful information. Generally speaking, you should enable Netflow on your perimeter devices – Internet routers, extranet routers and WAN routers. You should also enable Netflow on your core devices. This strategy will give you good flow information without generating too many duplicate flow records. There may be other places where you want to record flow data, such as data center distribution devices. These need to be evaluated on a case-by-case basis.
Netflow version 5 is currently the most widely used version. Version 9 is the latest version of Netflow, and contains additional flow information. It is now an open standard, called Internet Protocol Flow Information eXport (IPFIX). You can read about IPFIX in RFC 5101.
With information on all the flows through your network, you have a powerful tool for understanding how data flows through your network. Armed with this data, you can start to compare normal traffic to anomalous traffic and begin to identify devices that have suspicious activity.