Security Gateway System Team

Transcription

1 Security Gateway System Team Design and Implementation of Security Gateway System for Intrusion Detection on High-speed Links Byoung-Koo Kim, Ik-Kyun Kim, Jong-kook Lee, Ki-Young Kim and Jong-Soo Jang Security Gateway System Team Electronics and Telecommunications Research Institute 161 Gajeong-Dong, Yuseong-Gu, Daejeon, , KOREA Tel: , Fax: {kbg63228, ikkim21, ljk63466, kykim, Abstract The fast extension of inexpensive computer networks has increased the problem of unauthorized access and tampering with data. As a response to increased threats, many network-based intrusion detection systems(nidss) have been developed, but current NIDSs are barely capable of real-time traffic analysis on Fast Ethernet links[1]. As network technology presses forward, Gigabit Ethernet has become the actual standard for large network installations. Therefore, there is an emerging need for security analysis techniques that can keep up with the increased network throughput[2]. We have made effort to design and implement IDS that is run as a lower branch of our system named Network Security Control System. Our IDS named Security Gateway System has a pattern matching approach through the FPGA(Field Programmable Gate Array) logic and kernel logic as detection mechanism that can be applied to Gigabit-Ethernet links. However, the realtime traffic analysis and high-speed intrusion detection is not an easy task. In this paper, we briefly introduce the whole architecture of our system designed to perform intrusion detection on high-speed links. And then, we present the efficient detection mechanism that is run by cooperation of FPGA logic and kernel logic. In other words, we focus on the network intrusion detection mechanism applied in a lower branch of our system. Keywords: IDS, high-speed intrusion detection,, pattern matching. Contact Person: Byoung-Koo Kim(kbg63228@etri.re.kr) 1

2 Introduction Overview of NSCS Environment CPCS CPCS CPCS - CPCS : Cyber Patrol Control System - : Security Gateway System Introduction In the last decade, networks have grown in both size and importance. In particular, TCP/IP networks have become the main means to exchange data and carry out transactions. But, the fast extension of inexpensive computer networks also has increased the problem of unauthorized access and tampering with data[1]. As a response to increased threats, many network-based intrusion detection systems(nidss) have been developed to serve as a last line of defense in the overall protection scheme of a computer system. These NIDSs have two major approaches; misuse intrusion detection and anomaly intrusion detection[9][10], but most of existing NIDSs, such as Snort[6], NFR[7], and NetSTAT[8], only employs the misuse detection approach for reducing a lowering of performance to the minimum. Also, most of NIDSs based on misuse detection approach has concentrated on catching and analyzing only the audit source collected on Fast Ethernet links. However, with the advancement of network technology, Gigabit Ethernet has become the actual standard for large network installations. Therefore, there is an emerging need for security analysis techniques that can keep up with the increased network throughput[2]. Existing NIDSs have problems of a lowering of performance as ever, such as bottleneck, overhead in collecting and analyzing data in a specific component. Therefore, the effort of performing NIDS on high-speed links has been the focus of much debate in the intrusion detection community, and several NIDSs, such as RealSecure[3], ManHunt[4], and CISCO IDS[5], that is run on high-speed links actually has been developed. But, these NIDSs is still not practical because of technical difficulties in keeping pace with the increasing network speed, and realworld performance also will likely be less. In this paper, we briefly introduce the architecture of our system, named Network Security Control System (shortly NSCS) designed to detect intrusions on high-speed links. Also, we present the detailed architecture of Security Gateway System() that is a lower branch of NSCS. And then, we present the efficient detection mechanism that is run by cooperation of FPGA logic and kernel logic. Although the interoperability of overall system is an important and interesting issue, it will not be discussed in detail in this paper. In other words, we focus on the detection mechanism applied in a lower branch of our system. 2

3 Architecture of NSCS HAB(High-Analyzer Block) SMB(System Management Block) AMB(Alert Management Block) Viewer PMB(Policy Management Block) COPS/IAP Server(Interface Block) CPCS COPS/IAP Client(Interface Block) Inline Mode Operation CPAB(Cyber Patrol Agent Block) IDAB(Intrusion Detection and Analyzing Block) PSAB(Packet Sensing and Analyzing Block) Architecture of NSCS In this slide, we introduce the architecture of our system, named NSCS and components of the architecture. The architecture consists of two main components; Security Gateway System() and Cyber Patrol Control System(CPCS). First, performs the real-time traffic analysis and high-speed intrusion detection on two Gigabit Ethernet links that is run as inline-mode. We can divide this into several sub-modules; Interface Block(COPS/IAP Client), Cyber Patrol Agent Block(CPAB), Intrusion Detection and Analyzing Block(IDAB), Packet Sensing and Analyzing Block(PSAB). The summary of the internal blocks is following; COPS/IAP Client : COPS/IAP Client block has two communication channels with CPCS. One is COPS protocol channel for policy transmission, and the other is IAP protocol channel for alert message transmission. CPAB : CPAB block has many functions that have relevance to system management, such as SNMP agent function, policy management function and alert management function. Also, it decides and performs intrusion response according to the policy from CPCS. IDAB : IDAB block is run as kernel module for improvement in performance, and finally decides whether packet served from PSAB block is intrusion or not by performing the pattern matching function connected with packet payload. PSAB : PSAB block is run by FPGA logic for high-speed traffic analysis, and performs the pattern matching function connected with packet header. Since it sends only matching packets to IDAB block, matching operation of IDAB block reduces to the minimum. Also, it employs inline mode capable of effective response by using two Gigabit Ethernet links. Second, CPCS manages each s and has a Policy Decision Point(PDP) functionality to each s. Besides, CPCS has many functions for the whole system management. But, although the interoperability of overall system is an important and interesting issue, it will not be discussed in detail in this paper. As shown in the figure, this is overall architecture of our system. 3

4 Detailed Architecture Local GUI SNMP Agent Response Manager Database Manager System Manager Local Policy Manager Local Alert Manager COPS / IAP Client Filesystem /Database IOCTL I/F Socket I/F Application Task Rule Manager Payload Pattern Matching IP defragmentation TCP reassembly Application decode Portscan detection Data Structure for Rule Preprocessor PCI Bus IDAB : Kernel Module Preprocessor Filter Fixed Field Pattern Matching Flow Statistics Blocking Sensing Forwarding Rule Mirror Table PSAB : FPGA Logic Detailed Architecture is a substructure of CPCS aimed at real-time network-based intrusion detection based on misuse detection approach. As shown in the above figure, consists of three parts; Application Task for communication channel with CPCS and CPAB functions, IDAB block for packet preprocessing and payload pattern matching, PSAB block for packet sensing, preprocessor filtering, fixed field pattern matching and so forth. Again, we can divide IDAB block and PSAB block into several sub-modules. Most of all, the summary of the internal modules for detection operation is following; Preprocessor Filter : this module checks out the incoming packet according to filtering rule, and decides which actual preprocessing function is necessary to be performed or not. Fixed Field Pattern Matching : this module matches the incoming packet with fixed field patterns based on packet header information that is easily examined by fixed size and fixed offset. Briefly, it performs the first pattern matching for detecting intrusions. Preprocessor : this module performs the preprocessing function, such as protocol normalization, ip defragmentation, tcp reassembly and packet payload decoding, before step for pattern matching is run. Payload Pattern Matching : this module matches the first matching packet with payload patterns based on packet payload information that is not easily examined by variable size and variable offset. Briefly, it performs the final pattern matching for detecting intrusions. Rule Manager : this module manages the ruleset that is required for intrusion detection. Through the interoperability of these components, analyzes data packets as they travel across the network for signs of external or internal attack. Namely, the major functionality of is to perform the real-time traffic analysis and intrusion detection on high-speed links. Therefore, we focus on effective detection strategies applied FPGA logic and kernel logic. The next slide presents the effective rule management and intrusion detection mechanism for it. 4

5 Detection Rule Configuration TCP Group UDP Group ICMP Group IP Group Fixed Field Pattern Fixed Field Pattern Fixed Source Field Pattern Fixed IP Field Address Pattern Destination Source IP IP Address Destination Source Source IP Source IP Port IP Address Destination Destination IP Address Destination Source Port Port IP Destination Address Source TTL Port Source Port Destination Port IP Port Destination TTL ID TTL Port Fragbits IP ID IP TTL TCP ID Fragbits Flags TCP Fragbits IP ID SeqFlags TCP Fragbits Ack Seq Flags TCP Ack Seq Flags Ack Seq Ack 1:N matching Payload Pattern Payload Pattern Payload Data Pattern Payload size Pattern Content Data size Offset Data size Content Data size Depth Content Offset Content Uricontent Offset Depth Uricontent Offset Depth Uricontent Depth Uricontent Attack name Signature Alert Message ID Signature Alert Message ID Signature Alert Message ID Signature ID Detection related Fields Alert related Fields H/W Logic Rule Mirror Table Kernel Logic Rule Table Detection Rule Configuration For detecting network intrusions more efficiently on high-speed links, our system divides its ruleset into two tables. As shown in the figure, one is rule mirror table for FPGA logic, and the other is rule table for kernel logic. First, rule mirror table is configured to fixed field patterns based on packet header information that is easily examined by fixed size and fixed offset. Therefore, it holds many common properties that must be included in each patterns, such as the source and destination address, source and destination ports, TCP flags, ICMP codes and types, and ip identification. Second, rule table is configured to payload patterns based on packet payload information that is not easily examined by variable size and variable offset. Therefore, it holds several properties that must be required for performing the payload pattern matching, such as packet payload size, packet content, and packet payload offset. Besides, rule table of kernel logic holds several properties that must be included in generating alert message, such as attack name, and signature identification. Detection rules of our system is configured to association of the above two rule tables, and their relationship is as following. First, the detection rules that applied to our system is divided into four groups according to a protocol value[11]; TCP group, UDP group, ICMP group, IP group. In other words, each group has an association of rule mirror table and rule table that is configured to property values of the same protocol patterns. Therefore, each group has detection rules that is divided into fixed field patterns and payload patterns by rule mirror table and rule table. Basically, one fixed field pattern can have many payload patterns that is derived from its own. When incoming packets are being examined against a given detection rules, the packet is first compared along fixed field patterns in the rule mirror table until the packet matches a particular fixed field pattern. Only if such a match occurs is the packet then compared along the payload patterns derived from the matching fixed field pattern. That is, detection rules of our system is managed and configured in the direction for reducing a lowering of performance by the packet processing in kernel logic to the minimum. 5

6 H/W Rule Table Protocol TCP UDP ICMP IP SRC IP DST IP TTL IP ID Fragbits TCP Flags SRC Port DST Port Seq Ack ICMP type ICMP code ICMP ID ICMP Seq Matching ID H/W Rule Table For performing the fixed field pattern matching in FPGA logic, our system has four H/W(hardware) rule tables, named rule mirror table. As shown in the figure, Each rule table is configured to only properties dependent on protocol, such as TCP, UDP, ICMP, and IP. This rule tables includes fixed field patterns that must be checked according to characteristics of various network packets, and has fifteen properties available as following; SRC/DST IP : Test the source/destination address for specified IP address and netmask. SRC/DST Port : Test the source/destination port for specified port value or port range. TTL : Check the time-to-live(ttl) field of the IP header for specified settings. IP ID : Test the IP identification field of the IP header for specified value. Fragbits : Test the fragmentation bits of the IP header for specified settings. TCP flags : Test the TCP flags for specified settings. Seq : Test the TCP sequence number for specified value. Ack : Test the TCP acknowledgement number for specified value. ICMP type : Match on the ICMP type field. ICMP code : Match on the ICMP code field. ICMP ID : Test the ICMP Echo identification field for specified value. ICMP Seq : Test the ICMP Echo sequence number field for specified value. Matching ID : Sets the matching identification to be sent when a incoming packet is matched with the fixed field pattern consisting of the above properties. These properties may be combined in any manner to detect and classify packet of interest, and all of the testing properties in a rule must be true in order for the rule to generate a matching packet. Most of all, our system supports intrusion detection on high-speed links as performing the matching operation about the above properties through FPGA logic. 6

7 Detection Algorithm H/W PP Filter Check Kernel Preprocessing necessary? PP Flag=1 PP Flag=0 PCI Bus KERNEL LOGIC Packet Monitor PP Flag= 1 Or FF Flag= 1 Packet Send FF Pattern Search FF Flag=0 FF Pattern Matching? FF Flag=1 - PP : Preprocessor - FF : Fixed Field Detection Algorithm in FPGA Logic In design of our system, the major functionality of FPGA logic is to perform the fixed field pattern matching and preprocessor filtering about incoming packets. And, It mainly is performed by PSAB block in components of. Therefore, detection algorithm of PSAB block is very important as first step for intrusion detection. First, function for fixed field pattern matching is based on direct searching and matching approach about predefined fixed field patterns. In other words, it seeks to discover matching packets by testing properties in each patterns. Basically, if the incoming packet is matched with existing patterns, then it is sent to kernel logic. Otherwise, it is settled according to result of preprocessor filtering. Second, function for preprocessor filtering checks out the incoming packet according to predefined filtering rule, and decides which actual preprocessing function is necessary to be performed or not. If the incoming packet is decided to a target of preprocessing, then it is sent to kernel logic. Otherwise, it is settled according to result of fixed field pattern matching. Through the packet processing as this, PSAB block reduces a volume of packets handled by IDAB block to the minimum. As shown in the figure, FPGA logic has two packet processing flow performed concurrently. One is the flow for fixed field pattern matching, and the other is the flow for preprocessor filtering. First, the flow for fixed field pattern matching is as following. As the first step, PSAB block receives an incoming packet data from network interface(gigabit Ethernet links). And then the incoming packet is delivered to logic for searching the predefined patterns. If it is involved in pattern of specific rule table, then FF(Fixed Field) flag for interfacing with matching function of kernel logic is set to 1. Otherwise, FF flag is set to 0. The flow for preprocessor filtering also begins at the same starting point, and delivers an incoming packet data to logic for checking out the preprocessor filtering rules. If actual preprocessing about an incoming packet data is necessary to be performed, then PP(Preprocessor) flag for interfacing with preprocessing function of kernel logic is set to 1. Otherwise, PP flag is set to 0. As a result of these packet processing, if ether PP flag or FF flag is 1, then PSAB block sends the matching packet data to kernel logic. Otherwise, PSAB block receives new incoming packet from network interface, and performs packet processing repeatedly as above. 7

8 Detection Algorithm Kernel PCI Bus Packet Decode PP Flag = 1 Pre process FPGA LOGIC FF Flag = 1 / Preprocessor Detection? Socket Interface Alert Send Payload Pattern Search CPAB Payload Pattern Matching? Detection Algorithm in Kernel Logic In design of our system, the major functionality of kernel logic is to perform the payload pattern matching and preprocessing about matching packets from PSAB block. And, It mainly is performed by IDAB block in components of. Therefore, detection algorithm of IDAB block is very important as final step for intrusion detection. Most of all, IDAB block finally determines whether received packet is intrusion or not, and sends alert message to CPAB block as a result of analysis. First, function for payload pattern matching is based on direct searching and matching approach about predefined payload patterns. In other words, it seeks to discover network intrusions by testing properties in payload patterns that have identification coincided with matching identification of each fixed field pattern. Second, function for preprocessing decodes the packet payload according to a kind of application services, such as HTTP, Telnet, FTP, and RPC. Besides, it detects the protocol anomaly by performs function, such as ip de-fragmentation, tcp reassembly, and protocol normalization. These functions for preprocessing is run before the payload pattern matching is performed, but it is only performed as occasion demands. As shown in the figure, kernel logic has the serial packet processing flow for preprocessing and payload pattern matching. First, IDAB block receives an matching packet data inspected by PSAB block as the first step for performing its own logic. And then, the matching packet data is decoded to the information required for performing the detection flow of kernel logic. As result of packet decoding, if PP flag is set to 1, then function for preprocessing is run. Otherwise, next step is going on. If result of preprocessing is detected a suspicious packet as the protocol anomaly, then alert message is sent to CPAB block. Otherwise, next step is going on. As the next step, if FF flag is set to 1, then the matching packet data is delivered to logic for searching the payload patterns that have the same matching identification. If it is matched with existing payload patterns, then alert message generated from matching pattern is sent to CPAB block. Otherwise, IDAB block receives new matching packet from PSAB block, and performs packet processing repeatedly as above. 8

9 Prototype for NSCS FPGA Logic(H/W) Functions Wire-Speed Forwarding 5-Tuple based Flow Classification Statistics/Blocking/Sensing/Fixed Field Pattern Matching Kernel Logic Functions Linux kernel based Kernel Module Programming Payload Pattern Matching/Alert Generation The Implementation of prototype for NSCS We have developed our prototype based on the NSCS architecture. The prototype we have developed is programmed in a combination of Java and C, verilog programming language. Most of all, is implemented in programming languages that is best suited for the task it has to perform. Basically, application tasks of are implemented in C programming language, but IDAB block of is implemented as the kernel module programming that is best suited for high-speed pattern matching operation. PSAB module of is implemented in verilog HDL(Hardware Description Language) that is best suited for high-speed packet processing in H/W. Most of all, the prototype we have developed focus on kernel logic and FPGA logic for real-time traffic analysis and intrusion detection on high-speed links. Also, we employed inline mode capable of effective response by using two Gigabit Ethernet links as shown in the figure. That is, our prototype has developed in the side of improvement in performance for packet processing. In our prototype, FPGA logic performs many functionalities, such as wire-speed forwarding, 5- tuple(protocol, source/destination address, source/destination port) based flow classification, packet sensing, and fixed field pattern matching. Kernel logic also performs many functionalities, such as preprocessing, payload pattern matching, alert generation, and detection rule management. Besides, mysql database server is employed by as database server for managing securityrelevant information and policy information. On the other hand, CPCS manages to its own information by using oracle database server. Some functionalities such as reporting and communication are common to all and CPCS, and can be provided through shared libraries or similar mechanisms. Finally, for testing of our prototype, CPCS console has implemented in Java2 and HTML for security manager to support comfortable management in Web. Currently, we are in the process of improving the implementation as well as developing new ones. That is, our prototype leaves much to be desired. Furthermore, we analyzed the functions of various intrusion detection systems in our testbed network. And now, we are defining more effective analysis functionality in order to improve the performance of detection mechanism on high-speed links. 9

10 Conclusion & Future Work Present the architecture of NSCS Design the of NSCS Design the architecture of Design the ruleset configuration of Design the FPGA logic and kernel logic of Develop the prototype of Future Work Improve the detection mechanism on high-speed links Guarantee the secure transmission of messages among the prototype systems Resolve the problem derived from the verification of implemented system Conclusion and Future Work In this paper, we designed the architecture of our system, named NSCS that performs the realtime traffic analysis and intrusion detection on high-speed links, and proposed the detection mechanism and rule distribution technique that supports more efficient intrusion detection. Also, we have developed the prototype of our system for the analysis of the traffic carried by a Gigabit link. Most of all, the prototype of focuses on reducing a lowing of performance caused by high-speed traffic analysis to the minimum. Therefore, it is run by the FPGA logic and kernel logic proposed for improvement in performance. Also, it has the advantage that is capable of supporting the effective response by using inline mode monitoring technique on two Gigabit links. However, the current prototype is very preliminary and a thorough evaluation will require experimentation in a real-world environment. Furthermore, we will guarantee the secure transmission of messages among the prototype systems we have developed. In future, for resolving the problem derived from the verification of implemented system, we will go and consider on system performance, availability, fault tolerance test with prototype. Also, we will keep up our efforts for improvement in performance of detection mechanism on highspeed links. Finally, we will implement and expand our designed system and give more effort to demonstrate effectiveness of our system. 10

11 References [1] Byoung-Koo Kim, Jong-Su Jang, Sung-Won Sohn and Tai M. Chung, Design and Implementation of Intrusion Detection System base on Object-Oriented Modeling", In Proceedings of the International Conference on Security and Management, pp , June, [2] Kruegel, C., Valeur, F., Vigna, G. and Kemmerer, R. "Stateful intrusion detection for highspeed networks", In Proceedings of the IEEE Symposium on Security and Privacy, pp , [3] ISS. RealSecure Gigabit Network Sensor. /enterprise_protection/rsnetwork/gigabitsensor.php, September, [4] Symantec. ManHunt. ProductID=156, [5] CISCO. CISCO Intrusion Detection System. Technical Information, November, [6] M. Roesch. "Snort-Lightweight Intrusion Detection for Networks". In Proceedings of the USENIX LISA 99 Conference, November, [7] Marcus Ranum, "Burglar Alarms for Detecting Intrusions", NFR Inc., [8] Thomas Ptacek and Timothy Newsham, "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection", Secure Networks Inc., [9] H. Debar, M. Dacier and A. Wespi, "Research Report Towards a Taxonomy of Intrusion Detection Systems", Technical Report RZ 3030, IBM Research Division, Zurich Research Laboratory, Jun., [10] S. Kumar and E. Spafford, "A pattern matching model for misuse intrusion detection", In Proceedings of the 17th National Computer Security Conference, pp , Oct., [11] W. Richard Stevens, TCP/IP Illustrated Volume I: The Protocols, Addison Wesley,