SANDIA REPORTSAND2003-8624Unlimited ReleasePrinted October 2003

Adaptive Network Countermeasures

Jamie Van Randwyk, Eric Thomas, Anthony Carathimas, Randy McClelland-Bane

Prepared bySandia National LaboratoriesAlbuquerque, New Mexico 87185 and Livermore, California 94550Sandia is a multiprogram laboratory operated by Sandia Corporation,a Lockheed Martin Company, for the United States Department of Energy’sNational Nuclear Security Administration under Contract DE-AC04-94AL85000.

Approved for public release; further dissemination unlimited.

Issued by Sandia National Laboratories, operated for the United States Department of Energy bySandia Corporation.

NOTICE: This report was prepared as an account of work sponsored by an agency of the UnitedStates Government. Neither the United States Government, nor any agency thereof, nor any oftheir employees, nor any of their contractors, subcontractors, or their employees, make anywarranty, express or implied, or assume any legal liability or responsibility for the accuracy,completeness, or usefulness of any information, apparatus, product, or process disclosed, orrepresent that its use would not infringe privately owned rights. Reference herein to any specificcommercial product, process, or service by trade name, trademark, manufacturer, or otherwise,does not necessarily constitute or imply its endorsement, recommendation, or favoring by theUnited States Government, any agency thereof, or any of their contractors or subcontractors. Theviews and opinions expressed herein do not necessarily state or reflect those of the United StatesGovernment, any agency thereof, or any of their contractors.Printed in the United States of America. This report has been reproduced directly from the bestavailable copy.Available to DOE and DOE contractors from

U.S. Department of EnergyOffice of Scientific and Technical InformationP.O. Box 62Oak Ridge, TN 37831

Telephone: (865)576-8401Facsimile: (865)576-5728E-Mail: reports@adonis.osti.govOnline ordering: http://www.doe.gov/bridge

Available to the public fromU.S. Department of CommerceNational Technical Information Service5285 Port Royal RdSpringfield, VA 22161Telephone: (800)553-6847Facsimile: (703)605-6900E-Mail: orders@ntis.fedworld.govOnline order: http://www.ntis.gov/help/ordermethods.asp?loc=7-4-0#online

2

SAND2003-8624Unlimited Release

Printed October 2003

Adaptive Network Countermeasures

Jamie A. Van Randwyk, Eric D. Thomas, Anthony G. Carathimas, Randy T. McClelland-Bane

Information Security

Sandia National Laboratories

P.O. Box 969

Livermore, CA 94551

{jvanran, edthoma, agcarat}@sandia.gov, randy@frenzy.org

Abstract

This report describes the results of a two-year LDRD funded by the Differentiating Technologiesinvestment area. The project investigated the use of countermeasures in protecting computer networksas well as how current countermeasures could be changed in order to adapt with both evolving networksand evolving attackers. The work involved collaboration between Sandia employees and students inthe Sandia - California Center for Cyber Defenders (CCD) program. We include an explanation of theneed for adaptive countermeasures, a description of the architecture we designed to provide adaptivecountermeasures, and evaluations of the system.

3

This page intentionally left blank

4

Contents

Nomenclature 7

1 Introduction 9

2 Background 9

3 Accomplishments, Design,

and Implementation 10

3.1 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Athena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.2 Modular Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Evaluation and Performance 15

4.1 ifpw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3 Athena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.4 ANC as a Whole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Future Work 16

5.1 HENC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2 IDS Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.3 GI Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.4 Athena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6 Conclusion 18

7 Acknowledgments 18

Appendix A - Setting up an ANC System 20

Appendix B - FreeBSD IP Stack Patch 22

Appendix C - Information Correlation 23

List of Figures

1 ANC Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 HENC Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Typical datagram flow to Honeyd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Modified datagram flow to Honeyd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Flow of datagrams from Athena to HENC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5

This page intentionally left blank

6

Nomenclature

ANC Adaptive Network CountermeasuresANCP Adaptive Network Countermeasures ProtocolGI general information [modules]HENC Honeyd Enabled Network Countermeasures, countermeasure com-

ponent of Adaptive Network CountermeasuresIDS intrusion detection system

Athena decision-making component of Adaptive Network CountermeasuresBro an open source intrusion detection systemdatagram also called a “packet”Honeyd open source virtual honeypot softwareipfw/ipfw2 the FreeBSD packet filter / firewallmon a Sandia-developed intrusion detection systemNessus an open source network scanning toolNmap an open source network scanning toolSnort an open source intrusion detection systemXprobe 1 / Xprobe2 an open source operating system fingerprinting tool

7

This page intentionally left blank

8

1 Introduction

Internet attacks are on the rise as shown by the re-cent Blaster [1] worm. Our operational experiencehas shown an increase in the time and manpowerrequired to defend against attacks and clean up intheir wake. Along with a general increase in at-tacks, our experience has also been that targeted at-tacks are becoming more frequent. Malicious usersare now tailoring their attacks for maximum effectagainst specific target machines.

Targeted attacks are made possible by advancereconnaissance conducted by malicious users. At-tackers use tools such as Nessus [2] and Nmap [3]to conduct their network surveys. These tools relyon the fact that the TCP/IP protocol suite was de-signed to be an open suite of protocols. The proto-cols freely give information about the computer onwhich they are running rather than limiting thatinformation.

Efforts have been made to mask certain net-work characteristics in order to prevent malicioususers from tailoring their attacks. Perimeter de-fenses such as firewalls and proxy servers have beendeployed to limit the information available to at-tackers. Honeypots are being installed to distractattackers from “real” network resources.

We believe these solutions leave much room forimprovement. We want to be able to control theview of our network that can be obtained by outsideusers, whether malicious or not. We believe that bylimiting, and even creating, the view from the out-side, we can severely restrict an attacker’s ability toconduct reconnaissance of our network and exploitweaknesses or vulnerabilities found.

In our research we combined the common net-work security ideas of network countermeasures, au-tomated response, and honeypots to create Adap-tive Network Countermeasures (ANC). Our goal wasthreefold: to provide a comprehensive and robustnetwork countermeasure system, to dynamically (inreal-time) detect and respond to malicious trafficdirected to nonexistent and existent machines onour network, and to design and build an extensi-ble architecture for conducting the aforementionedactivities.

In this paper we discuss the background sur-rounding network scanning, network countermea-sures, and automated response. In the followingsection we lay out our ANC architecture and ourworking implementation of that architecture. Wediscuss in depth the design of the countermeasuresystem, our system for making decisions about thetype and timing of network countermeasures, and

