nfdump 1.7.8 on Ubuntu 24.04 on Azure User Guide

Overview

nfdump is the de-facto open source toolkit for collecting and analysing NetFlow, IPFIX and sFlow traffic data. nfcapd, the always-on collector, listens for flow exports from your routers, switches and firewalls and writes them to compact per-interval capture files; the nfdump command line tool then queries that archive with a fast, tcpdump-like filter language. It is the collector behind most open flow-analysis stacks and a long-standing staple for network operations centres and internet service providers doing traffic visibility, capacity planning and security investigation.

This image builds nfdump 1.7.8 from the current upstream release rather than the Ubuntu 24.04 archive package, which is still on 1.7.3 (published 2024-04-04, over two years behind at the time this image was built). nfcapd.service runs the collector on UDP port 9995 from the moment the VM boots, writing flows to a dedicated data directory with retention configured out of the box, so the appliance never silently fills its disk.

Security by design

The only two surfaces this appliance exposes are SSH and the flow-collection port. There is no web console, no management API, no database, and no other listener anywhere in this image.

• No source allowlist on the flow port, by design, not by oversight. nfcapd's entire purpose is to accept NetFlow/IPFIX/sFlow from a customer's own routers and switches, which by definition arrive from addresses this appliance cannot know in advance. NetFlow, IPFIX and sFlow carry no authentication of their own in the protocol, so a real NOC's collector accepts from any configured exporter's address too. Scope your Azure network security group to your own exporter address ranges as a hardening step, documented below.
• No login, no bootstrap credential. nfcapd is a headless daemon with no web console and no product account, so there is nothing to sign in to and no default credential exists to be found. Administration is entirely over your own key based SSH.
• The collector never runs as root. nfcapd.service runs under a dedicated, unprivileged nfdump system account with no login shell and no home directory.
• Retention is configured, not left to you. nfexpire caps the archive at 30 days or 5GB, whichever is hit first, both easily tunable, with a daily timer that actually enforces it.

What is included:

• nfdump 1.7.8 (BSD-3-Clause) built from a sha256 pinned upstream source tarball
• nfcapd.service running the NetFlow v5/v9, IPFIX and sFlow collector on UDP 9995
• The full toolkit: nfdump (query), nfreplay (resend captured flows), nfanon (anonymise), nfexpire (retention), nfpcapd (pcap to flow conversion)
• A daily retention timer (nfdump-expire.timer) enforcing a 30 day / 5GB cap
• nfdump-firstboot.service for a per VM instance note (no secrets — none exist for this product)
• Ubuntu 24.04 LTS base, fully patched, unattended security upgrades enabled
• 24/7 cloudimg support, 24h response SLA

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet with a subnet your routers, switches or firewalls can reach. Standard_B2s (2 vCPU, 4 GB RAM) is ample for a small to medium flow volume; the collector is I/O and memory bound rather than CPU bound; expand the OS disk or your retention window if you are capturing from a large fleet of exporters.

Step 1: Deploy the Virtual Machine

Option A: Azure Portal

Search the Marketplace for nfdump NetFlow Collector on Ubuntu 24.04, choose your VM size, and provide your SSH public key. Attach a network security group that allows:

• TCP 22 (admin SSH) from your management network only.
• UDP 9995 (the flow collector) from your router/switch/firewall address ranges. NetFlow, IPFIX and sFlow carry no authentication of their own, so scope this as tightly as your exporter topology allows — but note that, unlike a management port, this one legitimately needs to accept from wherever your exporters actually are.

Option B: Azure CLI

RG="nfdump-prod"; LOCATION="eastus"; VM_NAME="nfdump-01"
GALLERY_IMAGE_ID="/subscriptions/<sub-id>/resourceGroups/azure-cloudimg/providers/Microsoft.Compute/galleries/cloudimgGallery/images/nfdump-ubuntu-24-04/versions/<version>"
SSH_KEY="$(cat ~/.ssh/id_rsa.pub)"
az group create --name "$RG" --location "$LOCATION"
az network vnet create -g "$RG" --name nfdump-vnet --address-prefix 10.70.0.0/16 --subnet-name nfdump-subnet --subnet-prefix 10.70.1.0/24
az network nsg create -g "$RG" --name nfdump-nsg
az network nsg rule create -g "$RG" --nsg-name nfdump-nsg --name allow-admin-ssh --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp
az network nsg rule create -g "$RG" --nsg-name nfdump-nsg --name allow-flow-exporters --priority 110 \
  --source-address-prefixes "<your-router-and-switch-cidrs>" --destination-port-ranges 9995 --access Allow --protocol Udp
az vm create -g "$RG" --name "$VM_NAME" --image "$GALLERY_IMAGE_ID" \
  --size Standard_B2s --storage-sku StandardSSD_LRS \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name nfdump-vnet --subnet nfdump-subnet --nsg nfdump-nsg --public-ip-sku Standard

Step 2: Connect via SSH

ssh azureuser@<vm-ip>

Find the public IP with az vm show -d -g nfdump-prod -n nfdump-01 --query publicIps -o tsv.

