Netflow logs: Monitoring and analysis

What are Netflow logs?

A NetFlow log is a structured record that summarizes a single network flow, or a sequence of packets that share the same source and destination IP address, ports, and protocol. Instead of storing packet contents, the exporting device records the conversation's metadata (addresses, ports, protocol, interface, timestamps, packet count, and byte count) and sends that record to a central log collector. Because only metadata is kept, NetFlow gives network and security teams visibility into every connection on a link.

Why NetFlow logs matter for network and security teams

Most log sources describe what a device or application did. NetFlow describes what moved across the network, and that perspective fills gaps that the other audit logs leave open. A Windows Security log can confirm that a user logged on to a file server, but it will not show that the same server then opened 400 outbound connections to a hosting provider. A firewall that only logs denied traffic says nothing about the allowed sessions that carried data out. Flow records cover both cases because they are generated for traffic that is forwarded by the device, whether or not any rule logged it.

For network operations teams, flow data is the fastest route to answering capacity and performance questions without deploying probes. For security teams, it provides a durable, low-cost record of communication that supports threat hunting and post-incident reconstruction.

What data does NetFlow collect?

Every flow record carries a core set of fields. NetFlow v5 uses a fixed layout, while NetFlow v9 and IPFIX let the exporter define its own field set through templates. The table below lists the fields you will see in nearly every implementation.

NetFlow log example

Native NetFlow v5, v9, and IPFIX records travel as binary UDP datagrams, so you never read them directly. You read them once a collector decodes them, or once a collector re-emits them as text. The example below shows a single flow forwarded by a collector to a syslog server as a syslog message, followed by the parsed view.

<134>Oct 6 10:42:17 flowcol01 netflow: exporter=10.10.1.1 ver=9 src=10.20.4.37 dst=203.0.113.88 sport=51544 dport=443 proto=6 in_if=2 out_if=1  
 pkts=1840 bytes=2417730 tcp_flags=0x1b start=2026-10-06T10:41:02Z end=2026-10-06T10:42:15Z

Netflow protocols

NetFlow Version 5 is still widely supported but cannot describe IPv6 traffic or carry custom fields. Version 9 introduced templates, which let the exporter inform the collector which fields each record contains. A collector that misses the template cannot decode the data records that follow.

IPFIX: The open standard for flow export

IPFIX is the successor to NetFlow v9. It keeps the template model and adds variable-length fields, a shared information model (RFC 7012), and enterprise-specific information elements that vendors use to export fields such as application names or user identifiers. Because it is vendor-neutral, IPFIX is the safer choice when routers, firewalls, and virtual appliances come from different manufacturers. Its registered port is UDP/TCP 4739.

sFlow: Sampling-based network monitoring

sFlow takes a different approach: Instead of building flow records in a cache, the device samples one in every N packets, exports the first bytes of each sampled packet header, and periodically sends interface counters. The collector then estimates traffic totals statistically. This keeps CPU load predictable on switches forwarding hundreds of gigabits, at the cost of exact per-flow byte counts. Short, low-volume connections such as a single beacon to a command-and-control server can be missed entirely at high sampling ratios. sFlow collectors listen on UDP 6343 by default.

NetFlow vs. syslog: Key differences

NetFlow and syslog are both sent by network devices, frequently to the same management subnet, which leads to confusion between the two. They answer different questions. Syslog (RFC 5424) carries event messages: An interface went down, an administrator changed a rule, or a VPN user was authenticated. NetFlow carries traffic summaries. Most mature environments collect both.

The two formats meet in practice when a flow collector or enrichment tool reformats decoded flow records as syslog and forwards them to a centralized logging platform.

How Netflow pipeline works

NetFlow depends on three components working together.

The flow exporter is the network device (router, Layer 3 switch, or firewall) that watches packets on monitored interfaces, groups them into flows, and exports completed records.

The flow collector listens on a UDP port, receives those records, and stores them.

The flow analysis application queries the stored records and turns them into reports, dashboards, and alerts. In smaller environments one product may play the collector and analyzer roles together, while larger networks often run dedicated collectors that forward processed data onward to a log management platform.

How to analyze NetFlow logs

The process below moves from raw export to actionable alerts.

