Download pdf - Assisting Network Intrusion Detection with …rexlei86/hardwareSecurity/intrusion_detection... · .Snort[ 10] , an open-source NIDS that provided the test data for performance comparisons,

Assisting Network Intrusion Detection with Reconfigurable Hardware

B. L. Hutchings and R. Franklin and D. Carverpepartment of Electrical and Computer Engineering

Brigham Young University, Provo, UT 84602hutch @ee.byu.edu

1 Abstract

String matching is used by Network Intrusion Detec-tion Systems (Nms) to inspect incoming packet pay-loads for hostile data. String-matching speed is oftenthe main factor limiting NIDS performance. String-matching performance can be dramatically improved byusing Field-Programmable Gate Arrays (FPGAs); accord-ingly, a "regular-expression to FPGA circuit" module gen-erator has been developed. The module generator extractsstrings from the Snort Nms rule-set, generates a regu-lar expression that matches all extracted strings, synthe-sizes a FPGA-based string matching circuit, and generatesan EDIF netlist that can be processed by Xilinx softwareto create an FPGA bitstream. The feasibility of this ap-proach is demonstrated by comparing the performance ofthe FPGA-based string matcher against the software-basedGNU reg ex program. The FPGA-based string matcher ex-ceeds the performance of the software-based system by600x for large patterns.

malicious packet may be overlooked. This paper exploresthe feasibility of using reconfigurable FPGAs to performstring matching for NIDS with the end goal of performingstring matching on all packets at network rates.

This paper discusses the design and performance of anFPGA-based regular-expression module generator that wasdeveloped entirely in Java using JHDL [1, 7]. The mod-ule generator automatically: (1) extracts strings from theSnort rule database[10], (2) generates a regular expressionthat matches all extracted strings, (3) synthesizes a circuitthat will match the generated regular expression, and (4),generates an Emf netlist that can be processed by Xilinxplace and route software to create an FPGA bitstrearn.

3 Background

2 Introduction

Three topic areas are relevant to this project:

.past work in FPGA-based string matching,

.Snort[ 10] , an open-source NIDS that provided the testdata for performance comparisons, and

.JHDL, the Java-based hardware design tool kit thatwas used to implement the module generator.Network intrusion detection systems (NIDS) monitor

network traffic for predefined suspicious activity or datapatterns and notify system administrators when malicioustraffic is detected so that appropriate action may be taken.NIDSs often rely on exact string matching of packet pay-loads to detect hostile packets and string matching is themost computationally expensive step of the detection pro-cess [2]. Accordingly, NIDS typically apply string match-ing only to those packets that are most suspect, and only tothose sections of the packet most likely to contain the of-fending data. For example, Snort (a popular NIDS found atwww.snort.org) [10] checks port numbers, packet headersand flags, etc., to ensure a given packet has a high likeli-hood of containing hostile data before performing stringmatching on the packet data. Unfortunately, while thisstrategy of data reduction makes the problem of detectinghostile packets tractable, it also means that it is likely that a

String matching with FPGAs String matching is not anew application area for FPGA-based systems. Indeed,some of the earliest papers in FPGA-related research areasreport efforts to accelerate string matching in a variety ofareas. Several references [8,9,4,5,3] describe a few of themany string-matching efforts that have been reported overthe last ten years. These efforts cover the broad range oftext searching, from searching general text-based databasesto similarity matching of DNA databases.

Most relevant to this effort is recent work by Sidhuand Prasanna [ II] to accelerate grep regular expressionsearches with FPGAs. Because of the need for a rapid in-teractive response, their approach focused on compilationstrategies that could quickly convert a regular expressioninto an FPGA circuit. As is commonly done in software,

Proceedings of the 10 th Annual IEEE Symposium on Field-Programmable Custom Computing Machines (FCCM’02) 1082-3409/02 $17.00 © 2002 IEEE