the glue that integrates the two systems into ANC.We then provide results describing the performanceof ANC as well as our evaluation of its effectivenessin repelling malicious users. We finish by providingour thoughts regarding future improvements to theANC architecture and our prototype implementa-tion.

2 Background

The concept of network scanning has been aroundfor a long time. Network scanning tools includ-ing Nessus and Nmap have made network reconnais-sance easy. The concept of fingerprinting operatingsystems using specially crafted TCP/IP datagramsis newer as explained by Fyodor in [4]. After anattacker has performed a network scan, he/she willfurther profile machines based on which interest-ing ports were reported open. This further pro-filing can include OS fingerprinting, grabbing ban-ners from running services, and other techniques.Nmap is the best known of these OS fingerprintingprograms, using specially crafted TCP and UDPdatagrams to gather information about a remoteoperating system. Ofir Arkin wrote Xprobe 1 andXprobe2 [5] to fingerprint remote machines usingmostly ICMP messages. Arkin first described hismethods in [6]. These two fingerprinting tools eachinclude a database of the mappings between a par-ticular operating system and responses to probes.We used these databases essentially in reverse, craft-ing our own TCP/IP datagrams according to thedatabase information provided for a chosen operat-ing system.

Using automated response on a production net-work is risky because of potential interference withlegitimate (non-attack) network traffic. In order tomitigate potential interference with the productionnetwork, [7, 8] allow some leeway in their responses.We take this approach as well, requiring a giventhreat to be of a sufficient weight before we issue aresponse on the network. Additionally, we make useof user-defined white lists of Internet Protocol (IP)addresses to avoid interfering with certain criticalmachines inside and outside of our network.

Many of the most popular intrusion detectionsystems (IDSs) provide methods to automaticallyblock IP addresses and IP address ranges [9, 10, 11].Some even provide deterministic network responsesdirected toward the offending IP [12]. In our ar-chitecture we introduce a layer of intelligence ontop of our implementations of these functions. Wewill begin by describing our innovations including

9

Internet

Internal Network

HENC

Athena

IDS

Modules

GI Modules

Firewall

Figure 1: ANC Architecture

dynamically configurable network countermeasures,our pluggable architecture, our attempts to limitfalse positives to the bare minimum, and our infor-mation correlation intelligence.

3 Accomplishments, Design,

and Implementation

Our design, and thus our project, was split intotwo main parts: the countermeasures component(HENC - Honeyd Enabled Network Countermea-sures (pronounced “Hank”)), and thedecision-making component (Athena). As seen inFigure 1, the two components each run on theirown machine, using a back channel for unidirec-tional communication.

3.1 Countermeasures

We designed HENC based on an existing productionsystem at Sandia National Laboratories. Labora-tory staff had written individual programs to pro-vide protocol and service specific countermeasureprotection for the networks. We wanted to combinethese programs into a larger system capable of send-ing countermeasures using TCP, UDP, and ICMPas well as emulating various network services over

Honeyd

ipfw

Firewall Internet

Template Builder

Figure 2: HENC Architecture

these protocols. As we developed our plans, we re-alized that we wanted to essentially recreate all thedeterministic responses produced by TCP/IP net-work stacks when stimulated by all possible inbounddatagrams. Our goal was to build our own IP stackwithout actually offering any real services.

We decided to build our system to emulate theIP stacks of as many operating systems as possible.This would be accomplished by reversing the useof the Nmap and Xprobe OS fingerprint databases.By responding to network traffic consistent with theway a real OS would respond, our program wouldprovide countermeasures indistinguishable from theresponse traffic of a real operating system. Ourprogram needed to provide countermeasures thatwould create the appearance of fully functioningWindows 2000, Mac OS X, Linux, or other machinesresiding on our network.

We chose Honeyd [13], a virtual honeypot soft-ware package, to act as the base for our counter-measure system. Initially Honeyd could read fromthe Nmap fingerprint file and send TCP and UDPdatagrams based on the “recipes” in that file. Inorder to make our countermeasure system more ro-bust, we added support to Honeyd for reading theXprobe2 fingerprint file and transmission of ICMPdatagrams according to that file.

Our countermeasure system was designed to runon a single machine as a part of the larger adap-tive network countermeasures framework. We ar-chitected our system to run on FreeBSD 4.7 and4.8, but it would be easy to make changes to workwith other UNIX-like operating systems. In orderto allow the sending of countermeasures with anIP ID field that is predetermined by our system orwith an ID of zero (as many Linux systems do), wewrote a small patch for the raw sockets portion ofFreeBSD’s IP stack (see Appendix B).

The HENC architecture has Honeyd at its base

10

as shown in Figure 2. Honeyd builds network data-grams and sends them out. The software knows howto build those datagrams based on input from boththe Nmap and Xprobe2 fingerprint files. We mapindividual operating systems and services to IP ad-dresses on our network using Honeyd’s configurationfile.

We wrote a utility named Template Builder toaid in creating host templates for the Honeyd config-uration file. The utility actually creates a completeconfiguration, but its focus is on creating a specifieddistribution of operating system templates across allpossible IP addresses being protected by ANC. Forinstance, a system administrator can create a con-figuration file for Template Builder similar to theone shown below:

# cat net.cfg

iprange 10.3.4-5.1-254

40% Microsoft Microsoft NT 4.0 SP5-SP6

10% NetBSD 1.6

10% Sun Solaris 2.3 - 2.4

3% 3com Office Connect Router 810

2% Compaq Tru64 UNIX V5.1A (Rev. 1885)

25% Linux Kernel 2.4.0 - 2.5.20

5% Apple Mac OS X 10.1.5

2% Apple Mac OS 9 - 9.1

3% SGI IRIX 6.5.14

For the given range(s) of IP addresses, the util-ity will create random operating system templatesbased on the supplied percentages. Template Builderalso has a limited capability to modify configurationfiles that already exist.

We modified Honeyd to provide a mechanismwhereby the binding of an operating system tem-plate to an IP address changes randomly, at in-tervals specified by the system administrator. Thestandard Honeyd syntax for setting a template per-sonality and binding an IP address to it is as follows:

set my_template personality \

"Microsoft NT 4.0 SP5-SP6"

bind 10.3.1.3 my_template

Using our new keyword, mutate, we bind theabove template so that it will change to a randompersonality (operating system) every 100 seconds:

bind 10.3.1.3 my_template mutate 100

If no value is specified after the mutate keyword, adefault of 300 seconds between personality changesis used.

