Advanced NetFlow Traffic Analysis - ipfix Archives

Building a NetFlow Cache: Exporting IPFIX

2013-03-12T20:28:49Z

Most engineers implementing NetFlow or IPFIX know how to get started. Where they sometimes stumble is in the area of a properly structured export with well thought out relationships between the templates. Today I want to provide an good example.

This post on building a NetFlow Cache and exporting IPFIX is pretty deep. For this reason, my prior post on Exporting NetFlow or IPFIX really should be reviewed first. A flow cache entry in a router or switch is built using the first packet between two hosts and the cache table is maintained for all active connections (i.e. flows). When a packet comes into the device, its tuple is compared to existing entries in the cache table. A match of the key fields triggers a flow entry update where packet, byte counts and perhaps other fields are incremented and updated. Packets that don’t match a flow entry are compared to policy (e.g. firewall or ACL rules) and are ultimately dropped or used to create new cache entries. Flow entries are exported to a flow collector periodically based on timers (I.e. Active Timeout) or flow behaviors.
When talking with a vendor about building out a flow cache, it is very important that we first establish what we want to export. For most vendor implementations, this decision is easy and they copy NetFlow v5. Some software developers however, want to take their flow export to another level and provide the very best in Network Traffic Monitoring metrics. To do this, a list of all the details that need to be exported should be created.

All of the data available in NetFlow v5
VoIP details on caller ID, Codec, Jitter and packet loss
Cloud service details on round trip time, URLs and deep packet inspection details that identify tricky applications like Skype, Webex and BitTorrent.
Interface names and speeds to avoid the reporting tools dependency on SNMP
Syslog and trap message details

The next step is to layout the IPFIX elements needed for each template. We have to use IPFIX because in all likelihood your company name isn’t Cisco and even if it is, the list includes elements that will end up being variable length fields such as URL and syslog details. These are, for all practical reasons, difficult to export using NetFlow v9. Let’s get started on IPFIX template creation and take the list above one item at a time. Each element name is preceded by an IANA or a dot separated vendor specific IE.

Be sure to take notice that IANA defined IEs are always the preference over vendor specific IEs. The vendor specific IEs are followed by the vendor Private Enterprise Number (PEN) (e.g. .32473).

A) Template: All of the data available in NetFlow v5/v9. This template is easy to define because all of the information necessary has been defined by IANA:

1 octetDeltaCount
2 packetDeltaCount
4 protocolIdentifier
5 ipClassOfService
6 tcpControlBits

Sent as 0 for non TCP traffic

7 sourceTransportPort
8 sourceIPv4Address
9 sourceIPv4PrefixLength
10 ingressInterface
11 destinationTransportPort
12 destinationIPv4Address
13 destinationIPv4PrefixLength
14 egressInterface
15 ipNextHopIPv4Address
16 bgpSourceAsNumber
17 bgpDestinationAsNumber
21 flowEndSysUpTime
22 flowStartSysUpTime
95 Application ID

This element causes another template below

148 Flow ID

This element is used to link to other templates

The above template is used for all protocols not sent by a more specific template. See below.

B) Template: VoIP details on caller ID, Codec, Jitter and packet loss. These elements are exported using a new template that contains meta data related to the flows exported above for the UDP real-time protocol (RTP). It contains the following IDs:

148 Flow ID

Links to the flow in A)

400.32473 Caller ID
401.32473 Codec
402.32473 Jitter
403.32473 Packet Loss

C) Template: Cloud service details on round trip time, URLs and deep packet inspection details that identify tricky applications like Skype and BitTorrent. These elements are exported using a meta data template similar to the one created in b). In this case however, the template is only used for TCP traffic and includes the following IDs:

148 Flow ID

Links to the flow in a)

501.32473 Round Trip Time
503.32473 URL

D) Template: Interface names and speeds to avoid the reporting tools dependency on SNMP:
- 10 ingressInterface
- 82 interfaceName
- 83 interfaceDescription
- 82.32473 ifSpeed

IMPORTANT: Always check with IANA for the IE before creating one with the company PEN! This helps guarantee wider acceptance from collectors built by different vendors and improves cross vendor reporting.

E) Template: Syslog and trap message details:
- 322 observationTimeSeconds
- 700.32473 Facility
- 701.32473 Severity
- 8 sourceIPv4Address
- 10 ingressInterface
- 12 destinationIPv4Address
- 704.32473 Message

F) Template: Application Name - This template provides the correlation between the application ID and the actual name of the application. There is an effort underway to standardize this export which would allow consistency across vendors.

95 Application ID

Links to the flow in a)

96 Application Name

With the templates above defined, it is time to find an IPFIX software solution that will export the data from your appliance. There are plenty of open source projects on the Internet that can do this. One favorite is IPFIXify which also takes care of the template refresh (e.g. every 1-5 minutes) that has to be reported periodically. IPFIXify also exports the RFC 5610 details. To learn more about the above process, consider purchasing my book on NetFlow and IPFIX titled Unleashing the Power of NetFlow and IPFIX.

