NORMAL SIGNATURE BASED IDS FOR E-CAFÉ (HEP)

Transcription

1 NORMAL SIGNATURE BASED IDS FOR E-CAFÉ (HEP) Raihana Md Saidi, Abd. Hamid Othman, Asnita Hashim Faculty of Computer and Mathematical Sciences, Universiti Teknologi MARA Abstract Many intrusion detection analysts concentrate on identifying the characteristics of suspicious packets. However, it is also important to be familiar with what normal packet look like. This research focus on normal signature based ids for e-café. The objective of this research are; to capture packet e-café for data collection purpose, to analyse the network traffic and security condition in e-café system, and to design and deploy only the useable protocol during e-café system transaction using SNORT rule. This research is done in a real area control environment which consists of two servers; e-café server and IDS server and one client. As a result of this research, the system will detect normal packet detection using an open source network intrusion detection system called Snort. It is hoped that this project will bring benefits and useful to all the users as it can detect worm from spreading across the network. 1 INTRODUCTION As a network grows and expands, it has become apparent that more and more possibilities for miscommunication to occur between connections. Packet of information overloads the system, unidentified user in gaining access to the database or files, misconfiguration of devices, network slowdown and many more. It has come to the forefront particularly as the technologies are emerging. These complexities have created a demand for a sophisticated means to analyse the traffic and security level of network. Network-based IDSs can monitor an entire, large network with only a few well-situated nodes or devices and impose little overhead on a network. Network-based IDSs are mostly passive devices that monitor ongoing network activity without adding significant overhead or interfering with network operation. They are easy to secure against attack and may even be undetectable to attackers; it also require little effort to install and use on existing networks. E-café is a student meal system; it is been implemented at all UiTM branches. Currently the problems of e-café network traffic are the network packets are exposes to suspicious packets. This suspicious network packet will make the traffic of e-café system congested. This will affect the transaction of e-café system. As a result this project will come out with a special rule using SNORT to allow only the normal packet traffic during the transaction. 2 RELATED WORK Several studies has been conducted by Antonatos et al (2004) examines how nids performance is affected by traffic characteristics, rule sets, string matching algorithms and processor architecture. Kipp (2001) describe techniques to use Snort effectively and some of the interesting features. Paul and David (2001) gather passive measurements of network traffic at the Ipflow

2 level. IP flow level data as defined in is a unidirectional series of IP packets of a given protocol travelling between a source and a destination IP/port pair within a certain period of time. Ridza (2006) did a simulation, Honeyd performed better than Snort at Intrusions Identification Test, stress Test and also Resource Usage for Normal Test but lack in Total Resource Test. While Snort is efficient only at Total Resource Test, this result doesn t show the Honeyd is better than Snort in the real networking environment 3 PROJECT FRAMEWORK Figure 1 shows the project framework for packet capture phase while Figure 2 shows project framework for testing phase. Figure 1: Project framework: Packet capture and analysis phase 4 NETWORK PACKET Figure 2: Project framework: Testing phase According from Beltlich (2005), Observer packet is transformed into events. Events and the packet they represent can be categorized into three categories:

3 i. Normal Packet Anything that is expected to belong on an organization s network. HTTP, FTP, SMTP, POP3, DNS, and IPsec or SSL would be normal traffic for many enterprises. ii. Suspicious Packet Appear odd at first glance but causes no damage to corporate assets. While a new peer-to-peer protocol may be unwelcome, its presence does not directly threaten to compromise the local Web or DNS server. iii. Malicious Packet Anything that could negatively impact an organization s security posture. Attacks of all sorts fit into the malicious category and are considered incidents. Table 1:Normal service of e-café Service Port Number HTTP 80 SSH 22 MySQL 3306 MSSQL 1433 Table 1 shows the normal packet define for e-café; HTTP, ICMP, SSH, MySQL, MSSQL. Different between a packet, a segment, and a datagram Beltlich (2005) stated TCP produce a chunk of data called a segment for transmission by IP. UDP produces a datagram for transmission by IP. IP then creates its own datagrams out of what it receives from TCP or UDP. If the TCP segment or UDP datagram plus IP s headers are small enough to send in a single package on the wire, IP creates a packet, which is the same as the IP datagram. If the IP datagram is too large for the wire, that is, it exceeds the maximum transmission unit (MTU) of the media, IP fragments the datagram into smaller packets suitable for the media s MTU. These fragment packets will be reassembled by the destination. Whatever IP produces, it sends it to the interface, which creates Ethernet frames. 5 INTRUSION DETECTION SYSTEM From Susan, John, Dave, & Felix (2001), the terminology Intrusion Detection addresses a range of technologies that are involved in the detection, reporting, and correlation of system and network security events. Intrusion detection technologies are detective rather than preventive but can help mitigate any type of risk by providing a security administrator with information on attempted or actual security events. There are two main types of IDS which are host-based intrusion detection system (HIDS) and network-based intrusion detection system (NIDS). A host-based intrusion detection system (HIDS) operates on a host while the network-based intrusion detection system (NIDS) operates on network data flow. i. Network Based IDS Network-based intrusion detection system (NIDS), data may be correlated from several host or network traffic patterns to detect sign of intrusion. It performs security analysis on packet obtained by eavesdropping on a network link.