network

kernel

kernel

user

Link-level driver and

protocol

BPF

Honeyd

ipfw

TCP/IP

Stack

ip_input()

Protocol specific

input

routines

Figure 3: Typical datagram flow to Honeyd

BPF makes copies of the datagrams arriving on the

machine [15]. Honeyd receives these datagrams via the

libpcap library. Datagrams not destined for this machine

are filtered out by the ip input() function.

We configured Honeyd to respond for every ad-dress that we wanted to protect on our network.This included both unused and used address space.The ipfw firewall mechanism [14] provides an easyway for us to regulate the outside IP addresses thatreceive countermeasures. We used the standard ipfw

program, but ipfw2 should work as well. HENC’sfirewall rules are written so as to allow all outboundtraffic while allowing inbound traffic only from pre-viously determined malicious users. If a networkdatagram makes its way into our system, it is go-ing to be responded to by our implementation ofHoneyd.

When running Honeyd on FreeBSD, it relies onlibpcap [16], which in turn relies on BPF (The BSDPacket Filter) [15], for receiving its IP datagrams.The FreeBSD IP stack is written such that BPF in-tercepts and copies IP datagrams before the ipfw

packet filter is called (Figure 3). BPF works thisway by design of course, but we needed the ability toblock most inbound datagrams so that our counter-measures did not interfere with production networkoperations. So we added an interface to Honeyd

giving it the capability of receiving datagrams viaa FreeBSD divert socket in addition to the exist-ing libpcap interface (Figure 4). Use of these inter-faces is mutually exclusive. We enable this feature

11

network

kernel

kernel

user

Link-level driver and

protocol

BPF

Honeyd

ipfw

TCP/IP

Stack

ip_input()

Protocol specific

input

routines

(divert socket)

Figure 4: Modified datagram flow to Honeyd

BPF makes copies of the datagrams arriving on the

machine [15]. No applications are listening to BPF

descriptors. Datagrams are passed from the link-level driver

to the ip input() function in the TCP/IP stack.

ip input() sends the datagrams to ipfw before deciding

whether to send them up the stack. Honeyd receives

datagrams from ipfw via a divert socket.

by using -d divert port number in the standardHoneyd command-line. Our inbound ipfw rules aregenerated to include the divert divert port number

syntax to direct accepted datagrams to Honeyd.

HENC generates its ipfw rules upon startupand when told to do so by Athena. Athena talksto HENC using ANCP (Adaptive Network Coun-termeasures Protocol). ANCP is built on top ofUDP and consists of a C client library used byAthena and a standalone PERL server running onHENC. The server configures the ipfw firewall uponstartup and maintains the firewall rules thereafter.ANCP can also be used to call the Template Builderutility in order to generate new configurations dy-namically. Currently ANCP can only alter IP-to-template bindings by adding and removing themutate keyword, but as the capabilities of TemplateBuilder are expanded, the ANC protocol will be ex-tended as well. It should be noted that the ipfw

portion of ANCP affects outside (supposed mali-cious) IP addresses and the interface to TemplateBuilder affects inside IP addresses (countermeasuresources).

Figure 5 is a flow chart of HENC’s operationsstarting with the ANCP client in Athena and end-ing with a network-level response directed toward a

Athena performs

correlation on

source IP

Should source IP

be labeled “bad”?

Generate ANCP

message

Yes

No

Receive ANCP

message

Generate ipfw

“allow” rule

Datagram arrives

via ipfw divert port Internet

Honeyd generates

and sends

countermeasure

Change

countermeasures?

Yes

No

Modify IP-template

binding, reload

Honeyd

Athena

HENC

Figure 5: Flow of datagrams from Athena to HENC

12

malicious user. ANCP currently supports sendingmessages of two different types. In the first sce-nario, Athena makes a decision that an outside IPaddress is bad and generates an ANCP message in-dicating that the address should be blocked. TheANCP server generates a firewall rule allowing in-bound traffic from the malicious IP address. In-bound datagrams are then diverted to the divertport being used by Honeyd. Honeyd will craft aresponse based on the destination IP-to-templatebinding in its configuration. HENC then sends theresponse, destined for the malicious user.

In the second scenario, Athena generates a mes-sage that changes the characteristics of countermea-sures being sent from an inside IP address. TheANCP server calls Template Builder, passing a localIP address as a parameter, and changes the corre-sponding IP-to-template binding. A successful ex-ecution of Template Builder triggers a SIGHUP toHoneyd and subsequent reload of Honeyd’s configu-ration. Countermeasures continue to be crafted andsent according to the new configuration.

3.2 Athena

3.2.1 Design

Athena is the part of the ANC system that makesdecisions about when to send countermeasures andwhat the countermeasure behavior should be.Athena makes ANC adaptive by changing how itresponds based upon input from different modules.Athena accepts two different types of input: thatfrom Intrusion Detection System (IDS) modules andinput from General Information (GI) modules.When information from these two module sets arecombined and correlated by Athena, Athena de-termines what countermeasures, if any, HENC willsend.

All of the decision making of Athena revolvesaround a single piece of data, the source (outside)IP address of a network datagram. Processing isinitialized when an IDS module sends an alert toAthena. Athena then creates a cumulative scorefor the source IP address, potentially using infor-mation from GI modules, and adds the informationto a database. If an IP address already has an as-sociated cumulative score, the score is updated inthe database. If the cumulative score for an IP ad-dress ever exceeds a (user-defined) threshold, ANCinitiates countermeasures against that IP address.

The behavior of an outside IP address that hasalready generated an IDS alert may cause an al-teration of the countermeasures used against it. Ifa source IP address is continually exhibiting “bad

behavior,” it will continue to be responded to withcountermeasures. If a source IP address is occa-sionally committing “small offenses,” these offenseswill build up over time and the source IP addressmay be responded to with countermeasures. Thesetwo results are possible because Athena adds to theIP address’s cumulative score when an offense hasbeen committed. Finally, over time and through“good behavior,” an IP address can be removedfrom the list of addresses to which network coun-termeasures are directed. This is carried out by aseparate “aging” thread within Athena which peri-odically decrements the cumulative score associatedwith each outside address.

Determining which countermeasures to send isa simple task. Whenever the cumulative score iswithin a certain range, the system will perform aspecific countermeasure. This allows ANC to re-spond with more aggressive countermeasures when-ever a source IP address has a very high cumulativescore, and less aggressive countermeasures when asource IP address has a low cumulative score. Theactual countermeasures and threshold ranges arecustomizable by the site implementing the ANCsystem.

