Operational Experiences with High-VolumeNetwork Intrusion DetectionHolger Dreger Anja Feldmann Vern Paxson Robin SommerTU M¨unchen TU M¨unchen ICSI / LBNL TU M¨unchenGermany Germany Berkeley, CA, USA [email protected] [email protected] [email protected] [email protected] large-scale environments, network intrusion detection systems(NIDSs) face extreme challenges with respect to traffic volume,traffic diversity, and resource management. While crucial for ac-ceptance and operational deployment, the research literature mainlyomits such practical difficulties. In this paper, we offer an evalua-tion based on extensive operational experience. More specifically,we identify and explore key factors with respect to resource man-agement and efficient packet processing and highlight their impactusing a set of real-world traces. On the one hand, these insightshelp us gauge the trade-offs of tuning a NIDS. On the other hand,they motivate us to explore several novel ways of reducing resourcerequirements. These enable us to improve the state managementconsiderably as well as balance the processing load dynamically.Overall this enables us to operate a NIDS successfully in our high-volume network environments.Categories and Subject Descriptors: C.2.3 [Computer-Communication Networks]: Network Operations - Networkmonitoring.General Terms: Measurement, Performance, Security.Keywords: Bro, Evaluation, Network Intrusion Detection, Security1. INTRODUCTIONThe practical experience of running a network intrusion detec-tion system (NIDS) operationally is that with increasing volume thechallenges grow faster than linear. Three major difficulties arise.First, the sheer packets-per-second (pps) rates can reach levels atwhich the load due to interrupts and filtering push the system intothrashing. Second, as volume rises—particularly if it rises due togreater numbers of hosts—so does the traffic’s diversity, which canstress the NIDS’s fidelity by generating both more false alarms anda wider range of types of false alarms. Third, as the number of hostsincreases, so does the burden of managing state and other resources.These practical difficulties with high-volume network intrusiondetection rarely see investigation in the research literature: NIDSvendors often have a commercial interest in downplaying the dif-ficulties and keeping private their techniques for addressing them,and researchers seldom have opportunities to evaluate high-volume,operational environments.In this paper, we offer such an evaluation. Our study is inthe context of using commodity PC hardware running open-sourcePermission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.CCS’04, October 25-29, 2004, Washington, DC, USA.Copyright 2004 ACM 1-58113-961-6/04/0010 ...$5.00.software for operational security monitoring of quite high-volumeenvironments (Gbps, 10s of thousands of hosts transferring 2-3 TB/day). We found that in such environments, if we simply installand run an untuned/uncustomized NIDS such as the open-sourceSnort [19] or Bro [16] systems, they are unable to effectively copewith the amount of traffic. Snort immediately consumes the entireCPU, leading to excessive packets losses, while Bro, in addition,quickly exhausts all available memory.Obviously, the volume is too great a burden for the NIDS. Butwhat are the key factors that lead to such severe difficulties? In thisstudy we look at a number of issues that arise due to the problemsof resource management and efficient packet capture and filtering.We aim to analyze the main contributors to CPU load and mem-ory consumption and look for means to ameliorate their impact,which sometimes requires developing new mechanisms if the avail-able tuning parameters do not suffice.For a stateless NIDS, the load imposed on the CPU is the mainlimiting factor. This load is correlated with the types of analy-sis as well as the traffic’s volume and makeup. A stateful NIDS,additionally, maintains an in-memory representation of the currentstate of the network, which must be meticulously maintained at alltimes. This state provides the context necessary to evaluate the net-work events. Like CPU load, the volume of the state is also corre-lated with the traffic volume as well as the types of analysis, and isconstrained by the system’s available memory. Since maintainingstate requires state management, the NIDS requires some signifi-cant CPU time just for updating data structures.Common approaches for limiting NIDS resource usage includedifferent kinds of state management (e.g., via timeouts and/or fixedsize buffers); checkpointing [16] (i.e., regularly restarting the sys-tem to flush old state); limiting the traffic by analyzing only cer-tain protocols or subsets of the address space; and distributing thework to multiple machines. To understand the efficacy of these ap-proaches, we examine the resource requirements of a NIDS and theassociated trade-offs in operational use.Our study is in the context of the Bro NIDS, which we havedeployed operationally in a couple of high-performance environ-ments. Bro is a highly stateful NIDS. Its basic model has three lay-ers: packet filtering, event generation, and policy script execution.Packet filtering is done using a static BPF expression [10]. Eventsare generated by an event engine which performs policy-neutralanalysis of network traffic at different semantic levels. For exam-ple, there are events for attempted/established/terminated/rejectedconnections, the requests and replies for a number of applications,and successful and unsuccessful user authentication. Finally, theuser writes policy scripts using a specialized, richly-typed high-level language. These scripts execute on the events generated by theevent engine and codify the actions the NIDS should take: updatingdata structures describing the activity seen on the network, sending2out real-time alerts, recording activity transcripts to files, and exe-cuting programs as a means of reactive response. Thus, both theevent engine layer and the policy script layer generate and managea great deal of state.We find that three factors dominate overall