[Optional] Network Visibility with NetFlow

Table of Contents

1. NetFlow Architecture
2. NetFlow Versions
3. Requirements Analysis
4. Install, Configure and Test the Probe
5. Install and Test the Collector
6. Basic Reporting
7. Advanced Reporting
8. Assessment

In this lab, we shall investigate network visibility using the NetFlow architecture. There are many tools available for NetFlow, so we shall first review the NetFlow architecture and then perform some requirements analysis to see which set of tools will be most suitable for us, looking briefly at some of the tools available to us.

1. NetFlow Architecture

NetFlow is conceptually very simple: devices such as routers or switches have some probe configured which looks at the packets going through its configured interfaces. These observed packets are collected into flows. A flow, in the case of TCP, is all the packets that make up a particular connection; for UDP, a flow is everything with the same source and destination address and port. This description of a flow is a simplification, but is intuitively what is meant.

Periodically, such as when a flow is completed (eg. a TCP connection has been torn down) or after some period of time, the flow is exported to a configured collector. This is where the NetFlow protocol is used, which we shall discuss in more detail in a following section.

The collector process will generally run on a powerful machine with a lot of available disk space. The collector will often simply just write the exported data to disk, perhaps filtering to capture only certain data, and typically performing maintenance such as rotating files and expiring (deleting) old capture files. You may need to have multiple collectors in order to process all the data exported from all of your probes, so you can end up with some relatively more complex architectures to ensure you can process the incoming data fast enough. NetFlow is a UDP protocol, so one of the things a NetFlow administrator will want to do is monitor how many UDP packets are being dropped by the collector[88]; this can be in indication that the collector host is either not fast enough or that the collector process is not given a high enough scheduling priority.

The data stored by the collector(s) can be used for various purposes, such as accounting, traffic analysis and diagnosis and for investigating security incidents such as Denial of Service (DoS) attacks. We shall look further at some of these later in this lab.



[88] This can be done using netstat -s.