|
|
USENIX Home | ;login: Magazine Index | USENIX Intrusion Detection Workshop Cisco Flow Logs and Intrusion Detection at the Ohio State University
by Steve Romig
Steve Romig leads the Ohio State University Incident Response
Team, which provides incident response assistance, training,
consulting, and security-auditing services. He also works with Central
Ohio businesses to improve Internet-security response and practices.
and Suresh Ramachandran
Suresh Ramachandran is in the master's program in computer and
information science at Ohio State University. His computing interests
include networks and Web-based information systems.
<ramachandran.10@osu.edu>
Many Cisco routers support NetFlow accounting, which provides fast access-control list processing, accounting, and switching/routing with minimal impact on performance. One of the side benefits of enabling flow routing is that you can then "capture" a record of the flows as they are removed from the flow cache, creating what we call a "flow log." Among other things, the flow logs contain the source and destination IP addresses for all IP packets, source and destination port numbers for UDP and TCP traffic, and packet and octet counts. The University Technology Services Networking Group at The Ohio State University has written a suite of tools to record, filter, print, and analyze flow logs. Our initial interest was in computer intrusion response. When an intrusion is reported on campus, we can readily search the captured flow logs to determine when the initial attack occurred and from what IP source; where else the attacking host attempted to connect on our networks; and what network traffic ensued from the victim host after the intrusion. Although the flow logs do not contain packet-content information, the level of detail is sufficient to get a very detailed picture of network activity for our site. We recognized early on that we should be able to use the flow logs for some types of intrusion detection, possibly in near real-time. This article describes what the flow logs contain, the tools we have written for intrusion detection, and how we use those tools. We also point to related references you might find interesting. What the Flow Logs Are We'll start with Cisco's description of flows: A network flow is defined as a unidirectional sequence of packets between given source and destination endpoints. Network flows are highly granular; flow endpoints are identified both by IP address as well as by transport layer application port numbers. NetFlow also utilizes the IP Protocol type, Type of Service (ToS) and the input interface identifier to uniquely identify flows. Non-NetFlow enabled switching handles incoming packets independently, with separate serial tasks for switching, security, services and traffic measurements applied to each packet. With NetFlow-enabled switching, security (ACL) processing is applied only to the first packet of a flow. Information from the first packet is used to build an entry in the NetFlow cache. Subsequent packets in the flow are handled via a single streamlined task that handles switching, services and data collection concurrently.
(Source: NetFlow Services and Applications, Flow logs are a record of the flows created by NetFlow accounting. These logs contain interesting information about network traffic, including source and destination IP addresses and port numbers, the time for the beginning and end of the flow, count of packets and octets, and so on. It is probably easiest to explain by example. Suppose that I successfully telnet from host A port 1234 to host B port 23. The initial packet from A to B causes the router to create a flow entry for {TCP,A,1234,B,23}. The response from B to A causes the router to create a related flow {TCP,B,23,A,1234}. Data from subsequent traffic will be aggregated in these two flow records either until the TCP session terminates or until the flow records are removed from the cache, either because they have timed out or because the cache is full. The flow records contain a count of the number of packets and octets seen in that flow. For TCP traffic, the flow records also record the OR of all of the TCP header-flag bits seen in the flow so far. Flow records also record the IP protocol (TCP, UDP, ICMP), and router interfaces that the traffic was received on and sent to. One can see from this example that most network interactions will result in at least two flows, one for traffic going in each direction. It is important to note that a TCP session may consist of far more than two flows. You can generally tell which flows "belong together" by matching the IP addresses and port numbers, and you can tell whether a flow "contained" the packets for the start, middle, or end of the connection by looking at the TCP-flag bits. For example, a flow whose TCP flag includes the FIN bit but not the SYN bit covered either packets from the middle and end of a TCP connection or packets from a "stealth" scanner. Flows for UDP and ICMP traffic are similar, although it is important to note that since neither of these is a connection-oriented protocol, flows of UDP and ICMP traffic are just collections of "similar" packets. Flow Tools Ohio State has written a suite of tools for collecting, filtering, printing, and analyzing Cisco flows. The tools are written to work as UNIX pipelined commands, making it easy to perform data reduction without creating unnecessary intermediate files. We capture the flows on several Pentium-class computers running FreeBSD using a program called flow-capture. The capture hosts have enough disk space to hold a few days' worth of flow logs each. Flow-capture was designed specifically to handle the collection of high volumes of flow logs from multiple routers — our busier routers generate about 650MB per day of compressed log information. The captured logs are copied periodically to a 250GB RAID on a "decked out" host where we do most of our analysis of the flow logs. We retain a window of past logs to facilitate incident response and in anticipation of handling bill-dispute resolution once we move toward usage-based charges for billing. We store flow records in snapshots that cover small intervals of time (currently 15 minutes). This way, the individual files are of a more manageable size, and we can limit our analysis and review efforts more specifically to time periods that we are interested in, rather than wade through large amounts of data we would otherwise have to skip through. The flow-cat program concatenates separate flow log files that are named on its command line into stdout. (We can't simply use the UNIX cat command, since each flow log file starts with a short header that has to be stripped out.) The typical tools that we use for incident response are flow-filter, flow-print, and flow-search. Flow-print prints flow records in any of several forms. Flow-filter filters flow records using Cisco-style access control lists, allowing us to include or exclude records to limit what we are viewing. Flow-search is a script that makes it easier to apply flow-filter to a set of flow log files. It provides a simple command-line interface that allows you to filter on source or destination or to extract only traffic going between two sets of access control lists. The toolkit also includes programs that perform summary and statistical analysis of the data in flow logs.
Figure 1. Sample output from flow-print, edited to make it more
compact by deleting some columns, and changing some addresses to
protect the guilty.
We can investigate each of these more thoroughly by using flow-search
and flow-print to extract just the records pertaining to those hosts to
see both what they were doing and whether it was really a scan or not,
and also to see whether there was other activity that we should
investigate more closely.
Figure 2. (Edited) output from flow-dscan.
The detectors are not 100 percent foolproof, but flow-host-profile does
report useful information that helps us keep abreast of computer
security incidents involving our campus.
Figure 3. (Edited) output from flow-host-profile, showing new hosts
and services; the PERCENT represents the change in usage pattern (or
appearance of a new host/service) compared to historical data.
We have only limited experience with using the flow logs for intrusion detection. So far, the principal problem is false positives. Successful use of both flow-dscan and flow-host-profile depends on building and maintaining an accurate exclusion list to help eliminate false positives. Unfortunately, this would also tend to mask certain types of activity from being reported. The vast amount of data that we collect is useful, on the one hand, since we can "zero in" on network activity for debugging or investigation purposes, but it also presents certain challenges for designing accurate intrusion-detection systems, since one has to make a trade-off among accuracy of reporting, the level of analysis performed, and the system resources (especially memory) required for the analysis. We are exploring the use of better windowing to limit resource consumption. The OSU flow tools are available by anonymous ftp from <ftp.net.ohio-state.edu> in </users/maf/cisco/flow-tools.tar.gz>.
Other groups have also been working on tools for collecting Cisco flow
logs. In particular, you might be interested in looking at the CAIDA
tools at <https://www.caida.org>. These seem to be oriented more
toward statistical analysis of NetFlow logs, rather than incident
response or intrusion detection. Cisco has also released a set of tools
for collecting NetFlow logs that you can find at
<https://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/nfc>.
|
 Need help? Use our Contacts page.
Last changed: 9 Dec. 1999 jr |
|
Issue index