The following paper was originally published in the
Proceedings of the Eleventh Systems Administration Conference (LISA ’97)
San Diego, California, October 1997
For more information about USENIX Association contact:
1. Phone: 510 528-8649
2. FAX: 510 548-5738
3. Email: email@example.com
4. WWW URL: http://www.usenix.org
Implementing a Generalized Tool
for Network Monitoring
Marcus J. Ranum, Kent Landfield, Mike Stolarchuk, Mark Sienkiewicz,
Andrew Lambeth, and Eric Wall – Network Flight Recorder, Inc.
Determining how you were attacked is essential to developing a response or
countermeasure. Usually, a system or network manager presented with a successful intrusion has
very little information with which to work: a possibly corrupted system log, a firewall log, and
perhaps some tcpdump output.
When hackers come up with a new technique for cracking a network, it often takes the
security community a while to determine the method being used. In aviation, an aircraft’s
‘‘black box’’1is used to analyze the details of a crash. We believe a similar capability is needed
for networks. Being able to quickly learn how an attack works will shorten the effective useful
lifetime of the attack. Additionally, the recovered attack records may be helpful in tracking or
prosecuting the attacker. Since we’ve developed a general purpose statistics-gathering system,
we believe it will be useful for more than just security. For example, a network manager may
desire an historical record of the usage growth of certain applications, or details about the
breakdown of types of traffic at different times of day. Such records will provide useful
information for network managers in diagnosing performance problems or planning growth.
This paper describes an architecture and toolkit for building network traffic analysis and
statistical event records: The Network Flight Recorder. The NFR uses a promiscuous packet
interface to pass visible traffic into an internally meta-programmed decision engine which routes
information about packets and their contents into statistical or logging backends. In addition to
packet analysis and collection, the NFR’s internal architecture permits network managers to
sample interesting portions of network traffic for logging or statistical analysis. The NFR
programming language is simple, but powerful enough that you can perform reasonable analysis
on traffic before choosing to record it. For example, you might analyze SMTP transactions but
only choose to record those relating to a user who is sending spam or abusive E-mail. The
analysis language includes a capability for generating alert messages which the rest of the
system queues, multiplexes, and delivers. A simplified hyper-query interface allows extensive
browsing of the NFR’s stored datasets and statistics from any Java-enabled browser. The NFR is
currently being deployed at a number of ISPs and commercial sites, and is available for
download in source code form from www.nfr.net.2
Background and Motivation
In 1990, one of the authors managed a rather
chaotic network, including an embryonic firewall,
using NNStat as a security tool. NNStat  was
designed as a statistical analysis system for the
NSFnet backbone, not as a security tool, but possessed
several attractive properties:
1. It permits accurate and highly condensed sum-
maries of an event on the network.
2. It permits flexible specification of types of
events to record.
3. It permits flexible storage of information about
the events that are observed.
1They are actually Safety Orange.
2Use of the NFR software is free for noncommercial and
research purposes. A commercial release of the software is
While NNStat’s authors were concerned about,
for example, how much RIP traffic was crossing the
network, a security conscious network manager could
use NNStat to record all RIP traffic emanating from
any systems that were not on an ‘‘approved list’’ of
routers. Suddenly, NNStat was useful as a crude tool
for mapping who and what, as well as for setting an
alert to fire when something happened that the net-
work manager believed should not. NNStat, wrapped
with a bunch of quick and dirty shell scripts and cron
jobs, served well as a poor man’s intrusion detection
system. Other network managers have implemented
similar systems using tcpdump, or more sophisticated
special-purpose network watchers like ARPwatch ,
TCPwatch , Netman , clog , Netwatch ,
and Argus . Other intrusion detection burglar
alarms have focused on features of the host operating
system, such as tcp_wrappers , klaxon , and toc-
sin . Many of the monitoring systems implemen-
1997 LISA XI – October 26-31, 1997 – San Diego, CA1
Implementing a Generalized Tool for Network MonitoringRanum, et al.
Benko, and Craig Farrell. Curtin University of
 Clog, Brian Mitchell.
 Netwatch and Netwatch, Texas A&M University,
 Carter Bullard, Chas DiFatta,
announcement, Software Engineering Institute,
 Tcp_Wrappers and Logdaemon, Wietse Venema.
 Klaxon, Doug Hughes.
 Tocsin, Doug Hughes.
 libpcap, Lawrence Berkeley National Labs Net-
work Research Group, http://ftp.ee.lbl.gov.
 Ousterhout, J. K., ‘‘TCL: An Embeddable Com-
mand Language,’’ Proceedings of the 1990 Win-
ter USENIX Conference, pp 133-146, 1990.
 Anderson and Patterson, ‘‘Extensible, Scalable
Monitoring for Clusters of Computers,’’ Pro-
ceedings of the 1997 USENIX LISA Conference,
Appendix 1: A Simple Filter
# This filter serves two purposes:
# made to your web servers, and to serve as example in the LISA paper.
# Mark Sienkiewicz / NFR
# Copyright 1997, Network Flight Recorder, Inc.
to record client requests
# schema would be automatically generated by a "wizard"
watchservers_schema = [ 1, 1, 1, 6, 6, 2 ];
# list of my web servers
my_web_servers = [ 184.108.40.206 , 220.127.116.11 ] ;
# gather data the client sends to a web server.
# all my web servers are on port 80 I would make this more elaborate.
filter watch tcp ( client, dport: 80 )
If I didn’t know that
if (ip.dest != my_web_servers)
declare $blob inside tcp.connSym;
$blob = strcat ( $blob, tcp.bytes );
while (1 == 1)
$x = index( $blob, "\n" );
if ($x < 0)
if ($t == ’\r’)
# break loop if no complete line yet
# look for cr at end of line
# tear off line
# save the time, the connection hash, the client,
# the server, and the command to a list
record system.time, tcp.connHash, ip.src, ip.dest, $t to
# keep the remainder of the blob for the next pass
$blob = substr($blob, $x + 1);
# keep us from getting flooded if there is no newline in the data
if (strlen($blob) > 4096)
$blob = "";
watchservers_list = recorder ("bin/list packages/web/watchservers.cfg",
8 1997 LISA XI – October 26-31, 1997 – San Diego, CA