A 10-Gbps High-Speed Single-Chip Network Intrusion Detection and Prevention System

Transcription

1 A 0-Gbps High-Speed Single-Chip Network Intrusion Detection and Prevention System N. Sertac Artan, Rajdip Ghosh, Yanchuan Guo, and H. Jonathan Chao Department of Electrical and Computer Engineering Polytechnic University, Brooklyn, NY Abstract Network Intrusion Detection and Prevention Systems (NPSs) are vital in the fight against network intrusions. NPSs search for certain malicious content in network traffic (i.e., signatures). Comparing all traffic to these signatures is a challenge for high-speed networks. In this paper, we present the implementation of a 0-Gbps hardware NPS and related design issues. This goal of signature detection at high-speed is achieved using a single FPGA, without any external memory. We also implemented and tested a proof-of-concept system with -Gbps traffic. A database to store and a web server to display the intrusion alerts from the NPS were also developed for this system. I. INTRODUCTION Everyday, it is getting more profitable for malicious intruders to gain unauthorized access to different resources in a network. They sometimes gather critical information (such as credit card numbers), sometimes use computing resources for their illegal activities (such as spam relays), or simply disrupt the legitimate services of these networks. Network Intrusion Detection and Prevention Systems (NPSs) are vital systems for networks to fight against these intrusions. Certain malicious content in network traffic specific to each intrusion (a signature) is used to identify intrusions. NPSs search for these signatures in network traffic to detect and prevent intrusions. To detect signatures, all network traffic should be compared against each and every signature. This is very challenging especially for today s high-speed networks with line speeds of 0 Gbps and beyond. Additionally, the number of signatures increases daily as new intrusion types are introduced. An NPS is required to add these new signatures into its signature list rapidly without disrupting its main operation of detecting and preventing intrusions. Software NPS are not scalable to high-speeds. Hardware NPSs have gained a lot of attention recently due to the intrinsic speed advantage over software systems. In this paper, we present the design of a single-fpga, high-speed, signature-based NPS. Due to its small size, the design allows multiple parallel engines to run on a single FPGA chip, satisfying the high-speed requirement of today s networks. Additionally, the proposed system does not rely on any external memory. It can provide 0-Gbps throughput using a single commodity FPGA and we believe 40-Gbps throughput is achievable on current state-of-the-art FPGAs. Finally, since all signature data is stored in on-chip memory and not embedded into the FPGA logic, no FPGA reconfiguration is needed for signature updates, allowing rapid updates by simple memory updates. The contributions of this paper are as follows, We recently proposed a minimal perfect hashing scheme called TriBiCa (Trie Bitmap Content Analyzer) to efficiently store and query intrusion signatures []. In this paper, the improvements to the basic TriBiCa scheme are presented. A detailed hardware architecture of a 0-Gbps NPS is given and related design issues are addressed. A proof-of-concept design at Gbps is implemented and tested. Various tools, including a tool to automatically map intrusion signatures to on-chip memory in a storageefficient manner, a database to store, and a web server to display the alerts from the NPS, are also developed. The rest of the paper is organized as follows. Section II summarizes the related work on hardware-based NPS. Section III defines the problem of string (signature) matching for NPS using hash tables. Section IV describes the basic data structure, whereas Section V shows the improvements to this basic data structure. Section VI shows the architecture to detect long signatures based on the data structure. Section VII show implementation results of the proposed NPS. Section VII also describes the issues experienced during the design and testing of the NPS. Finally, Section VIII concludes the paper. II. RELATED WORK Current state-of-the-art hardware NPSs are either fast but hard to update, or easy to update but slow. One hardware NPS approach (such as [2], [3]) is to store signature data on off-chip memory. These systems are easy to update, since the update operation consists of replacing only a few values in external memory. However, access to data on external memory takes much longer than access to on-chip data. In other words, the speed of these NPSs is determined by the speed of external memory access rather than on-chip speeds. This is not acceptable for today s high-speed networks. The second hardware NPS approach [4] [] tends to store all signature data on-chip. These NPSs store some or all of the data on on-chip memory []. The data can also be stored partially on the on-chip logic. On-chip logic requires reconfiguration each time a new signature is added. This is a much slower process compared to off-chip memory updates and requires 343