3.2.2 Modular Code

ANC was architected with a very specific goal:adaptability. There are two ways in which Athenacan be considered adaptive. First, as describedabove, Athena will adapt countermeasures basedupon different behavior exhibited by a source IP ad-dress. The second way Athena is adaptive is by pro-viding a level of code modularity. When new net-work security technology is created, particularly inthe realms of intrusion detection and network statis-tics information, these technologies can be pluggedinto the ANC framework. Thus ANC retains thepossibility of remaining a useful layer of networksecurity long into the foreseeable future.

First, when new intrusion detection systems aredeveloped or improved, they can be used to sendalerts to Athena. Fortunately, this does not requiremodification of the IDS code itself. The new IDSsystem can be used as an additional IDS moduleby writing a wrapper for the IDS. The wrapper willtranslate alerts generated by the IDS into a com-mon format that Athena understands. This is theAthena Alert Protocol (AAP). The new IDS andwrapper are usually run on a computer separatefrom Athena, and AAP messages are sent over alocal, usually private, network.

The second form of modularity comes from the

13

ability to add new General Information (GI) mod-ules. Athena queries these modules, and the re-sponse is used in the information correlation pro-cess. To add a new GI module, the implementermust create or modify a function that performs allof the correlation. The correlation() function re-trieves information from the information modules,each with its own specific method of retrieval, andthen correlates all of the retrieved information toform a number used to update the cumulative score.

The third and final form of modularity in theANC framework is the addition and modificationof what countermeasures to use and when to usethem. As described above, different countermea-sures can be used when the cumulative score fallswithin a specific range. When new countermeasuresare developed, they can be integrated into the ANCframework to increase the adaptability.

3.2.3 Implementation

IDS Modules – In our prototype implementa-tion of ANC, we use Snort, a popular open sourceintrusion detection system, as our solitary IDS. Wewrote a wrapper to allow Snort to communicatewith Athena via the Athena Alert Protocol. Thethreat level of an alert is specified in a configura-tion file. When the Snort wrapper sees a specificstring, specifying the type of threat, the wrapperconverts that to a static number, which becomesthe threat level of that alert.

GI Modules – We use three different sources ofGeneral Information for correlation: Country Check,NetState, and AthenaDB. The first two are consid-ered General Information modules. Country Check,when queried with a source IP address, will return anumber that indicates the sensitivity of that coun-try according to the Department of Energy’s Sensi-tive Countries List. A zero value means the countryis not sensitive, one represents a moderately sensi-tive country, two is sensitive, and a value of threerepresents a highly sensitive country. The moduleis queried via a direct network connection.

NetState is a different type of information mod-ule. NetState, internally developed Sandia soft-ware, can be used outside of ANC for the purposeof passively gathering information about the “demo-graphics” of a network. NetState records what ser-vices are running on networked computers and whatports they are running on. NetState also stores in-formation about the operating system running oneach computer and summaries of previous networkactivity. Athena uses the NetState GI module to get

specific information about the target of an attack.This information includes the most recent time ofconnection to the target port, the first recorded timeof connection to the target port, and whether theport and recorded service correspond to the IANAstandard port assignment [17]. Information is gath-ered over the network via a direct connection to theNetState MySQL database.

Athena – Athena is the most complex part of ourimplementation of the ANC framework. It was de-signed with efficiency, adjustability, and modular-ity in mind. Multiple threads, implemented withpthreads (POSIX threads), handle the many tasksof Athena. When first initialized, Athena’s Sched-uler thread initializes variables and then starts theremaining threads. When finished performing ini-tialization, it waits for a signal from the operat-ing system to close all threads and clean up whenAthena terminates.

During initialization, Athena creates anAlertHandler thread. This thread listens on a localUDP socket for Athena Alert Protocol messages.When an AAP message is received, the followingoperations are performed: First, the alert messageis added to a cache of alerts, which is then usedto detect floods of attacks that could potentiallyoverwhelm normal Athena processing. Next, thethreat level of the alert is checked to see if it isalready above the threat threshold. If so, Athenauses ANCP to request that HENC respond to theattacker. If not, the alert is queued.

Athena also starts MessageHandler threads,which dequeue alerts from the alert queue and per-form the information correlation in order to deter-mine if the threat is high enough to warrant counter-measures. Both AlertHandler and MessageHandlerthreads update the AthenaDB with the new cumu-lative score for future correlation as well as otherstatistics.

AthenaDB uses a custom PostgreSQL databasethat holds attack statistics. In particular, theAthenaDB is queried for the most recent time ofthreat from the attacker, the number of attacksfrom the same subnet, the total number of recentthreats, and the number of recent threats of thesame type. This information, along with informa-tion from the GI modules is all gathered in thecorrelation() function, which returns a numberrepresenting the threat level and in turn is used tomodify the cumulative level. (See Appendix C: In-formation Correlation)

Finally, Athena starts up the FloodHandlerthread, which performs two tasks. First, it monitors

14

the threat cache. If a large number of threats arereceived in a small amount of time, it sets up vari-ables to indicate that the AlertHandler should lookfor multiple threats of the same type in the cacheand handle such threats as an attack flood. Flood-Handler’s second task is to periodically decrementall of the cumulative scores stored in the AthenaDBaccording to the aging policy. This allows false pos-itives to be removed from the malicious address listover time.

4 Evaluation and Performance

4.1 ifpw

FreeBSD’s ipfw works well within HENC for con-trolling the breadth of datagrams responded to.Adding and removing ipfw rules via ANCP is fast.Work done by Mikula, Tracy, and Holling [18] ondynamic spam blocking indicates that ipfw can fil-ter efficiently up through at least 1,000-1,500 fire-wall rules. Their work was performed on a machineconsisting of a 1GHz Athlon processor, 640MB ofRAM, and FreeBSD 2.2.8-STABLE. Our tests neverexceeded this number of rules, so we were not ableto push the limits of ipfw. In addition, we expectour system to scale even better because we are us-ing a newer version of ipfw on more powerful hard-ware. We did not investigate ipfw in depth enoughto determine if performance differences will surfacebecause we relied on a default “deny” policy in con-junction with “allow” rules and the previous workused a default “allow” policy with “deny” rules.

4.2 Snort

