Maya Gokhale, Dave Dubois, Andy Dubois, Mike Boorman, Steve Poole, and ... our system is a set of filter rule descriptions in the format of the public.
Granidt: Towards Gigabit Rate Network Intrusion Detection Technology Maya Gokhale, Dave Dubois, Andy Dubois, Mike Boorman, Steve Poole, and Vic Hogsett Los Alamos National Laboratory Los Alamos, NM, U.S.A. 87545
Abstract. We describe a novel application of reconfigurable computing to the problem of computer network security. By filtering network packets with customized logic circuits, we can search headers as well as packet content for specific signatures at Gigabit Ethernet line rate. Input to our system is a set of filter rule descriptions in the format of the public domain “snort” databases. These descriptions are used by the hardware circuits on two Xilinx Virtex 1000 FPGAs on a SLAAC1V [9]board. Packets are read from a Gigabit Ethernet interface card, the GRIP [8], and flow directly through the packet filtering circuits. A vector describing matching packet headers and content are returned to the host program, which relates matches back to the rule database, so that logs or alerts can be generated. The hardware runs at 66 MHz with 32-bit data, giving an effective line rate of 2 Gb/s. The granidt combination software/hardware runs at 24.9X the speed of snort 1.8.
1
Introduction
As digital network technologies become more advanced, the security issues related to these technologies become more complex [1], [4]. To protect public and private networks, software-based intrusion detection systems have become the norm, with the goal of protecting against compromise to the network’s integrity, the machines that form the network, and the information contained within it. However, with the widespread availability of 1 Gb/s Local Area Networks and 10Gb/s links, it has become clear that current software-based intrusion detection systems cannot process packets at those line rates, resulting in inadequate monitoring of network traffic and increasing the probability of an undetected attack. Available software-only systems can monitor, at the very most, 100Mb/s rate, which is an order of magnitude less than required. Parallel processing solutions are appearing in the marketplace (for example, see [6]), and reconfigurable hardware assist for ATM firewall [5] as well as regular expression matching [2] have been proposed. In this paper, we present a novel use of reconfigurable computing to filter GigE network packets for network security applications. Our hardware platform consists of the SLAAC1V[9] card, a reconfigurable computer containing three Xilinx Virtex XCV1000 FPGAs, ten 256KBx36 SRAM memory modules, and a M. Glesner, P. Zipf, and M. Renovell (Eds.): FPL 2002, LNCS 2438, pp. 404–413, 2002. c Springer-Verlag Berlin Heidelberg 2002
Granidt: Towards Gigabit Rate Network Intrusion Detection Technology
405
daughter Gigabit Ethernet card, the GRIP[8]. Packets pass from the line directly into the logic circuits programmed into the FPGAs. One set of logic circuits compare header fields from the packet with known attack features according to a “snort”-format rule database. A second set of circuits compares packet content to desired content strings. The patterns to be matched are loaded into the FPGAs on start-up, and new patterns can be easily accomodated without re-compiling the hardware. Positive matches from comparisons on both circuits are processed in software, where more complex analysis can be performed. By filtering packet headers and content in hardware, we greatly reduce the burden of software processing. The software can log the packet or generate an alert after examining the hardware match results. In the next section, we describe the network intrusion detection application and summarize current capabilities of these systems. Next, we describe our hardware/software approach, and the system we have built, “granidt,” that filters Gigabit rate Ethernet packets. We report area/clock-speed/throughput performance statistics of the system. We end with conclusions and directions for future work.
2
Network Intrusion Detection Systems
The purpose of network intrusion detection systems (NIDS) [7] is to protect a Local Area computer network from unauthorized access and malicious interference. A NIDS must scan every packet in order to monitor network traffic for pre-defined patterns that might indicate suspicious activity. Basic NIDS operations include scanning for particular patterns with packet headers, checking message content for suspicious patterns, and monitoring the interchange of related messages in a session. NIDS typically operate in passive receive-only mode, sniffing all packets coming over the wire and reporting results over a different channel. These systems are often rules-based, as illustrated in Figure 1. This rule language is used by snort, a light-weight public domain network intrusion detection. The rules specify actions to perform when a packet contains certain combinations of protocol, IP addresses, port address ranges, IP option values, content strings, etc. The action might be to log the packet, log summary information about the packet, or to alert an operator. The packet log can be used by backend analysis tools to determine post-facto intrusions. More sophisticated techniques analyze entire TCP messages and perform session-level analysis in “real-time” as packets are being received. However, all of these approaches share the need to scan and process packets at line speed. If a packet is dropped, the fidelity of downstream processing is reduced, and network security is potentially compromised. In the current state of the practice, all these functions are carried out in software, with a combination of kernel-level and application-level code. Software-only NIDS that we have measured operate in the 100Mb/s regime. As the complexity of the software processing increases,
406
Maya Gokhale et al.
alert tcp $EXTERNAL_NET any -> $HOME_NET 23 (msg:"BACKDOOR Telnet Solaris StoogR"; flags: A+; content: "StoogR"; reference: arachnids,526;) alert tcp any any -> $HOME_NET 139 (msg:"WORM - Possible QAZ Worm Infection"; flags:A; content: "/71 61 7a 77 73 78 2e 68 73 71/"; reference:MCAFEE,98775;)
Fig. 1. Examples of Intrusion Detection Rules from snort Data Base
software methods drop packets at even 100Mb/s, compromising the effectiveness of the network security application.
3
A Software/Hardware Approach to Packet Scanning
Our software/hardware co-processing approach combines flexible software with reconfigurable hardware circuits as illustrated in Figure 2.
Rule Compiler
rule 1; rule 2; ... rule n;
rule 1 HW rule 2 HW ... rule n HW SW Rule Table SW Rule Program
Hardware/Software Packet Processing System
Acquire Packet Hardware Packet Matcher
Hardware
Hardware
Match Vector Packet
Table Rule Processor Software
Fig. 2. Hardware/Software Co-Processing
To partition between hardware and software, the rule compiler (a modified snort rule parser) reads a snort format database (see Figure 1) and creates entries for Content Addressable Memories (CAMs). If rules are updated, the rule
Granidt: Towards Gigabit Rate Network Intrusion Detection Technology
407
compiler simply creates new CAM entries – no FPGA reconfiguration is required. Our modified snort loads the hardware configurations and CAM entries and then initiates packet processing. The software then receives each packet, to which a “Match Vector” is appended by the hardware, and performs the appropriate action as dictated by the rule(s) that match the packet. The hardware reads packets from a GigaBit Ethernet Network Interface Card (NIC) and matches the packet to CAM entries, creating the Match Vector. 3.1
Software Processing
The software consists of two components, the Rule Compiler, and Rule Processor. The rule compiler reads a rule file in snort database format. It creates – a hardware representation of the rule fields to be matched, and – a software representation of the rules, which is input to the Rule Program. The rule compiler accepts a subset of snort rule syntax, including the snort header, and the content and message fields of the snort options. Fields in the packet header such as protocol, source and destination IP addresses, and port address ranges may also be specified in a rule. For example, in Figure 1, the first rule specifies TCP protocol; the source IP address of “EXTERNAL NET,” which is a snort variable initialized elsewhere; any source port; the destination IP address of “HOME NET;” and destination port 23. The relevant options are the content string “StoogR,” the flags, and the message to be generated if a packet matches the rule. The action to be taken is an alert. The rule compiler creates several tables that are used to initialize hardware CAMs. These include a protocol table; source and destination IP addresses, possibly with subnet masks and possibly negated; specific source and destination ports; source and destination port range tables; and content strings. In addition, the rule compiler creates an internal representation of the rules that links fields specified by the rules to the hardware CAM tables and range tables. This data structure is used by the Rule Processor. The Rule Processor initializes the hardware CAMs and initiates packet processing. It receives each packet scanned by the hardware. Appended to the packet is a Match Vector generated by the hardware that records which CAM entries matched the packet. The Rule Processor correlates the Match Vector to the internal rule database and determines an action for each rule, such as alert or log. 3.2
Alternative Rule Processor
In the above design, the Rule Processor compares Match Vector results to the rule database for each rule in order to generate the appropriate action for that rule. This incurs a software overhead that moderates the hardware pattern match speedup. We have also designed an alternative rule processor in which the hardware automatically uses match vector output to identify matching rules, and returns
408
Maya Gokhale et al.
a Rule Vector to the software. A “1” bit in the Rule Vector indicates that the corresponding rule matched, and the software then merely performs the actions associated with the matching rules. In this approach, the Rule Compiler, in addition to the CAM and Range Tables, generates VHDL statements that set the Rule Vector. As an example, suppose we have three fields. Field A is 32 bits wide and has a CAM that is 64 slots deep. It does not require any Range Table (RT) entries. Field B is 16 bits wide and has a CAM with 16 slots, and uses 4 RTs. Field C is 8 bits wide and has a CAM with 128 slots. We have the following rules: Rule 1: A = X’00001234 and B= Range X’1000 downto X’0005 and C = X’CB Rule 2: A = X’00001234 and B= Range X’1000 downto X’0007 and C = X’01 Rule 3: A = X’abcd1234 and B= X’0050 and C = EXCEPT X’CB The software registers A= X’00001234 to slot 7 of field A CAM. It registers B= Range X’1000 downto X’0005 to RT 2, and C= X’CB to slot 127 of C CAM. VHDL code will be generated for rule 1: Rule(1)