2 taking the NPS off-line and leaving the network vulnerable to any attack during the update. Note that our design can fit signature data to a fraction of the on-chip memory, so that no external memory or reconfiguration is needed. III. PROBLEM DEFINITION Let s assume that there is a set S of signatures, and we d like to detect if any of these signatures appear in the input (i.e., input traffic). A fixed-length sliding window is slid over the input and for each location, one string matching operation is performed to detect signatures. Let s denote the number of signatures in S with n and assume that all signatures in S have a fixed-length of L. Obviously, actual intrusion signature lengths are not uniform (i.e., different signatures have different lengths) and we will address this issue later in the paper. A hash-table [2] can be used to implement such a string matching system as follows. First, all signatures are inserted into a hash-table. Every time the input window is slid, the content of the window is hashed. The hash output is used to retrieve the signature in the corresponding location in the hash-table. This signature is compared with the content of the input window to see if the input actually contains this traffic. Unfortunately, the hash-tables are not perfect. Even with low load factors (γ), collisions are expected. This means one bin may be allocated by more than one signature and each of these signatures should be compared with the content of the input window until a match or no match is found. Although it can be shown hash-tables have O() average lookup performance, their worst-case performance can go up to O(n). If the hashtable is not designed carefully, an attacker may force a hashtable to operate at the worst case by applying crafted traffic that will cause system degradation and eventually denial-ofservice for the detection system [3]. IV. BASIC DATA STRUCTURE As described above, hash-tables addressed with ordinary hash functions have two issues: () Collisions are inevitable, thus worst-case performance is not good. (2) To reduce collisions, more memory should be used. If a special class of hash functions, called perfect hash functions, is used to address the hash-table, then collisions can be avoided altogether, yet the memory requirement is still larger than n, in general. A special class of perfect hash functions, called minimal perfect hash functions, guarantees collision-free hashing for a given set with n items using a memory of n slots. Recently, we proposed a minimal hash function suitable for hardware implementation []. Here, we briefly summarize our minimal perfect hash function. The main goal of a minimal perfect hash function is to map a set of n items to a memory with n slots without any collisions. The key idea of our approach is to use a binary trie as an address decoder to reach this goal, as shown in Figure. A balanced, fully loaded binary trie, as shown in Figure with l = log(n) levels has 2 l = n unique paths from its root All logarithms in this paper are in base 2. log(n) levels Addr= Fig.. b b 2 b 3 b 4 b 5 b 6 b 7 b 4 b 5 b 6 b 7 b b 2 b 3 0 b 7 b 6 b 5 b 4 b 3 b 2 b b 7 b 6 b 5 b 4 b 3 b 2 b 00 Binary trie as address decoder node to any of its 2 l leaf nodes 2. Each of these unique paths can be represented with an l-bit label, which then can be used as the address of each memory location. This l-bit label can be retrieved while traversing the trie from the root to the leaves. At each node, based on whether the next node in the path is the left or right child, the next significant bit of the label will be zero or one, respectively. To use this trie as an address decoder for the input set, let s start by putting all the items in set S into the root node of the trie. Then, partition the items into two equally sized groups by putting half of the items to the left child node and the remaining to the right child node. If this operation is repeated for all nodes until a leaf node is reached, each item in the set will be on a unique path from root to leaves. This path s label is the address of this item in the memory. It is not straightforward to partition the items equally at each step. Actually, this problem is equivalent to the classical number partitioning problem and it is NP-complete. In [] we showed partitioning algorithms to achieve this goal. In this paper, we will not show the details of these partitioning algorithms; instead, we summarize the resulting data structure to realize the binary trie that allows equal partitioning. The data structure for an 8-item set is shown in Figure 2. The programming of this trie to the data structure is carried out as follows. Each level of the trie is implemented as two bitmaps. One hash function is used for each level. Items are first hashed using the hash function of the level. The resulting bit in the first bitmap of the level, the Data Bitmap (DB), is set to. When all items are written to a level, the items are partitioned into two equal-sized groups by the partitioning algorithm. If an item is partitioned to the left group, the bit corresponding to this item (i.e., bit at the address pointed by the hash result) in the second bitmap (Next Node Bitmap 2 If n is not a power of two, the trie won t be balanced. Then, l = log(n) levels has 2n >2 l =2 log(n) n unique paths from its root node to any of its leaves. While the trie is not balanced, the memory will be left aligned, thus, still providing the minimum perfect hash property. 344

3 b 6 b 5 b 4 b Path Determines address 2 b 7 b 3 b 0 0 out of the four nodes represented by the 2 bits in each NB bin. H b 7 b 6 b 5 b 4 b 3 b 2 b 0 H 0 Aggregate 2 3 b 7 b 6 b 5 b 4 b 3 b 2 b H H2 0 Node 0 Node Node 2 Node 3 Node 0 Node Node 2 Node 3 b 7 b 6 b 5 b 4 b 3 b 2 b Address=0000 Fig. 2. Data structure for the binary trie (NB)) is set to 0 to show the next node is the left node. Similarly, items that belong to the second group are denoted by a corresponding to their location in the NB. This operation is replicated for each level. When the items are programmed, the system is ready for queries. Figure 2 also shows an example query where item b 3 is queried. The item is hashed and queried at each level starting from the root level. If the corresponding location in DB is set to, the NB value determines the next node (left or right). If the corresponding location in DB is set to 0, this means this item is not in this set and the query returns a no match. V. IMPROVEMENTS TO THE BASIC DATA STRUCTURE A. Aggregated Levels The basic TriBiCa data structure uses a binary trie with log(n) levels where at each level, the items in each node are divided into two equally sized groups. TriBiCa can be generalized to use a k-ary trie where each node has k child nodes and the items in each node are divided into k equally sized groups (k 2 and k may also differ between levels). In this section, we investigate this k-ary trie option for TriBiCa and we show that this option reduces the memory required and increases scalability. One way to achieve a k-ary trie for k>2 is to aggregate 3 multiple levels into a single level as shown in Figure 3. When levels are aggregated into a single level, all path decisions corresponding to the original levels can be done in the single aggregated level by referring to the single aggregated NB of this node. For instance in Figure 3, at each level only one address bit is revealed before aggregation. Thus, to choose the child node out of the four leaf nodes, two levels are required. After aggregation, one level is enough to choose the next node 3 Aggregation only allows k values that are a power of two, which is still suitable for simple addressing using the path in the trie. Note that it is also trivial to have nodes with arbitrary k values (e.g., k =3) but then the path cannot be used for simple addressing. Fig. 3. Level aggregation. Four points are noteworthy for aggregated levels: () A single hash function is used to address the bitmaps. (2) Each NB bin has log(k) bits to represent k different children. (3) The number of levels is reduced by log(k). (4) The DBs are merged and not aggregated, i.e., the aggregated node has a single DB. For small data sets, the efficient structure of TriBiCa levels makes them too small for typical on-chip memory unit sizes. As a result, the number of memory units that can be accessed concurrently (i.e., Block RAMs (BRs)), rather than the total memory size, determines the scalability. Aggregating levels allows multiple levels to be packed together and accessed in one memory access, which increases the scalability of TriBiCa. For instance, the basic structure with two levels requires two memory accesses/lookups, whereas the aggregated node in Figure 3 requires only one access. Although the logic is vast, reduction of hash functions can improve scalability for chips with very limited logic resources. Since, the aggregated levels share the same DB, the total DB memory is reduced. For instance, a level with m bins requires a total of 2 m bits for DB and NB. In the basic data structure, l such levels require 2 l m bits. However, if these l levels are aggregated they will share a single DB, thus reducing the memory requirement to (l +) m bits. B. Compressed Low-Nodes The hash-bitmap node structure of the basic TriBiCa is a space-efficient way to locate items in a node quickly without any search through the items in the bitmap. As we go down in the trie, the number of items per node is reduced. When the number of items in a node is small, searching through these items in parallel is manageable without incurring any time penalty. When the number of items is small and searching is done in parallel, it is more efficient to store only the location of these items in these nodes, rather than keeping the entire bitmap. This is because, as we go down in the trie, the number of items per node and the size of the bitmap get smaller. Thus the number of locations to store and the size of each location are reduced. Based on this observation, we propose a new space-efficient representation scheme for these low-nodes. Here, we define low-nodes as nodes that belong to one of the few bottom levels of the trie. For instance, the node given in the left of Figure 4 has two items and the bitmaps occupy 345