Monitoring BYOD traffic with NetFlow

2012-03-24T09:48:50Z

Monitoring BYOD traffic is a growing concern amonst network administrators. Why? Gartner predicts that 645 million smartphones will be sold in 2012 – a 40% increase from this year. Cell phone reception is often weak on the interior of office buildings and smartphone owners will have their WiFi on. What's more is that many companies are allowing employees onto the corporate net with their personal smart phones in hopes of increased productivity.

Employees using Corporate Bandwidth with Personal Phones
This big increase brings with it big concerns when it comes to network monitoring:

How much bandwidth are all these additional devices collectively using and is it impacting business critical applications?
What applications and web sites are users hitting and what impact are these distractions having on productivity and how often?
What are the security implications introduced by allowing these devices onto the net? Many of these hand held devices do not have antivirus software.

Given that the traffic from a cell phone browsing a web site looks nearly identical to that of a PC hitting the same site, how can a company determine the amount of Internet bandwidth utilized by the combined smart phone devices? To answer this, we need a new flow element.

All hardware accessing the LAN utilizes a six byte hexadecimal MAC address. The first three bytes of this address is reserved to identify the vendor. For example, an iPhone may have an address of E4:CE:8F:C2:9D:AA. The first three bytes E4:CE:8F identifies the vendor ‘Apple’ and it is likely that thousands of other iPhones start with the same 3 bytes. The remaining three bytes C2:9D:AA are unique to the individual iPhone.

Nearly a dozen vendors (e.g. Cisco, Enterasys, Exinda, Juniper, nBox, Sonicwall) are now exporting MAC information in their flow exports. Learn how to export [MAC address with Flexible NetFlow] http://www.plixer.com/blog/netflow/getting-mac-addresses-from-netflow-v9/ . Setting up a simple network monitor will help you proactively keep track of this traffic.

Below is an example of our partnership reporting with Enterasys NetFlow and mIAM exports:

If your NetFlow or IPFIX hardware can export Username, you could click on a username and see the number of devices authenticated by the same user.

Monitoring BYOD traffic is a growing concern and the above report can be run against flow exports from the Cisco ASA, Palo Alto Networks and the SonicWALL (example above). Vendors are always looking for new and innovative ways to filter on this data.

[Gartner predicts that 645 million smartphones] http://www.channelinsider.com/c/a/Mobile-Devices/Mobile-Management-Styles-Driven-by-Consumerization-Gartner-634465/ will be sold in 2012 – a 40% increase from this year.   Cell phone reception is often weak on the interior of office buildings and smartphone owners will have their WiFi on. Many companies are allowing employees onto the corporate net with their personal smart phones in hopes of increased productivity.

Employees using Corporate Bandwidth with Personal Phones
This big increase brings with it big concerns when it comes to network monitoring:
1.   How much bandwidth are all these additional devices collectively using and is it impacting business critical applications?
2.   What applications and web sites are users hitting and what impact are these distractions having on productivity and how often?
3.   What are the security implications introduced by allowing these devices onto the net? Many of these hand held devices do not have antivirus software.
Given that the traffic from a cell phone browsing a web site looks nearly identical to that of a PC hitting the same site, how can a company determine the amount of Internet bandwidth utilized by the combined smart phone devices? To answer this, we need a new flow element.

All hardware accessing the LAN utilizes a six byte hexadecimal MAC address. The first three bytes of this address is reserved to identify the vendor. For example, an iPhone may have an address of E4:CE:8F:C2:9D:AA. The first three bytes E4:CE:8F identifies the vendor ‘Apple’ and it is likely that thousands of other iPhones start with the same 3 bytes. The remaining three bytes C2:9D:AA are unique to the individual iPhone.

<<< monitoringMobilePhoneTraffic.png >>>

Nearly a dozen vendors (e.g. Cisco, Enterasys, Exinda, Juniper, nBox, Sonicwall) are now exporting MAC information in their flow exports. Learn how to export [MAC address with Flexible NetFlow] http://www.plixer.com/blog/netflow/getting-mac-addresses-from-netflow-v9/ . Setting up a simple network monitor will help you proactively keep track of this traffic.

If your NetFlow or IPFIX hardware can export Username, you could click on a username and see the number of devices authenticated by the same user.

<<< sonicwall-Ipfix-username.png >>>

Monitoring BYOD traffic is a growing concern and the above report can be run against flow exports from the Cisco ASA, Palo Alto Networks and the SonicWALL (example above). Vendors are always looking for new and innovative ways to filter on this data.

KEY WORDS:
network monitoring
flexible netflow
network monitor
monitoring mobile phone traffic
monitoring byod traffic

big concerns when it comes to network monitoring:

1. How much bandwidth are all these additional devices collectively using and is it impacting business critical applications?

2. What applications and web sites are users hitting and what impact are these distractions having on productivity and how often?

3. What are the security implications introduced by allowing these devices onto the net? Many of these hand held devices do not have antivirus software.

