BSD DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


Building Detailed Network Reports with Netflow

by Michael W. Lucas
10/27/2005

At 2005's USENIX conference, I attended a talk by an intrusion response expert. He described a situation where a company had hired him to "find out what happened" to the network during an intrusion: who broke in, how did they get in, and what did they do? Anyone who has been there can tell you just what a difficult job this is, even with the full cooperation of the company. The network manager happily provided the specialist with all the logs, particularly the firewall logs. In only a few minutes, the expert determined that the hoarded and protected firewall logs were completely useless. They were intact, but the logs only listed blocked traffic. They recorded what didn't happen, not what had happened! (Yes, this is where you go check your own firewall logging.)

One of the best ways to avoid a situation like this is to record what actually happened, and that's where Netflow comes in. My previous couple of articles show how to monitor network traffic with Netflow and how to use Netflow, flow-tools, and FlowScan to generate pretty and detailed graphics of your network traffic. Netflow can also provide almost any level of visibility into your network's traffic. Netflow records tell us what did happen. The installation in the first article includes all sorts of tools for that.

People need many different things from Netflow data; they've written countless tools to separate that data in the manner they'd like, and then posted them on the Web to help other people. The end result is dozens of slightly different Netflow data processors, all publicly available. Definitely spend some quality time with Google before writing your own. The rest of this article discusses some tools that I find useful in my day-to-day work, which you have already installed during the Netflow setup discussed in the previous articles.

All these commands nondestructively process flow files. The label flowfiles indicates where to put these filenames throughout the rest of this article. You can list multiple files or use wildcards. Note that you must either be in the directory containing the flow files, or give the full path to them.

flowdumper

To peer deeply into individual flows, try flowdumper(1). By default, flowdumper writes all the flows in a file to the screen. I strongly recommend using a pager, as you might have thousands of flows in a single file. Flowdumper requires at least one argument, the flow file to parse.

# flowdumper flowfiles | less

If you're interested in details about traffic to a particular host, you can search within the pager for that IP. Here's a sample of a single flow:

FLOW
  index:          0xc7ffff
  router:         172.16.20.1
  src IP:         192.168.1.54
  dst IP:         10.0.8.3
  input ifIndex:  0
  output ifIndex: 0
  src port:       61521
  dst port:       443
  pkts:           10
  bytes:          3015
  IP nexthop:     0.0.0.0
  start time:     Wed Jul  6 10:47:29 2005
  end time:       Wed Jul  6 10:48:32 2005
  protocol:       6
  tos:            0x0
  src AS:         0
  dst AS:         0
  src masklen:    0
  dst masklen:    0
  TCP flags:      0x1e (PUSH|SYN|ACK|RST)
  engine type:    0
  engine id:      0

Your sensor won't flag flows with BGP data if it's not running BGP. This means that many fields will be blank unless you're collecting flow data from a BGP-using border router. The "router" field is the IP address of the Netflow sensor, which is not necessarily a router. Flow records include the source and destination port and IP address, as well as the number of packets and bytes in this single flow. One interesting set of fields is the start and end times: you can determine whether a large flow used up a lot of bandwidth for a brief time or a trickle of bandwidth for a longer time. The protocol field correlates with the entries in /etc/protocols. If you're using a BGP-speaking router as your sensor, the flow record will include such things as autonomous system (AS) numbers and address mask lengths.

One of flowdumper's most interesting talents is its ability to speak Perl with the -e flag. Flowdumper uses a whole variety of variables, all defined in perldoc Cflow. Here are the ones I find most useful, and they're mostly self-explanatory. (The possible exception is $exporterip, which is the IP address of the Netflow sensor that transmitted this flow.)

$srcip
$dstip
$srcport
$dstport
$protocol
$tos
$exporterip

I find flowdumper's abilities most useful for answering weird, off-the-cuff questions. For example, back when I worked for an ISP, my boss occasionally asked questions like "Who is using a VPN on our network?" Flowdumper answered that quickly. (Too bad I didn't know about Netflow at the time!) Standard internet traffic uses protocols other than TCP, UDP, and ICMP, so we grab everything else.

# flowdumper -e '6 ne $protocol && 17 ne $protocol && 1 ne $protocol' \
    flowfiles

Similarly, packets on my network shouldn't have any unusual Type of Service defined. An unusual ToS indicates some sort of nefarious activity.

# flowdumper -e '0x0 ne $tos' flowfiles

Or I could just grab the flows from a particular sensor and see what traffic passed that part of the network.

# flowdumper -e '"192.168.88.134" eq $exporterip' ft-v05.2005-07-06.10*

Pages: 1, 2, 3, 4

Next Pagearrow





Sponsored by: