Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

A trust-based model for collaborative intrusion response Singh, Kapil Kumar 2005

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Notice for Google Chrome users:
If you are having trouble viewing or searching the PDF with Google Chrome, please download it here instead.

Item Metadata


831-ubc_2005-0640.pdf [ 2.99MB ]
JSON: 831-1.0051329.json
JSON-LD: 831-1.0051329-ld.json
RDF/XML (Pretty): 831-1.0051329-rdf.xml
RDF/JSON: 831-1.0051329-rdf.json
Turtle: 831-1.0051329-turtle.txt
N-Triples: 831-1.0051329-rdf-ntriples.txt
Original Record: 831-1.0051329-source.json
Full Text

Full Text

A Trust-based Model for Collaborative Intrusion Response by Kapil Kumar Singh B.Tech., Indian Institute of Technology (IIT), Roorkee, India, 2001 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF Master of Science in THE FACULTY OF GRADUATE STUDIES (Computer Science) The University of British Columbia June 2005 © Kapil Kumar Singh, 2005 Abstract Intrusion detection systems (JDS) are quickly becoming a standard component of a net-work security infrastructure. Most IDS developed to date emphasize detection; response is mainly concentrated on blocking a part of the network after an intrusion has been detected. This mechanism can help in temporarily stopping the intrusion, but such a limited response means that attacking is free for the attacker. The idea behind our approach is to frustrate the intruder by attacking back. This requires developing a sense of trust in the network for the attacked host and establishing proof of the attack so the attack-back action can be justified. In an environment of trust, a more effective collaborative action can be taken by the network entities. To develop this trust model, we propose a protocol that uses encryption and digital signatures over the network logs. The protocol allows the attacked host to prove to the attacker's edge router that it has been attacked. The model is quite flexible, and based on the level of trust developed for the host, an appropriate countermeasure is taken. Besides attack-back, other possible responses could be blocking a part of the network and use of net-work puzzles to limit the attacker's access to network resources. We also define a heuristic algorithm for selecting the appropriate response based on the level of trust developed for the victim. We believe that the attack-back approach would certainly demoralize novice at-tackers, and even expert attackers will think twice before attacking again. In addition, the protocol prevents a host from pretending that it has been attacked. We are building a sys-tem that can handle a majority of known attacks (signature-based). We are also exploring the idea of adding a third trusted party into the system in order to provide countermeasure action for novel attacks (anomaly-based). ii Contents Abstract ii Contents iii List of Tables vi List of Figures vii Acknowledgements viii Dedication ix 1 Introduction 1 1.1 Motivation 1 1.2 Thesis Contributions 3 1.3 Thesis Structure 3 2 Background 4 2.1 Intrusion Detection Systems 4 2.1.1 Host-based JDS vs Network-based IDS 4 2.1.2 Misuse Detection vs Anomaly Detection 5 2.2 State-based IDS 7 iii 2.2.1 Suspicion State vs Conviction State 8 2.3 Automated Response Mechanisms 9 2.4 Assumptions 9 2.5 Summary 10 3 Protocol Description 11 3.1 Overview 11 3.2 Protocol for Trust Development 12 3.2.1 Example Scenario 14 3.3 Encryption Algorithm 14 3.4 Defense against possible protocol attacks 16 3.5 Summary 18 4 Responses 19 4.1 Overview 20 4.2 Heuristics for response selection 20 4.3 Attack-back Approach 23 4.4 Network Puzzles 24 4.5 Blocking malicious network traffic 25 4.6 Summary 25 5 Implementation 26 5.1 NetSTAT 26 5.2 Prototype 29 5.3 Testbed . 29 5.4 Experience with the prototype 32 5.4.1 Ping of Death attack 32 iv 5.4.2 SYN Flood attack 33 5.5 Summary 34 6 Related Work 35 6.1 Trust Development 35 6.2 Attack Back 37 6.2.1 Historical Attempts 37 6.2.2 Current Counter-Attack Products 40 6.2.3 Social and legal issues of attacking back 42 7 Limitations and Extentions 46 7.1 Limitations 46 7.2 Extensions 47 7.2.1 Anomaly-based Response 47 7.2.2 Use of multiple IDSs 48 7.2.3 Collaboration among different hosts 49 8 Conclusions 50 Bibliography 52 v List o f Tables 3.1 List of Variables 15 vi List of Figures 3.1 Typical network architecture 12 4.1 Pseudo code for response selection 21 5.1 Sample Attack Scenario in STATL 28 5.2 Block Diagram 30 5.3 Testbed Setup 31 7.1 Anomaly based Response 48 vii Acknowledgements I would like to express my sincere gratitude to my supervisor, Dr. Norman C. Hutchinson, for his guidance and support and for helping me understand the true meaning of research. I am also grateful to Dr. Charles "Buck" Krasic for his invaluable feedback on my research that went a long way in improving the thesis. I would like to thank Chamath, Ken, Dima, Geoffrey and everyone in the DSG lab for their fruitful discussions, their advice, their research tips and for giving me the most wonderful time of my life. I am proud of having been a part of DSG and I will cherish these memories forever. My heart also goes with the CS department and the wonderful people out here. I made some great friends in the department and they will always be a part of my life. I thank them all for their moral support. Finally, I would like to thank my family for their endless love and support. KAPIL K U M A R SINGH The University of British Columbia June 2005 viii To my parents and my big brother. Always therefor me, no matter what To my sister-in-law. Welcome to the family ix Chapter 1 Introduction The open nature of the Internet makes it difficult to trust anyone in the cyber world. On top of this, there is ever growing problem of network attacks. An effective solution to the network security problem requires a collaborative effort from various entities in the Internet, such as routers, gateways and end hosts. But the biggest question still remains - whom to trust? This thesis describes a model to develop trust among various network elements, effectively enabling them to take a collaborative action against network attacks. 1.1 Motivation 'Viruses', 'Trojans', 'worms' ...the attacks and intelligent intrusions - not anymore some alien discussions today, but we shall see to what extent the human mind can stretch, to counter the intelligence that only mind is capable of inflicting on machines, with a challenge to keep a step ahead ... [11] The 'intelligence inflicted' mentioned is the problem of 'intrusion' - the undesired access to resources. An intrusion can be defined as any set of actions that attempt to com-promise the integrity, confidentiality or availability of a resource. It can be in the form 1 of subtle port scans leading to unauthorized access to information, modification, deletion or denial-of-service and is most difficult to detect when the intruder moves away silently, eradicating all traces of their action. With the rapid expansion of computer networks during the past few years, these are fast becoming the subject to a variety of intrusions. The amount of financial losses due to cyber attacks have grown manyfold over the years. It is estimated that the worldwide impact of malicious code was $13.2 billion in the year 2001 alone [38]. A 2004 E-crime watch survey of 500 organizations shows financial losses of about $666 million due to Internet attacks, with 43% reporting an increase in the e-crime against them [3]. The constant increase of attacks against networks and their resources causes a necessity to protect these valuable assets. Security is a constant race between the attackers and the defenders. The attackers are getting smarter day by day and hence the need for smarter security solutions always remains. A collaborative effort is needed among the network elements to effectively detect and prevent the attacks from happening in future. With the idea of collaboration comes the need for trust among the cooperating parties and this is the motivation behind our thesis work. Intrusion detection systems are quickly becoming a standard component of a net-work security infrastructure. Most IDS developed to date emphasize detection; response is mainly concentrated on blocking a part of the network after an intrusion has been detected. This mechanism can help in temporarily stopping the intrusion, but such a limited response means that attacking is free for the attacker. The idea behind our approach is to frustrate the intruder by attacking back. This requires developing a sense of trust in the network for the attacked host and establishing proof of the attack so the attack-back1 action can be justified. 1 Attack-back has been used alternatively for counter-attack [32] or hack-back [17] used elsewhere. 2 1.2 Thesis Contributions This thesis makes the following contributions: • Development of a trust-based intrusion response model, that overcomes limitations of the existing approaches for collaboration among various network elements. A protocol has been designed to create an environment of trust in the network. • An exploration of various responses to an intrusive activity. The trust model allows the use of an attack-back approach as an extreme response to a network attack. • Design of a heuristic algorithm for appropriate response selection. This algorithm keeps track of the "criminal" record of an attacker in carrying out the intrusions and the "clean" record of a victim in being truthful about attacks on itself. • A prototype implementation of such a system and analysis of some intrusions to prove our concept. 1.3 Thesis Structure The rest of the thesis is structured as follows. Chapter 2 provides a comprehensive back-ground of intrusion detection systems and techniques, including the state-based IDS. It also lists the assumptions made as a prerequisite for our system. Chapter 3 describes the trust development protocol in detail along with the encryption algorithm used. Chapter 4 covers the possible responses to an intrusive activity by our system including the attack-back ap-proach and defines a heuristic algorithm for selecting the appropriate response. Chapter 5 describes the implementation of the prototype and analysis of our experiments. We review the related work in Chapter 6. We describe limitations and extensions in Chapter 7, ending with conclusions in Chapter 8. 3 Chapter 2 Background 2.1 Intrusion Detection Systems Intrusion Detection Systems (IDS) seek to monitor the behavior of users, networks or com-puter systems and help detect misuse of the systems through identification of anomalous behavior; also at times alerting the management to take appropriate corrective action (like a burglar alarm). IDS are the last line of defense against computer attacks behind firewalls, secure architecture design, secure program design, carefully configured network services and penetration audits. In spite of the availability of a large variety of intrusion prevention techniques, the intrusion problem still remains challenging as there is no fool-proof way of reading the attacker's mind and the attackers are still successful in finding system loopholes in order to compromise the system resources. Most computer attacks are made possible due to poorly configured services or bugs in the software. 2.1.1 Host-based IDS vs Network-based IDS Some of earliest intrusion detections were performed manually by system administrators who examined the audit logs of user and system events recorded by the computer hosts. 4 Logged events might indicate that activities like a large number of failed login attempts, FTP transfer of sensitive files or failed file access were potential events for intrusive ac-tivity. Later, the manual task was replaced by Host-based JDS that could automatically detect potential attacks by scanning audit logs for signs of any suspicious activity. More recently, due to tremendous growth in the field of computer networks, network-based IDS have gained popularity among researchers and even in commercial tools. Network-based IDS typically monitor the network data for intrusive activity and can be placed inside a firewall or outside it or at the system boundary. For example, network-based IDS can detect network probing attacks, which map out the network topology of a site, by searching for the "pings" to the network services across the complete site. The most difficult choice in the design of a secure system is to decide the location of the IDS in the network. On one hand, directly inspecting the state of the monitored system provides better visibility. Visibility makes detection more effective by increasing the range of analyzable events, decreasing the risk in having an incorrect view of the system and reducing the chances of an unmonitored attack. On the other hand, increasing the visibility of the target system usually leads to weaker isolation between the JDS and the attacker, thus increasing the risk of a direct attack on the IDS itself. This leads to a choice between Host-based IDS, that has an excellent view of the what is happening in the host but is more prone to attack, and Network-based IDS, that has a poor view of the host's software but offers high attack resistance to itself. 2.1.2 Misuse Detection vs Anomaly Detection Intrusion detection methods are broadly classified into two categories: misuse detection and anomaly detection. Misuse detection methods, also known as signature-based detection, use information about a known security policy, known vulnerabilities and known attacks 5 on the systems they monitor. This approach compares network activity or system audited data to a database of known attack signatures or other misuse indicators, whereas pattern match produces alarms of various sorts. A lot of work is being done by researchers to find intelligent ways to map the dynamically changing attack patterns to already known attacks. Example of such signature-based IDS are Snort [30] and NetSTAT [37]. Snort is a popular cross-platform, lightweight network intrusion detection tool configured using a public database of attack signatures. It can be deployed to monitor small TCP/IP networks and detect a wide variety of suspicious network traffic as well as outright attacks. It can provide administrators with enough data to make informed decisions on the proper course of action in the face of suspicious activity. Snort can also be deployed rapidly to fill potential holes in a network's security coverage, such as when a new attack emerges and commercial security vendors are slow to release new attack recognition signatures. NetSTAT is a state-based intrusion detection tool (Section 2.2) aimed for real-time network intrusion detection. We have used NetSTAT as part of our experimentation (more on NetSTAT in Section 5.1). Anomaly detection methods, also called behavior-based intrusion detection, use in-formation about repetitive and usual behavior on systems and attempt to detect intrusions by noting significant departures from normal behavior. The most significant advantage of anomaly detection techniques is the ability to detect novel attacks against systems. This is possible because anomaly detection techniques do not scan for specific patterns, but instead compare current activities against models of past behavior. The biggest disadvantage of anomaly detection approaches is the high rate of false alarms as compared to misuse detec-tion techniques. Because any significant deviation from the previously learned behavior can be flagged as intrusion, it is highly likely that any non-intrusive behavior that falls outside the normal range will also be flagged as intrusive, resulting in a false positive. Another lim-itation of the anomaly detection approach is that the training data should be free from any 6 intrusive behavior because if an attack occurs during the training period, then this intrusive behavior will become a part of the normal baseline. The most desirable feature of an ideal IDS is its ability to think one step ahead of the attacker, i.e., its potential to identify novel attacks. Therefore, in spite of its drawbacks, anomaly detection approaches are still a better bet for detecting any future, unknown and novel attacks against computer systems. We leave the discussion on IDS here, as our work is mainly focused on what happens after an intrusion has been detected. For our system, we are using a signature-based network IDS, NetSTAT. We have also explored the idea of using an anomaly-based IDS as part of future work. 2.2 State-based IDS State-based [24][15] is an approach of representing computer penetrations and can be ap-plied to the development of a real-time intrusion detection tool. The approach, referred to as state transition analysis, views a penetration as a sequence of state changes that lead a computer system from an initial secure state to a target compromised state. State transitions are defined in terms of critical actions and assertions that describe the pre- and post-action states of the system. A state transition diagram, which is the graphical representation of state transition analysis, identifies precisely the requirements and compromise of a penetra-tion and lists only those critical events that must occur for the successful completion of the penetration. The State Transition Analysis Tool (STAT) [15] is an advanced rule-based expert system that analyzes the audit trails of multi-user computer systems in search of impending security violations. STAT represents state transition diagrams within its rule-base and uses them to seek out those state transitions within the target system that correspond to known penetration scenarios. Unlike comparable analysis tools that pattern match sequences of 7 audit records to the expected audit trails of known penetrations, STAT rules focus on the effects that the individual steps of a penetration have on the state of the computer system. The resulting rule-base is not only more intuitive to read and update than current penetration rule-bases, but also provides greater functionality to detect impending compromises. STAT was initially developed for host-based IDS, but later extended to describe net-work attacks [37]. In network-based state transition analysis the state includes the currently active connections (for connection oriented services), the state of interactions (for connec-tionless services), and the values of the network tables (e.g., routing tables, DNS mappings, ARP caches, etc.). For instance, both an open connection and a mounted file system are part of the state of the network. A pending DNS request that has not yet been answered is also part of the state, such as the mapping between an IP address and the machine name. 2.2.1 Suspicion State vs Conviction State A suspicion state is a state in the state transition analysis at which there is an initial hint of an intrusive activity. This state might or might not lead to a final compromised state, but it acts as a trigger to start monitoring the system. An example of the initial state is the receipt of port scan packets from a different subnet. In the case of denial-of-service attacks (such as the ping of death), this initial state is the first attack packet. A conviction state is the final compromised state at which the IDS is convinced of the attack. In case of DoS attacks, this could be the receipt of a threshold number of packets in a given period of time. In case of SYN flood attack, the attacker sends packets with SYN flag set as a request to open a new connection to the server. The victim responds to the request, then waits for confirmation that never arrives. As a result, the victim's connection table fills up waiting for replies and all new connections are ignored. In case of this attack, the suspicious state could be receipt of a threshold number of requests with no following ACKs and the 8 conviction state is when the connection table is filled up. 2.3 Automated Response Mechanisms The ideal JDS is the one that responds to intruder action, to stop his/her activity before he/she can do any damage to the system or access sensitive information. Most systems require intensive management, which may be a cumbersome task for a human administrator. After the attack has been detected, the responsibility to respond to an attack is left to the system administrator. This process might be slow and prone to human errors. Hence there is a need to automate the response and management mechanism. An effective defense system should be able to detect the attacks and communicate with other entities in the system to take an effective collaborative action in an automated fashion. The basic lacking factor is the ability to detect attacks in real time and for that the ability to recognize unknown attacks is necessary. According to NIST, there are 20-30 new attacks that are posted on the Internet every month, and keeping track of all new attacks and updating the signatures can be quite expensive and inefficient, as one weak link can leave the system vulnerable. 2.4 Assumptions We have made few assumptions for the working of our system. • A state-based IDS would be in place and would be able to detect attacks effectively. We have not developed any new JDS, instead we have used an existing JDS as part of our system. • There would be some anti-spoofing mechanism in place, which limits source ad-dress spoofing to a certain degree. The Internet architecture in its current form does 9 not support this assumption. However, a lot of research is being done to provide a deployable anti-spoofing mechanism. Hamadeh et al. [14] have proposed a packet marking scheme, where each packet is stamped by the first participating border router that forwards the packet. Yaar et. al [43] have proposed Packet Identifier (Pi), where each participating router marks the forwarded packets, so that each packet obtains a "fingerprint" that describes the complete path followed by the packet. Each of these mechanisms provide a comprehensive solution for the spoofing problem and we are confident that a deployable solution would be available for the Internet in the near future. • The routers would support logging of traffic and provide additional functionality of-fline. Our mechanism, as we will see, motivates the edge router of the attacker to contribute, else it risks losing its connectivity to the host. 2.5 Summary In this chapter, we discussed in brief the concept behind Intrusion Detection Systems. We also touched upon their taxonomy. We introduced the idea of the state-based IDS, one such IDS is used by our system as described in Section 5.1. We discussed the background behind the suspicion state and the conviction state - an important concept needed for understanding of the thesis. We also pointed out the assumptions made for our work. The next chapter builds on the background developed in this chapter by introducing the protocol for developing trust in the network. It describes in detail the steps involved in the process and how the system is invulnerable to some well known attacks. 10 Chapter 3 Protocol Description This chapter describes the protocol for developing trust among the various network entities involved in our intrusion response system. This trust is needed to make sure that the ability to take proper action is not abused by a malicious node to disrupt other nodes' communi-cations. The protocol for trust development prevents an attacker from posing as a victim and thereby misusing the system for creation of an attack. The encryption algorithm, which forms a part of the protocol, certifies the identity of a particular host and prevents any sniff-ing on the control messages. 3.1 Overview The IDS at the host machine observes the incoming network traffic for signs of possible intrusions. Once the EDS is suspicious that the host is being attacked, it informs the edge routers to start monitoring the traffic originating at the attacker. When the IDS is convinced that the host is under attack, it sends the intrusion-specific information in an encrypted form to the attacker's edge router. The router, in turn, compares its own logs against the received information to decide on the appropriate response. The logs of the victim's edge router can 11 Router R1 Router R2 Attacker A Host H Figure 3.1: Typical network architecture, also be used to improve this trust level. 3.2 Protocol for Trust Development Figure 3.1 shows a typical system. 'A' is the attacker machine having the edge router 'RI ' . 'H ' is the host machine having the edge router 'R2 ' . IDSs are installed at the routers and the host machine. The typical steps involved in this protocol are: Step 1. The IDS at H scans for any intrusion attempt at the network interface. If the initial state of an intrusion is detected, the process moves to the next step. An example of the initial state is the receipt of port scan packets from a different subnet. In the case of denial-of-service attacks (such as the ping of death), this initial state is the first attack packet. The initial state is just a suspicion state and is not a confirmation of the attack. Step 2. H sends a Start-Logging message to inform the routers to start monitoring the traffic from A, specifying its own IP Address, IPH, and the IP Address of A, I PA- R stands for the edge routers RI and R 2 or some intermediate router that sees majority of traffic between A and H. H^R : IPH, I PA, Start-Logging (3.1) 12 In case of intrusions that are interactive and bidirectional, such as the attacks aim-ing to gain unauthorized access, this is done using the Watermarking technique [39]. In this technique, a small piece of information is injected into the backward traffic through the application. The information, called the watermark, is invisible to the normal user of network applications and in our system, this watermark is used as a trigger for logging at the routers. After receiving the Start-Logging message, the router starts logging the traffic com-ing from A. This logging is time controlled and if the router doesn't receive a confirmation message from the victim within a timeout period, it stops logging. This prevents overload-ing of the router when there is a false suspicious state and hence no confirmation is received from the host (Step 3). An alternative to the time-based garbage collection could have been an extra Stop-Logging message from H to the routers, but this can be exploited by inten-tionally sending an initial Start-Logging message and no confirmation. The routers would keep logging indefinitely waiting for confirmation from the host. Step 3. When the IDS at H is convinced that it is under attack, it sends the Verify-Attack message to A's edge router RI, specifying the attack signature (AttackScenario) and any parameters associated with that attack. H —y RI : IPH, I PA, Verify-Attack, AttackScenario, parameters (3.2) Step 4. After receiving the Verify-Attack message from H, RI verifies the attack claim offline by running the IDS on its own network logs. Doing this processing offline does not impact the general functionality of the router. The IDS just looks for the attack signature specified by the AttackScenario and its parameters and hence the processing is much faster than if it were scanning for all possible attacks. Step 5. Based on the level of trust developed, an appropriate action is taken by the router. We use a heuristic to develop this level of trust and decide on the possible action. 13 Details of this process are described in Section 4.2. Step 6. If the attacker router RI doesn't respond to H's request, the request is sent to the host's edge router R2 (or some intermediate router that sees the majority of traffic between A and H) and Steps 3-5 are repeated. 3.2.1 Example Scenario The ping of death is a type of buffer overflow attack that uses malformed packets to overflow the buffer used to reassemble the packets at the receiver (More on ping of death in Section 5.4.1). In this section, we describe how our protocol will handle ping of death attack. In the attack scenario, attacker A is sending ping of death packets to host H. The IDS at H successfully detects the first such packet (Step 1). This is the suspicion state for the IDS and it sends the Start-Logging message to RI and R2 requesting them to log any traffic coming from A (Step 2). After the number of attack packets reaches a theshold, the JDS at H is convinced about the attack. The IDS sends the Verify-Attack message to RI, specifying the AttackScenario as pod and passing the theshold value as the parameter (Step 3). At RI, the EDS looks for the signature of ping of death attack in the network logs and if this exceeds the specified theshold, RI agrees that it is an attack (Step 4). An appropriate action is taken by RI according to the heuristic described in Section 4.2 (Step 5). If RI doesn't comply with the request, then the request is sent to R2 and the process of verifying the attack is repeated (Step 6). 3.3 Encryption Algorithm In order to prevent eavesdropping on the control messages, the messages are encrypted. This ensures that the messages are not modified in the network path and are not read by the attacker. Also, the identity of the victim is certified by the use of digital signatures. 14 M The starting message KM ASHA1 hash ofM e-M Message M encrypted with AES j^AES AESkey KH Private key of host H (RSA) KH Public key of host H (RSA) KR1 Private key of router RI (RSA) KR1 Public key of router RI (RSA) Table 3.1: List of Variables. Table 3.1 lists the variables used to describe the algorithm that follows. The cer-tifiable public keys of the routers and the host are well-advertised (e.g., using web pages, e-mail, or IRC). We next describe the processing of the messages at the sender (encryption) and the receiver (decryption). At Host H (before sending) 1. hu is generated from the message M . 2. Create a block of data "hM-M". 3. Encrypt the block using K A E S . We used K A E S to encrypt the block instead of KM for two reasons. Firstly, the attacker can never guess the key as it can be changed for every new message. Secondly, encryption using AES key is faster and since the message block forms a major chunk of data being sent, encryption using K A E S results in better performance. 4. Encrypt the K A E S with KM (to make it secret). 5. Sign the HM with KH to certify the identity of the sender H. 6. Create a block of data "signed data:encrypted AES key:encrypted block". This data is sent to the router RI. 15 At Router RI (on receipt) 1. Unpack the block to get "signed data", "encrypted AES key" and "encrypted block". 2. Decrypt the encrypted AES key using Km to get KAES. 3. Decrypt the encrypted block using KAES and split it to get KM and M. 4. Create a SHA1 hash hi'M of the message M . 5. Compare h!M with HM to make sure that the message is received in its original form and not changed by a man-in-the-middle attack. 6. Verify the signed hash with hiM, using K^. This certifies the identity of the sender and prevents the attacker from masquerading as the host. Al l messages from the victim to the edge routers are encrypted using this algorithm before sending (RI being replaced with the appropriate router, if needed). We defined our own encryption algorithm for the system, but any well-known en-cryption technique can be used. One such example is Transport Layer Security (TLS) protocol [10]. TLS provides the most common security services to TCP-based network connections in a way that the need for cryptographic expertise is minimized. OpenSSL [1] is a cyptographic library that can be used for the implementation of TLS. 3.4 Defense against possible protocol attacks In this section, we discuss the possible attacks that can be attempted against our system and prove that our system is not susceptible such attacks. Eavesdropping. An intruder may try to listen to the messages being passed between the victim and the routers. Encrypting the messages prevents this as the attacker has to know 16 the private key of the router(s) in order to decipher the messages. Also, since we can change the AES key with every message, it is impossible for the intruder to guess the key by doing some reverse engineering on the messages. Man-in-the-middle Attack. Man-in-the-middle is a type of attack where an in-truder gets between the sender and receiver of information and sniffs or modifies any in-formation being sent. The attacker may be able to obtain the information from the attack but will have to decrypt the information before it can be read. If the attacker is successful in modifying the message, verification of the SHA1 hash would fail at the receiver router and hence the message will be discarded. The verification makes sure that the message is received in its original form. Attack to overload the router. An attacker, posing as a victim, can send a Start-Logging message asking the router(s) to start logging traffic coming from a specific host. Sending this message intentionally without any confirmation of the attack later would lead to the router logging the messages indefinitely. We have used a time-based approach to solve this problem. The logs are flushed if the router doesn't receive confirmation of an attack in the form of Verify-Attack message within a particular time interval. Replay Attack. Even after the use of encryption, there is still the possibility of a message replay attack. The intruder can capture the packets passed between the victim and the router(s) and then replay them at a later time. The attacker cannot interpret the packets here, but can only replay them as a whole message in the original form. The time-bound garbage collection of the logs at the routers prevents any damage due to the replay of the Start-Logging message. Another possibility of attack is the replay of the Verify-Attack mes-sage that can be used to prove a false attack claim. Our protocol prevents this by discarding all logs after an action has been taken against the attacker. The old information in the re-played message does not match the new logs and is hence discarded. Hence, the attacker 17 can never be able to prove the false claim by replaying an old Verify-Attack message. Masquerading the victim. The attacker can pose as a victim by taking a false identity. Our protocol uses digital signatures to verify the identity of the victim sending the messages and hence rules out the possibility of foul play using a false identity. 3.5 Summary This chapter described the protocol for developing trust among various network elements, making the platform for our aumomated intrusion response system. We also described the encryption algorithm used by the protocol to prevent sniffing on the control messages. We discussed how the protocol is impregnable to some well-known attacks, showing the strength of the protocol. The trust model allows the network entities to collaborate in taking an effective response to network attacks, which forms the basis of our next chapter. The next chapter examines the possible responses to network attacks and defines a heuristic to select the appropriate response. 18 Chapter 4 Responses Intrusion detection by itself does not mitigate the risks of an intrusion. Risk mitigation only occurs through an effective and timely response. The goal of the response is to minimize damage to the infrastructure of an institution through containment of the intrusion, and restoration of systems. The majority of intrusion response systems (IRSs) react to attacks by generating reports or alarms. The responsibility to take an effective action is left to the system admin-istrators. This introduces a window of vulnerability between when an intrusion is detected and when action is taken to defend against the attack. Cohen [8] indicates that the success of an attack is dependent on the time gap between detection and response. If skilled attackers are given 10 hours after they are detected and before an action is taken against the attack, the attack will be successful 80% of the time. This increases to 95% at 20 hours and a delay of 30 hours means a certain win for the attacker. This study proves that a rapid automated response is critical for success against intrusions. Most of the automated response systems developed till date [31] concentrate on defense by reconfiguring the firewall to block in-coming traffic from malicious hosts. Other smarter solutions [4] isolate the offending host and block the traffic close to the attacker. 19 Our framework is flexible enough to incorporate any of these possible responses. The trust model provides an additional advantage of collaboration between various network elements so that the response is more effective. Since the model is proof-based, it gives us incentive to use the attack-back approach (Section 4.3) that can be an effective weapon against network attacks. 4.1 Overview Depending on the extent a router is convinced about an attack, it takes appropriate action ranging from no action in case of a failed proof to the extreme measure of an attack-back. We have also developed an algorithm based on heuristics to select the appropriate response to an attack. We describe this algorithm in the next section. For our system, we have considered network puzzles [41], blocking a part of the network, and attack-back as possible responses, but the framework is flexible enough to add other response types. 4.2 Heuristics for response selection An appropriate response for an intrusion attempt is determined by two conditions - firstly, how much do you trust the host who is claiming to be a victim and secondly, how suspicious are you of the alleged attacker. We use two parameters to form the heuristics, Level of Trust and Suspicion Rank, which correspond to the two conditions. • Level of Trust is determined by the extent to which the router is convinced from its own logs about the attack claimed by the victim. This value is incremented if the attack is successfully proved and reduced if the proof fails. The reduction in the Level of Trust on a failed proof would discourage false attack claims, possibly from an attacker masquerading as a victim. 20 TakeAction(A, H, Scenario) if (canBeProved(Scenario)) if (proveAttack(A, H)) LoT(H)++, SR(A)++ SelectResponse(LoT(H), SR(A)) else LoT(H)--else SelectResponse(LoT(H), SR(A)) SelectResponse(LoT, SR) trust: 1 : [LoT > LoTmax] 0 : [LoTmin < LoT < LoTmax] -1 : [LoT < LoTmin] suspicion: 1 : [SR > SRmax] 0 : [SRmin < S R < SRmax] -1 I [SR < SRmin] responseValue = trust + suspicion if (responseValue > 2) Attack-back(A) else if (responseValue == 1) BlockAIITraffic(A) else if (responseValue == 0) BlockTrafficToVictim(A, H) else if (responseValue == -1) UselPPuzzles(A) else if (responseValue < -2) NoAction(A) Figure 4.1: Pseudo code for response selection. • Suspicion Rank maintains a count of the intrusion attempts made by a particular at-tacker. It is high for an attacker with a higher number of attempts that are successfully 21 proven as attacks. The idea behind the heuristic is simple - if the attacker has a bad track record of being notorious and the victim has a good record of being truthful, then the response is harsher against the attacker. In other words, for a given attacker-victim pair, if the attacker has a high Suspicion Rank and the Level of Trust associated with the victim is high, then the attacker gets the maximum punishment. If both these values are low, then there is a possibility that no action is taken against the attacker. In order to be fair for a known attacker who wants to redeem himself, the value of Suspicion Rank is decremented based on time. The algorithm also discourages false attack claims by reducing the Level of Trust associated with the host making the false claim. The complete algorithm for selecting the appropriate response is given in Figure 4.1. If the attack is successfully proved, Level of Trust is raised for the host (i.e., the host becomes more trustworthy) and Suspicion Rank is raised for the attacker (i.e., the routers are more skeptical of the attacker). If the proof failed as a result of a false claim, the routers lose trust in the host making the claim resulting in lowering of the Level of Trust. Both Level of Trust and Suspicion Rank are categorized into three classes represented by numerical values (corresponding to the variables trust and suspicion). Response selection is a function of these two variables and correspond to the variable responseValue. The decision of selecting the right response is made based on responseValue. The values of the thresholds for Level of Trust (LoTmax and LoTmin) and Suspicion Rank (SR m a x and SRmin) are determined by the level of sensitivity acceptable to the router. For example, if the router wants to be "soft" in its responses, it can choose large values for LoTmax and LoTmin and large values for SRmaX and SRmin- This would shift the range band to higher values and hence more attacks have to be proved before a stronger action such as attack-back is taken. Increasing the range would result in more moderate 22 actions to be taken. As described in Section 3.2, logging at the routers can only start after reaching the suspicious state. So, in order to prove an attack, we effectively need more than one attack packet. There might be attacks that consist of just one packet, for example, a single-packet buffer overflow attack. Our system is able to handle such "non-provable" attacks based on existing values of the aforementioned parameters. Effectively, there is no change in the value of LoT and SR, but still these values can be used to decide the response. In real life, this is analogous to having more suspicion on a criminal which has a notorious criminal record. The punishment for such a criminal keeps increasing with each proved crime, which is similar to having a stronger response for each proved attack in our algorithm. 4.3 Attack-back Approach The best defense is a good offense. This well-known proverb is also the motivation for our idea. Blocking a part of the network can temporarily stop the intrusion, but the attacker doesn't lose anything. The idea behind our approach is to frustrate the intruder by attacking back. This approach will surely de-moralize the novice attackers and even the expert attackers will think twice before attacking again. Since the majority of Internet attacks are generated by novice attackers, the attack-back approach can be quite effective. Even if the attacker plans for a different attack from a different location, he will always have the mental block regarding the attack-back response from the target host. Other response strategies might be successful in stopping the attack, but forcing the attacker to think twice is a victory in itself for the intrusion defense system. We also understand that this approach can be exploited by attackers posing as vic-tims to launch attacks on innocent hosts. But our protocol strikes down this possibility as 23 the routers don't need to have a prior belief in any host and their action is solely based on their own view of the traffic. It also removes the possibility of a wrong assessment by the router because the attack has been observed at more than one place, i.e., the victim and the edge router(s). 4.4 Network Puzzles Client Puzzles [19] [6] [9] [20] are an effective countermeasure against denial-of-service at-tacks. When the server is under attack, the server becomes selective in accepting the con-nection requests. It sends a unique client puzzle to each client making a request. A client puzzle is a quickly computable cryptographic problem formulated using the time, a server secret and additional client request information [19]. The client is required to correctly solve the given puzzle in order to keep its connection with the server. Since a DoS attack relies on a large number of connection requests, this would effectively slow down the at-tacker as it would need huge amount of computational resources to solve a large number of puzzles. Effectively, in case of an attack, the server pushes back load to the attack source and prevents overloading of server resources. On the other hand, a legitimate user would experience only a small degradation in the connection time. Even this degradation is limited to the condition when there is an attack on the server because the client puzzles come into play only in case of an attack. TCP/IP puzzles [41] [42] pushes the mechanism of using puzzles to the TCP/IP layers. The reasoning for doing so lies in the fact that DoS attacks can be targeted at any layer and hence the client puzzles can be more effective when placed in common network and transport layers. For our implementation, we used the client puzzles at the application layer for simplicity and also because such puzzles can be invoked by our application only when required. 24 4.5 Blocking malicious network traffic The most widely acceptable solution to attacks in the Internet today is to block malicious network traffic by reconfiguring firewall rules or changing routing table entries after an attack has been detected. This is most effective if taken as close to the attacker as possible. In our system, ideally the attacker's edge router is responsible for this response. Based on the trust level developed, either only end-to-end traffic from the attacker to the victim is blocked or all traffic originating from the attacking host is blocked. The victims are effectively collaborating here to defend other possible victims of a particular attacker by blocking all traffic originating at the attacker. 4.6 Summary In this chapter, we examined the possible responses to network attacks, ranging from a moderate response of using network puzzles to extreme measure of attack-back. A heuristic algorithm is developed to select the appropriate response, based on "criminal" record of the attacker and "clean" record of the victim. If the attacker has a poor criminal record and the victim has a good record of being truthful, then the attacker faces a harsher response. The next chapter gives a detailed description of the implementation and design of the system described in the preceding chapters. 25 Chapter 5 Implementation We have developed a prototype of our automated intrusion response system. We tested the prototype against some well-known attacks and were successful in getting the desired results. We were successful in generating the appropriate response as per our response heuristic described earlier. The main objective of our prototype was to prove our concept of trust generation between the network entities and automate the selection of appropriate responses. We used NetSTAT [37] as the EDS for our prototype, but any state-based EOS would work for the system. 5.1 NetSTAT NetSTAT [37] is a network-based IDS developed by the Reliable Security Group at UCSB. It is based on the state transition analysis technique (STAT) [15]. The NetSTAT approach models network attacks as state transition diagrams, where states and transitions are char-acterized in a networked environment. There were several incentives to choose NetSTAT as the EDS for our system. Firstly, NetSTAT is state-based and hence it is easier to differentiate between the suspicion state and the conviction state. Secondly, NetSTAT allows offline de-26 tection of attacks from network logs. This is required by our system, since the edge routers work on the network logs offline to evaluate the proof of the attack. Thirdly, NetSTAT uses an intrusion detection language STATL [12] and hence the responses are easier to program. We just made minor changes to the STATL scenarios and responses without touching the NetSTAT Core. STATL is an extendible language that is used to define the domain-independent characteristics of the STAT technique. The attack scenarios and responses are defined in STATL to be processed by the STAT Core. The language can be extended to define the set of events specific to the particular domain or environment and also represent new predicates on those events. The STAT Core represents the runtime environment of the STATL language. The STAT Core implements the domain-independent characteristics of STATL, such as the con-cepts of state, transition, timer and event matching. At runtime STATL scenarios are matched against a stream of events by the STAT Core. A running instance of the STAT Core is dynamically extended to build a STAT-based application pertaining to a particular steam of events. For example, NetSTAT is one such STAT-based application that performs STAT analysis of the network traffic event streams. In order to have a scenario processed by the STAT Core, it is compiled into a shared library called the Scenario Plugin. In addition, each Language Extension Module used by the scenario must be compiled into another shared library. Both STATL scenarios and lan-guage extensions are translated into C++ code and compiled into libraries by the STAT development tools. Figure 5.1 shows a sample attack scenario for the ping of death attack written in STATL. t c p i p is a language extension module developed to represent functions specific to TCP/IP traffic. States are used to represent the snapshots of the system at dif-ferent timestamps during an attack, starting from initial safe state s 0 to final compromised 27 use tcpip; scenario tcpip_pod { s t r i n g CLASSIFICATION_NAME = "Ping of Death Attack"; s t r i n g SOURCE_NODEADDRESS' = "unknown"; s t r i n g TARGET_NODEADDRESS = "unknown"; t r a n s i t i o n pod (sO->Pod) nonconsuming { [IPFrag ipfrag] : ((((ipfrag.header.ip_off &- IP_OFFMASK) « 3) + ipfrag.header.ip_len) > 65535) { SOURCE_NODEADDRESS = ipfrag.header.getSrcStr(); TARGET_NODEADDRE S S = ipfrag.header.getDstStr(); } } i n i t i a l state sO { } state Pod { { log("Ping of Death Attack Detected: %s -> %s", S OURC E_NODEADDRE S S.c_str() , TARGET_NODEADDRESS.C_str()); } } Figure 5.1: Sample Attack Scenario in STATL. state Pod. A transition defines the change of states (sO to Pod) and is associated with an assertion which represents the condition for transition. 28 5.2 Prototype Figure 5.2 shows the various components of our prototype implementation. The NetSTAT installation monitors the incoming traffic for any intrusive behavior. Once an attack is detected by NetSTAT, it passes the attack-specific parameters to the Message Generator. The Message Generator is responsible for creation of various messages according to the state of the attack sequence. The START_LOGGING message is used to request the edge router(s) to start logging the network traffic and is generated when the initial suspicion state is reached. The VERIFY-ATTACK message is generated when the final compromised state is reached and is sent as a proof of an attack along with the parameters describing the attack. The Encryption Engine encrypts the message using the algorithm described in Section 3.3. This encrypted message is passed to the router(s). On the router end, the received message is decrypted by the Decryption Engine using the algorithm described in Section 3.3. The decrypted message is passed to the Mes-sage Correlator. The Message Correlator is the heart of our system. This component is responsible for determining the truth of the attack claim by parsing the router's own logs in view of the message received. The Trust Level Detector is a sub-component of the Message Correlator that determines the trust level according to heuristics described in Section 4.2. Based on this level of trust, the Message Correlator specifies the action to be taken to the Response Engine, which in turn takes the action. 5.3 Testbed The code is developed in Java vl.4 using BouncyCastle vl.25 libraries for encryption. We configure Linux boxes as routers with forwarding enabled by default. The host and the attacker are put on different private networks, making sure that they have only one edge 29 Incoming i -Traffic ^ NetSTAT Message Generator • Encryption Engine Response Engine Jk Response y Action Decryption Engine Figure 5.2: Block Diagram. 30 Internet Router R1 (poto) Router R2 (rhabo •ttacker A (ardmore) Figure 5.3: Testbed Setup. router each. The edge routers are their only connection to the Internet. The setup is given in Figure 5.3. NetSTAT is installed on arran, rhabo and poto. It is in active state on the host a r r an and passive on edge routers rhabo and poto. Just for the proof-of-concept, we intentionally created a vulnerabilities in the at-tacker machine ardmore that can be exploited by the edge routers in case of attack-back. We use the i p t a b l e s module as the firewall to dynamically block the traffic coming from a malicious host, i p t a b l e s is used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel. It is possible to add rules to block traffic specific to a source and destination or block all traffic originating at a particular host. 31 5.4 Experience with the prototype We experimented with several well-known attacks by generating the attacks in our testbed. Though the vulnerability exploited by these attacks were fixed in the Linux version we used, the attacks could still be detected. Our system is limited by the performance of the IDS for detecting the attacks and we assume that the IDS would update itself periodically with the signatures of the recently discovered attacks. We experimented with limited number of attack scenarios, but still that is sufficient to prove our concept as there is no change in the protocol between different scenarios. 5.4.1 Ping of Death attack IP packets as per RFC-791 [29] can be up to 65535 (2 1 6 -1) octets long, which includes the header length (typically 20 octets if no IP options are specified). Packets that are bigger than the maximum size the underlying layer can handle (the MTU) are fragmented into smaller packets, which are then reassembled by the receiver. For Ethernet style devices, the MTU is typically 1500. An ICMP ECHO request "lives" inside the IP packet, consisting of eight octets of ICMP header information (RFC-792 [25]) followed by the number of data octets in the "ping" request. Hence the maximum allowable size of the data area is 65535 - 20 - 8 = 65507 octets. It is possible to send an illegal echo packet with more than 65507 octets of data due to the way the fragmentation is performed. The fragmentation relies on an offset value in each fragment to determine where the individual fragment goes upon reassembly. Thus on the last fragment, it is possible to combine a valid offset with a suitable fragment size such that (offset + size) > 65535. Since typical machines don't process the packet until they have all fragments and have tried to reassemble it, it is possible to overflow the 16 bit internal variables, which can lead to system crashes, reboots, kernel dumps and the like. NetSTAT successfully detected the ping of death attack packets. On receipt of the 32 first such packet, the host informed the edge routers to start logging and after some threshold number of packets were received, it informed the routers to take appropriate action passing them the scenario as ping of death. The attacker's edge router first blocked the traffic of the attacker for a period of time. We repeated the attack after that time period and this time the router attacked back as defined by our heuristic algorithm. 5.4.2 SYN Flood attack TCP SYN Flooding causes servers to quit responding to requests to open new connections with clients - a denial of service attack. The TCP SYN Flooding attack takes advantage of the way the TCP protocol establishes a new connection. Each time a client attempts to open a connection with a server, the connection parameters are stored at the server in a connection queue. Because the information stored takes up memory and operating system resources, only a limited number of in-progress connections are allowed, typically less than ten (more commonly six or less). When the server receives an acknowledgement from the client, the server considers the connection open, and the queue resources are freed for accepting another new connection. The attacking software generates spoofed packets that appear to be valid new con-nections to the server. These spoofed packets enter the queue, but the connection is never completed (i.e., there is no final ACK sent by the client) - leaving these new connections in the queue until they time out. Only a few of these packets need to be sent to the server, making this attack simple to carry out. The system under attack quits responding to new connections until some time after the attack stops. Detection of the first half-open connection is the trigger for the start logging mes-sage and after the number of such half-open connections from a particular host reaches a threshold value, our system responds back with the proper action. Since our protocol keeps 33 track of the "criminal" record of an attacker and the "clean" record of a particular host, we could test the algorithm collectively with different attack types. 5.5 Summary This chapter described the prototype implementation of our system. We also described the state-based IDS, NetSTAT, used by our prototype. We examined the prototype against two well-known network attacks, the ping of death attack and the SYN flood attack. Our prototype was successful in stopping these attacks and convinced the routers in taking ap-propriate action after the trust was developed for the victim host. The testing was done in a controlled environment by setting up a closed testbed described in the chapter. 34 Chapter 6 Related Work In this chapter, we describe previous research that relates closely to our work. The heart of our system is the trust development process. This process forms the first step towards an effective automated response system. Unfortunately, we could not find much work in the area of trust development. Most of the response systems currently in the market use blocking a part of the network as a possible response; very few have tried to explore the idea of using the attack back approach, though there is a lot of discussion in the research community about the social, moral and legal aspects of using this approach. 6.1 Trust Development To the best of our knowledge, not much work has been done to develop trust among vari-ous network entities that are involved in a collaborative intrusion response. Most solutions take the assumption of trusting one or more of such entities. Routers are considered to be trusted in all such solutions. Katerina et el. [4] describes a mechanism in which a victim can request the relay closest to the attack source to block traffic from the attack source. The mechanism uses a filter management scheme called AITF [5] to guarantee secure commu-35 nication between the victim and the relay (the attacker's edge router). Upon determining that it is under attack, the victim sends a traffic blocking request to its gateway. The victim's gateway, in turn, sends similar request to the attacker's gateway. If the attacker's gateway fails to comply with the request, then all the filtering of the attacker's traffic is done by victim's gateway. The victim's gateway contacts another border router close to the attacker and this process continues until a router along the attack path responds positively to the request. If no such router agrees, then the victim's gateway locally blocks all traffic coming from the attacker's gateway to the victim. As mentioned in Section 3.2, our protocol uses the similar technique of choosing a router as close to the attacker as possible. AITF uses a three-way handshake to verify that the request is real and prevents eavesdropping by a malicious node. But it fails if the malicious node is located on the communication path, resulting in a man-in-the-middle attack. We believe that this is a serious enough problem considering the widespread and open nature of the Internet. This problem does not exist in our system because the encryption algorithm ensures that the message is read only by the node it is intended for. Also, AITF assumes that the claim made by the victim is always true and if the attacker's edge router doesn't comply to the request, it loses the connectivity to the victim. Thus, AITF is vulnerable to fraudulent attack claims. In our protocol, the edge routers prevent this by verifying the claim locally using their own view of the network logs. Mahajan et al. propose a similar mechanism called Pushback [16] [21] to automate the response mechanism. The response is concentrated on deploying filters to block or rate control the attack traffic. The victim sends a request to its edge router, which in turn can send similar requests to upstream routers. In Pushback, the request is propagated hop-by-hop through the network. As a result, Pushback does not need to verify the authenticity of the filtering requests as only adjacent routers pass the pushback request. However, this 36 mechanism puts a lot of overhead on the Internet. This is the reason we used the AITF approach of message passing instead of hop-by-hop propagation done in Pushback. 6.2 Attack Back With the rapid growth of Internet technology, security has become a critical issue in mod-ern computer systems. The constant increase of attacks against networks and their resources causes a necessity to protect these valuable assets. In fact, security is a constant race be-tween the attackers and the defenders. The attackers are getting smarter day by day and hence the need for smarter security solutions always remains. The time has come to shift the focus of Internet security beyond passive firewall protection to a more active approach. One such active solution is to take offensive action by counter-attacking the attacker. A lot of attack-back attempts have been made in the past, but this approach has always been at the center of a big debate [27] [26]. In this section, we examine some of these attempts and also explore some of the counterattacking products available in the market. We also get a feel of the hot debate over this approach in the networking world. 6.2.1 Historical Attempts There have been several attack-back incidents, some of which are documented. One of the first such incidents occured in September 1998 when a hactivist organization, called The Electronic Distruption Theatre, launched a browser-based denial-of-service attack on the Pentagon [32]. The Pentagon retaliated by using offensive applets to shut down the attacking browsers. The offensive action was quite effective in stopping the attack, but the Pentagon was severely criticized for the action. The security experts behind the whole offensive action had broken too many laws to enumerate - including a military prime direc-tive, "posse comitatus," which forbids the military from taking unilateral actions within the 37 U.S. and against U.S. citizens. The net result was that both the attacker and the victim were held accountable for breaking the law, the attacker for launching the initial DoS attack and the victim for using the back-hacking. In January 2000, another such incident happened during the World Trade Organiza-tion (WTO) summit meeting in Seattle [28]. An online activist group, called the Electohip-pies (E-hippies), launched a denial-of-service attack on the WTO Web site. But the WTO's Web-hosting service spotted the attack and traced it back to the E-hippies server in U.K. The attack was repelled by redirecting the flood of page download requests back to the origin server. The E-hippies server was disabled for several hours, though the E-hippies coalition never publicly acknowledged that the attack had been turned back on its own server. But the next day, a notice appeared on the E-hippies site apologizing that "people have had problems getting through" to its site. Conxion, the San Jose hosting service that reversed the attack on the WTO server, recognized the attack was coming from a single IP address belonging to the E-hippies server. Conxion was so proud of having given the attackers a dose of their own medicine that it issued a press release about the incident. However, the reaction to the offensive strike in the corporate sector was mixed. The most recent incident happened in December 2004 when Lycos Europe released a screensaver "Make Love not Spam" [7] that bombarded spam websites with data to try to increase the cost of running such sites. The free screensaver launches a Distributed Denial of Service (DDoS) attack against spammer's machines. Lycos Europe claims that they have taken steps to ensure the sites aren't actually brought down, but rather simply slowed. The end result was that some spam sites were completely overwhelmed by the traffic directed their way and Lycos was criticized for encouraging vigilantism. The screenserver became quite popular with around 800,000 visits. The company claims that their campaign was successful against 100,000 spam sites slowing their capacity by 90% [2]. 38 There are several other incidents of using counterattack as a possible solution, how-ever many such incidents are not documented. Over the years, nations have been using organised attacks to bring down the cyber infrastructure of their adversaries. While the rash of cybervandalism against big corporate names has always made headlines, that's only part of the story. Governments and their surrogates are using the Internet to harrass political opponents and unfriendly neighbors, to go after trade secrets, and to prepare for outright warfare. The first such reported attack was a highly organised attack by Indonesia in Jan-uary 1999 against the virtual country domains of East Timor [33]. Burma's military junta is blamed for targeting the "Happy 99" E-mail virus at opponents who use the Internet to ad-vance their cause [35]. In the summer of 1999, China began to launch cyber attacks aimed at altering official Taiwanese government websites, after Taiwan's president Lee Teng-hui voiced support for the island's independence [34]. Attacks on the sites of the Falun Gong spiritual movement based in New York have been traced back to China's Secret Police in Beijing [35]. The intention of all these attacks might be another topic of debate, but the sole purpose of these attacks was to defend by taking offensive action, though the actions have been taken in preemption rather than retaliation. With limited information available, we infer that none of the above attack-back solutions provided a proof to support the response. Hence the individuals or companies involved in such action have been widely criticized. The advantage our system has over their approach is the development of trust before attacking back. To the best of our knowledge, we are the first to use the proof-based attack-back approach as a response to an attack. In our system, the edge routers are acting as "witness" to the attack against the victim and hence provide a proof supporting the attack-back action. 39 6.2.2 Current Counter-Attack Products Since the cyber laws in many countries at in the initial stages of development, the software vendors developing products with counterattack capabilities have to be diplomatic in their approach. Publicly they do not recommend a counterstrike using their product for liability reasons. But since the attack-back capability can be a big "eye candy" in attracting potential customers, privately they take pride in their product having significant retaliation capabil-ities. This trend can be expected to continue till specific laws are made to cover all legal aspects of this approach. FutureVision of Sante Fe New Mexico has developed a security system called Blitzkrieg that is designed to retaliate against an attacker [18]. Blitzkrieg was developed by Laurence F. Wood, a quantum physics theorist and chief scientist for the Network Waf-fen Und Munistionsfabriken Group (transated as Network Weapons Munitions Factories, subsidiary of FutureVision). The software installs on a central server and then sits in the background watching network activity, building a profile of normal data activity and then monitoring for subtle changes that may reveal an external attack on the network. If hacking activity is discovered, then Blitzkrieg goes to work, the military-strength version waging war on the attacker by launching a virus-like offensive against their machine in an attempt to destroy data. A less offensive version developed for the corporate sector uses DoS to overload the attacker's machine, without the use of the data-destroying viruses. Blitzkrieg is implemented within a Microsoft BackOffice NT Server environment. Like a virus, the Blitzkrieg virtual machine will attack and subsume the NT server operating system when first powered up after an installation. This infection assimilates all network nodes and becomes an invisible addition to the operating system. The encrypted multichannel com-munications are established with the parent Lightning server and all assimilated nodes, forming the essential components of an intelligent network collective. The virtual machine 40 is rendered 100 per cent fault-immune and invulnerable to attack. The result, according to its developer Wood, is the first ever virus-like collective digital life form, in the shape of Blitzkrieg [18]. Zombie Zapper is a free, open source tool that can tell a zombie system flooding packets to stop flooding, effectively stopping the distributed DoS attack. Instead of return-ing the DoS attack back to the closest zombie, it impersonates the master of the zombie and sends an order to those slaves to stop sending DoS packets [27]. The slaves can also be or-dered to send DoS packets back to the attack source. The tool was developed by Bindview, an Internet security vendor based in Houston, and according to them, it was downloaded more than 7000 times just in the initial two weeks of its launch. Two startup companies, Mazu Networks in Boston and Asta Networks in Seattle, have proprietary autodetection software aimed to stop a DoS attack at the ISP level. The idea is to move the battle front to the edge router of the ISP, as close to the source of attack as possible. The Mazu/Asta approach is to detect and contain a DoS attack before its leaves an ISP and impacts a destination corporate server [36]. ISPs have a large capacity infrastruc-ture to handle the DoS attacks without having any major effect of their own performance. For their approach to be successful, ISPs first need to have the permission and automated ability to analyze the traffic going to the person and detect an attack in time to stop it from getting to the person. But in order to reduce the problem of false positives, the Mazu/Asta approach needs to distinguish between attacks and normal traffic based on packet character-istics. One classic example of a DoS attack signature is numerous packets simultaneously heading to one server but there are legitimate packet streams such as streaming media that also have similar characteristics. Their approach seems similar to ours in trying to move the response capability near the attacker, but what kind of communication happens betwen the victim and ISP is not very clear. 41 Some Linux products, as well as FreeBSD, ship tools that can be used to counterat-tack such as Trojan horses (hidden executable programs) and port scanners [17]. However these tools can also be very dangerous if misconfigured or directed at an innocent party. 6.2.3 Social and legal issues of attacking back There is always a thin line between self-defense and retaliation. As a legal principle, you are authorized to punch someone in the nose if they kick you. Al l the solutions with offensive capabilities developed till date fall in this thin line between what is legal and what is illegal. There has been a long debate on whether the vendors of these products should be made liable to the damage caused to the attacker, similar to the way attacker is responsible for the damage caused to the attacked host. Vikas et al. [17] differentiates between reactive forward-looking self defense and aggressive backward-looking countermeasures. Backward-looking approach tries to jus-tify retaliation in terms of punishing the culprit and restoring the moral balance. But it is normally associated with revenge and hence considered illegal. The forward-looking ap-proach, on the other hand, justifies retaliation as a measure of preventing further crime and hence bringing something good to the society. This approach is associated with self-defense and prevention. But the question still remains that to what extent can a defense system go in order to prevent the attack from happening. And this is the gray area with no simple solution. "If they're functioning solely within their own system to take preventative action during an attack, there should not be a problem. Rejecting mail is a nor-mal system administration function. Now if they were inserting their own mail and sending that back to the e-hippie site, you may have a problem." - Lt. Commander Chris Malinowski, head of the New York City Police De-42 partment's computer crime unit, referring the WTO attack-back incident [27]. The biggest technical issue associated with the attack-back approach is the correct identification of the attack source. Considering that most smart hackers launch their attacks through hijacked IP addresses, an effective solution is needed to identify the attacker (or atleast identify the closest router) to make sure that countermeasures are taken against the real attacker and not some innocent zombie. There was an case in which a system admin-istrator at a private company hacked back. Unfortunately, the IP address was fake and the administrator slammed an innocent target, which, in turn, traced the DOS attack back to the system administrator and alerted his superiors. The system administrator lost his job [27]. Caution is the key in using this counterattack approach. "My fear scenario is that U.S. government agencies [involved in informa-tion warfare] will build in react capabilities. A smart hacker will launch a [denial-of-service] attack using those agencies' IP addresses, and they all start attacking each other. The worst case is Amazon shoots eBay who shoots the IRS who shoots Cisco who shoots..." - John Pescatore, an analyst at Gartner Group Inc. in Stamford, Conn [28]. To address this problem, researchers have proposed anti-spoofing mechanisms that provide each packet with an identifier [13][43]. These identifiers can be used by the IDS to identify the attack source. Research is still going on this area and we are confident that the problem of address spoofing can be effectively solved. Then there is the issue of liability. Major corporates can never risk to expose them-selves to civil and criminal charges by allowing counterattacks. In the eyes of the law, if you're a victim, doing it back to the bad guy doesn't make it any less of a crime. But the law is not really clear about the conditions when you would be held liable. 43 "Fighting back is a bad idea. I wouldn't do it. If it's illegal for them to attack you, then it's also illegal to attack them. And then we have this whole problem of crossing state and national boundaries. I don't even want to go there." - A l Potter, manager of network security labs at ICSA Labs in Carlisle, Pa [27]. The law is not clear about the conditions when you would be held liable. Also, cyber laws are lacking in many countries. Since the Internet community is like a "global village", the issue of inconsistent cyber laws would always remain. Another practical question still unanswered is the liability of the compromised hosts or zombies. The issue is whether a computer owner has a duty of care to the ultimate victim(s), but it is still an open issue. The other face of the coin tells a different story. The corporate networks and security managers are becoming increasingly frustrated with Internet crime - cybercops can't keep up with it. Time is a critical issue in taking action against the offenders. Cracking comes at a hefty cost to the corporate sector, with financial losses due to computer crime costing 273 organizations nearly $266 million in 2000 in the US alone [27]. The list of people and companies using the attack-back approach, openly or in disguise, is increasing every day since the law is too slow and not much of a deterrance. "My experience, I'm sad to say, is that unless you are a very large orga-nization - a multibillion-dollar company that is publicly traded and frequently in the media - whatever help is forthcoming from agencies like the FBI will certainly take a long time. But you, acting as your own security analyst, can accomplish a great deal more than can, say, the FBI." - Greggory Peck, a security analyst at a Fortune 500 company and editor of the "" newsletter [27]. 44 "I'd actually hope people get tired of things and take a stand." - Capt. John Jarrett, computer crime investigator with the Show Low Police Department in northeastern Arizona, would like to see more organizations get involved in actively protecting their assets [27]. Another argument in favour of the attack back approach is the economy of force [40]. Currently, there is no fear factor stopping the intruders. By striking back at attackers, their cost of the attack goes up and they have to devote more resources for their own defense. Counterstikes would not only demoralize the attacker, but effectively they would be a strong deterrent to other potential intruders. The debate will continue for years to come. New counterattacking tools will con-tinue to be used legally or illegally till more and more intruders are put to justice. More understanding is required to evaluate the advantages of the attack-back approach in terms of its success in stopping the attacks and its economical advantage. Applying commom law to distinguish an illegal counter attack from a valid self-defense is needed. 45 Chapter 7 Limitations and Extentions While we have been successful with our prototype, we recognize a number of limitations and potential challenges facing those building a complete automated intrusion response system. In this section we discuss these and discuss the extensions we plan to add as part of future work. 7.1 Limitations The biggest dependency of our system is on the efficiency of the underlying EDS. We haven't developed any new EDS for our system but instead we have concentrated on the trust-based response action after the IDS has detected the intrusion. Another limitation is that the system is effective only in case of attacks detected by network-based EDS. It is not easy for the router to locally reproduce the conditions prevalent at a particular host in order to determine the validity of the attack claim. But this can be regarded as a special case of a "non-provable" attack and can be handled by our system as described in Section 4.2. Our system is successful against any repetitive DoS attacks, where the flow contin-ues even after the edge router has started logging. In other words, there should be enough 46 attack packets to distinguish between the suspicion state and the confirmation state. An example of such an attack is the SYN flood attack targeted to overflow the connection table buffer by sending a large number of connection requests with no confirmation ACK. In case of attacks other than DoS, the attack sequence should have at least one intermediate state between the initial safe state and the final compromised state that can act as the suspicion state. Al l other attacks with just two states can be handled as "non-provable" attacks by our system. The effectiveness of our system against distributed DoS (DDoS) attacks is also questionable. Such attacks are normally carried out by means of several compromised hosts and the real attacker remains anonymous. In the current design, our system will attack the compromised hosts as it cannot determine the real identity of the attacker. The liability of the compromised hosts in being part of an attack is an open issue in itself. We assume that the DDoS attack would be detected at the first place when the real attacker is trying to compromise a host to launch attacks and the attack would not be allowed to escalate. A better solution to the problem would be a mechanism to determine the real source of the attack, so that approriate action is taken against the real attackers and not the zombies. This is another area of research in itself and is beyond the scope of this thesis. 7.2 Extensions 7.2.1 Anomaly-based Response Our prototype can successfully handle all known attacks whose signatures are available to the IDS. As part of a future extension, we plan to use the same concept for novel attacks whose signatures are not yet known. We have explored this possibility by addition of a universally trusted third party as shown in Figure 7.1. This party could be an organization 47 Trusted Third Party Figure 7.1: Anomaly based Response. or a set of hosts using some machine learning approaches to detect any abnormal network flows [22]. In this case, the victim would send its logs to the trusted host. The trusted host would determine if the given claim is a valid attack and then generate a token for the at-tacker's edge router. The edge router would take appropriate action based on this token. If the trusted party is not fully convinced by the victim's claim, it can ask the edge router to send its logs concerning the particular victim. The AI component of the IDS and the trusted party is currently being investigated. 7.2.2 Use of multiple IDSs In our current prototype, we have just used a network-based IDS. In case of some attack scenarios, the use of multiple IDSs could be more informative in detecting the attack. There is a possibility of using a combination of host-based and network-based IDS, but our system is limited in the use of host-based IDS as mentioned in Section 7.1. But our concept of "non-provable" attacks can come handy in incorporating the host-based IDS into our system. 48 We take an attack scenario to describe our concept. An attack can have the following sequence: (i) the attacker tries to do port scan on a particular host; (ii) after detecting an open SSH port, he tries to login into the machine by the use of some password cracker; (iii) he successfully logs in (by means of breaking the password or by simply stealing the password) and then adds some backdoor entries into the system. Step (i) and (ii) can be detected by a network-based EDS, while step (iii) can only be detected by a host-based EDS (a network-based IDS cannot infer the encrypted SSH connection). Steps (i) and (ii) are only suspicion states, as even a valid user might make multiple password attempts. Confirmation of the attack can only be made by the host-based EDS which can detect the attacker installing the backdoor entries or doing anything malicious. The edge router(s) can only log steps (i) and (ii) and has to rely on the host for final confirmation. This makes it a case of a "non-provable" attack and can be handled as described in Section 4.2. 7.2.3 Collaboration among different hosts Another idea worth exploring is the sharing of the heuristic parameters, Level of Trust and Suspicion Rank (Section 4.2), among various hosts. Since these parameters are maintained at the routers instead of the hosts, they can be shared easily. The "criminal" record of the attacker would be effectively shared while determining the truth of the attack claims by different hosts. An attack successfully proved by one host can effectively help other hosts to prove the attack, if the source of the attack is the same. The host can also request the router to log all traffic originating from the attack source irrespective of the destination. This could help other hosts to prove the attacks including some otherwise "non-provable" attacks. The feasibility of this idea needs to be explored in more detail. 49 Chapter 8 Conclusions With the increase in number of cyber attacks, security has become a critical component in the design of systems and networks today. New smarter tools are available every day ready to hack into systems, stealing important information or making the systems and networks useless for extended periods of time. In fact, it is like an arms race. Attackers are getting smarter, so there is always a need for smarter and better security solutions. We don't forsee any end to this race as the systems can never be made perfect, free of software bugs. In this thesis, we presented a trust-based model for an automated response to net-work intrusions. If network elements can collaborate, then they can be more effective against intrusions. We have developed a protocol to create trust among various network elements, so that they can coordinate to take appropriate action against the attack. The pro-tocol is fool-proof against false attack claims and prevents an attacker, posing as a victim, from using the protocol to generate attacks against innocent hosts. The encryption algo-rithm prevents any eveasdropping on the protocol messages being passed in the network. This is one of the first attempts to use an proof-based attack-back approach as a response for an attack. If this approach is harnessed in a controlled manner, it can be an effective weapon against the intruders. Our protocol provides this control by developing 50 a trust model before any extreme measure can be taken. We defined a heuristic algorithm for selecting the appropriate response based on the "criminal" record of the attacker and "clean" record of the victim. We used a limited set of responses as part of the algorithm, but the framework is quite flexible allowing for any new response type to be added. We also developed a prototype implementation in order to prove our concept and successfully tested it against some well known attacks. The tests demonstrate the strength of our protocol in providing an effective response mechanism to network attacks. 51 Bibliography [1] [2] [3] 2004 E-Crime Watch™ Suervey shows Significant Increase in Electronic Crimes. CSO Magazine, May 2004. [4] Katerina Argyraki and David R. Cheriton. Loose Source Routing as a Mechanism for Traffic Policies. In FDNA '04: Proceedings of the ACM S1GCOMM workshop on Future directions in network architecture, pages 57-64. ACM Press, 2004. [5] Katerina Argyraki and David R. Cheriton. Protecting Public-Access Sites Against DDoS Attacks. Technical report, Stanford University, May 2004. [6] Tuomas Aura, Pekka Nikander, and Jussipekka Leiwo. DOS-Resistant Authentication with Client Puzzles. Lecture Notes in Computer Science, 2133:170+, 2001. [7] BBC News World Edition. Anti-spam plan overwhelms sites, December 2004. [8] F.B. Cohen. Simulating Cyber Attacks, Defenses, and Consequences, May 1999. 52 [9] D. Dean and A. Stubblefield. Using Client Puzzles to Protect TLS. In Proceedings of the 10th USENIX Security Symposium, 2001. [10] T. Dierks and C. Allen. RFC 2246: The TLS Protocol Version 1.0. IETF RFC Publi-cation, January 1999. [11] Disha Gupta and Hu XiouDong. Self Learning Intrusion Detection Systems, March 2004. Unpublished report, KTH, Sweden. [12] S.T. Eckmann, G. Vigna, and R.A. Kemmerer. STATL: An Attack Language for State-based Intrusion Detection. Journal of Computer Security, 10(l/2):71-104, 2002. [13] Michael T. Goodrich. Efficient Packet Marking for Large-Scale IP Traceback. In CCS '02: Proceedings of the 9th ACM Conference on Computer and Communications Security, pages 117-126, Washington D.C, USA, 2002. [14] I. Hamadeh and G. Kesidis. Packet Marking for Traceback of Illegal Content Distri-bution. In Proceedings of International Conference on Cross-Media Service Delivery (CMSD), Santorini, Greece, May 2003. [15] K. Ilgun, R.A. Kemmerer, and P.A. Porras. State Transition Analysis: A Rule-Based Intrusion Detection System. IEEE Transactions on Software Engineering, 21(3), March 1995. [16] John Ioannidis and Steven M. Bellovin. Implementing Pushback: Router-Based De-fense Against DDoS Attacks. In NDSS, San Diego, USA, Fenruary 2002. [17] Vikas Jayaswal, William Yurcik, and David Doss. Internet Hack Back: Counter-Attacks as Self-Defense or Vigilantism. In Proceedings of the IEEE International Symposium on Technology and Society (ISTAS), Raleigh, USA, June 2002. 53 [18] Clarence A. Robinson Jr. Make My Day Server Throws Gauntlet to Network Hackers. Signal Magazine, May 1998. [19] Ari Juels and John Brainard. Client Puzzles: A Cryptographic Countermeasure Against Connection Depletion Attacks. In Proceedings ofNDSS '99 (Networks and Distributed Security Systems), pages 151-165, February 1999. [20] Jussipekka Leiwo, Tuomas Aura, and Pekka Nikander. Towards Network Denial of Service Resistant Protocols. In Proceedings of the IFIP TC11 Fifteenth Annual Work-ing Conference on Information Security for Global Information Infrastructures, pages 301-310, Deventer, The Netherlands, The Netherlands, 2000. Kluwer, B.V. [21] Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John Ioannidis, Vern Paxson, and Scott Shenker. Controlling High Bandwidth Aggregates in the Network. Computer Communication Review, 32(3):62-73, 2002. [22] Matthew V. Mahoney. Network Traffic Anomaly Detection Based on Packet Bytes. In SAC '03: Proc. of the 2003 ACM symposium on Applied computing, pages 346-350. ACM Press, 2003. [23] Ludovic M'e and C'edric Michel. Intrusion detection: A bibliography. Technical Report SSIR-2001-01, Sup'elec, Rennes, France, September 2001. [24] Phil Porras. STAT - A State Transition Analysis Tool For Intrusion Detection. Techni-cal report, University of California at Santa Barbara, Santa Barbara, CA, USA, 1993. [25] J. Postel. RFC 792: Internet Control Message Protocol. IETF RFC Publication, September 1981. [26] Deborah Radcliff. Can You Hack Back? NetworkWorld, June 2000. 54 [27] Deborah Radcliff. Hack Back. NetworkWorld, May 2000. [28] Deborah Radcliff. Should You Strike Back? ComputerWorld, November 2000. [29] RFC791. RFC 791: Internet Protocol. IETF RFC Publication, September 1981. [30] Martin Roesch. Snort - Lightweight Intrusion Detection for Networks. In LISA '99: Proceedings of the 13th USENIX Conference on System Administration, pages 229-238, Seattle, Washington, 1999. [31] D. Schnackenberg, K. Djahandari, and D. Sterne. Infrastructure for Intrusion Detec-tion and Response. In Proceedings of the DARPA Information Survivability Confer-ence and Exposition (DISCEX), Hilton Head, USA, January 2000. [32] Winn Schwartau. Can You Counter-Attack Hackers? NetworkWorld, April 2000. [33] Walter G. Sharp Sr. Cyberspace and the Use of Force. Aegis Research Corporation, 1999. [34] John J. Stanton. Rules of Cyber War Baffle U.S. Government Agencies. National Defense, February 2000. [35] Warren P. Strobel. A Glimpse of Cyberwarfare. U.S. News and World Report, March 2000. [36] R. Tadjer. Detect, Deflect, Destroy. InternetWeek, November 2000. [37] G. Vigna and R. Kemmerer. NetSTAT: A Network-based Intrusion Detection Ap-proach. In Proceedings of the 14th Annual Computer Security Application Confer-ence, Scottsdale, Arizona, December 1998. [38] Beverly Waite. Malicious Code Attacks Had $13.2 Billion Economic Impact in 2001. Computer Economics, January 2002. 55 [39] Xinyuan Wang, Douglas S. Reeves, S. Felix Wu, and Jim Yuill. Sleepy Watermark Tracing: An Active Network-Based Intrusion Response Framework. In Proc. of the 16th international conference on Information security: Trusted information, pages 369-384, Paris, France, 2001. [40] Donald J. Welch, Nathan Buchheit, and Anthony Ruocco. Strike Back: Offensive Actions in Information Warfare. In NSPW '99: Proceedings of the 1999 Workshop on New Security Paradigms, pages 47-52, Caledon Hills, Ontario, Canada, 2000. [41] Wu-chang Feng. The case for TCP/IP puzzles. In FDNA '03: Proc. of the ACM SIGCOMM workshop on Future directions in network architecture, pages 322-327, Karlsruhe, Germany, 2003. A C M Press. [42] Wu-chang Feng, Ed Kaiser, Wu-chi Feng, and Antoine Luu. The Design and Imple-mentation of Network Puzzles. In Proceedings of INFOCOM 2005, Miami, USA, March 2005. [43] A. Yaar, A. Perrig, and D. Song. Pi: A Path Identification Mechanism to Defend against DDoS Attacks. In Proceedings of the IEEE Symposium on Security and Pri-vacy, Oakland, USA, May 2003. [44] William Yurcik. Information Warfare Survivability: Is the Best Defense a Good Of-fense. In Proceedings of the 5th Annual Ethics and Technology Conference, Loyola University Chicago, USA, July 2000. 56 


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items