Step 3: Confirm the collector is running

sudo systemctl start nfcapd.service 2>/dev/null || true
sleep 2
sudo systemctl status nfcapd.service --no-pager | head -10
ss -ulnp | grep 9995
nfdump -V

nfcapd.service should report active (running), listening on *:9995 (UDP), running as the nfdump user, and nfdump -V should report version 1.7.8.

Step 4: Prove the collector actually captures flows

A green service status and an open port prove nothing for a flow collector — the whole product is whether a flow that arrives is actually written to disk in a format nfdump can query. This image ships the exact self-test it was built and validated with, so you can run the same proof on your own VM at any time:

sudo /usr/local/sbin/nfdump-flow-roundtrip.py

It crafts a real NetFlow v5 UDP packet carrying a marker flow between two RFC 5737 documentation addresses (so it can never collide with real traffic), sends it to the collector on 127.0.0.1:9995, forces nfcapd to finalise its in-progress capture file, then reads that file back with nfdump -r and asserts the marker flow's source and destination addresses and port are present. You should see a line starting OK.

Step 5: Query captured flows

Point your routers, switches or firewalls at this VM's address on UDP 9995 (most vendors call this "NetFlow export" or "IPFIX export" configuration; consult your device's documentation for the exact syntax). Once flows start arriving, query the archive:

nfdump -R /var/lib/nfdump/flows
nfdump -R /var/lib/nfdump/flows 'dst port 443'
nfdump -R /var/lib/nfdump/flows 'src net 10.0.0.0/8'

nfdump's filter language is tcpdump-like: host <ip>, net <cidr>, port <n>, proto tcp|udp|icmp, combined with and/or/not. See man nfdump for the complete filter grammar and output format options (-o csv, -o json, aggregation with -A, top-N with -s).

Step 6: Read this VM's instance note

sudo cat /root/nfdump-instance.txt

This appliance has no login and no bootstrap credential, so there is nothing secret in this file — it exists purely as a quick reference for this VM's private address, the collector port, the data directory and the retention policy. It is written once at first boot and is not regenerated on every boot.

Step 7: Retention

nfexpire -l /var/lib/nfdump/flows

Shows the current retention configuration and the archive's current size and age. As shipped it is capped at 30 days or 5GB, whichever is hit first, enforced by a daily systemd timer. To change it:

sudo nfexpire -u /var/lib/nfdump/flows -t 60d -s 20G
sudo systemctl start nfdump-expire.timer

Managing the service

sudo systemctl status nfcapd.service
sudo systemctl restart nfcapd.service
sudo journalctl -u nfcapd.service -n 50 --no-pager

nfcapd has no live-reload signal — a configuration change (rotation interval, listen address) means editing /etc/systemd/system/nfcapd.service and restarting. Restarting is also how you force an immediate rotation of the current capture file if you need to query the most recent data before the next scheduled 5 minute window closes; the collector performs one final rotation cycle before it stops, so no in-flight data is lost.

Server Components

Filesystem Layout

Persistence, first boot and updates

On each VM's first boot, nfdump-firstboot.service resolves this machine's own private address and writes the instance note. It runs once and does not run again. nfcapd.service starts independently and does not wait on it — there is no per-VM secret or configuration the collector needs before it can start accepting flows.

Ubuntu security updates are applied automatically by unattended upgrades. nfdump itself was built from source at image build time, so new upstream releases arrive through a refreshed cloudimg image rather than through apt.

Troubleshooting

nfcapd.service is not active. Check sudo journalctl -u nfcapd.service -n 50 --no-pager. The most common cause is the UDP port already being bound by another process, or the data directory /var/lib/nfdump/flows having lost its nfdump:nfdump ownership.

No flows are arriving. Confirm your exporter is actually configured to send to this VM's address on UDP 9995, confirm the Azure NSG allows the exporter's source address range on UDP 9995, and run sudo /usr/local/sbin/nfdump-flow-roundtrip.py to prove the collector itself works — if that passes, the issue is upstream of this VM (exporter configuration or network path), not the collector.

nfdump -R returns nothing. The most recent capture file is still open and will not appear until the next rotation (every 5 minutes by default) or a systemctl restart nfcapd. This is expected — nfcapd only exposes a file to nfdump once it has been finalised.

Security Recommendations

• Scope the Azure NSG to your actual exporter address ranges on UDP 9995, not Any. The collector itself accepts from any source by design (NetFlow/IPFIX/sFlow have no protocol-level authentication), which is exactly why the network-level scoping matters here.
• Restrict admin SSH to your management network, and keep it key based — there is no other credential to fall back on or misconfigure.
• Size your retention to your investigation window. 30 days is a reasonable default; extend it with nfexpire -u if your compliance or incident-response requirements need longer.
• Forward query results to your SIEM or ticketing system as part of an incident workflow — nfdump -o csv and -o json output formats are built for exactly this.

Support

For assistance, contact cloudimg support:

• Email: support@cloudimg.co.uk
• Response Time: 24/7 with guaranteed 24 hour response SLA
• Website: https://cloudimg.co.uk