Monitoring Network Traffic with Netflowby Michael W. Lucas
As far as I'm concerned, network management is about knowledge. If you know what your network and servers are doing, making decisions is easy. I make heavy use of SNMP and MRTG to provide information I consider necessary on my network. Getting a new hard drive from management is much easier when you can say "Our fileserver usage grows by 2GB a month, so we need a new disk installed within six months," as opposed to "Our fileserver ran out of space; we need a new disk now!"
This helps, but MRTG doesn't provide any detail about what the network is actually doing. So your T1 is 90% full? What hosts are responsible, and what services are they using or providing? If you have MRTGified your network down to the switch level you can tell which host is using that traffic, but that's all. You then have to fire up tcpdump or investigate that host in a more painstaking way.
Netflow provides a session-level view of network traffic, recording information about every TCP/IP transaction that occurs over your network. It might not be as complete a record of network traffic as tcpdump can provide, but it's also much easier to manage and much more informative when aggregated.
By session data I mean "which host talked to which other host, on which ports, and how much data did they exchange?" One session is a flow. Netflow can easily tell you if that 1.5Mb/s to your Web server is honest Web traffic, or if your system has become part of a botnet and is providing vital assistance in the destruction of ONLamp.com. Once you have Netflow running, you'll wonder how you ever survived without it.
The downside of this visibility is that Netflow is more complicated to set up than MRTG or other SNMP-based monitoring software. The vast array of obsolete and irrelevant documentation still available on abandoned Web sites and ancient mailing list archives only confuses the issue. The setup is more than worth it, however.
A Netflow system has three major components: a sensor, a collector, and some sort of reporting system. The sensor (also known as a probe) is a daemon that listens to the network and captures your session data. Just as with Snort or any other IDS system, the collector needs to connect to a hub, "mirrored" switch port, or other device where it can see all the network traffic. If you're running a BSD or Linux firewall, this is an excellent place to run a Netflow collector--all the traffic has to pass through this device anyway! This sensor bundles up the session information and tosses it at the collector.
The collector is a second daemon that listens on a UDP port of your choice for reports from the sensor and dumps them into a file for later evaluation. Different collectors store their data in different file formats.
Finally, the reporting system reads the files generated by the collector and produces human-readable reports. The reporting system must be able to read the format used by the collector.
Because there are a wide variety of sensor software, collector daemon, and reporting systems available, you can forgive a newcomer for thinking that Netflow is too complicated to begin to set up. I'd like to sidestep this problem by choosing a single specific scenario that will fit 90% of network environments immediately, and that can work for most of the remainder with only minor changes. Assume that:
- you have a system with BSD or Linux OS in an appropriate place to act as a sensor, with sufficient capacity to run the sensor software. I find a 500MHz CPU/256Mb RAM system sufficient to monitor 20Mb/s without much difficulty, so chances are you have this hardware either lying around or already in production but underutilized. My demonstration will be on FreeBSD.
- you have a host to act as a collector and reporting server. This can be the same host as your sensor, but collecting the data and generating reports will increase load on this system. Skilled intruders also have an interest in Netflow data, so you should place the collector behind a firewall. If you can have a Web server installed on the collector, you can generate pretty web-based Netflow reports. I'm using FreeBSD as the collector and reporting system; change the package names as appropriate for other operating systems.