Currently we use the default rule-set for Snort. Wedidn’t want to spend time tuning the rule-set forour network since this is an art already establishedby system administrators. Our Snort system wasoverwhelmed on our network with traffic averaging8Mb/s. It is obvious that the rule-set needs to betrimmed in order for Snort and the Snort alertwrapper to run effectively. The rule-set should besimilar to that of the IDS system being used forproduction network monitoring.

4.3 Athena

We tested the rate at which IDS alerts could be re-ceived by Athena. Athena was run on a machinewith a 1.7GHz Athlon XP2000+ CPU, 512MB ofRAM, and a Fast Ethernet (100Mb/s) network in-terface card. We ran a test program from another

machine that simply spit out IDS alerts as fast as itcould. We ran several tests sending 10,000 alerts –a number we decided was unrealistically high for areal enterprise network at Gigabit Ethernet speeds– as fast as possible. Athena was able to handleevery single alert without dropping any.

Next we tested sending 1,000 alerts – still a highnumber except when under a Distributed Denial ofService (DDoS) attack – as fast as our testing toolwould generate them. We ran this test four dif-ferent times without Athena dropping any alerts.We restarted Athena in between tests to clear outits cache. The total time to process the alerts wasonly recorded for two of the tests. It took about10.5 seconds to process the alerts both times. Thisshowed that Athena could process each alert in littlemore than 1/100 of a second. It appears then, thatAthena will be able to process somewhere between90 and 100 threats per second on any similar ma-chines. We anticipate that IDS alerts (on a “tuned”IDS machine) will not occur nearly this often, evenon an enterprise network with a Gigabit Ethernetinfrastructure.

We noticed three obvious processing bottlenecksin Athena. The first bottleneck is a result of slow in-teractions with the databases. The database queriesto both NetState and AthenaDB take the most timewithin Athena, even with AthenaDB running on thelocal Athena machine.

Because of the time spent querying the databases,the processing of alert messages causes a backlogsince receiving alerts is much faster. This secondbottleneck could potentially fill up Athena’s alertcache, causing alerts to be dropped.

The third bottleneck appears when Athena isrun with multiple MessageHandler threads. On oursingle processor system, multiple threads tend toslow down the overall speed of processing messages.We believe that multithreaded or multiprocessorsystems will be able to handle multiple threads withinAthena more efficiently.

We also noticed that processing the first alert af-ter starting Athena routinely takes more time thansubsequent alerts. The first alert often took be-tween 1.5 and 3.5 seconds for Athena to process.Further alerts were processed in the 10,000 microsec-ond range.

4.4 ANC as a Whole

We ran two different tests to evaluate the overallperformance of our ANC prototype on our produc-tion network. The first test determined whetheror not we could send countermeasures to attackers

15

from a particular address while someone performedreal work across the Internet on the computer withthat same network address. Our test showed thatwe could effectively send countermeasures to pro-tect a computer while that computer participatedin production work via the Internet. HENC andAthena were each running on their own computer–a 2.8GHz Intel Xeon CPU, 1 GB of RAM, and Gi-gabit Ethernet NICs. Snort was run on a machinewith dual 2.8GHz Intel Xeon CPUs, 1 GB of RAM,and Gigabit Ethernet NICs.

To do this, we wrote a rule for Snort that wouldinterpret standard ICMP echo request datagrams asmalicious packets. Each time Snort received oneof these datagrams, it notified Athena, which inturn incremented the malicious IP address’s cumu-lative level by a value of 5. Our threat level thresh-old was set at 25, so that six ICMP echo requests(within the time limit of the threat level aging rou-tine) would cause the offending IP address to beadded to HENC’s list of hosts to respond to withcountermeasures. We configured Honeyd to respondwith network traffic typical to a specific operatingsystem (randomly chosen by us) as if no TCP orUDP ports were open. Using an attacking host un-der our control on the Internet, we began sendingICMP echo requests to the computer we were try-ing to protect. After sending six echo requests andreceiving six echo replies from the real computer,we started receiving duplicate echo replies. Thiswas a result of both HENC and the real computerreplying to the attack echo requests. We verifiedthat HENC had received the appropriate informa-tion from Athena by listing its ifpw rules. We triedto connect to the protected computer via ssh andwere not able to connect. Using a good host underour control on the Internet, we were able to connectto the protected computer immediately via ssh andperform our work.

We changed the test slightly so that both ourattacking host and our good host were connectedto the protected computer via ssh before Snort de-tected our malicious echo requests. We initiated theecho requests from the attacking host, and after sixrequests, HENC terminated the ssh connection tothat host while we continued to conduct our workfrom the good host.

Our second test of ANC determined the averagetime between detecting an attack and sending thefirst countermeasure in response to the attack. Weused the same Snort rule of six ICMP echo requeststo identify our “attack.” We determined this timeby measuring the latency between the time of thesixth datagram arriving and the time of the first

countermeasure datagram (echo reply) leaving. Weused a tcpdump network tap at our border router totake these measurements.

We ran six tests:

Run ANC Latency (in seconds)1 .7203622 .6902513 .5105384 .4507185 .3003226 .633722

Mean .551

Notice that there is a rather large deviation fromthe mean in most of the data points. We were moreinterested in the order of magnitude of the latencyrather than precise values.

There may be many causes for the large devia-tions, assuming static time for the cost of correla-tion and communication over the control network.For one, the reliability of packet delivery over theInternet can affect the results. For example, if dur-ing a given run datagrams six through ten were lost,then the start time of the run would actually be thereception time of the eleventh packet, not the sixth.This would actually cause our calculation to under-state the latency.

Another (more likely) cause of the deviations isthat Snort is not receiving all of the ICMP echorequests. Because our Snort process is utilizing theCPU close to 100%, it is highly likely that the IDS isnot running fast enough to keep up with the streamof incoming datagrams. The result is that data-grams are being dropped from the receive buffer.Some of those dropped datagrams would likely bethe malicious ICMP echo requests. Due to the dy-namics of Internet traffic, it would be very diffi-cult to predict which of the echo requests is beingdropped. Our sixth recorded datagram may actu-ally be the tenth datagram sent, for instance. Thisphenomenon would also cause our calculation to un-derstate the actual latency.

We believe the latency of 551 milliseconds is ac-ceptable in a real-time countermeasure system. Op-timizations could be made to the Snort ruleset, thecontrol network, and the ANC software itself, if lesslatency were required.

5 Future Work

While working on this project, we discovered severalareas where we would like to spend more time. Be-

16

low we outline several areas that we believe deservefurther investigation.

5.1 HENC