4 ii. Host Based IDS Host-based intrusion detection system (HIDS), data from a single host is used to detect sign of intrusion. Rafeeq (2003) stated there are five characteristics of IDS namely: i. Network-based IDS Network-based IDSs can monitor an entire, large network with only a few well-situated nodes or devices and impose little overhead on a network. Network-based IDSs are mostly passive devices that monitor ongoing network activity without adding significant overhead or interfering with network operation. They are easy to secure against attack and may even be undetectable to attackers; they also require little effort to install and use on existing networks. ii. Host-based IDS Host-based IDS can analyze activities on the host it monitors at a high level of detail; it can often determine which processes and/or users are involved in malicious activities. Though they may each focus on a single host, many host-based IDS systems use an agent-console model where agents run on (and monitor) individual hosts but report to a single centralized console (so that a single console can configure, manage, and consolidate data from numerous hosts). Host-based IDSs can detect attacks undetectable to the network-based IDS and can gauge attack effects quite accurately. Host-based IDSs can use host-based encryption services to examine encrypted traffic, data, storage, and activity. iii. Application-based IDS An application-based IDS concentrates on events occurring within some specific application. They often detect attacks through analysis of application log files and can usually identify many types of attack or suspicious activity. Sometimes application-based IDS can even track unauthorized activity from individual users. They can also work with encrypted data, using application-based encryption/decryption services. iv. Signature-based IDS A signature-based IDS examines ongoing traffic, activity, transactions, or behavior for matches with known patterns of events specific to known attacks. As with antivirus software, a signature-based IDS requires access to a current database of attack signatures and some way to actively compare and match current behaviour against a large collection of signatures. Except when entirely new, uncataloged attacks occur, this technique works extremely well. v. Anomaly-based IDS An anomaly-based IDS examines ongoing traffic, activity, transactions, or behavior for anomalies on networks or systems that may indicate attack. The underlying principle is the notion that attack behavior differs enough from normal user behavior that it can be detected by cataloging and identifying the differences involved. By creating baselines of normal behavior, anomaly-based IDS systems can observe when current behavior deviates statistically from the norm. This capability theoretically gives anomaly-based IDSs abilities to detect new attacks that are neither known nor for which signatures have been created.

5 6 SNORT RULE Rafeeq (2003) found that all snort rules have two logical parts: rule header and rule option. RULE HEADER RULE OPTION Figure 3: Basic Structure of Snort Rules The rule header contains information about what action a rule takes. It also contains criteria for matching a rule against data packets. The option part usually contains an alert message and information about which part of the packet should be used to generate the alert message. The options part contains additional criteria for matching a rule against data packets. A rule may detect one type or multiple types of intrusion activity. Intelligent rules should be able to apply to multiple intrusion signatures. Action Protocol Address Port Direction Address Port Figure 4: Additional Structure of Snort Rules The action part of the rule determines the type of action taken when criteria are met and rule is exactly matched against a data packet. Typical actions are generating an alert or log message or invoking another rule. i. Pass This action tells Snort to ignore the packet. This action plays an important role in speeding up Snort operation in cases where you don t want to apply checks on certain packets. For example, if you have a vulnerability assessment host on your own network that you use to find possible security holes in your network, you may want Snort to ignore any attacks from that host. The pass rule plays an important part in such a case. ii. Log The log action is used to log a packet. Packets can be logged in different ways, as discussed later in this book. For example, a message can be logged to log files or in a database. Packets can be logged with different levels of detail depending on the command line arguments and configuration file. iii. Alert The alert action is used to send an alert message when rule conditions are true for a particular packet. An alert can be sent in multiple ways. For example, you can send an alert to a file or to a console. The functional difference between Log and Alert actions is that Alert actions send an alert message and then log the packet. The Log action only logs the packet. iv. Activate The activate action is used to create an alert and then to activate another rule for checking more conditions. Dynamic rules, as explained next, are used for this purpose. The activate action is used when you need further testing of a captured packet. v. Dynamic Dynamic action rules are invoked by other rules using the activate action. In normal circumstances, they are not applied on a packet. A dynamic rule can be activated only by an activate action defined in another role.