4 a total memory of eight bits. However, if only the locations (i.e., hash results) for the two items in this node are stored, this takes four bits in total. This compression reduces the required memory for this node by half. If all items are represented by their locations in the bitmap, a memory of n log(m) bits is required. In general, for a node where n log(m) < 2 m and n is not too high, so that matching all items in parallel is manageable on hardware, this compression scheme can be used. 8 bits in total I q L L 2 L 3 L 4 Fig. 5. Hash b b Fig. 4. L q Compress 4 bits in total Compression for low nodes. 2- Encoder 0 0 b Addr Query circuit for a compressed low-node with 4 items. Querying compressed nodes requires more care than the uncompressed scheme (address comparators rather than simple bit value test (0 or )). However, the circuit to achieve this goal is still very simple as can be seen from Figure 5, which shows a query circuit for a 4-item node. The query input, I q is first hashed to determine its location, L q. Then, this location is compared in parallel with the locations of the items stored in this node, L L 4. If any of the top two comparators gives a match, then this means the item belongs to the left child node. If any of the bottom two comparators give a match, then this means the item belongs to the right child node. The 2- decoder converts these two match values into a single bit address value (to left child or right child). If no comparators gives a match, then this item is not in the set S and can safely be discarded. Two items in the same group can be in thesamebin(e.g., L = L 2 is possible), however two items in different groups cannot be in the same bin (e.g., L 2 = L 3 is not possible) so at most one group can give a match as required. VI. DETECTING LONG SIGNATURES So far, we assumed that each item in S perfectly fits into each memory slot. In reality, this is not always guaranteed. For instance, in the intrusion signature database of Snort [4], signature sizes vary between to 22 bytes. To fit varying length items into a fixed size memory, an indirect addressing can be used. In indirect addressing, fixed size pointers to actual items are stored. This approach suffers from additional memory usage for pointer storage and increased memory access (one for the pointer and one for the actual item). Another approach is to divide the items into fixed size items to form a new set S. Then S can perfectly fit into the memory slots. The items in S can then be statefully constructed back when needed. In this approach, the operation is carried out in two steps. In the first step, fixed-size signatures are detected using the data structure. If there is a match, an corresponding to the signature is generated. Let s assume the fixed signature size is four bytes. If two s are detected four bytes apart, these may constitute an eight-byte prefix of a signature or the signature itself. To detect these long signatures, the two s detected are applied to a second detector that is also based on our data structure. The only difference is this detector detects pairs rather than fixed-size signatures. A signature does not necessarily have a size multiple of four bytes. But any signature with size more than 4-bytes can be divided into a prefix that has a length multiple of four bytes and a suffix that is up to four bytes. This observation allows a simple scheme to detect signatures with any length. Until the suffix is reached, the prefix of the signature is detected using the two detectors described above. For each suffix size (less than four bytes), separate detectors are used. The suffixes are also detected in two steps. In the first step, the suffixes are detected as one- to three-byte strings. If there is a match, an is generated. This is combined with the from the stateful detector and applied to the corresponding suffix detector to get a complete match. The whole engine is shown in Figure 6. The -3 byte detectors also detect signatures of size -3 bytes. Data In 32b 32b 24b 6b 8b 4-byte 3-byte 2-byte -byte Stateful State 3-byte suffix detector 2-byte suffix detector -byte suffix detector Queue es Fig. 6. Detection engine that consists of multiple detectors and detects signatures with all lengths. Signature detection is done in two steps. Short suffixes are detected separately. Each detector is further divided into two stages. The first stage is the minimal perfect hashing based address decoder that addresses the second stage, which is a memory where the 346