Currently, countermeasures are sent in response toinbound datagrams as determined by the bindingof the destination IP address to a Honeyd template.Using the mutate keyword, we can randomly changethat binding at a specified interval. We would liketo allow Athena to choose a specific Honeyd tem-plate (and thus operating system) to rebind an IPaddress to. In addition, we would like to dynam-ically open and close virtual ports of machines onthe protected network.

We envision countermeasures that are even moredynamic in nature than they currently are. Wewould like to investigate sending different counter-measures from the same IP address when the sourceof the malicious datagrams differs. Doing this wouldrequire a substantial overhaul of the underlyingHoneyd code in order to allow for a binding betweensource and destination addresses. Athena’s scoringsystem, with its varying threat levels, would alloweasy use of these types of countermeasures.

As noted in the performance evaluation of ANC,attackers will receive two responses to each of theirdatagrams when attacking real machines. This isbecause both HENC and the real computer respond.A smart attacker may analyze his/her probe or at-tack results at the network level (as opposed toblindly accepting results given by the attack ap-plications) and thereby see that he/she is receiv-ing countermeasures. The attacker could then al-ter his/her attack methods to slip into the net-work undetected, without being subjected to coun-termeasures. HENC could be modified to commu-nicate with a firewall on the protected network.The firewall would filter out network datagrams di-rected from the real computer to the attack hostonce countermeasures have been initiated to pro-tect the real computer.

Also, we would like to investigate the perfor-mance of ipfw further to determine its scalabil-ity on the newest CPUs with the most up-to-dateFreeBSD operating system. We were not able tofind other recent research in this area.

5.2 IDS Modules

We currently only support receiving IDS alerts fromSnort. We would like to write additional IDS mod-ule wrappers to support Sandia’s mon system andVern Paxson’s Bro.

5.3 GI Modules

Currently, to incorporate additional GI modules,the user is required to modify the Athena sourcecode directly. To increase the usability and modu-larity of the system, we want to create a standardinterface to the modules using an Expect script.The wrapper would listen for a standardized re-quest, query the GI modules, and then translatethe response from the GI modules to a strictly for-matted message useable within Athena.

5.4 Athena

Athena relies on the IDS modules for recognitionof malicious patterns of traffic on the network. Ifthe IDSs do not detect a threat, Athena will nothave a stimulus to begin correlation. We would liketo initiate the Athena correlation engine based onother stimuli to the system. Pattern recognitioncould take place within Athena as well, tipping thesystem off to threats before an IDS has picked themup. Using sources other than those typically usedby an IDS could allow earlier detection of threats.

We would like Athena to gather more statis-tics about its performance. Athena already com-putes and uses the real-time load of the system,but it would also be useful to compute the CPUload for each type of alert and keep a history ofmeasured loads. Athena could use these values toadjust thresholds at various times during the courseof a day or month when the load is abnormallyhigh or low. The system would essentially adaptto varying network conditions, changing the prior-ity and/or types of threads to appropriately handlethe load (or expected load) at any given time.

It is difficult to handle real-time threats becausealerts can arrive at gigabit speed from the network,and analysis and processing of the alert may requiremany network based queries and numerous calcula-tions. We could speed up Athena’s analysis by re-placing the PostgreSQL back-end database with areal-time database such as Prevayler [19], which isfully ACID compliant and much faster.

Another way to speed up real-time threat han-dling would be to have Athena adapt to suit theneed of the given configuration. Since the GI mod-ules are user configurable, we cannot predict howlong it would take to query them all. Having Athenaperform this calculation ahead of time would pro-vide the system administrator a means for decidingwhich GI modules Athena should query based onthe expected slowdown.

We could also speed our system up by load bal-ancing the Athena duties. We could link multi-

17

ple systems running Athena, thereby adding redun-dancy and increasing capacity for analysis of IDSalerts.

6 Conclusion

The Adaptive Network Countermeasure system hasproven to work well in our test environment andin limited production testing. We believe that afull-scale implementation of this system on a pro-duction network would produce significant resultsin repelling Internet attacks while not interferingwith legitimate use of the network.

Through our work we have shown that we canprovide a comprehensive and robust countermea-sure system. The system responds quickly enoughto be effective in repelling active attackers. Networkdatagrams generated by the system appear authen-tic and succeed in leading malicious users in thedirection of our choosing.

The ANC system is able to dynamically (in real-time) detect and respond to malicious traffic di-rected to nonexistent and existent machines. Thisbehavior allows us to send countermeasures to pro-tect a machine that is conducting typical businessvia the network without interfering with that legit-imate communication.

The Athena portion of ANC has proven to bean intelligent system for detecting malicious behav-ior and acting on it dynamically. Athena can takeinformation from several different sources, correlatethat information to provide a threat assessment ofa potential malicious user, and issue commands tothe countermeasure system to act on that threat.The code was written modularly so that additionalinformation sources can be added easily to the ex-isting set of sources. Athena’s “brain” can be eas-ily reprogrammed by modifying or rewriting thecorrelation() function.

7 Acknowledgments

The authors acknowledge the effort of Steve Hurd,Jim Hutchins, and Tim Toole in writing the fundingproposal for this project. We also thank Jim andTim for their insights into intrusion detection asperformed by mon at Sandia National Laboratories- California. Jim’s contributions to the realm ofnetwork countermeasures have been invaluable.

We also thank Sandia CCD (Center for CyberDefenders) interns Derek Cotton, Chris Kolina, andYuqing Mai for their assistance in adding ICMP re-sponse capabilities to Honeyd.

References

[1] Symantec Corporation. (2003, Au-gust) W32.blaster.worm. [Online]. Avail-able: http://securityresponse.symantec.com/avcenter/venc/data/w32.blaster.wor%m.html

[2] Renaud Deraison. (2003) Nessus. [Online]. Avail-able: http://www.nessus.org/

[3] Fyodor. (2003) Nmap. Insecure.org. [Online].Available: http://www.insecure.org/nmap/

[4] Fyodor. (1998, October) Remote os detectionvia tcp/ip stack fingerprinting. Insecure.org. [On-line]. Available: http://www.insecure.org/nmap/nmap-fingerprinting-article.html

[5] Ofir Arkin. (2003) Xprobe/xprobe2. Sys-Security Group. [Online]. Available: http://www.sys-security.com/html/projects/X.html

[6] Ofir Arkin. (2000, July) Icmp usage in scanning.Sys-Security Group. [Online]. Available: http://www.sys-security.com/html/projects/icmp.html

[7] Anil Somayaji and Stephanie Forrest, “Automatedresponse using system-call delays,” in Proceedings