6 The protocol part is used to apply the rule on packets for a particular protocol only. This is the first criterion mentioned in the rule. Some examples of protocols used are IP, ICMP, UDP and etc. The address part define source and destination address. Address may be a single host, multiple host or network address. The researcher can also use these parts to exclude some address from a complete network. Source and destination address are determined based on direction field. As an example, if the direction field is, the address on the left side is source and the address at the right side is destination. In case of TCP or UDP protocol, the port parts determine the source and destination ports of a packet on which the rule is applied. In case of network layer protocols like IP and ICMP, port numbers have no significance. The direction part of the rule actually determines which address and port number is used as source and which as destination. 7 PACKET ANALYSIS AND DETECTION 7.1 Method of Detection and Analysis Method of detection is the tools use for capturing and analysis the traffic. There are few tools that can be use such as: i. Tcpdump Tcpdump is a packet capture utility deployed with libpcap and maintained by the libpcap developers. Both libpcap and Tcpdump undergo very active development, as demonstrated by the frequent post to the three Tcpdump mailing list. The version of Tcpdump package with based FreeBSD ii. Windump Windump is also for packet capture and analysis, but it is for the Windows version. It available with libpcap as its capture library. iii. Tethereal Tethereal is similar to Tcpdump in that it relies on libpcap and can both collect and display traffic captures. it can examining a large capture file on a remote sensor in a command-line environment. While Tcpdump can look at the same traffic, Tethereal s extensive range of protocol decoding options makes inderstamding certain protocols much easier. iv. Snort as Packet Logger Snort is most famous for being a network-based intrusion detection system, but it can also be used to collect and view packets. Legend has it that Marty Roesch wrote Snort because he wanted a sniffer that would display packet contents more uniformly than other software available in By default, snort output is fairly different from Tcpdump and Tethereal. v. Ethereal/Wireshark Graphical packet capture and analysis utility, it can capture packets in real time by using the Capture Options window. vi. Tcpreplay Tcpreplay is a tool used to replay packets captured in libpcap format. It works very well with applications that do not have capability to read in libpcapformatted traces. Using Tcpreplay it can replay trace file and have the non-libpcapfriendly application listen for packets.

7 vii. BASE (Basic Analysis and Security Engine) BASE is a web interface to perform analysis of intrusions that snort has detected on the network. It uses a user authentication and role-base system, so that the security admin can decide what and how much information each user can see. It also has a simple to use, web-based setup program for people not comfortable with editing files directly. 7.2 Capturing packet from client and server by using windump and tcpdump i. Client captured using windump WinDump.exe i 2 s 1500 w client.pcap port 80 -i <interface> tells Tcpdump which interface to watch. -s <snaplen> tells Tcpdump how much of the packet to record. -w <file> write the file Port 80 capture packet base on port 80 Figure 5: Excerption of packet from the client of e-café Table 2: Explanation of packet for e-café client Value Explanation 07:25: Timestamps IP Source IP address (IP client for the café) 1063 Source Port > Direction indicator hep.uitm.edu.my Destination host (Server e-café) http Port host (port 80) P TCP PSH flag is set 1 TCP initial sequence number (ISN) 605 Sequence number of the next byte of application data expected by TCP (604) Count of application data in this segment ack 1 Acknowledge equal to 1 win Size of the window in bytes

