[attachment=11085]
Chapter 1
INTRODUCTION
1.1 INTRODUCTION TO PROJECT
The Internet is not a safe place. Unsecured hosts can expect to be compromised within minutes of connecting to the Internet and even well-protected hosts may be crippled with denial-of-service (DoS) attacks. However, while such threats to host systems are widely understood, it is less well appreciated that the network infrastructure itself is subject to constant attack as well. Indeed, through combinations of social engineering and weak passwords, attackers have seized control over thousands of Internet routers . Even more troubling is Mike Lynn’s controversial presentation at the 2005 Black Hat Briefings, which demonstrated how Cisco routers can be compromised via simple software vulnerabilities. Once a router has been compromised in such a fashion, an attacker may interpose on the traffic stream and manipulate it maliciously to attack others—selectively dropping, modifying, or rerouting packets.
Several researchers have developed distributed protocols to detect such traffic manipulations, typically by validating that traffic transmitted by one router is received unmodified by another . However, all of these schemes—including our own—struggle in interpreting the absence of traffic. While a packet that has been modified in transit represents clear evidence of tampering, a missing packet is inherently ambiguous: it may have been explicitly blocked by a compromised router or it may have been dropped benignly due to network congestion. In fact, modern routers routinely drop packets due to bursts in traffic that exceed their buffering capacities, and the widely used Transmission Control Protocol (TCP) is designed to cause such losses as part of its normal congestion control behavior. Thus, existing traffic validation systems must inevitably produce false positives for benign events and/or produce false negatives by failing to report real malicious packet dropping.
In this project, we develop a compromised router detection protocol that dynamically infers the precise number of congestive packet losses that will occur. Once the congestion ambiguity is removed, subsequent packet losses can be safely attributed to malicious actions. We believe our protocol is the first to automatically predict congestion in a systematic manner and that it is necessary for making any such network fault detection practical. In the remainder of this paper, we briefly survey the related background material, evaluate options for inferring congestion, and then present the assumptions, specification, and a formal description of a protocol that achieves these goals. We have evaluated our protocol in a small experimental network and demonstrate that it is capable of accurately resolving extremely small and fine-grained attacks.
1.2 PROJECT OVERVIEW
we consider the problem of detecting whether a compromised router is maliciously manipulating its stream of packets. In particular, we are concerned with a simple yet effective attack in which a router selectively drops packets destined for some victim. Unfortunately, it is quite challenging to attribute a missing packet to a malicious action because normal network congestion can produce the same effect. Modern networks routinely drop packets when the load temporarily exceeds their buffering capacities. Previous detection protocols have tried to address this problem with a user-defined threshold: too many dropped packets imply malicious intent. However, this heuristic is fundamentally unsound; setting this threshold is, at best, an art and will certainly create
unnecessary false positives or mask highly focused attacks. We have designed, developed, and implemented a compromised router detection protocol that dynamically infers, based on measured traffic rates and buffer sizes, the number of congestive packet losses that will occur. Once the ambiguity from congestion is removed, subsequent packet losses can be attributed to malicious actions. We have tested our protocol in Emulab and have studied its effectiveness in differentiating attacks from legitimate network behavior.
Chapter 2
SYSTEM ANALYSIS
2.1 Existing System
The earliest work on fault-tolerant forwarding is due to Perlman who developed a robust routing system based on source routing, digitally signed route-setup packets, and reserved buffers. While groundbreaking, Perlman’s work required significant commitments of router resources and high levels of network participation to detect anomalies. Since then, a variety of researchers have proposed lighter weight protocols for actively probing the network to test whether packets are forwarded in a manner consistent with the advertised global topology Conversely, the1997 WATCHERS system detects disruptive routers passively via a distributed monitoring algorithm that detects deviations from a conservation of flow” invariant . However, work on WATCHERS was abandoned, in part due to limitations in its distributed detection protocol, its overhead, and the problem of ambiguity stemming from congestion To perform all these processes manually is a very tedious process for a trained expert and, thus, an automated differential counting system that helps in saving time and money is highly desirable.
2.2 Proposed System
We have designed, developed, and implemented a compromised router detection protocol that dynamically infers, based on measured traffic rates and buffer sizes, the number of congestive packet losses that will occur.
Once the ambiguity from congestion is removed, subsequent packet losses can be attributed to malicious actions. We have tested our protocol in Emulab and have studied its effectiveness in differentiating attacks from legitimate network behavior
2.3 OVERVIEW OF MODULES
Total project has divided into 5 Modules. They are
1. GUI Design
2. Protocol Utilization
3. Packet Transmission Details
4. CLP Calculation using Bayesian Theorem
5. Identifying Normal Packet using Threshold value.
Module 1: GUI Design
Using swing concepts in Java, we allocate area for the statistical characterization for the transmitted packets. So that the design is consistent and efficient for the user to interact with the software.
Module 2rotocol Utilization
Packets are transmitted through the use of networking protocols. So that ports are distinguished by different colors. I consider two types of protocols called TCP and UDP protocols. Here I use the acknowleged TCP protocol to transmit the packets.
Module 3 TD (Packet Transmission Details)
Packet scores are generated based on the protocol values, the size of the packet and the destination.
Module 4: CLP Calculation using Bayesian Theorem
The Scores of each packet is generated and the probability calculation is performed. The attribute value of each packet is compared with the base line profile value and sorting of packets occurred.
Module 5: Identifying NP using Threshold Value
In this module, the threshold value is calculated and is compared with the attribute value of each packet. Discarding of packets takes place in comparison with the threshold value.
Chapter 3
ALGORITHM/TECHNIQUES USED
3.1 RED Algorithm Description
RED monitors the average queue size, based on an exponential weighted moving average: where the actual queue size and weight for a low-pass filter. RED uses three more parameters in minimum threshold, Maximum, Maximum threshold. Using, RED dynamically computes a dropping probability in two steps for each packet it receives. First, it computes an interim probability, Further; the RED algorithm tracks the number of packets, since the last dropped packet. The final dropping probability, p, is specified to increase slowly as increases.
3.2 Methodology And Specifications
There are inherently two threats posed by a compromised router. The attacker may subvert the network control plane (e.g., by manipulating the routing protocol into false route updates) or may subvert the network data plane and forward individual packets incorrectly. The first set of attacks have seen the widest interest and the most activity—largely due to their catastrophic potential. By violating the routing protocol itself, an attacker may cause large portions of the network to become inoperable. Thus, there have been a variety of efforts to impart authenticity and consistency guarantees on route update messages with varying levels of cost and protection We do not consider this class of attacks in this paper. Instead, we have focused on the less well-appreciated threat of an attacker subverting the packet forwarding process on a compromised router. Such an attack presents a wide set of opportunities including DoS, surveillance, man-in-the-middle attacks, replay and insertion attacks, and so on. Moreover, most of these attacks can be trivially implemented via the existing command shell languages in commodity routers. The earliest work on fault-tolerant forwarding is due to Perlman who developed a robust routing system based on source routing, digitally signed route-setup packets, and reserved buffers.
While groundbreaking, Perlman’s work required significant commitments of router resources and high levels of network participation to detect anomalies. Since then, a variety of researchers have proposed lighter weight protocols for actively probing the network to test whether packets are forwarded in a manner consistent with the advertised global topology Conversely, the 1997 WATCHERS system detects disruptive routers passively via a distributed monitoring algorithm that detects deviations from a “conservation of flow” invariant However, work on WATCHERS was abandoned, in part due to limitations in its distributed detection protocol, its overhead, and the problem of ambiguity stemming from congestion . Finally, our own work broke the problem into three
pieces: a traffic validation mechanism, a distributed detection protocol, and a rerouting countermeasure. In we focused on the detection protocol, provided a formal framework for evaluating the accuracy and precision of any such protocol, and described several practical protocols that allow scalable implementations.
However, we also assumed that the problem of congestion ambiguity could be solved, without providing a solution. This paper presents a protocol that removes this assumption. INFERRING CONGESTIVE LOSS In building a traffic validation protocol, it is necessary to explicitly resolve the ambiguity around packet losses. Should the absence of a given packet be seen as malicious or benign? In practice,