All hardware accessing the LAN utilizes a six byte hexadecimal MAC address. The first three bytes of this address is reserved to identify the vendor. For example, an iPhone may have an address of E4:CE:8F:C2:9D:AA. The first three bytes E4:CE:8F identifies the vendor ‘Apple’ and it is likely that thousands of other iPhones start with the same 3 bytes. The remaining three bytes C2:9D:AA are unique to the individual iPhone.

<<< monitoringMobilePhoneTraffic.png >>>

Nearly a dozen vendors (e.g. Cisco, Enterasys, Exinda, Juniper, nBox, Sonicwall) are now exporting MAC information in their flow exports. Learn how to export [MAC address with Flexible NetFlow] http://www.plixer.com/blog/netflow/getting-mac-addresses-from-netflow-v9/ . Setting up a simple network monitor will help you proactively keep track of this traffic.

If your NetFlow or IPFIX hardware can export Username, you could click on a username and see the number of devices authenticated by the same user.

<<< sonicwall-Ipfix-username.png >>>

Monitoring BYOD traffic is a growing concern and the above report can be run against flow exports from the Cisco ASA, Palo Alto Networks and the SonicWALL (example above). Vendors are always looking for new and innovative ways to filter on this data.

KEY WORDS:

network monitoring

flexible netflow

network monitor

monitoring mobile phone traffic

monitoring byod traffic

NetFlow Behavior Analysis Systems : Limited Impact

2012-01-13T10:24:48Z

NetFlow Network Behavior Analysis (NBA) systems have limited impact on detecting threats. They are only suitable as a second or perhaps third layer of threat detection. Some companies offering NetFlow Threat Detection tools would have you believe otherwise. Don't fall for it. "Gartner says NBA is suitable as a complementary technology to intrusion detection and prevention software, which is effective for addressing network attacks that can be positively identified." As a HUGE NetFlow and IPFIX supporter, I tend to agree that flow technologies can augment security practices, but can't replace them.

What's Missing in NetFlow Threat Detection?
Most NetFlow exports do not include the entire data portion of the packet. Sophisticated threat detection systems require this data in order to compare the contents to a database of signatures.

Can NetFlow Export Packets?
A NetFlow competitor called sFlow exports the entire packet, however its sampling architecture results in frequently missed infected frames. Cisco Smart Logging Telemetry NetFlow technology which is available on the Catalyst 3000 series can export entire packets however, it only exports datagrams that it detected via ACLs. NetFlow-Lite on the Catalyst 4948E can also export entire packets however, in most cases it is configured to sample. The bottom line is that NetFlow and IPFIX collection is not intended for large scale full packet exports. NetFlow does however try to give you 100% of the connection information which can be useful for behavior analysis, but it is still limited.

NetFlow Behavior Analysis systems
Some NetFlow Behavior Analysis systems attempt to detect threats by base lining system behaviors overtime. When a host communicates outside of its normal behavior baseline, its index goes up. If the index goes too high an alarm can be triggered. Because an end systems behavior is constantly changing, the alarm is frequently a false positive.

Certainly NetFlow and IPFIX, but generally not sFlow can be used to accurately detect threats. The point of this post is to educate on why it should only be part of a company's Unified Threat Management solution. NetFlow can be used to accurately detect SYN scans, ICMP redirect issues, DDoS attacks, XMAS scans, etc. In practice, these same algorithms will often also get triggered by legitimate traffic. Experience tells us that IPFIX and NetFlow are ideally suited for accounting and utilization reporting.

Grow Your Internal Threat Detection
Internal threat detection is a growing area of concern in many networks today. Some companies are placing firewalls on backbone links as yet another layer of protection from internal infected hosts. Forrester Research calls for a Zero Trust model where networks are designed from the inside out. "The redesign starts with a black box or network segmentation gateway that can handle high speeds – up to 10G interfaces. The gateway acts like a UTM appliance, but it does much more than provide firewall, antispam and content filtering features. It can add data leakage prevention capabilities, intrusion prevention and encryption to the network" said John Kindervaq, a senior analyst with Forrester Research, Inc. NetFlow is largely about monitoring internal traffic. The Cisco ASA, Palo Alto Networks firewall and the SonicWALL firewall all export NetFlow or IPFIX.

NetFlow's threat detection value belongs as part of a internal UTM effort where potential threats detected are sent to a SEIM which will then look for other messages from appliances witnessing the same behavior of a host. If other threat detection efforts are not detecting the same suspicious behavior perhaps a false positive can be avoided. Here's a thought: maybe the security appliance reporting the bad behavior should have an index whereby its accuracy for detecting legitimate threats could be graded over time.

Although often used as a differentiator by NetFlow reporting companies, the demand for dedicated NetFlow and IPFIX threat detection tools is limited. Detecting security threats with NetFlow Behavior Analysis systems is not often the best primary threat protection due to unpredictable host behaviors and lack of the entire packet. The largest opportunity for threat detection with NetFlow lies in IP Host Reputation lookups.

Join NetFlow Developments on Linkedin.