8 ii. Server captured using tcpdump tcpdump i bge0 s 1500 w server.pcap -i <interface> tells Tcpdump which interface to watch. -s <snaplen> tells Tcpdump how much of the packet to record. -w <file> write the file Figure 6: Excerption of packet from the server of e-café Table 3: Explanation of packet for e-café server Value Explanation 07:38: Timestamp IP ivy.uitm.edu.my Source host name address 3306 Source port number (mysql process) > Direction indicator hep.uitm.edu.my Destination host name address Destination port number (client café) P TCP PSH flag is set 295 TCP Initial sequence number (ISN) 391 Sequence number of the next byte of application data expected by TCP (96) Count of application data in this segment ack 285 Acknowledgement 285 Win Size of the TCP window in bytes <nop Means no operation ; include to pad the TCP options section appropriately Timestamp Timestamp value ( ) and timestamp echo reply setting ( ) 7.3 Analyse SNORT rule Figure 7 shows the snort rule for this project. alert tcp /16 any -> any $HTTP_PORTS (msg:"traffic from teratai,mawar,melati,anggerik"; uricontent:"/smp/index3.php"; classtype:ecafé_packet; econtent:"no_id=2008"; sid:9333;) Figure 7: SNORT rule

9 Table 4: Explanation of SNORT rule Value Explanation alert rule action; alert will be generated when conditions are meet TCP TCP, which means that the rule will be applied only on TCP type packet /16 source IP address any source port number; any means, that the rule will be applied to all packets coming from any source. symbol direction; this shows that the address and port number on the left hand side of the symbol are source and those on the right hand side are destination any destination IP address $HTTP_PORTS Destination port (var declare at snort.conf) msg:"traffic from teratai, message contain for alert mawar,melati,anggerik" uricontent:"/smp/index3.php"; look for a string only in the URI part of packet classtype:e-café_packet; econtent:"no_id=2008"; sid:9333;) class type for the rule content of the packet snort ID Figure 8 shows the Snort rule implemented using BASE. Figure 8: Snort rule result shows in BASE

10 Figure 9: Total alert packet For this alert data packet, Figure 9 shows the TCP packets are the greatest from UDP and ICMP. Figure 10: Snort rule result shows in BASE for incoming packet by classification Figure 10 shows Snort rule result implemented in BASE for incoming packet by classification

11 Figure 11: Packet classification Figure 11 shows the classification of total number of alert packet transfer. From the total alert packet, there is four abnormal alert packet, shellcode- detect, misc-activity, attemptedrecon, and unclassified. Packet for e-café shows the highest total packet alert % ~70%. Unclassified is the second highest, which is 9.945% ~ 10%. From the unclassified alert packet, the signature of snort alert was detect there is Bad Traffic Loopback IP. For shellcode-detect, it was 5.304% ~ 5% and one signature was detected, SHELLCODE x86 NOOP. Misc-activity shows only 8.476% ~ 8%, there are four signature are detected; ICMP Ping, SQL Ping Attempt, ICMP Ping Windows and ICMP Destination Unreachable communication with destination host is administratively prohibited. Total alert packet for attempted-recon shows, only 5.985% ~ 6%, and the signature detect is ICMP L3retriver Ping. Figure12: Unclassified packet

12 Figure 12 shows packet classification for unclassified. The signature detect shows there is Bad Traffic Loopback IP. Source address /24 and the destination address is , from my observation and reading, after searching a weird source IP address from google, it determine the packets to are suspicious. These packets are generated by a certain DDoS client operating erroneously. A DDoS client is a compromised machine which has software installed so that it, and others like it, can be controlled centrally, and commanded to attck a third-partywho has angered the attacker. Figure 13: Snort rule result shows in BASE for incoming packet Figure 13 shows the result of incoming e-café packet. Signature for MYSQL databases shows the highest total alert packet with alert packets 65%. Others signatures detect are remote server 147 alert packets, DHCP 519 alert packet, DNS 17 alert packet and the others signature are come from data pelajar from each cafeteria base on year of ID student.

13 Figure 14: Snort rule result shows in BASE in detail, for 31 total alert signatures Figure 14 shows the Snort rule result shows in BASE in detail, for 31 total alert signatures tested in the project.

