NetFlow and Traffic Flow Analysis

NetFlow is a network protocol developed by Cisco for collecting IP traffic information and monitoring network traffic. It was introduced in the late 1990s as a way to provide network administrators with visibility into traffic patterns without the overhead of full packet capture. The core idea is simple: instead of capturing every packet, routers and switches summarize groups of packets that share common properties into a 'flow record.' A flow is defined as a unidirectional sequence of packets between a given source and destination—sharing the same source IP, destination IP, source port, destination port, protocol, and (for Cisco) the IP type of service (ToS) byte. This 5-tuple (or 6-tuple with ToS) uniquely identifies a conversation.

NetFlow is not a single standard; it has evolved through several versions. Cisco NetFlow versions include v1 (obsolete), v5 (most common for IPv4), v7 (with Cisco Catalyst switches), v8 (aggregation schemes), and v9 (template-based, flexible, supports IPv6 and MPLS). The industry-standard IPFIX (IP Flow Information Export, RFC 7011) is based on NetFlow v9 and is vendor-neutral. For the CS0-003 exam, you must know NetFlow v5 and v9/IPFIX, their differences, and typical use cases.

2. Flow Aging: Flows are removed from the cache (exported) based on aging criteria. Cisco NetFlow uses three timers: - Active flow timeout: Default is 30 minutes. If a flow has been active for this long, it is exported as a 'long-lived flow' and a new flow record is started for subsequent packets. - Inactive flow timeout: Default is 15 seconds. If no packets are seen for this duration, the flow is considered finished and exported. - TCP FIN/RST detection: When a TCP session ends with a FIN or RST, the flow is exported immediately.

- Source IP address (4 bytes) - Destination IP address (4 bytes) - Source port (2 bytes) - Destination port (2 bytes) - Protocol (1 byte) - IP ToS (1 byte) - Input interface index (2 bytes) - Output interface index (2 bytes) - Packet count (4 bytes) - Byte count (4 bytes) - Flow start timestamp (4 bytes, milliseconds since device boot) - Flow end timestamp (4 bytes) - TCP flags (1 byte, OR of all flags observed) - Source AS number (2 bytes) - Destination AS number (2 bytes) - Source mask (1 byte) - Destination mask (1 byte) - Next-hop IP address (4 bytes)

NetFlow v9/IPFIX uses templates, allowing flexible field definitions. Common fields include IPv6 addresses, MPLS labels, VLAN IDs, and application IDs.

On a Cisco IOS router, enabling NetFlow involves:

! Enable flow export
ip flow-export destination 192.168.1.100 2055
ip flow-export version 5
! Enable flow capture on an interface
interface GigabitEthernet0/0
 ip flow ingress
 ip flow egress

Verification commands:

show ip flow export       ! Shows export stats, destination, version
show ip cache flow        ! Shows active flows in cache
show ip flow top-talkers  ! Shows top bandwidth consumers

For NetFlow v9:

ip flow-export version 9
ip flow-export template timeout 60   ! Template refresh interval in minutes

NetFlow is invaluable for: - Anomaly Detection: Sudden spikes in traffic to a specific port (e.g., 445/TCP) may indicate worm propagation. - Data Exfiltration Detection: Large outbound flows to unusual destinations (e.g., cloud storage) at odd hours. - Botnet Identification: Flows to known C2 servers, or regular beaconing (periodic small flows). - Bandwidth Monitoring: Identify top talkers, peak usage times. - Forensics: After an incident, replay flow records to reconstruct communication patterns.

Exam Tip: NetFlow does NOT detect attacks within encrypted traffic (since it doesn't decode payload), but it can detect unusual volumes or patterns that suggest malicious activity.

A large enterprise with 10,000 endpoints deploys NetFlow on all core routers and distribution switches. The flow collector is a cluster of three servers running Elasticsearch, Logstash, and Kibana (ELK). One day, the security team notices a sudden spike in flows to port 445/TCP (SMB) from multiple internal IPs. The analyzer shows that the number of flows per second jumped from 2,000 to 50,000, and the top talkers are all workstations in the finance department. The team immediately isolates the affected VLAN and runs a packet capture on a sample host. The capture confirms EternalBlue exploit traffic. Without NetFlow, the team would have relied on user complaints or SNMP interface counters, which would not have revealed the specific protocol or the internal spread pattern. The misconfiguration risk here is setting the active timeout too high (e.g., 60 minutes), which would delay detection of the outbreak because flows would not be exported until they age out. The team now uses a 10-minute active timeout for better responsiveness.

A cloud service provider uses NetFlow v9 on its edge routers to monitor traffic to external DNS servers. The security analyst configures the flow analyzer to flag any flow where the destination port is 53/UDP and the byte count exceeds 100 bytes per packet (normal DNS queries are ~50-60 bytes). One alert shows a single internal server sending 1,000 flows to an external DNS server with an average packet size of 512 bytes. The flow records show that the queries are to domains like 'data.example.com' with long subdomains (typical of DNS tunneling). The analyst blocks the external IP and investigates the server. NetFlow was critical because it provided per-flow byte counts, which SNMP cannot. A common mistake is to ignore flow data from internal-to-DNS traffic, assuming it's benign. The team now applies a baseline of normal DNS flow sizes and alerts on deviations.

A university with 30,000 students uses NetFlow for bandwidth billing. Each department is charged based on its external traffic volume. The flow collector aggregates bytes per source IP subnet (assigned to departments). NetFlow v5 is used because it is simple and supported on older routers. The challenge is that NetFlow records are unidirectional, so the collector must sum both ingress and egress flows for each IP. The team discovered that some students were using VPNs, which changed the source IP to the VPN server's IP, causing incorrect billing. The solution was to enable NetFlow on the VPN concentrator as well. Performance considerations: the campus core router handles 10 Gbps and generates 200,000 flows per second. With a 64K flow cache, flow cache overflow causes packet drops. The team increased the cache to 512K flows and enabled sampling (1:100) to reduce CPU load. Misconfiguration: setting the inactive timeout too short (e.g., 5 seconds) caused premature export of flows, resulting in many short-lived flows that overwhelmed the collector. The team adjusted to 30 seconds.