[ Pobierz całość w formacie PDF ]
Implementing and testing a virus throttle
1
Jamie Twycross, Matthew M. Williamson
Trusted Systems Laboratory
HP Laboratories Bristol
HPL-2003-103
May 21
st
, 2003*
E-mail:
jamie@milieu3.net
,
matthew.williamson@hp.com
In this paper we build on previous theoretical work and describe the
implementation and testing of a
virus throttle
- a program, based on
a new approach, that is able to substantially reduce the spread of
and hence damage caused by mobile code such as worms and
viruses. Our approach is different from current, signature-based
anti-virus paradigms in that it identifies potential viruses based on
their network behaviour and, instead of preventing such progr ams
from entering a system, seeks to prevent them from leaving. The
results presented here show that such an approach is effective in
stopping the spread of a real worm, W32/Nimda-D, in under a
second, as well as several different configurations of a testworm.
* Internal Accession Date Only Approved for External Publication
1
Proceedings 12
th
USENIX Security Symposium, 4-8
th
August 2003, Washington, DC, USA
ª Copyright Hewlett-Packard Company 2003
Implementing and testing a virus throttle
Jamie Twycross
jamie@milieu3.net
Matthew M. Williamson
matthew.williamson@hp.com
Hewlett-Packard Labs, Bristol, U.K.
May 13, 2003
Abstract
of certain classes of worms. Our approach, virus
throttling [27], [30], is based on the observation that
under normal activity a machine will make fairly few
outgoing connections to new machines, but instead
is more likely to regularly connect to the same set
of machines. This is in contrast to the fundamen-
tal behaviour of a rapidly spreading worm, which
will attempt many outgoing connections to new ma-
chines. The idea behind the virus throttle is to put
a rate limit on connections to new machines such
that normal trac remains unaected but suspect
trac is slowed, quickly detected and stopped.
In this paper we build on previous theoretical work
and describe the implementation and testing of a
virus throttle - a program, based on a new approach,
that is able to substantially reduce the spread of and
hence damage caused by mobile code such as worms
and viruses. Our approach is dierent from cur-
rent, signature-based anti-virus paradigms in that
it identies potential viruses based on their network
behaviour and, instead of preventing such programs
from entering a system, seeks to prevent them from
leaving. The results presented here show that such
an approach is eective in stopping the spread of
a real worm, W32/Nimda-D, in under a second,
as well as several dierent congurations of a test
worm.
Our approach is dierent from current approaches
in three key ways: it focuses on the network be-
haviour of the virus and prevents certain types of
behaviour, in our case the attempted creation of a
large number of outgoing connections per second.
It is also unique in that, instead of stopping mobile
code from entering a system, it restricts the code
from leaving. Lastly, because connections over the
allowed rate are delayed and not dropped, the sys-
tem is tolerant to false positives and is therefore
robust.
1
Introduction
CNET dubbed 2001 the \Year of the Worm" [14]
and 2002 has only seemed to conrm this, with high-
speed mobile code forming the majority of entries
in the top ten of most infectious programs. In-
deed, on the weekend this paper was being com-
pleted, the W32/SQLSlam-A worm [22] infected
what is currently estimated at 75,000 machines in
30 minutes [16] and caused major network disrup-
tion. Finding eective ways to prevent such activity
is a high priority.
In this paper we give a detailed description of an
implementation of the virus throttle and our exper-
imental setup, and present the results of a number of
tests. These tests show that the virus throttle is able
to very quickly detect and prevent worms spreading
from an infected machine. For example, the throttle
is able to stop the W32/Nimda-D worm [21] in un-
der one second. Furthermore, since the throttle pre-
vents subsequent infection, the eect on the global
spread of the virus will depend on how widely it is
deployed. Our results also show that when 75% of
machines are installed with the throttle, the global
The work we present here provides just that - an
extremely eective way of halting the propagation
spread of both real and constructed worms is sub-
stantially reduced. Throttled machines do not con-
tribute any network trac in spite of being infected,
signicantly reducing the amount of network trac
produced by a virus.
are vulnerable to infection, and will then attempt
to exploit any target machines found. If successful,
the exploit will allow the mobile code to transfer a
copy of itself to the target machine, which will itself
begin its own scan/exploit/transfer cycle.
The next section, Section 2, paints the background
against which our work stands, briey reviewing
what mobile code is and how it propagates and dis-
cussing current approaches to limiting this propaga-
tion. It then goes on to outline the foundations on
which our perspective is based, and briey reviews
related work. Section 3 describes in detail the de-
sign 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.
2.2
Current approaches
Current approaches to virus protection involve pre-
venting a virus from entering a system, predom-
inantly through signature-based detection meth-
ods [8]. These methods concentrate on the physi-
cal characteristics of the virus i.e. its program code,
and use parts of this code to create a unique sig-
nature of the virus. Programs entering the sys-
tem are compared against this signature and dis-
carded if they match. In terms of the three-stage
scan/exploit/transfer cycle described above, current
approaches can be seen as focusing on the transfer
stage.
2
Background
While this approach has up to now been fairly eec-
tive in protecting systems it has several limitations
which, as the number of virus samples increases,
decrease its eectiveness. It is fundamentally a re-
active and case-by-case approach in that a new sig-
nature 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 fur-
ther in the interim. Furthermore, comtemporary
viruses are using techniques such as polymorphism
and memory-residency to sidestep signature detec-
tion entirely.
In this section we oer 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.
2.1
Mobile code
We are interested in a class of software broadly
known as mobile code [10]. For our purposes we
dene mobile code pragmatically as any program
that is able to transfer itself from system to system
with little or no human intervention. Many exam-
ples 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 dierent media, for exam-
ple, removable storage, since we are particularly in-
terested in propagation across networks, we will re-
strict our discussion to code that spreads across this
medium. Although technical dierence do exist be-
tween virus and worms [6, 7], in what follows we will
use these terms and mobile code interchangeable.
2.3
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 dierent
concepts and also allows a vast amount of literature
on complex and adaptive systems from elds con-
cerned 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 mech-
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
anistic details of its construction on which the cur-
rent approach described in the last section is based.
rithm to detect attacks, inspecting network packets
for predened sequences of data, for example, shell-
code or unusual HTTP requests, in contrast to our
behaviour-based approach.
The distinction between mechanism and behaviour
can lead to some simple but potentially powerful
conclusions. While a virus is able to instantiate
an eective spreading mechanism in an extremely
large number of ways, each requiring a separate sig-
nature, the number of ways in which a virus can
behave to spread eectively is perhaps much more
limited. This is especially the case with the class
of high-speed worms which are becoming increas-
ingly prevalent and which, due to their high-speed
nature, need to scan a large number of hosts per sec-
ond. Behaviour is a much more powerful discrimina-
tor than that employed in current, mechanistically-
orientated signature-based methods, as it poten-
tially allows the automatic identication and hence
removal of an entire class of worms.
3
The virus throttle
After outlining the context of our work in the last
section, we now go on to give a detailed explana-
tion of the design and implementation of a virus
throttle, of which an initial description and proof-
of-concept based on theory and simulation was pre-
sented in [27]. The main focus of this section will
be on a TCP implemention of the virus throttle,
although we have also tested UDP, SMTP and Ex-
change throttles with similar designs.
Considering behaviour also leads to some less obvi-
ous insights, one being that it could be more produc-
tive 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 rst sight appear inef-
fective, recent work by Williamson and Leveille [29]
and other work discussed in the next section indi-
cates that it can be extremely eectual in preventing
the spread of viruses across networks.
3.1
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 be-
low allows for multiple source IP addresses. Connec-
tions 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,
identied by a destination IP address. The tar-
get machine then sends back a SYN-ACK packet,
which the source machine replies to with an ACK
packet [17]. By controlling the number of SYN pack-
ets transmitted from the source machine we can con-
trol the number of connections it is able to make.
2.4
Related work
Our approach is related to the \behaviour blocking"
of Messmer [15] which seeks to specify policies den-
ing normal or acceptable behaviour for applications.
If an application breaches such a policy it is reported
to an administrator. The approach we take diers 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 be-
nign response used in an intrusion detection applica-
tion is given by Somayaji and Forrest [20], although
their application implements this response in rela-
tion 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 algo-
A note should be made about the relationship be-
tween connection attempts and SYN packets. At
the application layer, a connection is usually initi-
ated by opening a socket [23]. This results in the
sending of an initial TCP SYN packet and, if no re-
sponse is received within a certain time, the sending
of further, identical, SYN packets. 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 sev-
eral SYN packets. In our implementation we make
no attempt to dierentiate initial SYN packets from
retries, and count the retries as separate connection
attempts.
ond as they want to the 5 most recently connected-
to machines. Any further connection attempts will
be delayed for at least a second, and then attempted.
Delaying connections rather than simply dropping
them is important as such a benign response [20] al-
lows the virus throttle a certain amount of leeway in
its conception of normal behaviour and a response
that, if incorrectly targeted at legitimate connection
attempts, will introduce an often imperceptible de-
lay in the connection, instead of prohibiting it en-
tirely.
A machine will establish many such connections in
the course of normal usage, for example when re-
questing a web page or the delivery of email. Many
worms also use such connections when scanning in
order to establish the existence and conguration
of remote machines, with high-speed worms such as
W32/Nimda-D [21] or CodeRed [4] initiating large
numbers of connections to dierent targets per sec-
ond. The virus throttle rests on the observation that
the patterns of connections due to normal usage are
very dierent from the patterns of connections cre-
ated by such mobile code. Our research has sug-
gested 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].
request
i
delay
queue
working set
n = 5
h
Queue
length
detector
not−new
new
add
g
a
b
c
d
e
f
update
rate limiter
clock
The virus throttle parses all outgoing packets from
a machine for TCP SYN packets. The destination
address of an intercepted SYN packet is then com-
pared against a list of destination addresses of ma-
chines 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 desti-
nation 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.e. it
holds less than 5 addresses, the destination address
is added to the working set and the connection is
once again allowed to proceed immediately. 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.
process
Figure 1: A schema of the control ow of the virus
throttle
In [27], it was argued that if the rate of connections
to new targets is high, as is the case with many
worms, the delay queue would rapidly grow result-
ing in attempted connections being severely delayed.
When implementing the throttle, we took this idea
further and introduced an upper limit to the size of
the delay queue which, once reached, will disallow
all further connection requests by the host. Thus
the throttle can be said to behave benignly within
certain limits. From observation of the normal be-
haviour of a range of users we saw that the delay
queue rarely grew bigger than a handful of packets
and concluded that the size of the delay queue could
oer an indication of the presence of a worm on the
host: large delay queue sizes would almost certainly
indicate an application behaving in a suspect man-
ner. In our throttle we set this upper limit on the
delay queue size to 100 packets.
Once every second the delay queue is processed
and the SYN packet at its head and any other
SYN packets with the same destination address are
popped and sent, allowing the establishment of the
requested connection. The destination address of
this packet is also added to the working set, the
oldest member of which is discarded if the working
set is full. If the delay queue is empty at processing
time and the working set is full, the oldest member
of working set is also discarded, allowing for the po-
tential establishment of one connection per second
to a target not recently connected to.
Lastly, as mentioned previously, we have also im-
plemented UDP, SMTP and Exchange versions of
the throttle. The UDP throttle works in exactly
the same way as its TCP counterpart except that
instead of parsing outgoing network trac for TCP
SYN packets, it looks for outgoing UDP packets,
This design, summarised schematically in Figure 1,
allows hosts to create as many connections per sec-
[ Pobierz całość w formacie PDF ]

zanotowane.pl

doc.pisz.pl

pdf.pisz.pl

mirabelkowy.keep.pl