programmatic structural design [7]. In its current state,JHDL is a complete structural design environment thatin-cludes debugging, netlisting and other design aids. Cir-cuits are described by writing Java code that programmat-ically builds the circuit via JHDL libraries. Each circuitelement in JHDL is represented as an object; these objectsinherit from core classes that setup the net-Iist and simula-tion models. Circuits are created by calling the construc-tor for the corresponding JHDL object and passing Wireobjects as constructor arguments that are connected to theports of the circuit. Once constructed, these circuits can bedebugged and verified with the JHDL simulator and designbrowser. JHDL emits EDIF net-Iists that can be passedto Xilinx place and route software for bit-stream genera-tion. Finally, JHDL provides run-time support for debug-ging the running hardware in the context of the originaldesign using the same GUI as the JHDL simulator. JHDLis suitable for this project because it can be used to writemodule generators [6] that are much more complex thancan be accomplished with VHDL. For example, complexcircuit-generation algorithms and data structures that aremuch more amenable to general-purpose languages can bewritten in Java and combined with JHDL circuit librariesto create sophisticated module generators.

Sidhu and Prasanna compile the regular expression into aNondeterministic Finite Automata (NFA); however, unlikesoftware approaches, they skip the usual step of deriving aDeterministic Finite Automata (DFA) from the NFA, anddirectly implement the NFA with FPGA hardware. Thissimplifies and speeds up the compilation process ofcreat-ing regular-expression matching hardware. Each NFA usesa single FF to implement the accepting state of the preced-ing stage. Flip-flop-rich FPGAs provide logic and flip-flopresources well suited for this arrangement.

The module generator discussed In this paper uses theNFA-based hardware implementation strategy of Sidhuand Prasanna because of its inherent modularity. With theNFA approach, each character and metacharacter of thesupported reg-ex syntax can have a corresponding, pre-compiled circuit element in a related circuit library. Us-ing a syntax-directed approach, the module generator in-stances a circuit element that corresponds to each charac-ter/metacharacter it finds in the regular expression and theninterconnects these elements according to the structure ofthe expression. The module generator also extends the pre-vious work by automating it and augmenting it with addi-tional metacharacters, including: "?", ".", and "0". Over-all contributions of this work include: (I) development ofa fully automated module generator that can generate cir-cuits that match arbitrarily large regular expressions, (2)exploration of various circuit optimizations that improvespeed and area utilization, and finally, (3) application ofthis module generator to prove feasibility of using FPGAsto accelerate string matching in network security applica-tions.

4 Technical Approach

The technical approach was to create a JHDL-basedmodule generator capable of handling a wide range of reg-ular expression operators, based on standard reg-ex syn-taX. Supporting several reg-ex operators makes the modulegenerator easier to adapt to future research and also makesit usable for other string-matching tasks apart from net-work intrusion detection. However, for this project, onlytwo regular expression operators were absolutely neces-sary: concatenation (implicit) and alternation ( I ). Themodule generator uses concatenation to create strings fromsingle characters and alternation to create one large regu-lar expression from all of the individual strings extractedfrom the Snort rule-set. This section will provide a briefoverview of regular expression syntax and the general formof the strings that were used to test the system, will dis-cuss how the module generator was developed in JHDLand will discuss some of the circuit optimizations that were

explored.

Snort, An Open Source Nms Snort[10] is a popularNIDS that runs under most versions of Linux and Win-dows. Snort's basic operation is to examine all networktraffic, and log intrusion events. Pattern-matching tech-niques are used to compare network traffic to known at-tacks that are specified in a rule-set. Snort is very popularbecause it is open-source and because of the control it af-fords the user over rule-set configuration. A user can easilymodify the rule-set, for example, to reduce the number ofpatterns to improve performance or to add patterns to de-tect new attacks. For this project, Snort provided a modelof NIDS function and, more importantly, a default rule-set that contained the test data that were used to test theautomatic module generator and the ci~cuits that it gener-ates. The default rule-set contains patterns for detectingvarious attacks as well as viral exploits such as Code Redand NIMDA.

4. Regular Expression Syntax

Regular expressions are a common way to express

string matching patterns. The atomic elements of a reg-

ular expression are the single characters to be matched.

JHDL, a Java-based Design Tool JHDL [ 1, 7] con-

sists of a set of Java libraries that can be used to perfoIlD


Figure I: A Matching Circuit for a(blc)?

ed together with the output from the 'a' character matcheroutput and generates a true value on the Match output (theregular expression matches "ab"). For additional exam-ples, please see the paper by Sidhu and Prasanna [11].