14 Figure 15: Snort rule result shows in BASE in detail, classification for TCP packet Figure 16: Classification for TCP packet Figure 15 shows the classification for TCP packet while Figure 16 shows there are 20 signatures packet-for-e-café, and shellcode-detect with 2 signature. The 20 signatures are remote server, MYSQL Database, data pelajar 2007 mawar and malati, data pelajar 2008 mawar and malati, data pelajar 2008 jati, data pelajar 2006 mawar and malati, data pelajar 2005 jati, data pelajar 2006 jati, data pelajar 2007 jati, data pelajar 2008 perindu, data pelajar 2007 perindu, data pelajar 2005 perindu, data pelajar 2008 seroja, data pelajar 2007 seroja, data pelajar 2006 seroja, data pelajar 2005 seroja, data pelajar 2008 teratai, data pelajar 2007 teratai, data pelajar 2006 teratai, and data pelajar 2005 teratai. For shellcode-detect, the signature is SHELLCODE x86 NOOP.

15 Figure 17: Snort rule result shows in BASE in detail, classification for UDP packet Figure 18: Classification for UDP packet Figure 17 shows the classification for UDP packet while Figure 18 shows the total alert for UDP packet. Misc-activity, detect only one signature, SQL Ping Attempt. Signature detect for packet for e-café are three, which are DNS two signature and DHCP. Shellcode-detect, the signature is SHELLCODE x86 NOOP.

16 Figure 19: Snort rule result shows in BASE in detail, classification for ICMP packet Figure 20: Classification for ICMP packet Figure 19 shows the classification for ICMP packet while Figure 20 shows total alert packet for ICMP. There are two classifications are detected, misc-activity and attempted-recon. For miscactivity it consist only one signature; ICMP L3retriever Ping and for attempted-recon there are three signature, ICMP PING, ICMP PING Windows, and ICMP Destination Unreachable Communication with Destination Host is Administratively Prohibited. 8 CONCLUSION Security is a big issue for all networks in today's enterprise environment. Hackers and intruders have made many successful attempts to bring down high-profile company networks and web services. Many methods have been developed to secure the network infrastructure and communication over the Internet, among them the use of firewalls, encryption, and virtual private networks. Intrusion detection is a relatively recent addition to such techniques. Snort is free and powerful software that capable of performing real-time traffic analysis and packet logging on IP networks. Snort rules have been configured to make it detect the selected normal packet of e-café. The network packet analysis was done accordingly. From the data collected there is normal packet from e-café has been detected in BASE. There also bad traffic packet during the tcpreplay replay the packet for testing the rule. That shows the traffic flows on a network status must keep the network performance to its optimum level.

17 References Baker, A.R. (2000). Snort Documentation Receive on 14 January from Beltlich R. (2005).The Tao of Network Security Monitoring, Beyond Intrusion Detection. Publication of Addison-Wesley. Daniel, J. Adaptation Techniques for Intrusion Detection and Intrusion Response Systems Received on 14 January from Frederick, K.K. (2001) Network Intrusion Detection Signatures, Part One Receive on 14 January from Kipp, J. (2001) Using Snort as an IDS and Network Monitor in Linux Receive from 15 January from Kevin T. (2003) Passive Network Traffic Analysis: Understanding a Network Through Passive Monitoring Receive from 22 January from Mohd Ridza, M. Z. (2006) Performance Analysis Using IDS Thesis (BSc) Mara University of Technology. Paul,B. F. and David, P. (2001) Characteristic of Network Traffic Anomalies Receive from 15 January from Rafeeq A. (2003). Intrusion Detection Systems with Snort advance IDS technique Using Snort, Apache, MySQL, PHP, and ACID. Publication Pearson Education. Upper Saddle River, New Jersey. Roesch, M. (1990) Snort- Lightweight Intrusion Detection for Networks Receive from 14 January from http// Roesch, M. Writing Snort Rules: How to Write Snort Rules and Keep Your Sanity Receive from 22 January from Robert, J. (2002) What You Need to Know About Intrusion Detection Systems, Receive from 14 January from _Intrusion_Detection_Systems.html Susan, Y., John, D.T., Dave, A., & Felix, L. (2001) The Hacker s Handbook, CRC Press. Receive on 14 January from PA174&dq=signature+based+network&source=web&ots=LeRC4cdZK7&sig=jZW2o68ViZdm nb4pspr0zagttxi&hl=en#ppa173,m1