Packet Information Collection and Transformation for Network Intrusion Detection and Prevention Mohsen Beheshti, Jianchao Han, Kazimierz Kowalski Joel Ortiz, Johnly Tomelden, Damian Alvillar Computer Science Department, California State University Dominguez Hills 1000 E. Victoria Street, Carson, California, USA 90747 Emails:
[email protected],
[email protected], kkowalski}@csudh.edu
Abstract Data mining and machine learning technology has been extensively applied in network intrusion detection and prevention systems by discovering user behavior patterns from the network traffic data. Some commercial tools for collecting network traffic data exist, such as SNORT. The traffic data collected from the network using these tools, however, usually doesn’t fit the format requirement of the input data for data mining systems. Thus transforming the network traffic data into the required format is mandate for a data mining system to induce network intrusion detection rules. In this paper, collecting the network packet information using SNORT is introduced, storing the collected data into the MySql database is presented, and selecting the significant data in the database and transforming them to the format of input data for a data mining system See5 is discussed. The data collection, selection, and transformation approaches illustrated in this paper have been used in the Information Fusion in Sensor Based Intrusion Detection System that is being under development in our Computer Security Research Laboratory. The system framework is briefly introduced and the preliminary results for data collection from multiple resources are illustrated.
Keywords: Data collection and pre-processing, data mining and machine learning, data transformation, information fusion, network intrusion detection and prevention.
I. Introduction Various network intrusion detection and prevention systems have been used to monitor computer systems for signs of security violations [1]-[7]. Basically, an intrusion detection system collects information gathered from the network, host, or file systems and analyzes the information to find suspicious activities. The increased connectivity between computer systems has opened up many possibilities of attacks, such as attempted break-in, tempered executables, denial of service, leakage, masquerade attack, malicious use,
etc. Suspicious network activities are usually divided into two main categories [1] [6]: misuse and anomaly. Detecting misuses is to analyze the network traffic information and compare to large databases of attack signatures to find patterns signaling well known attacks that have already been documented. The obvious disadvantage of the misuse detection is that it is not capable of detecting new attacks. On the other hand, detecting anomalies is to compare the actual network traffic data to a profile of all allowed normal user behavior. Any deviation from the profile is considered to be a suspicious action. Anomaly detection seems to be able to detect all kind of attacks, including “novel” or “unknown” attacks. However, it can only signal that some event is unusual, but not necessarily hostile, thus generating false alarms [1]. This is why anomaly detection usually leads to a high rate of false positives. Intrusion detection systems must be capable of distinguishing between normal (not security-critical) and abnormal user activities, to discover malicious attempts in time. However translating user behaviors (or a complete user-system session) in a consistent security-related decision is often not that simple, because many behavior patterns are unpredictable and unclear. The processes in a typical intrusion detection system include data collection, data pre-processing, pattern detection, and response [6]. There many commercial tools exist to collect data from the network traffic, such as SNORT [8], Tcpdump, Dsniff [9], etc. [10]. The audit data collected this way may not be understandable to other components of the detection system, and thus needs pre-processed. Data preprocessing includes transforming data to understandable format, handling noisy data and/or missing data, mapping data type, and selecting significant data portion. Pattern detection is to find rules to recognize normal and abnormal activities. Currently, data mining and machine learning techniques have been extensively used to perform this task [11]-[13], such as inducing classification rules to recognize anomalies, discovering temporal association rules to detect time-related correlations, finding short sequences of system calls to
discriminate between normal and abnormal operating characteristics. We are developing an information fusion in sensor based intrusion detection system in our CSRL lab. The primary design of this network intrusion detection system is based on a machine learning system See5/C5.0 [14] which is the commercial version of C4.5 for decision tree and rule induction [15]. See5 runs on a windows platform while C5.0 is designed to run on Linux. The components of this system are described as follows: 1.
Capture packet data in network traffic by using the tool SNORT; The SNORT system collects packet information and stores in the audit logs;
2.
Preprocess and transform the data into the suitable input format that are required by See5;
3.
Apply See5 to induce intrusion detection rules, a set of alert rules for recognizing malicious activities;
4.
Integrate the detection rules into a firewall to prevent potential attacks.
In this paper, we present our implementation for the first two components of the information fusion and intrusion detection system. Section 2 introduces the SNORT system and the setup of SNORE for use in our system is described in Section 3. The See5 system is presented in Section 4, including its input format requirement. Section 5 illustrates the data transformation from the SNORT logs to the See5 inputs. Section 6 briefly introduces the information fusion and honeypots approach that we proposed to combine information from multiple sources to make a more informed decision, and shows our preliminary findings. Finally, Section 7 is concluding remarks and our future work.
II. The SNORT System SNORT is a network sniffer developed by Martin Roesch in 1998 as a solution to a cross platform sniffer problem [8]. The SNORT application is a combination of a network sniffer and a log that logs packets per a rule system that works on the sniffer. The SNORT can be applied to analyze current traffic and rule systems that capture the packet. A network sniffer (or Packet Capture utility [16]) is an application to collect the network traffic that is announced normally to a network segment that the computer is on. This technology works on the security vulnerability of trust. The early networks trusted all nodes on the network segment to only take the massage that is meant for them, but modern networks use encryption to hide the content between the sender and the receiver. The use of such devices is as of a network monitoring service. The sniffer technology can also be used to gain privileged information from
individuals on that network segment of the LAN that the network sniffing device is located on by switching the nic on that machine to promiscuous mode. The segment of the LAN can be controlled by network tools or hardware, from a bridge to a router these devices will segment a network into smaller LAN's so that a compromised computer can be isolated from the other transmitting systems and network segments. To make the SNORT system operate, one need to understand the components of it as well as relationships among components [17]. The first component is the SNORT database, which is particularly important for our intrusion detection system, because it contains the traffic data for the See5 system to work on. The SNORT database created by the SNORT installation includes many tables. There are four tables to record information of network packets using the following protocols, icp, udp, icmp, and ip. Also two other important tables are acid_event and opt. These tables that will be used in our data transformation are briefly described as below: acid_event consolidates all the logs of alerts that SNORT captures and orders them by the cid field. iphdr is the IP header table and used to log all network streams that have TCP/IP protocol. This table stores the IP header information of packets. tcphdr is the TCP header table and collects the TCP portion of the TCP/IP protocol that is not captured by the iphdr table. The opt table holds the optional data that can be part of the TCP/IP protocol. udphdr is the UDP header table and contains the header information for the UDP protocol. This protocol has fewer details than the TCP/IP protocol and is used for faster communication but less reliability. Icmphdr is the ICMP header and used to log information about the network traffic between network hardware. These tables store all the information collected from the network communication, including flags, off sets, and payload, while there are other tables that hold information from the rules that will be tripped or evoked to create the log from the SNORT community rules sid (signature id – the rule number from the rule set). The database for SNORT has some elements from the BASE system [18] that take information from the SNORT database and adds one primary table called acid_event. The acid_event takes several of the columns from other tables. The acid_event table cumulates most of the information that can be used to build target attributes
using the sig_class_id. If we need to investigate further any particular rule from the SNORT community, we can look at the cid from the acid_event.sig_class_id => sig_sid, with the sig_sid value we can then look for the SNORT rule in the sigmsg.map in the /etc/SNORT/rules/ directory. In order to look at the actual rule we need to match the first part of the massage to the actual rules in that directory as the files split the rules into there attack fingerprint. This table also serves for now as a way to connect the other tables with the cid (event id) common to the tables that we will be looking at. The most commonly used protocol in the data set is TCP/IP and UDP but with SNORT. These protocols are broken down to five tables, four header tables iphdr, tcphdr, udphdr, opt, and a data table. The header information (tcp/ip/udp-hdr) resides in their own tables, while the IP/TCP option field is put in the opt table, and their data or the actual datagram resides in the data table with opt and data tables having a text field. While analyzing the datagram is one thing that can be done, it is not the part we are looking at as it is the header information by passing it through a data mining application that can then give us some information on what kind of rules we need to implement in order to stop attacks The inclusion of the icmphdr table is used as a form of back ground noise or a way to find a possible false positive result. This field also has a potential of catching intruders that are looking to take over the routers to create a false router table reference from an HTTP command. The ICMP packet has router information for next hop dead connections and other connection specific information and is often over looked as a source for security attacks. The tables in the SNORT database share a primary key cid (Alert id) that can be used to gather the related information from the different tables to get a clear picture of what was logged in the database. There are two main sections of the database. The first one stores all the information collected from the packet, while the second one holds information from the different SNORT rules. The main relationship between the two sections is its signature.sig_id and event.signature that are created by the SNORT system. Another relationship between these two sections is that the SNORT rules that are stored in the files in the SNORT directory /rules/ correlate their sid numbers to the sig_sid numbers in the sid and msg sections of the actual rules.
III.The SNORT Setup The setup of the SNORT system is important in order to collect packets or test new SNORT rules as the SNORT program can be used for either [17]. A tap is set up to have the network traffic be repeated to the
station with the SNORT system set in promiscuous mode in order to excerpt network traffic. When the SNORT system is setup during installation, the MySql database management system [19] is used as the SNORT database. The first system is to gather information from the wide area network. The main point on this one is to get normal traffic and suspected intrusion traffic recorded on to the network sniffer. We use two servers running a Linux server and a Windows server respectively in order to keep the gathering of information more cross platform. The second system is the testing system that is used to test the SNORT rules and to transfer databases in order to verify or investigate some of the performance of SNORT and its different components. This is conducted in a closed network or LAN. To check if the SNORT rule added works, we have to use the signature table looking at the sig_sid column. The SNORT community has chosen to allocate sig_sid in one millions local rules that will be used. The way that SNORT holds the IP addresses in the database is using the aton form to make the IP address an integer to hold and compare. Once that is complete we can then move on to the transfer of the database for use by other applications such as JACED_IPTables.php [20] and see5 [14]. We set up the network with taps to gather the information then set the SNORT system up to collect the information that can be used. The SNORT system uses a rule set to set an action based on rules as to whether to capture a network packet or release it. The SNORT community keeps a directory full of files that put over 2k rules for specific network intrusions. The full documentation of the snort rules can be found in [17]. An example for us to look and dissect is: alert tcp any any 192.168.1.0/24 111 (content:”|00 01 86 a5|”; msg:”mountd access”;) The first part of the rule is the login method there is alert, log, pass, activate, dynamic, drop, reject, and sdrop. The second part of this example is the protocol type that it detects TCP, UDP, ICMP, and IP are the current protocols snort is able to detect. The next part is for the IP address and port information witch can be given a key word any for any IP or any port. The directional can be also to specify any direction. The rule can treat incoming or outgoing network packet information with the directional switch (, , ). Using above packet protocol pattern, we can start looking at the specifics enclosed in the parentheses.
This field has many options, e.g. sid to identify each rule, the msg option to add a comment to the database. Above login method can be changed. For this purpose, we created a new type of method using the following lines in the snort.config file: ruletype nonalert { type alert output database: log, mysql, user=snort password=password dbname=snortTest host=localhost } This rule type creates an alert called nonalert to capture incoming traffic into a database called snorttest. The following are the rules that are added to the database using above rule type nonalert to log normal traffic pass tcp 0.0.0.0 any $HOME_NET any pass udp 0.0.0.0 any $HOME_NET any pass icmp 0.0.0.0 any $HOME_NET any pass ip 0.0.0.0 any $HOME_NET any nonalert tcp $EXTERNAL_NET any $HOME_NET any (msg:"Traffic CSRL 1.0 tcp"; classtype:not-suspicious; sid: 1000001;) nonalert udp $EXTERNAL_NET any $HOME_NET any (msg:"Traffic CSRL 1.0 udp"; classtype:not-suspicious; sid: 1000002;) nonalert icmp $EXTERNAL_NET any $HOME_NET any (msg:"Traffic CSRL 1.0 icmp"; classtype:not-suspicious; sid: 1000003;) nonalert ip $EXTERNAL_NET any $HOME_NET any (msg:"Traffic CSRL 1.0 ip"; classtype:not-suspicious; sid: 1000004;) We add a rule in the file of local. Rules to the community downloaded rules and check the SNORT database in order to confirm implementation of the new rule. To get a view of the database stored in our system under MySql, we use the describe command on all tables. Then later when the system is populated with logs, the select query finds what is in the tables. The .config and .conf files of the SNORT system are also used to find what is called and what is skipped from the file systems /etc/snort/ directory for the SNORT system [17] These rules filter out traffic from the routers and then log the incoming traffic into the nonalert database snorttest.
IV. The See5 System Data Mining is the process of analyzing large amounts of data stored in data warehouses or databases and summarizing it into useful information
– information that could be used for decision making. Classification is a common technique used in data mining and machine learning, and is the technique that we are going to employ in our research. Classification is the process of determination of a predefined class, to which an example belongs to. See5/C5.0 [14] is the commercial version of C4.5 decision tree and rule induction product by Rulequest developed by Ross Quinlan [15]. See5 is the software that runs on a windows platform while C5.0 is designed to run on Linux. In the intrusion detection system that we are developing, See5 for Window XP is applied. Using classification techniques in conjunction with the data mining tool C5.0/See5, one can analyze the SNORT database and IP Tables to identify any anomalies in the traffic patterns, thus giving us a better understanding of how to detect and prevent security flaws in today’s networks and computer Systems. Anomalies may include multiple attacks from the same IP address, multiple occurrences of a certain type of attack, and can also detect clustered ranges of IP addresses. Classifiers outputted by See5 are generally in the form of decision trees or sets of ifthen rules, which are usually easier to understand than other formats such as neural networks. However, the database that stores the SNORT audit logs has the different format than the input of See5. Basically, the data set from which See5 induces a decision tree is a two-dimensional data table, where each row represents an object, while each column characterizes an attribute or feature of objects. The data table is described in two input files to the See5 system, the .names file and the .data file. The .names file describes the attributes and classes of the data table that the See5 is going to work on. Such a file would consist of the names of each column from a data table with a description of the type of attribute each column contains. The attribute type can be continuous, label, date, time, timestamp, ignore, and discrete N for some integer N. On the other hand, the .data file enumerates each object or case.
V. Data Transformation In order to adhere to the See5 system format of the data set, we need to convert various tables in the SNORE database. The transformation can be done by either using a software program such as ODBC and JDBC or writing a transformation program such as a PHP script. The latter is chosen in the implementation of our system since the SNORE system is setup with MySQL and it is to write PHP scripts to extract information from the MySQL database [21]. PHP (Personal Home Page) is a computer scripting language originally designed for producing dynamic web pages. In our implementation, we are using PHP to communicate directly with the SNORT database so
that the data in MySql can be ported into a format that See5 will understand. While the PHP script is in execution, it opens the SNORT database and stores it in a buffer for manipulation. Storing the SNORT database into a buffer is an advantage because manipulating the data in the database using PHP is faster and more efficient than manipulating the SNORT database directly from the MySQL command console. Once the SNORT database is stored in the buffer, the PHP script begins to select the data via queries from multiple tables that we think are the most important to our research. While the data is being selected, it is simultaneously being stored into a new table within the SNORT database. Once the PHP script is finished selecting and adding the related data into the new table, it is now possible to directly export the new table into a flat file with the .data extension that is needed to run See5. Basically, the transformation of data from the SNORT database to the See5 system includes converting the database schema in to a .names file and selecting data from tables to generate the .data file, both of which are required as the input See5 for its execution. The See5 system execution will output either a set of classification rules or a decision tree. The MySql commands are embedded in the PHP scripts to quickly generate the desired results. The common connection to the data tables in the SNORE database is that they all have a cid that can be used to keep Cartesian products from being created. The MySql command used is: create table s5 (select (acid_event.cid + 0) cid, sig_class_id, sig_priority,acid_event.timestamp, layer4_sport, layer4_dport, acid_event.signature, iphdr.ip_src, iphdr.ip_dst, ip_ver, ip_hlen, ip_tos, ip_len, ip_id, ip_flags, ip_off, ip_ttl, iphdr.ip_proto, ip_csum, optid, opt_proto, opt_code, opt_len, opt_data, tcp_sport, tcp_dport, tcp_seq, tcp_ack, tcp_off, tcp_res, tcp_flags, tcp_win, tcp_csum, tcp_urp, udp_sport, udp_dport, udp_len, udp_csum, icmp_type, icmp_code, icmp_csum, icmp_id, icmp_seq from acid_event left join iphdr on acid_event.cid = iphdr.cid left join tcphdr on acid_event.cid = tcphdr.cid left join udphdr on acid_event.cid = udphdr.cid left join icmphdr on acid_event.cid=icmphdr.cid left join opt on acid_event.cid = opt.cid order by timestamp); This query uses left joins in order to replicate an outer join that first makes a table and populates it with the acid_event table then it compares the cid of acid_event with the proceeding tables in each left join.
The implementation of data queries from the MySql database is implemented using PHP scripts. The following is a snippet of PHP script that is used in our implementation to define the query from the acid_event table. $eventQuery="select cid,sig_class_id, sig_priority, timestamp, layer4_sport, layer4_dport, signature from acid_event order by cid;"; $resultEvent = mysql_query($eventQuery, $conn) or die("problemi " . mysql_error()); $cidNum=mysql_num_rows($resultEvent) or die("snap"); echo $cidNum . "
"; $resultIPHDR = mysql_query("select * from iphdr order by cid;", $conn) or die("problem"); echo mysql_num_rows($resultIPHDR). "
"; $iphdrNum = 0; $iphdrMax = mysql_num_rows($resultIPHDR); During the testing of see5 with the output of the table created above, it was found that MySql will export null values to the file with the '\n' space holder. See5 did not process this and marked it as an error and stopped after many errors are encountered. To fix the problem, the following query was used to export the data table from the SNORE database into a .data file for see5: select cid, ifnull(sig_class_id,'N/A'), ifnull(sig_priority,'N/A'), ifnull(timestamp,'N/A'), ifnull(layer4_sport,'N/A'), ifnull(layer4_dport,'N/A'), ifnull(signature,'N/A'), ifnull(ip_src,'N/A'), ifnull(ip_dst,'N/A'), ifnull(ip_ver,'N/A'), ifnull(ip_hlen,'N/A'), ifnull(ip_tos,'N/A'), ifnull(ip_len,'N/A'), ifnull(ip_id, 'N/A'), ifnull(ip_flags,'N/A'), ifnull(ip_off,'N/A'), ifnull(ip_ttl,'N/A'), ifnull(ip_proto,'N/A'), ifnull(ip_csum,'N/A'), ifnull(optid,'N/A'), ifnull(opt_proto,'N/A'), ifnull(opt_code,'N/A'), ifnull(opt_len,'N/A'), ifnull(tcp_sport,'N/A'), ifnull(tcp_dport,'N/A'), ifnull(tcp_seq,'N/A'), ifnull(tcp_ack,'N/A'), ifnull(tcp_off,'N/A'), ifnull(tcp_res,'N/A'), ifnull(tcp_flags,'N/A'), ifnull(tcp_win,'N/A'), ifnull(tcp_csum,'N/A'), ifnull(tcp_urp,'N/A'), ifnull(udp_sport,'N/A'), ifnull(udp_dport,'N/A'), ifnull(udp_len,'N/A'), ifnull(udp_csum,'N/A'), ifnull(icmp_type,'N/A'), ifnull(icmp_code,'N/A'), ifnull(icmp_csum,'N/A'), ifnull(icmp_id,'N/A'), ifnull(icmp_seq,'N/A') into outfile 'see5test.data' FIELDS TERMINATED BY ',' LINES TERMINATED BY '\n' from stuff order by timestamp; This query dumps the table in to a file called see5test.data that can be taken out of the database directory by navigating to it.
By embedding these queries into our intrusion detection system to get network traffic into a database to be used for data mining this makes automation of this process can be made with an interface, in order to have the process do the data set retrieval.
VI. Information Fusion Framework for Intrusion Detection In this section we discuss our experience in analyzing benefits of using information fusion and honeynets for intrusion detection. Network-based distributed attacks are especially difficult to detect and require coordination among different intrusion detection components. Using honeypots provides effective solution to increase the security; and it is also a useful tool for network forensic. Our purpose for this work is to examine how to integrate multiple intrusion detection sensors and honeynets in order to minimize the number of incorrect-alarms. Our implementation framework for designing data fusion/honeynets based project for network security analysis is illustrated in Figure 1, which concerns of including all important attributes and thus having all data available. On the whole, our information fusion based intrusion detection model is in fact a prototype and needs to evolve into more mature and efficient model.
desirable. If a new type of attack becomes known, the system would detect it as a previously unseen pattern. If there are multiple sources of information (sensors) available that provide relevant information that can help identify an attack and distinguish between the different types of attacks, and support from intrusion detection system then the system would be able to update its functioning so as to be able to detect this attack type in the future. The current implementation of the framework shown in Figure 1 installs two sensors. The numbers of attacks per day collected from two sensors is collectively shown in Figure 2, and the number of essential attacks per hour on two sensors is separately shown in Figure 3.
Figure 2: Essential Attacks Collected from Two Sensors per Day
Figure 3: Essential Attacks Collected from Two Sensors per Hour Figure 1: Information Fusion-based Intrusion Detection Framework It is known that the information about a given traffic pattern being normal or malicious can be obtained from multiple sources such as the traffic statistics, the content information and other basic information about the connection. Our framework takes advantage of this fact, and attempts to build a system that is capable of combining information from multiple sources to make a more informed decision. In real scenarios, the traffic patterns change over time and a classification system that is capable of adapting to these changes is
Our preliminary implementation has the capabilities to fuse information from multiple sources and also adapt itself to changing environments. It uses a multiple sensors approach to incorporate these capabilities.
VII.Conclusion and Future Work An automatic computer system for information fusion in sensor based intrusion detection is under development in our computer security research laboratory. It uses the SNORE system to collect network traffic data, pre-processes data and transform
data into input format of a data mining and machine learning system See5, which induces a set of classification rules or a decision tree from the input data. The outcome of the See5 system can be used to recognize the suspicious network activities by discriminating normal user behaviours and abnormal behaviours. Our intrusion detection and prevention system will automatically set these rules to a firewall to prevent malicious. In this paper, the first two components of our intrusion detection and prevention are presented, including the packet information collection and data transformation. The SNORE system and the See5 system are briefly introduced. The framework of our information fusion based system implementation is briefly introduced and the preliminary findings for data collection from multiple resources are illustrated. Our future work is to complete the remaining two components of the system under developed, including application of See5 and the firewall automatic setting of rules. The results and findings will be reported in the near future.
Acknowledgment This paper is based on work supported by the National Science Foundation (NSF) through grant CNS-0540592 and NGA. Any opinions, findings, and conclusions or recommendations expressed in the paper are those of the authors and do not necessarily reflect the views of the NSF.
References [1] R. G. Bace, Intrusion Detection, Sans Publishing, 1999. [2] H. Debar and A. Wespi, Aggregation and Correlation of Intrusion-Detection Alerts. Proc. of RAID, 2001. [3] W. Lee, J. Cabrera, A. Thomas, N. Balwalli, S. Saluja, and Y. Zhang, Performance Adaptation in Real-Time Intrusion Detection Systems. Proc. of RAID, 2002. [4] P. Ning, Intrusion Detection in Distributed Systems: An Abstraction-Based Approach, Springer, 2003. [5] D. Wagner and D. Dean, Intrusion Detection via Static Analysis, Proceedings of the 2001 IEEE Symposium on Security and Privacy, 2002. [6] C. Y. Chung, M. Gertz, and K. Levitt, "Discovery of Multi-Level Security Policies". The Fourteenth Annual IFIP WG 11.3 Working Conference on Database Security, 2000 [7] W. Lee and S. Stolfo, A Framework for Constructing Features and Models for Intrusion Detection Systems, ACM Transactions on Information and System Security: 3 (4), November 2000.
[8] M. Roesch, The Story of Snort: Past, Present and Future. 2005, http://www.netsecurity.org/article.php?id=860 . [9] D. Dittrich, Network “sniffers” and You,
http://staff.washington.edu/dittrich/misc/snif fers/, 1998. [10] L. L. Peterson and S. B. Davie, Computer Networks: A systems Approach, Morgan Kaufmann Publisher. San Francisco, CA. 2003. [11] J. Gomez and D. Dasgupta, Evolving Fuzzy Classifiers for Intrusion Detection, Proc. of IEEE Workshop on Information Assurance, New York, June, 2002. [12] J. Han, K. Kowalski, M. Beheshti, Detecting Network Intrusions Based on a Generalized Rough Set Model, Proc. of International Symposium on Telecommunications, 247-252, September 10-12, 2005, Shiraz, Iran. [13] K. Julisch and M. Dacier, Mining intrusion detection alarms for actionable knowledge. Proc. of the 8th ACM SIGKDD, 366-375, 2002. [14] Rulequest Research, See5: An Tutorial, http://www2.cs.uh.edu/~ceick/ai/C5Tutorial.html [15] J. R. Quinlan, C4.5: Programs for Machine Learning, Morgan Kaufmann Publisher, 1993. [16] B. Richard, The Tao of Network Security Monitoring: Beyond Intrusion Detection. Pearson Education, Inc., 2004, Boston, MA [17] B. Caswell and J. Hewlett, Snort Users Manual, 2003, Snort.org
http://www.snort.org/docs/snort_htmanuals/ htmanual_281/ [18] F. Alejandro, F. James, G. Axton, H. Jon, J. Kevin, M. Dough, M. Sean, R. Tim, S. Christian, and V. Max, BASE, Basic Analysis and Security Engine, 2000 – 2004,
http://base.secureideas.net/ [19] MySQL A B, mysql, 1995-2008, http://www.mysql.com/ [20] J. Cerna and J. Tomelden, JACED_IPTables.php, Department of Computer Science, California State University Dominguez Hills, 2007 [21] L. Ullman, PHP and MySQL for Dynamic Web Sites, Peachpit Press, 2003
