To limit propagation a rate-limiter or virus throttle is described that does not affect normal traffic, but quickly slows and stops viral traffic. The paper includes an analysis of normal emailing behaviour, and details of the throttle design. In addition an imple-mentation is described and tested with real viruses, showing that the approach is practical. Documents: Advanced Search Include Citations. It then goes on to outline the foundations on which our perspective is based, and briefly reviews related work.
Section 3 describes in detail the design and implementation of our virus throttle, the performance of which, along with our experimental setup, we describe in Section 4. Concluding remarks are made in Section 5. Background In this section we offer a brief review of mobile code and current approaches to limiting its spread. We then go on to introduce the conceptual framework upon which our work rests, and end the section with a summary of related work. Mobile code We are interested in a class of software broadly known as mobile code [ 10 ].
For our purposes we define mobile code pragmatically as any program that is able to transfer itself from system to system with little or no human intervention. Many examples of such mobile code can be found in real life, the most common of which are the many viruses and worms that are becoming an increasingly prevalent feature of the Internet [ 5 , 14 ]. While mobile code can propagate through different media, for example, removable storage, since we are particularly interested in propagation across networks , we will restrict our discussion to code that spreads across this medium.
Although technical difference do exist between virus and worms [ 6 , 7 ], in what follows we will use these terms and mobile code interchangeable. An archetypal piece of mobile code can in general be seen as repeating a cycle composed of several distinct stages.
The code will perform some form of scan to attempt to locate target machines which are vulnerable to infection, and will then attempt to exploit any target machines found. Current approaches Current approaches to virus protection involve preventing a virus from entering a system, predominantly through signature-based detection methods [ 8 ].
These methods concentrate on the physical characteristics of the virus i. Programs entering the system are compared against this signature and discarded if they match.
While this approach has up to now been fairly effective in protecting systems it has several limitations which, as the number of virus samples increases, decrease its effectiveness.
It is fundamentally a reactive and case-by-case approach in that a new signature needs to be developed for each new virus or variant as it appears. Signature development is usually performed by skilled humans who are only able to produce a certain number of signatures in a given time.
As the number of viruses increases, the time between initial detection and release of a signature increases, allowing a virus to spread further in the interim. Furthermore, comtemporary viruses are using techniques such as polymorphism and memory-residency to sidestep signature detection entirely. Agents and complex systems An alternative and fruitful approach can be gained by viewing the mobile code as an autonomous agent acting within a complex system [ 19 ].
Such a paradigm shift leads to an emphasis on different concepts and also allows a vast amount of literature on complex and adaptive systems from fields concerned with these entities to be drawn upon. For example, when viewed as an agent the question of how the agent behaves within the environment it inhabits becomes as important as the purely mechanistic details of its construction on which the current approach described in the last section is based.
The distinction between mechanism and behaviour can lead to some simple but potentially powerful conclusions. While a virus is able to instantiate an effective spreading mechanism in an extremely large number of ways, each requiring a separate signature, the number of ways in which a virus can behave to spread effectively is perhaps much more limited.
This is especially the case with the class of high-speed worms which are becoming increasingly prevalent and which, due to their high-speed nature, need to scan a large number of hosts per second.
Behaviour is a much more powerful discriminator than that employed in current, mechanistically-orientated signature-based methods, as it potentially allows the automatic identification and hence removal of an entire class of worms. Considering behaviour also leads to some less obvious insights, one being that it could be more productive to focus on preventing viruses leaving a system, as opposed to stopping them entering, the strategy taken by current methods.
While such a seemingly altruistic approach may at first sight appear ineffective, recent work by Williamson and Leveille [ 29 ] and other work discussed in the next section indicates that it can be extremely effectual in preventing the spread of viruses across networks.
If an application breaches such a policy it is reported to an administrator. The approach we take differs in that it is able to automatically respond to abnormal behaviour, taking the administrator out of the loop in this respect. The benign facet of this response is particularly important as it makes the throttle more tolerant to false positives. Another example of a benign response used in an intrusion detection application is given by Somayaji and Forrest [ 20 ], although their application implements this response in relation to abnormal sequences of syscalls.
Bruschi and Rosti [ 2 ] discuss various ways in which hosts can be prevented from participating in network attacks and describe a tool, AngeL [ 3 ], which can be used to prevent systems from participating in such attacks. AngeL, however, relies on a signature-based algorithm to detect attacks, inspecting network packets for predefined sequences of data, for example, shellcode or unusual HTTP requests, in contrast to our behaviour-based approach. The virus throttle After outlining the context of our work in the last section, we now go on to give a detailed explanation of the design and implementation of a virus throttle, of which an initial description and proof-of-concept based on theory and simulation was presented in [ 27 ].
Design The virus throttle is a program that limits the rate of outgoing connections to new machines that a host is able to make in a given time interval. For the purposes of simplicity in this section we will assume that the host has one unique address - its source IP address, although the implementation described below allows for multiple source IP addresses.
Connections to a remote machine are established through what is known as a three-way-handshake in which the initiator of the connection, the source machine, sends a TCP SYN packet to the target machine, identified by a destination IP address. By controlling the number of SYN packets transmitted from the source machine we can control the number of connections it is able to make.
A note should be made about the relationship between connection attempts and SYN packets. At the application layer, a connection is usually initiated by opening a socket [ 23 ]. This continues up to a maximum time, the socket timeout, when the socket will give up and return control to the application.
Thus, in attempting to open a single connection a machine may actually transmit several SYN packets. In our implementation we make no attempt to differentiate initial SYN packets from retries, and count the retries as separate connection attempts. A machine will establish many such connections in the course of normal usage, for example when requesting a web page or the delivery of email.
The virus throttle rests on the observation that the patterns of connections due to normal usage are very different from the patterns of connections created by such mobile code.
Our research has suggested that under normal usage often no more than one connection to a target not recently connected to is made per second, and that the majority of connections are made to destination addresses that have recently been connected to [ 27 ]. The destination address of an intercepted SYN packet is then compared against a list of destination addresses of machines to which connections have previously been made, which we term the working set. The working set can hold up to 5 such addresses.
If the destination address is in this working set the connection is allowed immediately. If the addresses is not in the working set and the working set is not full i. If none of these two conditions are met, the SYN packet is added to what we term the delay queue and is not transmitted immediately.
In addition an implementation is described and tested with real viruses, showing that the approach is practical. Technical Reports. HP Labs. Tandem Technical Reports.
0コメント