The next threat could emerge anywhere on the network and when it does, what will you rely on to gain insight into its traffic patterns? Moving the packet analyzer to just the right location simply cannot be done soon enough as often times, it’s too late. Perhaps it happened weeks ago in a corner of the network where little or no traffic monitoring is taking place. What would you do?
Turn to the Flows
NetFlow and IPFIX have typically been used by IT staff to reactively follow up on network performance complaints. In the past few years however, it is being used more and more to follow up on potential malware activities. For these reasons, flow technology has had to evolve in order to help IT determine whether the poor network performance is attributed to utilization or response time, as well as assist with forensic sleuthing. To better deal with these objectives, NetFlow v9 and IPFIX introduced new metrics not possible with NetFlow v5.
The most popular new details being exported in flows today are layer 7 application name (e.g. Skype, Facebook, Citrix, Webex, etc.), round trip time, retransmits and HTTP Host/URL. Although not all vendors support these elements, popularity has grown to over two-dozen vendors. This exciting new paradigm has also introduced a problem, as many collector vendors need time to update their decode engines to take advantage of the new elements. Although IPFIX has the capability to make provisions for dynamic element adoption in RFC 5610 only a couple vendors have added it to their export. Without support for RFC 5610, IPFIX faces the same conundrum that packet-capture and SNMP suffers from: the need for decode libraries and MIB files respectively.
How the flow data is displayed is one of the many criteria that sets flow consuming vendors apart. Flow reporting needs to provide the ability to narrow in on problems fast. For this reason, it is generally defined by two important traits: filtering and reporting options.
Narrowing in on the desired traffic is sometimes a practice of trial and error. During the process, filters are added that include or exclude certain attributes. If the desired results are not the outcome, the filter is removed and another is added. Most vendors provide the user with a fixed number of default filtering options ranging from IP address (es), ports, autonomous system, interface, next hop, etc. The choices are pretty much restricted to the information exported in NetFlow v5, which can be very limiting.
A better strategy, taken by some reporting vendors, is to allow the consumer to leverage any element that is exported in the flow template. For example, if MAC address, packet loss, round trip time, URL, etc. are in the template, the user can add the element to the filter, match specified criteria and include the value based on logic such as: greater than, less than, equal to, not equal to, like, etc. Usually, numerous filters can be added to the report in an effort to focus in on the desired flows. Filtering alone, however, is not enough.
During the process of adding filters, often times the report needs to change in order to expose information that the user needs to filter on. At times, users want to begin the investigation process by removing ‘noise’ around the selected time frame. By reporting on ports or protocols, the administrator can exclude subnets or protocols such as TCP and ICMP in order to focus on UDP or other traffic type. Below is an example of a solution that allows the user to filter on any element in a selected template (e.g. HTTP Host = youtube).
Some reporting solutions provide a custom report creator, which empowers the user to choose the elements from a selected template as well as specify the columns and the values to group by in the report. These are the telltale signs of an advanced flow reporting and analysis solution as going back to a vendor with a new report request may be met with a quote for professional services.