4.2 Examples from the Snort Rule Database

These are combined with meta-character operators that al-low the user to express concatenation, alternation, Kleene-star, etc. Concatenation (implicit) is used to create multi-character matching patterns from single characters (or sub-strings) while alternation ( f) is used to create patterns thatcan match any of two or more substrings. Kleene-star(*) allows a pattern to match 0 or more occurrences ofthe pattern in a string. Combining the different opera-tors and single characters allows complex expressions tobe constructed. For example, the expression (th(islat)*)will match "th", "this", "that", "thisis", "thisat"', "thatis","thatat", etc. The supported syntax also accommodateshexadecimal notation that is used to describe nonprintablecharacters (ASCII) in the Snort rule database. For exam-ple' the sequence \xO a will match the null character and\x2 a will match a space.

The module generator also supports the "?" operatorwhich will match 0 or 1 occurrences of the expression towhich itisapplied. rlr2? willmatchrl,orrlr2. It is imple-mented such that it matches rl :c where c means it matchesimmediately. The availability of this operator makes it pos-sible to study the impact that sharing common string pre-fixes has on FPGA circuit area. For example, the expres-sion runlrunning can be converted into run(ning)? whichmay reduce the number of comparators used to match thecharacters in the expression.

A simple circuit for matching the regular expressiona(blc)? is presented in Figure I to help explain the gen-eral operation of the matching circuits created by the mod-ule generator. a(blc)? matches: "a", "ab", and "ac". Thecorresponding matching circuit (shown in Figure I) con-sists of three character matchers (the three blocks in thefigure), two OR-gates and interconnecting wires. A charac-ter matcher consists of an edge-triggered D flip-flop (FF),a character comparator, and an AND-gate. The input tothe FF serves as an enable to the character matcher; theoutput of the character matcher becomes true on the nextclock edge if: (I) the character input matches the comparedvalue, and (2) the enable signal (the FF input) is a logi-cal 'I' .During circuit operation, all input characters arebroadcast to all character matchers one character at a time.For the sake of illustration, assume that the input string tothe circuit is "ab" and that all FFs are reset to a logical '0'.Now, 'a', the first character, is broadcast to all charactermatchers and on the next clock edge the output of the firstcharacter matcher becomes a logical '1 '. This enables the'b' and 'c' character matchers because this output is wiredto the enables for these matchers; it also causes the Matchsignal to become true (the regular expression matches "a").The second character, 'b', is then broadcast to the charac-ter matchers and on the next clock edge the output of the'b' character matcher becomes true. This signal is OR-

Patterns from the Snort rule database are used to gener-ate regular expressions for intrusion detection. Snort rules,in general, specify much more than just a data pattern tosearch for; they include information on packet headers andflags, TCP ports, etc. However, this effort is only con-cerned with string matching, so the parser extracts only the"content" fields from Snort rules and combines them intoone regular expression. For example,

content: "IOOIEloo/MlooIL";content: "IOOINlooIWIOOIS";

content:"RIOoIIloolclooIHlooIElooIDlooI21°olo.;

are the actual content fields from a Snort rule that de-tects the NIMDA virus. These three patterns are combinedby the module generator into a single regular expression,shown below.

(\xOOE\xOOM\xOOL I

\xOON\xOOW\xOOS I

R\xOOI\xOOC\xOOH\xOOE\xOOD\xOO2\xOOO)

Another example is the content field from a Snort rule for

detecting attempts to access the Code Red 2 back Door:

content: "scripts/root.exe?"

which is converted to the regular expression:

(scripts/root\ .exe\?) (the backslash "escapes"the .'." and "?").


4.3 Operating Environment 4. optimizes the generated regular expression to extractsubstrings that can be shared, etc.

The operating environment for this module generatordiffers from that described in Sidhu and Prasanna in two

significant ways.

I. Hardware can be precompiled. Patterns are knownwell beforehand and compile time is not an issue fornetwork security applications. Thus, vendor placeand route tools are used to create a fully automaticregular-expression-to-bitstream tool. This is in con-trast to Sidhu and Prasanna where vendor place androute software could not be used and there was no au-tomatic path from the regular expression to matchinghardware (several manual steps were reported in the

paper).

2. Matching patterns can be very large. The entire de-fault Snort rule-set contains content rules in excess of15,000 characters and will continue to grow as moreattacks and viruses are identified. This means that cir-cuits must be area efficient so that the available FPGAresources can be used to match as many patterns as

possible.

The module generator front-end is implemented with Javasource code and the back-end uses Java source and JHDLlibraries to generate a detailed structural description andEDIF net-list.

VHDL is not suitable as the sole implementation lan-guage for a module generator such as that described inthis paper. Apart from the general awkwardness of writ-ing parsers, dynamic data structures, etc., in VHDL anddebugging them with a simulator, VHDL tools make it im-possible to perform execution of both the front-end (dataprocessing) and back-end (circuit generation) in a singletool or environment. For example, front-end software writ-ten in VHDL can be "executed" with a VHDL simulator,however, it is not possible to then generate circuits in a sim-ulator. On the other hand, a VHDL synthesis tool can per-form circuit generation, but it cannot execute the front-endsoftware in order to obtain the parameters used to generatethe circuit.

The only way to overcome this problem with VHDL isto take a combined strategy that uses a general-purpose lan-guage such as C++ for front-end processing and a VHDLsynthesis tool as the back-end for circuit generation. How-ever, this approach is also unsatisfactory for several rea-sons:

4.4 JHDL versus VHDL

I. It requires the designer of the module generator tohave expertise in both C++ and VHDL.

2. It complicates the design and debugging of the mod-ule generator because the designer will have to debugboth the C++ and VHDL code.

3. It requires the end-user to install and maintain an ex-pensive synthesis tool that in many cases only servesas a net-Iist translator because the front-end usuallygenerates a structural description from the user input.

4. It requires the end-user to understand how to use theVHDL synthesizer (at least be able to interpret mes-sages generated by the VHDL synthesizer) becausethe front-end will occasionally generate incompatibleVHDL code due to bugs in either the front-end or thesynthesizer, or due to versioning problems.

JHDL overcomes the basic problems listed above be-cause it is based on a general-purpose language. More-over, this general-purpose language heritage also makes itstraightforward to add new functionality to the JHDL suite.The schematic viewer, simulator, and various browser win-dows have been developed in modular fashion and canbe extended or modified to ease debugging and verifica-tion on a per application basis. For example, the default

The design and implementation of the regular-expression module generator was heavily influenced by theavailability of a general-purpose language such as Java.Generally, complex module generators consist of two ma-jor parts: a front-end that perfonns data processing to de-tennine the structural circuit details based on some userspecification, and a back-end that perfonns circuit gen-eration and emits the corresponding net-Iist. Except incases where the module generator is extremely simple, ageneral-purpose language is better suited for implement-ing the front-end than a Hardware Description Language(HDL) such as VHDL. Front-end processing usually in-terprets user input and this often requires the sort of pro-cessing nonnally associated with programs written usinggeneral-purpose languages: parsing of input, error detec-tion, construction and processing of dynamic data struc-tures such as linked lists and trees, file 1/0, etc.

For example, the front-end of the regular-expressionmodule generator perfonns the following:

I. opens and parses the Snort file to extract the contentfields of each rule (the strings to be matched),

2. generates a large regular expression that includes allof these strings,

3. parses the generated regular expression to create aninternal representation of the expression that is usedfor circuit generation, and


Figure 2: Modified Schematic View

SL:[CE OUTPUT

Il\~ ~ .

~ex , ,I .

I.'"

schematic view was extended during this project to pro-vide a direct visual indication of subexpression matchesthat occur during a debugging session. In Figure 2, the ex-pression ( JHDL I bus t ) is being matched against an in-coming string of characters. In this example, the cross-hatch pattern indicates that the' I' and 'H' characters havematched thus far. Extending JHDL tools in this manner isenabled via a standard API and a few lines of lava code.

"--,CHARACTER INPUT

I L;"-y.PREV:to:1 .OtrrPOT ~.

4.5 Hardware Implementation Details

i~ O I

II~

Figure 3: Virtex Slice usage

generator overcomes this by creating a pipelined broad-cast tree that takes into account the fan-out requirementsof the string matcher. The tree structure reduces loadingon any individual wire by distributing the load across sev-eral branches of the tree. The tree is pipelined to further

improve clock rate.The module generator also reorganizes the regular ex-

pression to make it easier to implement the alternation op-erators as distributed OR-gates. For example, the alter-nation operator can be naively implemented with a singleOR-gate for each occurrence of the operator. However, thiswill create a long serial chain of OR-gates that may resultin long delays and poor performance. The module genera-tor takes an alternative approach and transforms the regularexpression from infix to postfix form. For example, the ex-pression (a I b I c I d) is transformed into (abcd III) .

This makes it easier to detect a run of alternation opera-tors. Each run of alternation operators is grouped togetherwith an OR-gate of appropriate size (four-input in the ex-ample) and the module generator connects these with otherOR-gates for which these runs are constituents. This par-

Efficient utilization of FPGA resources is important be-cause Snort rule-sets currently contain approximately 15Kcharacters -a figure that will grow continually. Accord-ingly, various optimization strategies are used to improvethe utilization and performance of circuits generated by themodule generator. To improve overall performance, themodule generator: (1) uses mapping directives to reducethe area of the most commonly used operator (concatena-tion), (2) creates a pipelined fan-out tree to reduce propa-gation delay for character broadcasting, (3) reorganizes theregular expression to improve OR-gate performance, and(4) shares common subexpressions to further reduce area.

The module generator optimizes the concatenation op-erator (the most commonly used operator) by forcing a sin-gle, eight-bit character matcher to fit within a single sliceby using mapping directives. The output of the matcherpasses through a flip-flop and connects back into the slicevia the carry chain to implement a logical AND of thematch of the current character and the previous one asshown in Figure 3. This leads to a reduction in circuit areathat is reported later. Minor attempts were also made atmanual placement but early feedback suggested this maynot be effective for this application.

With the NFA approach, incoming characters are glob-ally broadcast to all character matchers and this can createperformance problems due to very large fan-out and theresultant loading of the broadcasting wires. The module


just after the string match occurs). Overall throughput wascomputed by dividing the size of the data set by the aver-age time taken to process the entire data set over ten testruns. The CPU utilization figures are calculated accordingto;

allel approach to implementing the OR-gate improves per-formance by reducing the combinational delay that occurswith the naive, serial approach.

Different versions of the module generator also com-bined common prefixes to reduce FPGA area. For exam-pIe, the words "this" and "that" share the common pre-fix "th". This means that the two regular expressions,"thislthat" and "th{islat)", are equivalent. The module gen-erator recognized these common prefixes by building aTRIE dictionary from the different sequences within theregular expression. Experiments confirmed the area sav-ings, however, clock frequency was generally lower be-cause sharing common prefixes lowers the number of flip-flops between combinational logic. Table I illustrates thetradeoffs for a 600 character string containing shared pre-fixes.

su s~ime + Syste~~)