1. Configure the flow exporter. Enable flow monitoring on the interfaces that matter (internet edge, data center core, WAN links), set the collector IP and UDP port, and choose NetFlow v9 or IPFIX where supported. Confirm export with the device's statistics commands.
2. Deploy the flow collector. Stand up a collector that matches the exporter's protocol and port, verify that templates are being received, and confirm that record counts at the collector match the exporter's statistics.
3. Enrich the flow records. Raw records carry only IP addresses. Enrichment adds reverse DNS, geolocation, application names mapped from ports, and, where possible, the user associated with an internal IP at that time (usually derived from DHCP leases or authentication logs). Enriched network flow logs are what make investigations practical.
4. Centralize the records in an analysis platform. Forward enriched records to a flow analyzer, SIEM, or log management platform so they can be searched and retained with your other security data.
5. Query and visualize. Start with top talkers by bytes, top destinations, protocol distribution, and traffic per interface over time. Then look for outliers: internal hosts contacting many internal peers on SMB or RDP, unusual destination countries, or long-lived connections on non-standard ports.
6. Set threshold-based alerts. Convert the patterns you found into alerts, for example outbound byte volume from a single host above its normal range or connections to known malicious IP addresses, and tune thresholds against a few weeks of baseline data to keep false positives manageable.

Integrating NetFlow logs with log management platforms

A flow analyzer on its own answers traffic questions well. Correlating flow data with authentication events, firewall decisions, endpoint changes, and threat intelligence is where security value multiplies, and that requires the records to reach a log management platform.

ManageEngine EventLog Analyzer is one example of a log management platform that takes in flow data through the syslog forwarding pattern. A flow collector or enrichment tool first decodes the NetFlow, IPFIX, or sFlow records into syslog messages and forwards it to EventLog Analyzer.

Netflow log ingestion

The solution ingests those messages through its syslog listener over UDP, TCP, or TLS, the same way it collects from firewalls, routers, switches, and Linux servers. A dedicated flow connector is not needed. The flow records are stored and indexed alongside the authentication, firewall, and endpoint logs they need to be compared against, so analysts do not have to switch between a traffic tool and a log console during an investigation.

Parsing flow logs

Flow messages built from key-value pairs or JSON arrive in a format with no predefined parser. EventLog Analyzer's custom log parser extracts the fields that matter for log analysis: source and destination addresses, ports, protocol, byte and packet counts, and flow start and end times. After extraction, these fields can be searched, filtered, and reported on in the same way as fields from natively supported sources. This makes it possible to build traffic-based reports next to existing security and compliance reports.

Flow log correlation

The added security value comes from correlation. A rule can link an unusually large outbound flow with a successful logon from the same internal host shortly before it. It can also tie a permitted firewall connection to a destination listed in a threat intelligence feed, which points to possible data exfiltration or command-and-control traffic that neither data source would clearly show on its own. Alerts from these rules go into the same notification and incident workflow as every other detection. The archived flow log records stay available for forensic review and retention requirements.

Threat detection using Netflow data

Flow data exposes behavior that endpoint and application logs may never record. Port scans show up as one source touching many destination ports with few packets per flow. Lateral movement appears as a workstation suddenly opening sessions to dozens of internal hosts on administrative ports. Data exfiltration indicators include large outbound transfers to IP addresses with no prior history, sustained uploads outside business hours, and DNS traffic volumes far beyond normal query sizes. System intrusion and web application attacks are the most common breach patterns, and both leave network traces in flow data even when attackers clear host logs.

Flow log forensics

Because flow records are compact, organizations can keep months of history. During an incident, analysts filter that history for every connection involving a compromised host or a known-bad IP, then reconstruct the timeline: first contact, internal spread, staging, and exfiltration for forensic analysis.

NetFlow log best practices

• Choose the storage format by purpose: Binary nfcapd files are the most space-efficient format for raw flow history and are well suited to traffic analysis tools. JSON or key-value text is larger, but log management platforms search and correlate the former. Many teams keep both, with short-term binary storage at the collector and forwarded text records in the central platform for security use.
• Reduce volume deliberately: Export only from interfaces that matter, filter out known high-volume, low-risk traffic such as backup replication between two fixed hosts, and use sampling on very high-speed links where exact counts are not needed. Aggregate records for long-term trend reporting, but preserve full records for the period your incident response process needs.
• Set retention to your strictest requirement: PCI DSS v4.0 Requirement 10.5.1 calls for at least 12 months of audit log history, with the most recent three months immediately available for analysis. Other frameworks and internal policies vary, so map flow retention to the most demanding obligation that applies to the networks you monitor.
• Size and distribute collectors by flows per second: Measure fps at peak, plan for incident spikes, and split exporters across regional collectors before a single collector starts dropping packets. Monitor the collector host's UDP receive buffer errors, since drops there are the first sign of saturation.
• Keep templates in sync: For NetFlow v9 and IPFIX, set the exporter's template refresh interval short enough (60 seconds is common) that a restarted collector can decode records quickly. Long intervals produce gaps in data after every collector restart.
• Tune alert thresholds against a baseline: Collect two to four weeks of flow data before enforcing volume-based alerts, set thresholds per segment rather than globally, and revisit them after network changes such as new sites or cloud migrations.