of the 9th USENIX Security Symposium. TheUSENIX Association, August 2000.

[8] Jamie Twycross and Matthew M. Williamson, “Im-plementing and testing a virus throttle,” in Pro-

ceedings of the 12th USENIX Security Symposium.The USENIX Association, August 2003.

[9] (2003) Snort. [Online]. Available: http://www.snort.org/

[10] (2003) Snortsam. [Online]. Available: http://www.snortsam.net/

[11] Vern Paxson, “Bro: A system for detecting net-work intruders in real-time,” Computer Networks,vol. 31, no. 23–24, pp. 2435–2463, December 14,1999.

[12] ForeScout Technologies Inc. (2003) Activescoutsite. [Online]. Available: http://www.forescout.com/activescout.html

[13] Niels Provos, “Honeyd: A virtual honeypot dae-mon,” presented at 10th DFN-CERT Workshop,February 2003.

[14] Ugen J. S. Antsilevich, Poul-Henning Kamp, AlexNash, Archie Cobbs, and Luigi Rizzo. (2003)Freebsd hypertext man pages: ipfw. LawrenceBerkeley National Laboratory Network ResearchGroup. [Online]. Available: http://www.freebsd.org/cgi/man.cgi?query=ipfw

[15] Steven McCanne and Van Jacobson, “The bsdpacket filter: A new architecture for user-levelpacket capture,” in Proceedings of the 1993 Winter

USENIX Conference. The USENIX Association,January 1993.

18

[16] Lawrence Berkeley National Laboratory Net-work Research Group. (2003) libpcap. [Online].Available: http://ftp.ee.lbl.gov/nrg.html

[17] (2003) Port numbers. IANA. [Online]. Available:http://www.iana.org/assignments/port-numbers

[18] Deeann M. M. Mikula, Chris Tracy, and MikeHolling, “Spam blocking with a dynamically up-dated firewall ruleset,” in Proceedings of LISA

2002: 16th Systems Administration Conference.The USENIX Association, November 1992.

[19] (2003) Prevayler. [Online]. Available: http://www.prevayler.org/

19

Appendix A

Setting up an ANC System

1. Overall design – The ANC architecture is com-posed of many modular components with spe-cific functions. In our prototype system, eachof these parts is implemented by software withcommunication channels between each part.Some of the software is open source, off-the-shelf software, and some is internally devel-oped software. Our working prototype mir-rors very closely the logical model that we ar-chitected (Figure 1).

Corresponding with each of the four parts inthe model – IDS modules, GI modules, Athena,and HENC – are four different physical com-puters that, in our prototype, provide each ofthe functions. Our communication channelsbetween systems and the greater network areclosely analogous as well.

2. Configuring the Basic system – Each of thefour computers in the prototype has the samebasic underlying hardware and operating sys-tem. They are fairly high-performance server-like systems with 2.8 GHz Intel Xeon proces-sors, 1GB of RAM, and 36 GB SCSI hard-drives. Two of the computers, for Snort andNetState, require one Gigabit Ethernet cardand one Fast Ethernet card each. The HENCcomputer requires two Gigabit Ethernet cardsand one Fast Ethernet card. The Athena sys-tem requires only one Fast Ethernet card. Theinternal communication can be set up in manydifferent ways. We chose to have all four com-puters attached to the same 10/100 Ethernetswitch for internal communication. We do notanticipate that traffic loads will require morebandwidth on this internal network.

Each of the four systems is running FreeBSD4.8-RELEASE. The default kernels are accept-able, with two exceptions: the HENC com-puter needs to have the IPFW and DIVERToptions turned on. IPFW is used to filter outtraffic that HENC is not responding to, andHoneyd uses divert sockets to receive networkdatagrams.

3. Configuring the Snort computer – Snort canbe installed from the FreeBSD ports tree. RunSnort according to the supplied documenta-tion. We use the default rule set that comeswith Snort. Snort gets its incoming trafficfrom the GigE network.

Snort needs to be run with the ’-A unsock’flag so that messages are sent to a local Unixsocket. Our program, snort wrapper, listenson the other end of that Unix socket and sendsAthena Alert Protocol messages to Athenaover the Fast Ethernet control network.

4. Configuring the NetState computer – NetStateis Sandia-developed softwareand must be installed from source. The com-puter with NetState must have MySQL in-stalled, which can be installed from the portstree. Follow the NetState-supplied instruc-tions for installing and running NetState.

NetState does have one flaw when combinedwith network countermeasures. The counter-measures themselves, if seen by NetState, willaffect how NetState views the network. Thesolution is to place NetState in a location inthe network architecture such that it does notreceive traffic that is the result of networkcountermeasures.

Additionally, the NetState computer runs theCountry Check program, which has its ownset of installation instructions. Athena com-municates with Country Check using a TCP/IPconnection over the control network.

5. Configuring the Athena computer – Athenashould be compiled from source and run onthe Athena computer. All of Athena’s com-munication happens over the Fast Ethernetcontrol network. Both PostgreSQL and MySQLneed to be installed on the Athena computer;they can be installed from the ports collection.The Athena configuration files offer many vari-ables that can be changed to tune for perfor-mance and/or desired modes of operation.

6. Configuring the HENC computer – The mod-ified version of Honeyd needs to be compiledfrom source and run on the HENC computer.This computer also runs the countermeasurelogger (cmlog) and the ANCP server (server.pl).Some of the configuration variables can bechanged in the configuration files. TemplateBuilder (tb.pl) can be used to build the con-figuration files.

7. Putting it all together – All of the services andprograms should be set up to be run when thecomputer is booted. When the network con-nections are all set up properly, the HENC,NetState, and Snort computers should all be

20

receiving network traffic. The HENC com-puter should also be able to send countermea-sure datagrams. Finally, all computers shouldbe able to communicate on the internal con-trol network.

21

Appendix B

FreeBSD IP Stack Patch

(available from http://erie.ca.sandia.gov/anc/)

This patch has been successfully tested with both FreeBSD 4.7 and 4.8. Other versions of FreeBSDshould work, but care should be taken to ensure the patch is applied successfully.

You must have the FreeBSD source installed to apply this patch and be comfortable with compiling yourown kernel. Please look in /usr/src/Makefile for steps to compile the kernel. Basic directions to apply thepatch and recompile are as follows:

# patch < /path/to/stack.patch

# cd /usr/src/

# make buildkernel KERNCONF=YOUR_KERNEL_HERE (default is GENERIC)

# make installkernel KERNCONF=YOUR_KERNEL_HERE (default is GENERIC)

# reboot

Patch:

--- /usr/src/sys/netinet/raw_ip.c Fri Feb 15 13:25:24 2002

+++ /usr/src/sys/netinet/raw_ip.c Fri Sep 6 09:53:19 2002

@@ -239,12 +239,14 @@

m_freem(m);

return EINVAL;

}