Elapsed Real Time

5.2 Interpretation of Results

From the results in Tables 2 and 3 it can be seen thatfor small test cases, software and hardware performanceare approximately the same. However as the size of theregular expression increases, the hardware based imple-mentation outperforms the software-based version by morethan 600x in the worst case. Throughput for the circuit-based string matchers requires one clock cycle per char-acter of input (0(1) in regular-expression length); largerregular expressions simple acquire more circuit area to ex-ploit more parallelism to process the longer string in thesame amount of time. Throughput for the circuit-basedstring matchers is thus independent of the length of the reg-ular expression and the small variances seen in the tablesare the result of experimental error. In contrast, software-implemented string matchers require more time to pro-cess each incoming character as the regular expressiongrows in length. An examination of the two tables showsthat, for the middle range of the tests (844 -2689 charac-ters), software slowdown relative to the size of the regularexpression is roughly linear (O(n) in regular-expressionlength) although it gets worse at 4971 characters. An-other item of interest is the relatively low and relativelyconstant CPU utilization of the hardware based implemen-tation which is independent of the size of the data beingsearched. This occurs in the hardware-based test setupbecause the CPU is primarily moving data, leaving thecomputationally-intense string matching operations to theFPGA-based matcher. CPU utilization and throughput datafrom Table 2 are also plotted in Figures 4 and 5.