5 signatures (or pairs) are stored. Each detector is pipelined to guarantee one query per clock cycle. VII. IMPLEMENTATION TABLE I BLOCK RAM (BR) USAGE FOR ONE ENGINE # of levels Trie BR SigMem BR 4-byte Stateful byte byte suffix byte byte suffix 3 3 -byte byte suffix 3 3 Fig. 7. Architecture of the NPS The overall architecture of the NPS is shown in Figure 7. The incoming packets are distributed evenly among multiple packet queues, where each queue is served by one Detection Engine. If an engine detects a signature (i.e., finds a match), then the of this signature is passed to the Alert Generator. The alert generator issues UDP alert packets that show the information about the malicious packet (5-tuple and time stamp) and the signature(s) detected in this packet. These packets are sent to an alert database for further processing. In addition to the hardware, various software tools are developed for TriBiCa. Most notably, a tool for mapping signatures (generic signatures or Snort signatures) into TriBiCa is developed. Given a signature set with varying sizes, the tool first chops the signatures into fixed size chunks of size c = 4 bytes. The tool also identifies the short signatures and suffixes (i.e., signatures and suffixes with size less than c bytes). Next, to detect full signatures, the tool generates state tables to be programmed into the stateful detector and suffix detectors. Then, the tool maps the signatures, suffixes and state tables into their respective TriBiCas. Although, the focus here is on the application of TriBiCa on NPS, TriBiCa can also be applied to different applications. The developed tool also has a separate module to generate VHDL files for generating TriBiCa architectures with various parameters (e.g., number of levels, memory sizes, number of children, etc.). A simple simulator is also developed to simulate TriBiCa data structure on software with simple queries. Finally, for testing basic hardware functionality a simple database and web server is developed to store and view the alerts generated by the NPS. A. Memory and Performance The Block RAM usage of each engine for Snort 2.4 signatures is shown in Table I 4. Each row corresponds to one of the detectors in Figure 6. The second column shows the number of trie levels allocated for each detector. The third column shows the memory requirements of these tries in terms of Block RAMs (BRs) occupied. The last column shows the BR requirement for the memory where the actual signatures and states are stored. For 2- and 3-byte detectors, the number of fixed-size signatures to store is very low. A simple hash-table having two items per bin using one and two BRs, respectively is enough. Reading two items in parallel from these hash tables guarantees the worst case for these small sets, making it unnecessary to further optimize. So, we did not attempt to use the data structure for these small sets. For -byte detector, since there can be up to 256 -byte entries and they can be stored in a small bitmap, no BR is used for this set either [5]. From the table, each engine requires 43 BRs in total. Note that out of these 43 total BRs used, the 22 BRs in the last column of Table I are used to store the actual signatures and states for the stateful detectors. Since the FPGA used has 36 BRs in total, three such engines can fit into a single FPGA. To accommodate packet queues, other buffers necessary for Ethernet and alert generator, and for future expansion, we left one of these engines out and designed our system with two engines. Each engine can reach up to 300 MHz speed and can process 8 bits of input for each clock cycle, resulting in 2.4-Gbps throughput. Note that since the FPGA used for the design (as well as most of the modern FPGAs) has dual-port BRs, this single engine can process two 8 bit inputs at the same time, doubling the throughput for the same amount of memory, giving a total throughput of 9.6 Gbps. As a result, this design achieves the same throughput using 28% less memory compared to the basic TriBiCa design []. B. Testing the NPS To test the proposed system, a two-engine reduced-speed system operating at Gbps was designed. The design is implemented on a Xilinx Virtex 2 Pro FPGA. The test setup is shown in Figure 8. A Spirent - AX4000, -Gbps Ethernet Traffic Generator is used as the packet generator, which is used to apply a mix of clean and malicious traffic at full line speed. The alerts generated by the NPS are sent to a database 4 Note that the trie is sized to accommodate more signatures compared to the actual Snort signature set to allow further updates. 347