+/* FreeBSD patch for proper honeyd functionality

if (ip->ip_id == 0)

#ifdef RANDOM_IP_ID

ip->ip_id = ip_randomid();

#else

ip->ip_id = htons(ip_id++);

#endif

+*/

/* XXX prevent ip_output from overwriting header fields */

flags |= IP_RAWOUTPUT;

ipstat.ips_rawout++;

22

Appendix C

Information Correlation

Athena receives information for characterizingthreats from multiple entities in the ANC system.This information is correlated to determine thethreat level of a particular outside IP address. Thethreat level describes how bad or malicious the re-mote host is. When the threat level has crosseda given threshold, countermeasures are sent to theoffending host. The types and frequency of coun-termeasures may change based on the system ad-ministrator’s configuration of ANC.

In addition to the alert information send by anIDS module, Athena retrieves information from sev-eral built in GI (General Information) modules:CountryCheck, a NetState module, and an inter-nal database, AthenaDB. The AthenaDB databaseis used to maintain statistics about the behavior ofremote hosts. The querying and correlation of all ofthis information occurs in the correlation() func-tion.

The first step in information correlation is theretrieval of information. The correlation() func-tion receives the IDS alert from the MessageHan-dler thread as a parameter. This message containsthe source and destination IP addresses and ports,the time of receipt of the alert (in microseconds),the threat type, the threat level, and the protocolof the datagram(s) that triggered the alert. Someof this information is used to retrieve informationfrom the NetState database. In particular, Athenaretrieves the time of the most recent connection toa local IP/port pair, the time of the first connectionto a local IP/port pair, and whether the local desti-nation port matches the recorded service accordingto the IANA registry of well-known ports.

Next, the local AthenaDB is queried for spe-cific recent (within the last 60 seconds) statistics.These statistics include the number of IDS alerts,the number of IDS alerts of the same threat type,and the number of IDS alerts whose source IP ad-dress is within the same 24-bit subnet as the IPaddress that generated the IDS alert in question.

Finally, Athena retrieves statistics related to thespecific remote IP address. Athena retrieves thecurrent cumulative level for that IP address, the lasttime a threat was received for that IP, and the lasttype of threat received from that IP. The CountryCode level is also retrieved.

Six-Step Correlation

The computed threat level always starts off at thelevel retrieved from AthenaDB or zero if the IP ad-dress has never caused an alert before. This com-puted threat level is then modified by the resultsof different correlations, with each correlation mul-tiplying their contribution by a user configurableweight value.

The first modifier is the threat level of the IDSalert message itself. This number is weighted andthen added to the computed threat level.

Next, the country code modifier, a number be-tween zero and three, is weighted and added to thecomputed threat level.

Next, Athena checks the port-to-service matchmodifier by querying NetState. If the port does notmatch the service running on that port accordingto the list of well-known ports, this is considereda bad situation. It may mean that the destinationhost is compromised and running a backdoor (Tro-jan Horse) program that allows remote access. Ifthat port was opened recently (within the last 60seconds), the situation is worsened because it couldmean that the host is actively being compromised.Numerical values associated with these conditionsare weighted and added to the computed threatlevel. This correlation is limited by the fact thatNetState is only able to recognize a limited set ofservices.

The fourth modifier is related to detecting ma-licious intent. A remote host may accidentally trig-ger an alert once, but alerts become increasinglyless likely to be accidental if the host continues totrigger the same alert. So, if the current threat typeis the same as the last threat type from the specifiedIP address, the computed threat level is updated toreflect this possibly bad behavior.

The next modifier is similar to the backdoor de-tection modifier above, except that there is no cor-relation to whether the service matches the port.Though not necessarily a sign of malicious intentby itself, this information may signify bad behaviorwhen combined with other alerts generated for thatremote source IP address.

The final correlation determines whether thealert has been generated during normal businesshours. Some attackers may opt to perform mali-cious activities at night because they believe no-body will be watching their actions. This modifierpenalizes this traffic based on that line of thought.

When all of the information is correlated, thenew cumulative threat level is set to the computedthreat level for the remote IP address. This new

23

level may trigger changes in response. After anychanges have been initiated via ANCP, the databaseis updated to reflect the new threat level.

24

Distribution:

1 Chris Tracy1001 Milton Street #1Pittsburgh, PA 15218

1 MS 0455 R. S. Tamashiro1 MS 0630 D. H. Schroeder1 MS 0801 A. L. Hale1 MS 0801 W. F. Mason1 MS 0801 M. R. Sjulin1 MS 0806 J. A. Hudson1 MS 0806 P. C. Jones1 MS 0806 M. M. Miller1 MS 0806 L. Stans1 MS 0812 R. L. Adams1 MS 0813 R. M. Cahoon1 MS 0813 S. R. Carpenter1 MS 0813 D. M. Kayatt Jr.1 MS 0813 A. A. Quintana1 MS 0813 R. A. Suppona1 MS 9003 J. L. Handrock1 MS 9003 C. M. Hartwig1 MS 9003 K. E. Washington1 MS 9011 N. A. Durgin1 MS 9011 B. V. Hess1 MS 9011 J. D. Howard1 MS 9011 S. A. Hurd1 MS 9011 J. A. Hutchins1 MS 9011 E. D. Thomas1 MS 9011 T. J. Toole5 MS 9011 J. A. Van Randwyk1 MS 9012 J. A. Friesen1 MS 9012 S. C. Gray1 MS 9012 P. E. Nielan1 MS 9019 S. C. Carpenter1 MS 9019 B. A. Maxwell1 MS 9037 J. C. Berry1 MS 9217 S. W. Thomas1 MS 9914 C. D. Ulmer1 MS 9915 N. M. Berry1 MS 9915 H. Y. Chen1 MS 9915 M. L. Koszykowski

3 MS 9018 Central Technical Files, 8945-11 MS 0899 Technical Library, 96161 MS 9021 Classification Office, 8511/Technical Library, MS 0899, 9616

DOE/OSTI via URL1 MS 0323 D. Chavez, LDRD Office, 1011

25

This page intentionally left blank

26