5 Performance Analysis

To determine relative performance, the circuits gener-ated by the module generator were compared against asoftware-based string matcher, GNU «reg ex". The testingprocess used three computers: one that sends data consist-ing of mostly printable text with inserted attacks, a secondthat reads this data over the network and time stamps itimmediately before and after passing it through either theGNU reg ex or FPGA-based matcher, and a third computerthat reads the time-stamped data and computes overallla-tency. The test data varied in size and incorporated a rep-resentative sample of rules in the default Snort rule-set thattarget the following types of intrusion:

.attacks on webservers

.viruses such as NIMDA and Code Red

.backdoor/trojan exploits

5.1 Test Setup

Pentium 3 (750 MHz) computers running Redhat Linuxversion 2.3.7-10 served as the test computers. The string-matching circuits executed on a PCI-based ISI SLAAC-IV board (housed in the second computer) that containsa Virtex XCVl000 device and several FIFOs that supporthigh-throughput DMA transfer. Global clock rate for theFPGA device was set to 33MHz because of limitations inthe FPGA interface to the PCI bus -a figure that is gen-erally much lower than the FPGA circuits can operate, asreported by the Xilinx static timing analyzer. The reportedlatencies include only the actual time spent string match-ing and ignore any delays due to TCP/IP overhead or othernetwork delays (time stamps are computed just before, and

5.3 FPGA Utilization Data

Tests also included the computation of FPGA area uti-lization for several string matchers of different sizes. Dataare organized into two sets: one set shows the perfor-mance/utilization data with manual mapping turned on {asdiscussed in the Technical Approach), the other set showsperformance/utilization data with manual mapping turnedoff {Table 5). As is typical for many FPGA-based designs,clock frequency for the hardware string matchers dropswith increased utilization. This tends to be especially truefor circuits like the string matcher which require lots of


Table I: Comoarison of approaches for Reg~ ~xoression Implementations

LRouted I Frequency (MHz) IImplementationI 7946 ,; 43.219NFA(non-shared, 660 chars) 674

NFA(shared, 660 chars) 556

II Slices 1 Flip-Flops I LUTs 100 I 661 11347 I

r 527 I 1092 j 6405 34.483


global routing resources (string matching requires broad-casting of character data throughout the FPGA).

The results obtained by turning off manual mapping aresomewhat surprising. Turning off manual mapping dra-matically increases the amount of circuitry by at least 50%or more but reduces clock rate for the largest regular ex-pressions. Further study of this issue will be required tofully understand the tradeoffs that manual mapping pro-vides, however, for the time being, these data indicate thatthe module can either optimize for clock rate or area de-pending on whether the number of patterns or overall per-formance is the major concern.

.§

I~"'8"

6 Conclusions

FPGA-based string matching appears to be a suitablecandidate for use in NIDS. Inclusion of FPGA-basedmatchers in these systems may reduce the CPU workloadsignificantly and make it possible to examine more datain more packets than is possible with software-only ap-proaches. Presently, the rules in NIDS like Snort must be-carefully written to examine packet data payloads onlyaf-ter everything else has been tried; hardware-based match-ers like those described in this paper should ease this re-striction considerably. This is not to imply that acceleratingstring matching as discussed in this paper is a panacea; net-work security is a very complex problem and sning match-ing represents only a small part of the overall solution.Still, hardware-based pattern matchers that are capable ofinspecting packet data at network data rates for most or allof the traffic on the network should prove to be very useful.

Figure 4: CPU Utilization

'7 Future Work

The work reported here proves basic, technical feasi-bility of using reconfigurable FPGAs to accelerate stringmatching for network security applications. Future workwill probably focus in two general areas: circuit and tech-nology optimizations, and additional applications in net-work security. In these early stages of the project, the focuswas on achieving error-free operation with moderate levelsof performance. The generated circuits are only moder-ately pipelined and there is a lot of room for clock rateimprovement. Virtex-2 devices also present opportunitiesfor performance enhancement and optimization strategiesfor these devices will be studied. Beyond string match-ing, there are opportunities for applying circuit-based op-timizations to other parts of the networking and securityproblem. For example, packet reassembly was performedusing software for this project. It may make sense to im-nlement the TCP/IP stack directly on the FPGA in order

Figure 5: CPU Throughput


to achieve higher levels of perfonnance. Finally, FPGAsthat include an embedded processor present an interestingtarget of opportunity; they have the potential to provide anintegrated, scalable approach that allows a mix of softwareand hardware to be dedicated to problems in network secu-rity. Software may be used for less regular, control-specificprocessing while the hardware may be used for perfonningcomputationally intensive tasks for large, regular data sets.

FPGAsforCustom Computing Machines, pages 175-

184, Napa, CA, April 1998.

[2] C. I. Coit, S. Staniford, and I. McAlerney. Towardfaster string matching for intrusion detection or ex-ceeding the speed of snort. In DARPA Informa-tion Survivability Conference and Exposition II, 200JProceedings, volume 1, pages 367-373,2001.

[3] W. Culbertson, R. Amerson, R. Carter, P. Kuekes, andG. Snider. The Teramac configurable custom com-puter. In I. Schewel, editor, Proceedings of the Inter-national Society of Optical Engineering (SPIE). FieldProgrammable Gate Arrays ( FPGAs) for Fast BoardDevelopment and Reconfigurable Computing., pages201-209, Philadephia, PA, October 1995.

8 Acknowledgements

The authors would like to thank the many students inthe Reconfigurable Logic lab for their help in this project.Many thanks also go out to the folks at Los Alamos Na-tional Laboratories and ISI-East (Maya Gokhale, BrianSchott and others) for suggesting this topic to us at aSLAAC retreat. [4] P. W. Fou1k. Data-fo1ding in SRAM configurab1e FP-

GAs. In D. A. Bue11 and K. L. Pocek, editors, Pro-ceedings of IEEE Workshop on FPGAs for CustomComputing Machines, pages 163-171, Napa, CA,

Apri11993.

9 References

[1] P. Bellows and B. L. Hutchings. IHDL- an HDL for

reconfigurable systems. In I. M. Arnold and K. L.

Pocek, editors, Proceedings of IEEE Workshop on

[5] B. Gunther, G. Milne, and L. Narasimhan. Assess-ing document relevance with run-time reconfigurable


machines. In J. Arnold and K. L. Pocek, editors, Pro-ceedings of IEEE Workshop on FPGAs for CustomComputing Machines, pages 10-17, Napa, CA, April1996.

[6] S. Hemmert and B. L. Hutchings. An application-specific compiler for high-speed image morphology.In J. M. Arnold and K. L. Pocek, editors, Proceedingsof IEEE Workshop on FPGAs for Custom ComputingMachines, pages to-appear, Napa, CA, April 2001.

[7] B. Hutchings, P. Bellows, J. Hawkins, S. Hemmert,B. Nelson, and M. Rytting. A cad suite for high-performance fpga design. In K. L. Pocek and J. M.Arnold, editors, Proceedings of the IEEE Workshopon FPGAs for Custom Computing Machines, pagen/a, Napa, CA, April 1999. IEEE Computer Society,IEEE.

[8] D. P. Lopresti. Rapid implementation of a genetic

sequence comparator using field-programmable gatearrays. In C. Sequin, editor, Advanced Research inVLSI: Proceedings of the 1991 University of Cali-

fornialSanta Cruz Conference, pages 138-152, SantaCruz, CA, March 1991.

[9] D. V. pryor, M. R. Thistle, and N. Shirazi. Textsearching on Splash 2. In D. A. Buell and K. L.Pocek, editors, Proceedings of IEEE Workshop onFPGAsforCustom Computing Machines, pages 172-177, Napa, CA, Apri11993.

[10] Martin Roesch. Snort -lightweight intrusion detec-tion for networks. In 13th Systems AdministrationConference, LISA '99, Seattle, WA, November 1999.www. usenix. orgl events/lisa99/full-papers/roesch/roeschJttmV.

[11] R. Sidhu and V. K. Prasanna. Fast regular expres-sion matching using fpgas. In I. M. Arnold and K. L.Pocek, editors, Proceedings of IEEE Workshop onFPGAs for Custom Computing Machines, pages to-

appear, Napa, CA, Apri12001.
