Home > Articles > NetFlow for Cybersecurity

NetFlow for Cybersecurity

Chapter Description

In this sample chapter from CCNA Cyber Ops SECOPS 210-255 Official Cert Guide, readers learn how to configure basic NetFlow in a Cisco device. Content also covers the industry standard IPFIX as well as how NetFlow is used for cybersecurity and incident response.

IPFIX

The Internet Protocol Flow Information Export (IPFIX) is a network flow standard led by the Internet Engineering Task Force (IETF). IPFIX was created to develop a common, universal standard of export for flow information from routers, switches, firewalls, and other infrastructure devices. IPFIX defines how flow information should be formatted and transferred from an exporter to a collector. IPFIX is documented in RFC 7011 through RFC 7015 as well as RFC 5103. Cisco NetFlow Version 9 is the basis and main point of reference for IPFIX. IPFIX changes some of the terminologies of NetFlow, but in essence they are the same principles of NetFlow v9.

IPFIX defines different elements that are placed into 12 groups according to their applicability:

  1. Identifiers

  2. Metering and exporting process configuration

  3. Metering and exporting process statistics

  4. IP header fields

  5. Transport header fields

  6. Sub-IP header fields

  7. Derived packet properties

  8. Min/Max flow properties

  9. Flow timestamps

  10. Per-flow counters

  11. Miscellaneous flow properties

  12. Padding

IPFIX is considered to be a push protocol. Each IPFIX-enabled device regularly sends IPFIX messages to configured collectors (receivers) without any interaction by the receiver. The sender controls most of the orchestration of the IPFIX data messages. IPFIX introduces the concept of templates, which make up these flow data messages to the receiver. IPFIX also allows the sender to use user-defined data types in its messages. IPFIX prefers the Stream Control Transmission Protocol (SCTP) as its transport layer protocol; however, it also supports the use of the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) messages.

Traditional Cisco NetFlow records are usually exported via UDP messages. The IP address of the NetFlow collector and the destination UDP port must be configured on the sending device. The NetFlow standard (RFC 3954) does not specify a specific NetFlow listening port. The standard or most common UDP port used by NetFlow is UDP port 2055, but other ports, such as 9555, 9995, 9025, and 9026, can also be used. UDP port 4739 is the default port used by IPFIX.

IPFIX Architecture

IPFIX uses the following architecture terminology:

  • Metering process (MP): Generates flow records from packets at an observation point. It timestamps, samples, and classifies flows. The MP also maintains flows in an internal data structure and passes complete flow information to an exporting process (EP).

  • Exporting process (EP): Sends flow records via IPFIX from one or more MPs to one or more collecting processes (CPs).

  • Collecting process (CP): Receives records via IPFIX from one or more EPs.

IPFIX Mediators

IPFIX introduces the concept of mediators. Mediators collect, transform, and re-export IPFIX streams to one or more collectors. Their main purpose is to allow federation of IPFIX messages. Mediators include an intermediate process (ImP) that allows for the following:

  • For NetFlow data to be kept anonymously

  • For NetFlow data to be aggregated

  • Filtering of NetFlow data

  • Proxying of web traffic

  • IP translation

IPFIX Templates

An IPFIX template describes the structure of flow data records within a dataset. Templates are identified by a template ID, which corresponds to set ID in the set header of the dataset. Templates are composed of “information element (IE) and length” pairs. IEs provide field type information for each template.

A standard information model covers nearly all common flow collection use cases, such as the following:

  • The traditional 5-tuple (source IP address, destination IP address, source port, destination port, and IP protocol)

  • Packet treatment such as IP next-hop IPv4 addresses, BGP destination ASN, and others

  • Timestamps to nanosecond resolution

  • IPv4, IPv6, ICMP, UDP, and TCP header fields

  • Sub-IP header fields such as source MAC address and wireless local area network (WLAN) service set identifier (SSID)

  • Various counters (packet delta counts, total connection counts, top talkers, and so on)

  • Flow metadata information such as ingress and egress interfaces, flow direction, and virtual routing and forwarding (VRF) information

Option Templates

Option templates are a different type of IPFIX template used to define records referred to as “options” that are associated with a specified scope. A scope may define an entity in the IPFIX architecture, including the exporting process, other templates, or a property of a collection of flows. Flow records describe flows, and option records define things other than flows, such as the following:

  • Information about the collection infrastructure

  • Metadata about flows or a set of flows

  • Other properties of a set of flows

Introduction to the Stream Control Transmission Protocol (SCTP)

IPFIX uses SCTP, which provides a packet transport service designed to support several features beyond TCP or UDP capabilities. These features include the following:

  • Packet streams

  • Partial reliability (PR) extension

  • Unordered delivery of packets or records

  • Transport layer multihoming

Many refer to SCTP as a simpler state machine (compared to the features provided by TCP) with an “a la carte” selection of features. PR-SCTP provides a reliable transport with a mechanism to skip packet retransmissions. It allows for multiple applications with different reliability requirements to run on the same flow association. In other words, it combines the best effort reliability of UDP while still providing TCP-like congestion control. SCTP ensures that IPFIX templates are sent reliably by improving end-to-end delay. RFC 6526 introduces additional features such as per-template drop counting with partial reliability and fast template reuse.

NetFlow and IPFIX Comparison

key_topic.jpg

IPFIX was derived from NetFlow v9. The IPFIX standard specifications (RFC 5101 and RFC 5102) were co-authored by Benoit Clais, who also co-authored the NetFlow v9 RFC (RFC 3954).

IPFIX introduces several extensions, the most popular of which are the Information Element identifiers. These identifiers are compatible with the field types used by NetFlow v9 that you learned about in the previous sections of this chapter.

There are several similar concepts between NetFlow v9 and IPFIX. The first identifier in NetFlow v9 is called IN_BYTES, and in IPFIX is called octetDeltaCount.

As you learned earlier in this chapter, NetFlow v9 has 127 field types. IPFIX defines 238, many of which are the same as the ones defined in NetFlow v9. IPFIX allows a vendor ID to be specified, whereby the vendor can stick proprietary information into NetFlow.

The Cisco Flexible NetFlow IPFIX Export Format feature allows a NetFlow-enabled device to export packets using the IPFIX export protocol.

5. NetFlow for Cybersecurity and Incident Response | Next Section Previous Section

There are currently no related articles. Please check back later.