Resources
Location:

Monitoring and Network Forensics at the University of Chicago

Title:Monitoring and Network Forensics at the University of Chicago (ID: EPS175)
Author(s):E. Larry Lidz (University of Chicago)
Topics:Incident Handling and Response, Intrusion Detection and Prevention, Logging and Monitoring, Security Architecture
Origin:Community Contributions (2003)
Type:Effective Practices
Abstract:

Overview of the University Network The University of Chicago's network has approximately 15,000 network devices on it, spanning across about a thousand switches. The network infrastructure is a 100 MB per second switched infrastructure with a gigabit backbone. For off campus connectivity, we currently have 155 MB/sec Internet2 connectivity, and two 40 MB/sec commodity links. We have a handful of T1 and T3 connections which connect into our campus backbone for affiliated organizations or sites away from the main campus network. Evolution of Network Forensics at the University We have been running various network forensic tools since around 1995. We started with TAMU NetLogger logging traffic on the subnet on which we had our main e-mail, Web, and other important servers. NetLogger relied on a non-switched network for logging. As the University's network swapped over to a switched network we stopped using NetLogger. Around 1998, as the university started the Network Security Center, we started searching for a way to have similar network audit logs, except to monitor traffic across the university's gateway instead of or in addition to monitoring the main servers. At that time we started logging traffic by exporting NetFlows from our Cisco routers (both at the gateway and the routers which route traffic for leased lines through which we provide network access to affiliated organizations) to a machine set to capture the data with Mark Fullmer's flow-tools . We ported TAMU NetLogger's extract program to support flow files on the back end. This allowed us to have a very flexible syntax for selecting flow records during forensic investigations of compromised systems. We then wrote some scripts that act as a makeshift IDS. They report on incoming and outgoing network scans, detect specific attacks (these days we detect ping floods, Nachi, Blaster, AgoBot3, and so forth), and report to system administrators of computers on the unexpected network flows to their machines. Around 2000 we started installing Argus for network logging as well. Argus listens on a spanning port instead of receiving the flows from a router. This allows us to monitor specific segments of the network. We have Argus set to capture 64 bytes of application data as well as the header information. This has become extremely helpful. In investigating machines that have been compromised to distribute copyrighted information, we can generally recover the FTP username and password used by the intruders and verify that the machine is illegally distributing copyrighted material before removing it from the network. Additionally, Argus removes a single point of failure by having two logging mechanisms. In 1995 we used a Sun IPX to capture network traffic. The network audit logs have been so useful in our operations that we now process the logs on an 8 processor machine with about a terabyte of disk storage. Current Configuration Currently, we export NetFlows from three routers. Two of these routers handle our off-campus connections, and the third handles leased lines. The two off-campus connections are aggregated together every hour, and duplicate flows are removed. We currently have a span port set on the backbone switch, off which hang the gateway routers and a few subnets of the campus network. This span port is connected to a passive regeneration tap that prevents any traffic from being passed up to the switch. Our Argus collector hangs off that tap. Both NetFlows and Argus data are exported to our central log server for storage. We maintain as much data as we can fit. Currently, we're storing around eight weeks of logs. We would like to store closer to three months of logs.

View this resource:

 
© Copyright 1999-2009 EDUCAUSE