6 server, where these alerts are stored. A web interface allows users to query this database. In this setup, NPS can support full line rate and the main bottleneck for the whole system is the database server running on a general purpose CPU. Fig. 8. Test setup VIII. CONCLUSION In this paper, we presented the implementation of a 0- Gbps Network Intrusion Detection and Prevention System. The system does not use any external memory and is completely contained within a single commodity FPGA. We also implemented and tested a proof-of-concept system with - Gbps traffic. A software tool to map intrusion signatures to the proposed data structure as well as a database to store, and a web server to display the intrusion alerts from the NPS, were also developed for this system. This work focuses on detection of exact signatures contained in a single packet. We previously proposed a method to detect signatures spanning multiple packets [5]. As future work, we d like extend the approach in this paper to detect signatures over multiple packets and support more complex signature types such as signatures with wildcards. REFERENCES [] N. S. Artan and H. J. Chao, TriBiCa: Trie bitmap content analyzer for high-speed network intrusion detection. in 26th Annual IEEE Conference on Computer Communications (INFOCOM), 2007, pp [2] F. Yu, T. Lakshman, and R. Katz, Gigabit rate pattern-matching using TCAM, in Int. Conf. on Network Protocols (ICNP), Berlin, Germany, Oct [3] H. Song and J. Lockwood, Multi-pattern signature matching for hardware network intrusion detection systems, in IEEE Globecom 2005, Nov-Dec [4] C. Clark and D. Schimmel, Scalable pattern matching for highspeed networks, in IEEE Symposium on Field-Programmable Custom Computing Machines (FCCM), Napa, California, 2004, pp [5] Y. H. Cho and W. H. Mangione-Smith, Fast reconfiguring deep packet filter for + gigabit network. in FCCM, 2005, pp [6] Z. K. Baker and V. K. Prasanna, High-throughput linked-pattern matching for intrusion detection systems, in Proceedings of the First Annual ACM Symposium on Architectures for Networking and Communications Systems, [7] J. Moscola, J. Lockwood, R. P. Loui, and M. Pachos, Implementation of a content-scanning module for an Internet firewall. in FCCM, 2003, pp [8] I. Sourdis, D. Pnevmatikatos, S. Wong, and S. Vassiliadis, A reconfigurable perfect-hashing scheme for packet inspection, in Proc. 5th International Conference on Field Programmable Logic and Applications (FPL 2005), Aug. 2005, pp [9] L. Tan and T. Sherwood, Architectures for bit-split string scanning in intrusion detection, IEEE Micro, Jan-Feb [0] G. Papadopoulos and D. N. Pnevmatikatos, Hashing + memory = low cost, exact pattern matching. in Proc.5th International Conference on Field Programmable Logic and Applications (FPL), Aug. 2005, pp [] Y. Lu, B. Prabhakar, and F. Bonomi, Perfect hashing for network applications, in IEEE Symposium on Information Theory), Seattle, WA, 2006, pp [2] T. Cormen, C. Leiserson, and R. Rivest, Introduction to Algorithms. The MIT Press, 200. [3] S. Crosby and D. Wallach, Denial of service via algorithmic complexity attacks, in Proceedings of the 2th USENIX Security Symposium, Aug [4] [Online]. Available: [5] N. S. Artan and H. J. Chao, Design and analysis of a multi-packet signature detection system, Int. J. Security and Networks, vol. 2, no. /2,