defending against hitlist worms using network address space...

Computer Networks 51 (2007) 3471–3490

www.elsevier.com/locate/comnet

Defending against hitlist worms using network addressspace randomization q

S. Antonatos b, P. Akritidis b, E.P. Markatos b, K.G. Anagnostakis a,*

a Systems and Security Department, Institute for Infocomm Research, 21 Heng Mui Keng Terrace, Singapore 119613, Singaporeb Institute of Computer Science, Foundation for Research and Technology, Hellas P.O. Box 1385 Heraklio, GR-711-10, Greece

Received 20 September 2006; received in revised form 7 February 2007; accepted 15 February 2007Available online 4 March 2007

Responsible Editor: L. Salgarelli

Abstract

Worms are self-replicating malicious programs that represent a major security threat for the Internet, as they can infectand damage a large number of vulnerable hosts at timescales where human responses are unlikely to be effective. Sophis-ticated worms that use precomputed hitlists of vulnerable targets are especially hard to contain, since they are harder todetect, and spread at rates where even automated defenses may not be able to react in a timely fashion.

This paper examines a new proactive defense mechanism called Network Address Space Randomization (NASR) whoseobjective is to harden networks specifically against hitlist worms. The idea behind NASR is that hitlist information couldbe rendered stale if nodes are forced to frequently change their IP addresses. NASR limits or slows down hitlist worms andforces them to exhibit features that make them easier to contain at the perimeter. We explore the design space for NASRand present a prototype implementation as well as experiments examining the effectiveness and limitations of the approach.� 2007 Elsevier B.V. All rights reserved.

Keywords: Worm defense; Randomization; Hitlist worms

1. Introduction

Worms are widely regarded to be a major secu-rity threat facing the Internet today. Incidents suchas Code Red [1,2] and Slammer [3] have clearly

1389-1286/$ - see front matter � 2007 Elsevier B.V. All rights reserved

doi:10.1016/j.comnet.2007.02.006

q Parts of this work has been previously published in theProceedings of the ACM Workshop on Rapid Malcode(WORM), 2005, and the Proceedings of IFIP Conference onCommunications and Multimedia Security (CMS), 2006.

* Corresponding author. Tel.: +65 9482 2340.E-mail addresses: [email protected] (S. Antonatos),

[email protected] (P. Akritidis), [email protected] (E.P.Markatos), [email protected] (K.G. Anagnostakis).

demonstrated that worms can infect tens of thou-sands of hosts in less than half an hour, a timescalewhere human intervention is unlikely to be feasible.More recent research studies have estimated thatworms can infect one million hosts in less thantwo seconds [4–6]. Unlike most of the currentlyknown worms that spread by targeting randomhosts, these extremely fast worms rely on predeter-mined lists of vulnerable targets, called hitlists, inorder to spread efficiently.

The threat of worms and the speed at which theycan spread have motivated research in automatedworm defense mechanisms. For instance, several

.

mailto:[email protected]

mailto: [email protected]



3472 S. Antonatos et al. / Computer Networks 51 (2007) 3471–3490

recent studies have focused on detecting scanningworms [7–12]. These techniques detect scanningactivity and either block or throttle further connec-tion attempts. These techniques are unlikely to beeffective against hitlist worms, given that hitlistworms do not exhibit the failed-connection featurethat scan detection techniques are looking for. Toimprove the effectiveness of worm detection, severaldistributed early-warning systems have been pro-posed [13–16]. The goal of these systems is to aggre-gate and analyze information on scanning or otherindications of worm activity from different sites.The accuracy of these systems is improved as theyhave a more ‘‘global’’ picture of suspicious activity.However, these systems are usually slower than localdetectors, as they require data collection and corre-lation among different sites. Thus, both reactivemechanisms and cooperative detection techniquesare unlikely to be able to react to an extremely fasthitlist worm in a timely fashion.

Observing this gap in the worm defense space, weconsider the question of whether it is possible todevelop defenses specifically against hitlist worms.We start by looking at likely strategies for buildinghitlists and examine how effective these strategiescan be. We observe that hitlists tend to decay natu-rally for various reasons, as hosts disconnect andapplications are abnormally terminated. A rapidlydecaying hitlist is likely to decrease the spread rateof a worm. It may also increase the number of unsuc-cessful connections it initiates and may thus increasethe exposure of the worm to scan-detection methods.

Starting with this observation, we ask whether itis possible to intentionally accelerate hitlist decay,and propose a specific technique for this purposecalled network address space randomization (NASR).This technique is primarily inspired by similar effortsfor security at the host-level [17–23]. It is also similarin principle to the ‘‘IP hopping’’ mechanism in theAPOD architecture [24], BBN’s DYNAT [25] andSandia’s DYNAT [26] systems, all three designedto confuse targeted attacks by dynamically changingnetwork addresses. In this paper, we examine thesame basic idea in the context of defending againsthitlist worms. In its simplest form, NASR can beimplemented by adapting dynamic network addressallocation services such as DHCP [27]1 to force more

1 Another known address allocation service is bootp [28], butit allocates addresses semi-permanently, without any mechanismfor renewing the allocation and is thus not usable for ourpurposes.

frequent address changes. This simple approach maybe able to protect enabled networks against hitlistworms, and, if deployed at a large enough scale,may be able to significantly hamper their spread.

We must emphasize that, like most (if not all)other worm containment proposals, NASR is onlya partial solution to the worm containment prob-lem. Where applicable, our approach succeeds inlimiting the extent or slowing down the rate of aworm infection. However, the mechanism is specificto IP-hitlist worms, and may be less effective againstDNS hitlists (we discuss such issues in Section 5).Furthermore, it cannot always completely squashhitlist-based worm epidemics, and it cannot be useduniversally. Nevertheless, being able to slow downthe fastest known propagation mechanism is likelyto be valuable, as it may allow more time for otherreactive defenses to kick in. Furthermore, we notethat our analysis does not invalidate the worst-caseestimates provided in previous work [4], nor is ourgoal to play down the threat posed by such worms.The purpose of this paper is to help examinewhether NASR is worth considering as part of abroader worm defense portfolio.

In the rest of this paper, we present NASR inmore detail and examine issues of applicability,effectiveness and implementation cost.

2. Background

For the purpose of placing our work in context,we first give a brief overview of what is knownabout worms, with some emphasis on hitlist worms,and present a summary of proposals for defendingagainst worms and how they relate to hitlist wormswhich are the focus of this paper.

2.1. Worms

Computer viruses have been studied extensivelyover the last couple of decades. Cohen was the firstto define and describe computer viruses in theirpresent form. In [29], he gave a theoretical basisfor the spread of computer viruses. The strong anal-ogy between biological and computer viruses ledKephart et al. [30] to investigate the propagationof computer viruses based on epidemiological mod-els. They extend the standard epidemiological modelby placing it on a directed graph, and use a combi-nation of analysis and simulation to study its behav-ior. They conclude that if the rate at which defensemechanisms detect and remove viruses is sufficiently

S. Antonatos et al. / Computer Networks 51 (2007) 3471–3490 3473

high relative to the rate at which viruses spread, it ispossible to prevent widespread virus propagation.

The Code Red worm [1] was analyzed extensivelyin [31]. The authors conclude that even though epi-demic models can be used to study the behaviorof Internet worms, they are not accurate enoughbecause they cannot capture some specific proper-ties of the environment these operate in: the effectof human countermeasures against worm spreading(i.e., patching, filtering, disconnecting, etc.) and theslowing down of the worm infection rate due to theimpact of worm on Internet traffic and infrastruc-ture. They derive a new general Internet wormmodel called two-factor worm model, which theythen validate in simulations that match the observedCode Red data available to them. Their analysisseems also to be independently supported by thedata on Code Red propagation in [2].

A similar analysis on the SQL ‘‘Slammer’’ (orSapphire) worm [32] can be found in [33]. Sapphire,the fastest worm today, was able to infect more than70,000 victim computers in less than 15 min.

The Blaster/Welchia epidemic is an interestingexample of a ‘‘vigilante’’ worm (Welchia) causingmore trouble than the original outbreak (Blaster).A ‘‘vigilante’’ worm attempts to clean-up anotherworm by using the same vulnerability. However,the very notion of ‘‘vigilante’’ worms is rendereduseless if worms immediately disable the vulnerabil-ity after compromising a machine.

The Witty worm [34] is of interest for several rea-sons. First, it was the first widely propagated Inter-net worm to carry a destructive payload. Second,Witty was started in an organized manner with anorder of magnitude more ground-zero hosts thanany previous worm and also began to spread asearly as only one day after the vulnerability waspublicized, which is an indication that the wormauthors had already prepared all the worm infra-structure, including the ground-zero hosts and thereplication mechanisms, and were only waiting foran exploit to become available in order to launchthe worm. Finally, Witty spread through a popula-tion almost an order of magnitude smaller than thatof previous worms, showing that a hitlist is notrequired even for targeting small populations.

All these worms use (random) scanning to deter-mine their victims, by using a random number gen-erator to select addresses from the entire IP addressspace. Although some worms chose their next targetuniformly among all the available IP addresses,other worms seemed to prefer local addresses over

distant ones, so as to spread the worm to as manylocal computers as possible. Once inside an organi-zation, these worms make sure that they will infectseveral of its computers before trying to infect anyoutside hosts.

2.2. Hitlists

Instead of attempting to infect random targets, aworm could first determine a large vulnerablepopulation before it starts spreading. The wormcreator can assemble a list of potentially vulnerablemachines prior to releasing the worm, for example,through a slow port scan. The list of known vulner-able hosts is called a hitlist. Using hitlists, worms donot need to waste time scanning for potential targetsduring the time of the attack and will not generateas many unsuccessful connections as when scanningrandomly. This allows them to spread much faster,and it also makes them less visible to scan-basedworm detection tools. A hitlist can be either a col-lection of IP addresses, a set of DNS names or aset of Distributed Hash Table identities (for infect-ing DHT systems irrelevantly of the networkinfrastructure).

Hitlist worms have not been observed in the wild,perhaps because the co-evolution of worms anddefenses has not reached that stage yet: they arenot currently necessary for a successful worm epi-demic, since neither scan-blocking nor distributeddetection systems are widely deployed yet. However,hitlists are certainly feasible today and wormcreators are very likely to use them in the future.

Hitlist worms have attracted some attentionlately, as they are easy to model off-line [5,4]. In thiscontext, several hitlist construction methods havebeen outlined: random scanning, DNS searches,web crawling, public surveys and indexes, as wellas monitoring of control messages in peer-to-peernetworks.

Random scanning can be used to compile a list ofIP addresses that respond to active probing. Sincethe addresses will not be (ab)used immediately, theworm author can use the so-called stealth, low rate,scanning techniques to make the scan pass unno-ticed. On the other hand, if the duration of thelow-rate scanning phase is very long, some IPaddresses will eventually expire.

Hitlists of Web servers can be assembled by send-ing queries to search engines and by harvesting Webserver names off the replies. Similar single-wordqueries can also be sent to DNS servers in order


to validate web server names and find their IPaddresses. Interestingly enough, these types of scanscan be used to easily create large lists of web serversand are very likely to go unnoticed.

However, any form of active scanning, probing,or searching, has the potential risk of beingdetected. This gives special appeal to passive tech-niques, such as those based on peer-to-peer net-works. Such networks typically advertise many oftheir nodes and this information can be collectedby just observing the traffic that is routed througha peer. The creation of the hitlist does not requireany active operation from the peer-to-peer nodeand therefore cannot raise suspicion easily.

2.3. Worm defenses

We discuss some recent proposals for defendingagainst worms and whether they could be effectiveagainst hitlist worms.

Approaches such as the one by Wu et al. [7]attempt to detect worms by monitoring unsolicitedprobes to unassigned IP addresses (‘‘dark space’’)or inactive ports. Worms can be detected by observ-ing statistical properties of scan traffic, such as thenumber of source/destination addresses and the vol-ume of the captured traffic. By measuring theincrease on the number of source addresses seen ina unit of time, it is possible to infer the existenceof a new worm when as few as 4% of the vulnerablemachines have been infected.

An approach for isolating infected nodes insidean enterprise network is discussed in [11,8]. Theauthors show that as little as four probes may besufficient in detecting a new port-scanning worm.Weaver et al. [12] describe a practical approxima-tion algorithm for quickly detecting scanning activ-ity that can be efficiently implemented in hardware.Schechter et al. [10] use a combination of reversesequential hypothesis testing and credit-based con-nection throttling to quickly detect and quarantinelocal infected hosts. These systems are effective onlyagainst scanning worms (not topological, or ‘‘hit-list’’ worms), and rely on the assumption that mostscans will result in non-connections.

Several cooperative, distributed defense systemshave been proposed. DOMINO is an overlay systemfor cooperative intrusion detection [13]. The systemis organized in two layers, with a small core oftrusted nodes and a larger collection of nodes con-nected to the core. The experimental analysis dem-onstrates that a coordinated approach has the

potential of providing early warning for large-scaleattacks while reducing potential false alarms. Zouet al. [15] describes an architecture and models foran early warning system, where the participatingnodes/routers propagate alarm reports towards acentralized site for analysis. The question of howto respond to alerts is not addressed, and, similarto DOMINO, the use of a centralized collectionand analysis facility is weak against worms attack-ing the early warning infrastructure. Fully distrib-uted defense mechanisms, such as [14,16] may bemore robust against infrastructure attacks, yet alldistributed defense mechanisms that we are awareof are likely to be too slow for the estimated time-scales of hitlist worms.

3. Network address space randomization

The goal of network address space randomiza-tion (NASR) is to force hosts to change their IPaddresses frequently enough so that the informationgathered in hitlists is rendered stale by the time theworm is unleashed.

3.1. Abstract model of NASR

To illustrate the basic idea more formally, con-sider an abstract system model, with an address spaceR = {1,2, . . .,n}, a set of hosts H = {h1, . . .,hm}where m < n, and a function A that maps all hostshk to addresses A(hk) = r 2 R. Assume that at timeta, the attacker can (instantly) generate a hitlistX � R containing the addresses of hosts that are liveand vulnerable at that time. If the attack is started attime tx and all hosts in X are still live and vulnerableand have the same address as at time ta, then theworm can very quickly infect jXj hosts.

In a system implementing NASR, consider thatat time tb, where ta < tb < tx, all hosts are assigneda new address from R. Thus, at the time of theattack tx the probability that a hitlist entry xk stillcorresponds to a live host is p = m/n and thus theattacker will be able to infect (m/n)jXj hosts. Besidesreducing the number of successfully infected nodesin the hitlist, the attack will also result in a fraction1 � m/n of all attempts failing (which may be detect-able using existing techniques). In this simple model,the density m/n of the address space seems to be acrucial factor in determining the effectiveness ofNASR. So far we have assumed a homogeneousset of nodes, all with the same vulnerability andprobability of getting infected. If only a subset of


the host population is vulnerable to a certain type ofattack, then the effectiveness of NASR in reducingthe fraction of infected hitlist nodes and the numberof failed attempts is proportionally higher.

3.2. Practical constraints

The model we presented illustrates the basic intu-ition of how NASR can affect a hitlist worm. Map-ping the idea to the reality of existing networksrequires us to look into several practical issues.

3.2.1. Scope

Random assignment of an address from a globalIP address space pool is not practical for several rea-sons: (i) it would explode the size of routing tables,the number of routing updates and the frequencyof recomputing routes, (ii) it would result in tre-mendous administrative overhead for reconfiguringmechanisms that make address-based decisions,such as those based on access lists and (iii) it wouldrequire global coordination for being implemented.The difficulty of implementing NASR decreases aswe restrict its scope to more local regions. EachAS could implement AS- or prefix-level NASR,but this would still create administrative difficultieswith interior routing and access lists. It seems thata reasonable strategy would be to provide NASRat the subnet-level, although this does not com-pletely remove the problems outlined above. Forinstance, access lists would need to be reconfiguredto operate on DNS names and DNS would needto be dynamically updated when hosts changeaddresses. It is also obvious that it is pointless toimplement NASR behind NATs, as the internaladdresses have no global significance. It is sufficientto change the address of the NAT endpoint (e.g.,DSL/home router) to protect the internal hosts.

3.2.2. Static addressing

Some nodes cannot change addresses and thosethat can may not be able to do so as frequently aswe would want. The reason for this is that addresseshave first-class transport- and application-levelsemantics. For instance, DNS server addresses areusually hardcoded in system configurations. Evenfor DHCP-configured hosts, changing the addressof a DNS server would require synchronizing thelease durations so that the DNS server can changeits address at exactly the same time when all hostsrefresh their DHCP leases. While technically feasi-ble, this seems too complex to implement and such

complexity should be avoided. Similar constraintshold for routers.

3.2.3. DNS updatesFor services referenced through the DNS name,

such as email, FTP and Web servers, implementingNASR requires the DNS name to accurately reflectthe current IP address of the host. This means thatthe DNS time-to-live timers need to be set lowenough so that remote clients and name servers donot cache stale data when an address is changed.The NASR mechanism also needs to interact withthe DNS server to keep the address records up todate. It is reasonable to ask whether this couldincrease the load on the DNS system, given thatlower TTLs will negatively affect DNS cachingperformance. Fortunately, a recent study of DNSperformance suggests that reducing the TTLs ofaddress records to values as low as a few hundredseconds does not significantly affect DNS cache hitrates [35].

3.2.4. Tolerance to address changes

Generally, all active TCP connections on a hostthat changes its address would be killed, unless con-nection migration techniques such as [36–38] areused. Such techniques are not widely deployed yetand it is unrealistic to expect that they will bedeployed in time to be usable for the purposes ofNASR. Many applications are not designed to tol-erate connection failures. For instance, NFS clientsoften hang when the server is lost, and do not trans-parently re-resolve the NFS server address fromDNS before reconnecting.

Fortunately, many applications are designed todeal with occasional connectivity loss by automati-cally reconnecting and recovering from failure,and more recent research prototypes even explicitlydeal with such failures[39]. For such applications,we can assume that infrequent address changescan be tolerated. Examples of these applicationsare many P2P clients, like Kazaa and DirectCon-nect as well as SMB sharing (when names are used),messengers, FTP clients, chat tools, etc. However,tolerance does not always come for free: frequentaddress changes may result in churn in DHT-basedapplications and would generally have the side-effect of increasing stale state in other distributedapplications, including P2P indexing and Gnutella-like host caches. Furthermore, naive implemena-tions of NASR may cause problem to networkoperation protocols, like ARP. ARP entries expire


every 4 h and if we do not use a specialized NATbox, like the one we will introduce in Section 6,ARP entries will render stale.

There exist ways to make systems more robust toaddress changes. In a LAN environment, a solutionusing a specialized NAT box may be applicable insome cases, with the client host being oblivious toaddress changes and the NAT box making sure thataddress changes do not affect applications. We pres-ent our realization of such a scheme in Section 6.

Another option, which appears more attractive,is to make the NASR mechanism aware of theactive connections on each host, so that addresschanges can be timed to coincide with the host beinginactive. We will discuss one possible approach toaddress this problem in the following section.

3.3. Implementation

The practical constraints presented in the previ-ous sections suggest that NASR should be imple-mented very carefully. A plausible scenario wouldinvolve NASR at the subnet level and particularlyfor client hosts in DHCP-managed address pools.How such concessions affect NASR, as well as therate at which address changes should be made forNASR to be effective will be explored in more detailin Sections 4 and 5.

A basic form of NASR can be implemented byconfiguring the DHCP server to expire DHCPleases at intervals suitable for effective randomiza-tion. The DHCP server would normally allow a hostto renew the lease if the host issues a request beforethe lease expires. Thus, forcing addresses changeseven when a host requests to renew the lease beforeit expires requires some minor modifications to theDHCP server. Fortunately, it does not require anymodifications to the protocol or the client. We haveimplemented an advanced NASR-enabled DHCPserver, called Wuke-DHCP, based on the ISCopen-source DHCP implementation [40]. To mini-mize the ‘‘collateral damage’’ caused by addresschanges we introduce two modules in our DHCPimplementation: an activity monitoring module,and a service fingerprinting module.

The activity monitoring module keeps track ofopen connections for each host with the goal ofavoiding address changes for hosts whose servicescould be disrupted. In our prototype, we only con-sider long-lived TCP connections (that could be,for example, FTP downloads). More complicatedpolicies can be implemented but are outside the

scope of our proof-of-concept implementation.Wuke-DHCP communicates with a flow monitorthat records all active sessions of all hosts in thesubnet. The flow monitor responds with the numberof active connections that are sensitive to addresschanges.

Service fingerprinting examines traffic on the net-work and attempts to identify what services are run-ning on each host. The purpose of servicefingerprinting is twofold. First, we want to supple-ment activity monitoring with some context to makeaddress change decisions by indicating whether aconnection failure is tolerable by the end-system.Second, we want to avoid assigning an address to ahost that has significant overlap in services (andpotential vulnerabilities) with hosts that recentlyused the same address. For instance, randomizationbetween hosts with different operating systems, e.g.,between a Windows and a Linux platform appearsas a reasonable strategy. Our implementation of ser-vice fingerprinting is rudimentary: we only use portnumber information obtained through passive mon-itoring to identify OS and application characteristics.For instance, a TCP connection to port 80 suggeststhat the host is running a Web server, and port 445is an indication that a host might be a Windowsplatform. In an operational setting, more elaboratetechniques would be necessary, such as the passivetechniques described in [41,42], administrative dat-abases that keep track of host types like WindowsActive Directory and active probing techniquesimplemented as part of open-source tools [43–46].

In our implementation, we use three timers onthe DHCP server for controlling host addresses.The refresh timer determines the duration of thelease communicated to the client. The client isforced to query the server when the timer expires.The server may or may not decide to renew the leaseusing the same address. The soft-change timer isused internally by the server to specify the intervalbetween address changes, assuming that the flowmonitor does not report any activity for the host.A third, hard-change timer is used to specify themaximum time that a host is allowed to keep thesame address. If this timer expires, the host is forcedto change address, despite the damage that may becaused. We explore the configuration of these timersin Section 4.3. We should note that for IPv6 there isa proposed extension for stateless address reconfig-uration that performs randomization as described in[47]. This work, however, focuses on current IPv4technology.

2 The worm sent Google a specific search request, essentiallyasking for a list of vulnerable sites. Armed with the list, the wormthen attempted to spread to those sites using a PHP requestdesigned to exploit the phpBB bulletin board software.


4. Measurements

To explore the design space of network addressspace randomization we first need to consider somebasic hitlist characteristics, such as the speed at whicha hitlist can be constructed, the rate at whichaddresses already change (without any form of ran-domization), and how address space is allocated andutilized. We perform measurements on the Internetto obtain a more clear picture of these characteristics.

4.1. Hitlist generation strategies

There are two key issues that need to be exam-ined to determine how hitlist generation strategiesrelate to the effectiveness of NASR. First, we needto have a rough estimate of the speed at which anattacker can generate a hitlist. Second, we need todetermine whether these strategies produce reason-ably accurate hitlists, given that hitlists may decaynaturally.

Unfortunately, we cannot accurately measurehitlist generation speeds. The speed that can beachieved will depend heavily on the defense mecha-nisms deployed, for which we do not have anyrobust operational data, as well as the generationstrategies used, which we could not exhaustivelyanalyze to produce a safe estimate.

We must note that although it seems reasonableto assume that IP-level stealth scans can take daysor weeks to do properly, a skilled attacker may beable to use a botnet to speed up data collection. Sys-tems such as DShield [48] and DOMINO [13]should be able to detect this activity, but the exactthresholds under which the attacker would have tooperate to evade detection are unclear at this point.

We must also note that application-level probingappears as a bigger threat, as some distributed appli-cations provide protocol functionality for crawlingthat can be exploited by an attacker to rapidlybuild hitlists. For example, by crawling throughselected Gnutella superpeers, we were able to collect520,000 unique IPs within 5 min. Normal crawlingthrough regular peers was significantly slower, aswe will discuss briefly afterwards. Of course, addi-tional probing would be needed to determine clientsoftware and version information, assuming thatthe worm can only infect specific software versions.

Given the complexity and intricacies of this ques-tion, we defer the answer to future work. For thepurposes of this paper, it seems reasonable to expectthat if such discovery functionality is determined to

be dangerous, it may be disabled or at least carefullymonitored. Recent experience with the Santy worm[49], that used Google to search for victims 2, seemsto support this assumption, as Google quickly res-ponded by blocking requests originating from theworm. (See Fig. 1).

Next, we briefly present three different hitlist gen-eration strategies and focus on their effectiveness interms of natural decay rates.

4.1.1. Random scanning

We determine the effectiveness of random scan-ning for building hitlists. We first generate a list ofall/16 prefixes that have a valid entry with thewhois service, in order to increase scan successrates and avoid reserved address space. We thenprobe random targets within those prefixes usingICMP ECHO messages. Using this approach, wegenerated a hitlist of 20,000 addresses. Given thishitlist, we probe each target in the hitlist once everyhour for a period of two weeks. Every probe con-sists of four ICMP ECHO messages spaced out overthe one-hour run in order to reduce the probabilityof accidentally declaring an entry stale (e.g., becauseof short-term congestion or connectivity problems).Note that these measurements do not give us exactlythe probability of the worm successfully infectingthe target host, but only a rough estimate. Althoughwe were tempted to perform more insightful recon-naissance probes on the nodes in the hitlist, thiswould result in a much higher cost in terms of trafficand a high risk of causing (false) alarms at the targetnetworks. More accurate results could be obtainedusing full port scans, application-level fingerprintingand more frequent probes needed for ipid-baseddetection of host changes [50,51].

The results of the ICMP ECHO experiment areshown in Fig. 2a. We observe that the hitlist decaysrapidly during the first day and continues to decay,albeit very slowly, over the rest of the two-week run.The number of reachable nodes tends to vary duringthe time of day, apparently peaking on businesshours in the US with minor peaks that may coincidewith working hours elsewhere in the world. Overall,the decay of the hitlist slows down over time, reach-ing an almost stable level of 75% of hitlist nodesreachable.

Fig. 1. Propagation speed of different types of worm attacks.

0.50

0.55

0.60

0.65

0.70

0.75

0.80

0.85

0.90

0.95

1.00

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

frac

tion

of n

odes

time (days)

ICMP ping scan hitlist decay

0.50

0.55

0.60

0.65

0.70

0.75

0.80

0.85

0.90

0.95

1.00

0 1 2 3 4 5 6 7 8 9 10 11 12

frac

tion

of n

odes

res

pond

ing

time (days)

Gnutella hitlist decay

0.50

0.55

0.60

0.65

0.70

0.75

0.80

0.85

0.90

0.95

1.00

0 1 2 3 4 5 6 7 8 9 10 11 12

frac

tion

of n

odes

res

pond

ing

time (days)

Search-engine hitlist decay

Fig. 2. Decay of addresses harvested using different methods: (a) using random scanning, (b) by monitoring peer-to-peer traffic routerthrough a Gnutella peer, and (c) by querying a popular web search engine.


4.1.2. Passive P2P snooping

In the Gnutella P2P network, node addresses arecarried in QueryHit and Pong messages. By snoop-ing on these messages, a Gnutella client can harvestthousands of addresses without performing anyatypical operations. In our experiments, a 24-h per-iod sufficed for gathering 200K unique IP addresses,as shown in Fig. 3. Intensive searches and the use ofother, more popular P2P networks will probablyresult in a higher yield.

Most P2P nodes are short-lived, and thereforeaddresses harvested through P2P networks becomeunavailable very quickly. Fig. 2b shows the decayof the hitlist as a function of elapsed time. Note thatin this experiment we only check whether the nodesrespond to ICMP ECHO probes, not whether the

0

20000

40000

60000

80000

100000

120000

140000

160000

180000

200000

3 6 9 12 15 18 21

Uni

que

Har

vest

ed A

ddre

sses

Time (Hours)

1 node2 nodes3 nodes4 nodes

Fig. 3. Number of distinct addresses harvested by monitoringGnutella traffic as a function of time and number of monitoringnodes.

Gnutella client is still up and running. Thus, it ispossible that the IP address is not used by the samehost recorded in the hitlist. This may or may not beimportant for the attacker, depending on how muchthe attack depends on software versions andwhether version information has been used in con-structing the hitlist.

4.1.3. Search-engine harvesting

Querying a popular search engine for the or sim-ilar keywords returns hundreds of millions ofresults. Retrieving a thousand results gave 612unique live hosts and 30 dead hosts. Most searchengines restrict the number of results that can beretrieved, but the attacker can use multiple key-words either randomly generated or taken from adictionary.

The hosts that immediately appear as dead are aresult of the frequency of the indexing by the searchengine. It plays a role in the speed of harvesting theaddresses and must be considered for the decay ifthe addresses are not checked.

Fig. 2c shows the decay of the hitlist createdusing the search engine results. We observe that,compared to the other address sources, the searchengine results are very stable. This was expected,since web servers have to be online and use sta-ble addresses. It does not mean, however, thataddresses retrieved through search engines are bet-ter suited for attackers. Depending on the vulnera-bility at hand, unprotected, client PCs, such as


those returned by crawling peer-to-peer networksmay be preferred.

4.2. Subnet address space utilization

The feasibility and effectiveness of NASR dependon the fraction of unused addresses in NASR-enabled subnets. Performing randomization on asparse subnet will result in more connection failuresfor the hitlist worm compared to a dense subnet.Such failures could expose the worm as they couldbe picked up by scan-detection mechanisms. In adense subnet with homogeneous systems (e.g., run-ning the same services) the worm is more likely tosucceed in infecting a host, even if the original hostrecorded in the hitlist has actually changed itsaddress. Finally, in the extreme (and probably rare)case of a subnet that is always fully utilized, therewill never be a free address slot to facilitate addresschanges.

We attempt to get an estimate of typical subnetutilization levels. Because of the high scanningactivity, we cannot perform this experiment globallywithout tripping a large number of alerts. We there-fore opted for scanning five /16 prefixes that belongto FORTH, the University of Crete (UoC) and alarge ISP, after first obtaining permission by theadministrators of the networks. We performedhourly scans on all prefixes using ICMP ECHO mes-sages over a period of one month.

A summary of the results is shown in Fig. 4. Forsimplicity, we assume that all prefixes are subnettedin /24’s. We see that many subnets were completelydark with no hosts at all (not even a router). Nearly,30% of the subnets in two ISP prefixes were totallyempty, while for the FORTH and UoC the percent-age reaches 70%. This means that swapping subnetswould likely be an effective NASR policy, but

Hosts per subnet

0 32 64 96 128 160

% o

f tot

al s

ubne

ts

0

20

40

60

80

100

FORTH

UoC CAMPUS

ISP prefix 1

ISP prefix 2

ISP prefix 2

Fig. 4. Cumulative distribution of subnet address spaceutilization.

unfortunately it is not practical, as discussed in Sec-tion 2.2.1. We also see that 95% of these subnetshave less than 50% utilization and the number ofmaximum live hosts observed does not exceed 100.If subnet utilization at the global level is similar towhat we see in our limited experiment, then NASRat the level of /24 subnets is likely to be quite effec-tive, as there is sufficient room to move hostsaround, reducing the effectiveness of the wormand causing it to make failed connections.

4.3. The cost of NASR: address change frequency

vs. application failures

We attempt to estimate the ‘‘collateral damage’’caused by NASR. The damage depends on how fre-quently the address changes occur, whether hostshave active connections that are terminated andwhether the applications can recover from the tran-sient connectivity problems caused by an addresschange.

We first consider a scenario where host addressesare only changed when a node is rebooted. In thiscase, we know that the failure rate is zero, and tryto determine what address change frequency thisould permit. We measured the maximum uptimefor hosts on the three networks presented pre-viously.

The measured distribution is shown in Fig. 5.The liveness of the hosts was monitored for a fullweek by sending ping messages every hour. Almost60% of the hosts inside FORTH were always up,which seems reasonable for an environment consist-ing mostly of workstations. In more dynamic envi-ronments, like the ISP and the University of Cretenetworks only 20–30% of the hosts were continu-ously up and running (hosts with uptime 168 h),while nearly 40% of the hosts had a maximum

0

20

40

60

80

100

24 48 72 96 120 144 168

Per

cent

age

of h

osts

Max. host uptime (hours)

FORTHUoC

ISP prefix 1ISP prefix 2ISP prefix 3

Fig. 5. Cumulative distribution function of host uptimes in fivedifferent networks.


uptime of 10 h. These results lead to two observa-tions. First, although it may be possible to performNASR once every 1–4 days for hosts only when theyreboot, thus not causing any disruption, a signifi-cant fraction of hosts has a longer uptime. Consid-ering that we may want to change addresses moreaggressively, this trivial form of randomization isunlikely to be sufficient. Second, although suchdynamic environments perform some form of natu-ral randomization on their address space, mostlydue to DHCP, most of the DHCP servers are con-figured to maintain leases for machines connectingto the network. The usual scenario is that a DHCPserver is giving the same IP to a specific host (bycaching its Ethernet address). Typically, a leaseexpires in 15 days, so hosts that do not refresh thelease before it expires (e.g., because they are notconnected) would obtain a new address. Althoughwe do not have measurements on how often thishappens, it appears that this minor, slow form ofrandomization is unlikely to be effective by itself.

Given the above, we try to estimate the abortedconnections caused by more aggressive randomiza-tion, by simulating NASR with different parameterson four different traces: a one-week contiguous IPheader trace collected at Bell Labs research [52], a5-day trace from the University of Leipzig [53],a 1-day trace from the University of Crete, and a20-day trace from a link serving a single Web serverat FORTH-ICS. For the first experiment, we use arefresh timer of 1 min, a soft-change timer of 2 hand vary the hard-change timer. The results areshown in Fig. 6. As expected, there is a clear down-ward trend as the timer increases, consistent amongdifferent traces. An observation that initially sur-prised us was that the means of our samplesdid not converge towards a smooth, monotonically

hard limit (hours)

0 4 8 12 16 20 24

% o

f con

nect

ions

abo

rted

.001

.01

.1

1

10

UCNET BELL WEBICS LEIP

Fig. 6. Percentage of aborted connections as a function of thehard change limit. Soft-change limit is 2 h and refresh time is1 min.

decreasing function, despite hundreds of simula-tions for each value of the hard-timer and the initial‘‘last-lease’’ times for each host randomized. Thesamples we obtained indicated a behavior that wasalmost deterministic. Indeed, a closer look revealedthat the address change process for the same valueof the hard-change timer is synchronized for eachhost across different simulations. The first synchro-nization point is the first successful soft-changeevent, which depends only on the timings of theflows in the trace and the soft-change timer, whichboth remain constant across different experiments.Thus, we consider this to be an artifact of ourexperiment.

We also examine how the failure rate is affectedwhen we keep the hard-change timer constant, at4 h and vary the soft-change timer. The results areshown in Fig. 7. We see very little change as we varythe soft-change timer. There is a small improvementas soft-change decreases, because we can find asmall number of additional hosts that have no con-nections and perform successful randomization onthem.

A closer examination of the raw data reveals thatmore than 90% of the failures come from a fewhighly active hosts. These hosts almost always havesome active connections which will always beaborted, regardless of how much we relax the timer.Thus, it might make sense for the DHCP server toalso make exceptions and not strictly enforce thehard-change limit for such hosts that are highlyactive, assuming they represent only a small fractionof hosts on the network. We also note that our anal-ysis overestimates the failure rates because we donot filter out those applications that are resilientto aborted connections.

soft limit (hours)

0 0.5 1 1.5 2 2.5 3 3.5 4

% o

f con

nect

ions

abo

rted

0

0.2

0.4

0.6

0.8

1

1.2UCNET BELL WEBICS LEIP

Fig. 7. Percentage of aborted connections as a function of thesoft change limit. Hard-change limit is 4 h and refresh time is1 min.

0

5

10

15

20

25

30

35

1 week1 day6h3h1h30m15m

time

to 9

0% in

fect

ion

(min

utes

)

mean time between address changes (log-scale)

time to build hitlist1 hour

10 hours100 hours

Fig. 8. Worm spread time vs. time between address changes.

0

5

10

15

20

25

30


time

to 9

0% in

fect

ion

(min

utes

)

mean time between address change (log-scale)

iprand nodes100%

80%40%20%

0%

Fig. 9. Effect of NASR on worm spread time when partiallydeployed.


Overall, we observe that the failure rates are rea-sonable when compared to typical connection fail-ure measurements on network links. Previousstudies [54] have shown that 15–25% of TCP con-nections are reset due to network outages, attacksor reconfigurations. Additionally, failure rates ofNASR are reasonable when compared to typicalfalse positive rates of attack detection heuristics[55–58].

5. Impact of NASR on worm infection

It is infeasible to run experiments on the scale ofthe global Internet. To evaluate the effectiveness ofour design, we simulated a small-scale (comparedto the Internet) network of 1,000,000 hosts, eachof which could be a potential target of worms.

Because of the variety of operating systems usedand services provided, we assume that a fraction ofhosts v is vulnerable to the worm. For simplicity, weignore the details of the network topology, includ-ing the effect of end-to-end delays and traffic gener-ated by the worm outbreak. We simply consider aflat topology of routers, each serving a subnet ofend-hosts.

A fraction of addresses is allocated in each sub-net, which affects the probability of successful scanattempts within the subnet. This probability is animportant parameter in the case where a host inthe hitlist has changed its address, because it deter-mines if another live host would be available at thesame address. A separate parameter is used for ran-dom scanning, reflecting the fraction of the overalladdress space that is completely unused.

The hitlist is generated at configurable rates, andwe assume that the worm starts spreading immedi-ately after finishing with generating the hitlist.Because the early hitlist entries are more likely tohave become stale between their discovery and thestart of the attack, the worm starts attacking thefreshest addresses in the hitlist first. For simplicity,we ignore the details of how the hitlist is distributedand encoded in the payload of the worm: we assumethat every worm instance can obtain the next avail-able entry at zero cost. After finishing with the hit-list, we assume that the worm may continue tryingto infect hosts using random scanning. We assumethat entries of the hitlist are only attacked once.After all hitlist nodes are infected, the attacker willstop attacking them so as not to raise any suspi-cions. For new worm outbreaks, it is up to theattacker if she will use previous hitlists or will

generate new ones. We believe that the generationof a new hitlist is more probable.

5.1. Impact of NASR

In the first experiment, we simulate worm out-breaks with different parameters, and measure theworm spread time, expressed in terms of the timerequired for the worm to infect 90% of the vulnera-ble hosts. We compare the impact of networkaddress space randomization, varying how fast thehitlist is generated and how fast the host addressesare changed. The fraction of vulnerable hosts is20%, the internal scan success probability is 0.3(based on the subnet utilization measurements ofSection 4.2) and the random scanning success prob-ability is 0.05 (based on the measurements presentedin Section 4.1.1).

The results are shown in Fig. 8. We observe thatNASR achieves the goal of slowing down the wormoutbreak, in terms of the time to reach 90% infec-tion, from 5 min when no NASR is used to between24 and 32 min when hosts change their addressesvery frequently. As expected, defending against hit-lists that are generated very fast requires more fre-quent address changes. It appears that the mean

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1


frac

tion

of v

alid

hitl

ist e

ntrie

s

mean time between address changes (log-scale)


10 hours100 hours

Fig. 11. Effect of NASR on hitlist decay.

0

5

10

15

20

25

30

35

1 week1 day6h3h1h30min

time

to 9

0% in

fect

ion

(min

utes

)


subnet util 90%80%30%10%


time between address changes needs to be 3–5 timesless than the time needed to generate the hitlist forthe approach to reach around 80% of its maximumeffectiveness, while more frequent address changesgive diminishing returns. We define as maximumeffectiveness the slowdown factor we can achievewith NASR when we perform randomization in veryshort intervals. From our experiments, the maxi-mum effectiveness of NASR is a slowdown factorof 6 for the given simulation settings. Consideringthe observations of Section 3, it appears that dailyaddress changes could significantly slow down aworm whose hitlist is generated by passive snoopingon a P2P network.

Note that when using NASR, the hitlist worm isnot completely reduced to a random-scanningworm: knowledge of subnets that have even one hostavailable already gives the worm some advantageover a purely random-scanning worm. In this partic-ular experiment, it would take roughly 30 min forthe hitlist worm to infect the whole network (underNASR), and 2 h for a purely scanning worm. Thisis the result of performing subnet-level instead ofglobal-level NASR; global-level NASR wouldindeed reduce the hitlist worm to random-scanning.We must also note that although the spread timesreported depend on scanning frequency, the relativeimprovement when using NASR appears to beconstant.

The above experiment assumed that the hitlistworm will fall back to random scanning afterexhausting the hitlist. For a pure hitlist worm, thefraction of nodes that are successfully infected isequal to the fraction of valid hitlist entries. The frac-tion of valid hitlist entries for different addresschange and hitlist generation times is shown inFig. 11. Again we observe that NASR is quite effec-tive, even for short hitlist generation times.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9


frac

tion

of n

odes

infe

cted



10 hours100 hours

Fig. 10. Maximum fraction of infected hosts vs. time betweenaddress changes assuming scan-blocking.

We also simulated NASR with average subnetutilization and different fractions of vulnerablehosts. The results are summarized in Figs. 12 and13, respectively. The impact of NASR is greater interms of slowing down the infection for smaller vul-nerable populations. This is expected, as in suchcases the failure rate for stale entries is higher com-pared to a network where every available host isvulnerable. The results for the impact of NASR asa function of subnet utilization are similar: highersubnet utilization results in a higher success ratewhen hitting stale entries. However, NASR remainseffective even for 90% subnet utilization.

Fig. 12. Effect of NASR vs. subnet usage density.

0

5

10

15

20

25

30


time

to 9

0% in

fect

ion

(min

utes

)


vuln. hosts100%80%40%20%

Fig. 13. Effect of NASR vs. vulnerable population.


5.2. Partial deployment scenario

We have so far assumed that NASR is deployedglobally throughout the network. In reality, it is morelikely that only a fraction of subnets will employ themechanism, such as dynamic address pools. As weare not aware of any studies estimating the fractionof DHCP pools in the Internet, we measure the effec-tiveness of NASR for different values for the fractionof NASR-enabled subnets. The results are shown inFig. 9. We observe that NASR continues to be effec-tive in slowing down the worm, even when deployedin 20% or 40% of the network. The worm still infectsthe non-NASR subnets quite rapidly, with a slow-down in the order of 50% caused by the worm failingto infect NASR subnets. In other words, NASR has amilder but still notable impact on non-NASR hosts.However, the worm will have to resort to randomscanning after exhausting the hitlist, and it will takesignificantly more time to infect NASR comparedto non-NASR subnets. This observation suggeststhat there is a clear incentive for network administra-tors to deploy NASR, as it may provide them the crit-ical amount of time needed to react to a wormoutbreak. Ten to twenty-five minutes more timemay prove to be valuable for an administrator to takesome fast measures.

5.3. Interaction with scan-blocking

Hitlist worms are generally immune to scan-blocking mechanisms such as [12]. Even for the nat-ural decay rates measured in Section 4, such wormswould still be under the detection threshold most ofthe time. Randomization, however, will cause manyinfection attempts to fail, as hosts change addressesand their previous addresses are either unused orused by a different host that may or may not runthe same service, and thus may or may not be vul-nerable. To determine the interaction betweenNASR and scan-blocking mechanism we simulateworm outbreaks in a network where both NASRand scan-blocking are deployed. As scan-blockingcontains the outbreak, in this experiment we mea-sure the maximum fraction of hosts that are infectedin the presence of NASR together with scan-block-ing. The results are shown in Fig. 10. We observethat if NASR is performed according to the rule-of-thumb observation made previously (e.g., withaddress changes at a rate that is 3–5· faster than hit-list generation), the infection can be contained tounder 15% of the vulnerable population.

6. Practical NASR using transparent address

obfuscation

The damage caused by network address spacerandomization (NASR) in terms of aborted connec-tions may not be acceptable in some cases. Termi-nating, for example, a large web transfer or anSSH session would be both irritating and frustrat-ing. Additionally, it would possibly increase net-work traffic as users or applications may repeatthe aborted transfer or try to reconnect. To addressthese issues, we suggest Transparent Address

Obfuscation, an external mechanism for deploy-ing NASR avoiding connection failures.

The idea behind the mechanism is the existence ofan ‘‘address randomization box’’, called from nowon ‘‘TAO box’’, inside the LAN environment. Thisbox performs the randomization on behalf of theend hosts, without the need of any modificationsto the DHCP behavior. TAO box controls all trafficpassing by the subnet(s) it is responsible for, analo-gous to the firewall or NAT concept. The addressused for communication between the host and thebox remains the same. We should note that thereis no need for private addresses, unlike the case ofNAT, as end hosts can obtain any address fromthe organization they belong. The public addressof the end host – that is the IP that outside worldsees – changes periodically according to soft andhard timers, similar to the procedure described inSection 3. Old connections continue to operate overthe old address, the one that host had before thechange, until they are terminated.

The TAO box may look like similar to symmetricNAT but has one fundamental difference. Withsymmetric NAT all requests from the same internalIP address and port to a specific destination IPaddress and port are mapped to a unique externalsource IP address and port. If the same internal hostsends a packet with the same source address andport to a different destination, a different mappingis used. In our approach, the mapping does notchange per destination host but in predefined timeintervals. To the best of our knowledge, symmetricNAT is nowadays abandoned as port preservationschemes are mostly supported.

The TAO box is responsible for two things. First,to prevent new connections on the old addresses(before randomization) reaching the host. Second,to perform address translation to the packets basedon which connection they belong to, similar to theNAT case. Until all old connections are terminated,


a host would require multiple addresses to beallocated.

An example of how the TAO box works is illus-trated in Fig. 14. The box is responsible for addressrandomization on the 11.22.70.0/24 subnet, that is itcan pick up addresses only from this subnet. Ini-tially the host has the IP address 11.22.70.40 andTAO box sets the public IP address of this host to11.22.70.50. The host starts a new SSH connectionto Host A and sends packets with its own IP address(11.22.70.40). The box translates the source IPaddress and replaces it with the public one, settingit to 11.22.70.50. Simultaneously, the box keepsstate that the connection from port 2000 to HostA on port 22 belongs to the host with behind-the-box address 11.22.70.40 and public address11.22.70.50. Thus, on the Host A side we see pack-ets coming from 11.22.70.50. When Host Aresponds back to 11.22.70.50, box has to performthe reverse translation. Consulting its state, it seesthat this connection was initiated by host11.22.70.40 so it rewrites the destination IP address.

After an interval, the public address of host11.22.70.40 changes. TAO box now sets its publicaddress to 11.22.70.60. Any connections initiatedby external hosts can reach the host through thisnew public IP address. As it can be seen in Fig. 14the new connection to Host B website has the new

Fig. 14. An advanced example of NASR using the TAO box. Host hasession to Host A and the other (11.22.70.60) for new connections, suc

public IP as source. Note that in the behind-the-box and public address mapping table host nowhas two entries, with the top being chosen for newconnections. The only connection permitted to com-municate with the host at 11.22.70.50 address is theSSH connection from Host A. For each incomingpacket, the box checks its state to find an entry. Ifno entry is found, then packet is not forwarded tothe internal hosts, else the ‘‘src IP’’ field of the stateis used to forward the packet. As long as the SSHconnection lasts, the 11.22.70.50 IP will be boundto the particular host and cannot be assigned toany other internal host. When SSH session finishes,the address will be released. For stateless transportprotocols, like UDP or ICMP, only the latest map-ping between public and behind-the-box IP addressis used.

6.1. Evaluation

The drawback of the TAO box is the extraaddress space required for keeping alive old connec-tions. An excessive requirement of address spacewould empty the address pool, making the boxabort connections. We tried to quantify the amountof extra space needed by simulating the TAO boxon top of four traffic traces. The first two traces,CAMPUS and CAMPUS(2), come from the UoC

s two public IP addresses, one (11.22.70.50) devoted for the SSHh as a HTTP connection to Host B.

hard limit (hours)

0 4 8 12 16 20 24

% o

f was

ted

IP a

ddre

ss s

pace

1

10

100

400

CAMPUS BELL WEBICS CAMPUS (2)

Fig. 16. The percentage of extra IP space needed relative to theload of subnets.


campus and include traffic from 760 and 1675 hosts,respectively. All hosts of this trace belong to thesame /16 subnet. The second trace, BELL, is aone-week contiguous IP header trace collected atBell Labs research with 395 hosts located in a /16subnet. Finally, the WEBICS trace is a 20-day tracefrom a link serving a single Web server at FORTH.In this trace, we have only one host and we assumeit is the only host in a /24 subnet. In our simulation,the soft timer had a constant value of 90 s, while thehard timer varied from 15 min to 24 h.

The results of the simulation are presented inFig. 15. In almost all cases, we need at most 1%more address space in order to keep alive the oldconnections. We measured the number of hosts thatare alive in several subnets. We used full TCP scansto identify the number of hosts that were alive infive subnets: FORTH, the University of Crete cam-pus and three subnets of a local ISP. Our results, asshown in Fig. 4, indicate that 95% of the subnets areless than half-loaded and thus we can safely assumethat this 1% of extra space is not an obstacle in theoperation of the TAO box. However, the little extraaddress space needed derives from the fact that sub-nets are lightly loaded. For example, the 760 hostsof the CAMPUS trace correspond to the 1.15% ofthe /16 address space. In Fig. 16, the relative resultsof the previous simulation are shown, that is howmany addresses we need more in relation with usedaddresses and not the total number of addresses inthe subnet as plotted in Fig. 15. On average, 10%more address space for hard timer over one houris needed, which seems a reasonable overhead. Inthe case of the WEBICS trace the percentage is inmost cases 100%, while maximum percentageobserved is 400%. This is expected as we have onlyone host in the subnet and in some exceptional casesup to four additional addresses are needed.

hard limit (hours)0 4 8 12 16 20 24

% o

f IP

add

ress

spa

ce

.001

.01

.1

1

10

CAMPUS BELL WEBICS CAMPUS (2)

Fig. 15. Extra IP space needed for TAO.

7. Discussion

Our experiments suggest that network addressspace randomization is likely to be useful. However,these results should only be treated as preliminary, asthere are several issues that need to be examined moreclosely before reaching any definite conclusions.

First, the interaction between NASR and otherdefense mechanisms needs to be studied in moredepth. Our simulation results show that NASRenables scan-blocking mechanisms to contain theworm to under 15% infection. However, scan-block-ing is not entirely foolproof, at least in its currentform. For example, a list of known repliers can beused to defeat the failed-connection test used bythese mechanisms, by padding infection attemptswith successful probes to the known repliers.Whether it is possible to design better mechanismsfor detecting and containing scanning worms is thusstill an open question. Therefore, we should alsoconsider other possibilities, including reactivedefenses and distributed detection mechanisms. AsNASR is likely to at least slow down worms, itmay provide the critical amount of time neededfor distributed detectors such as DOMINO [13] tokick in, and for reactive approaches to deploypatches [59] or short-term filters [60]. Determiningwhether this is indeed a possibility requires furtherexperimentation and analysis.

Second, we have so far focused entirely on IP-level address randomization, as IP hitlist wormsseem to have the most efficient propagation proper-ties. On the one hand, we have only considered IPv4as deployed today. In an IPv6 Internet, the addressspace is so much bigger that randomization could beeven more effective. On the other hand, we need toalso consider worms that use higher-level addressingschemes, such as DNS or DHT identifiers. DNS


hitlist worms will defeat NASR, assuming that hostsalso update their DNS records. This would be truefor Web servers, but when the DNS name is onlya descriptor (such as a string containing the IPaddress), which is typical for DHCP and broadbandaddress pools, a DNS-based hitlist worm would notbe successful. DNS hitlist worms would also sufferthe additional lookup latency, a slightly larger pay-load3 and the added risk of being detected. While weare not aware of any such detection mechanism inplace today, it could be deployed, for example, onDNS servers.

Third, we have not considered how worm cre-ators would react to the widespread deployment ofNASR. One option would be for the attacker toperform a second round of (stealthy) probing, andretain only entries that seem to be stable over time.If NASR is partially deployed, then the worm couldinfect the non-NASR part of the Internet, withoutbeing throttled by stale entries or generating toomany failed connections. Interestingly, in this sce-nario all networks that employ NASR will beworm-free, unless the worm switches to randomscanning after finishing with the hitlist. Even if thishappens, NASR-enabled networks will still getinfected much later than the nodes in the hitlist.Although we are not aware of any other possiblereactions to the deployment of NASR, we cannotsafely dismiss the possibility that worm creatorscould come up with other measures to counter thisdefense. Thus, this question deserves further debateand analysis.

8. Related work

Our work on network address space randomiza-tion was inspired by similar techniques for random-ization performed at the OS level [17–23]. Thegeneral principle in randomization schemes is thatattacks can be disrupted by reducing the knowledgethat the attacker has about the system. For instance,instruction set randomization [22] changes theinstruction set opcodes used on each host, so that

3 We measured the length of the fully qualified domain name(FQDN) for several thousand entries obtained from a searchengine. The average length was 16 bytes. Servers that hold webcontent tend to have shorter, more memorable names, so weexpect that this is a conservative estimate. We measured a 46%compression ratio for these strings, and therefore on average eachentry will take up 7.5 bytes in the hitlist. IP addresses take up 4bytes, so storing DNS names causes almost a doubling of thehitlist size.

an attacker cannot inject compiled code using thestandard instruction set opcodes. Similarly, addressobfuscation [20] changes the locations of functionsin a host’s address space so that buffer-overflowexploits cannot predict the addresses of the func-tions they would like to utilize for hijacking controlof the system. Our work at the network level is sim-ilar, as it reduces the ability of the attacker to buildaccurate hitlists of vulnerable hosts.

The use of IP address changes as a mechanism todefend against attacks was proposed independentlyin [24–26]. Although these mechanisms are similarto ours, there are several important differences inthe threat model as well as the way they are imple-mented. The main difference is that they focus ontargeted attacks, performing address changes toconfuse attackers during reconnaissance and plan-ning. Neither project discusses or analyzes the useof such a mechanism for defending against wormattacks.

More specifically, the BBN DYNAT system [25]was developed as part of the DARPA InformationAssurance Program exploring the area of dynamicnetwork defense, with the hypothesis that dyna-mic network reconfiguration would inhibit anadversary’s ability to gather intelligence, and thusdegrade the ability to successfully launch an attack.BBN’s DYNAT operates by obfuscating host iden-tity information in TCP/IP headers when packetsenter public parts of the network. The obfuscationalgorithm depends on a pre-established keyingparameter that varies with time. The evaluationshows that the adversary was (a) severely time lim-ited by the dynamic nature of the network and (b)forced into more vulnerable and detectable behav-ior. We raise the same arguments for defending typ-ical LANs against hitlist worm attacks, the maindifference being that in our case the clients areloosely coupled to the servers and therefore pre-established keying parameters were undesirable. Inparticular, the BBN approach requires a ‘‘shim’’module to be installed on the client to coordinateaddress changes with the (modified) server, whilein our approach we consider a DHCP-based imple-mentation that is easier to deploy as it does notrequire any changes to the client. However, client-side modifications make it easier for DYNAT tomanage address changes without affecting applica-tions, unlike the DHCP-based approach thatrequires additional care to minimize application dis-ruption. The reason behind this difference in the twodesigns is that DYNAT assumes an adversary that


can passively listen to client-server communication.In contrast, our work focuses on attackers perform-ing scans and other active harvesting activities tobuild a worm hitlist.

The APOD (Applications That Participate inTheir Own Defense) project [24] set out to developtechnologies that increase an application’s resilienceagainst attacks. One of the mechanisms theydescribe, called Port and Address Hopping, is rele-vant to our work as it is designed to evade attacksagainst a service by constantly changing its IPaddress and TCP port using random numbers.The intention is both to hide the service’s real iden-tity and confuse the attacker during reconnaissance.Packets intercepted by attackers will reveal randomaddresses and ports, which are valid only for a smallperiod of time, e.g., 1 min. For an attack to be suc-cessful, the attacker must discover the currentaddresses and ports and execute the attack all withinone refresh cycle. A stated additional benefit is theincreased likelihood of an attacker being detected.This mechanism too relies on synchronization ofrandom number generators and time synchroniza-tion between the two components. Port hopping,as opposed to address hopping, was not an optionin our design due to the loose coupling between cli-ents and servers. APOD also provides hoppingfunctionality on protocol layers above TCP, suchas distributed CORBA calls, which requires addi-tional modification of TCP/IP data in the IIOP pro-tocol. This feature would be a reasonable additionto our proposal.

Sandia’s Dynamic Network Address Translationfor network protection is a similar proposal [26].The authors discuss several types of dynamicaddress translation and point out that the use of thisapproach is dependent on many different factorswhich can influence overall effectiveness. With thisin mind, they provide a detailed decision tree whichallows the designer to determine which type ofaddress translation is suitable for a particular envi-ronment.

9. Summary

We have explored the design and effectiveness ofnetwork address space randomization (NASR), atechnique that hardens networks against IP hitlistworms. NASR forces hosts to frequently changetheir network address, with the goal of making hit-lists stale. The approach is appealing in severalways. First, it is effective in limiting the infection

for pure IP hitlist worms, or slowing down the infec-tion for hybrid hitlist-scanning worms. Second, itforces both types of worms to exhibit scan-likebehavior that exposes them to scan detection mech-anisms. Third, it is relatively easy to implement.Unlike network-level detection mechanisms, NASRdoes not add any additional packet-level processingon network elements. Unlike host-based detectionor other proactive mechanisms, it does not requireany changes to the end-points.

We have discussed various constraints that limitthe applicability of NASR, such as the administra-tive overhead for managing address changes, ser-vices that require static addresses, and applicationsthat do not tolerate address changes. Our experi-ments indicate that the connection failure ratesdue to NASR are comparable to typical connectionfailure rates on modern networks and typical falsepositive rates of attack detection heuristics. We havealso presented an alternative approach, calledTransparent Address Obfuscation, that implementsaddress changes without causing connection fail-ures. This approach comes at the expense of requir-ing edge-router (or NAT) modification, and alsorequires some spare address space to facilitateaddress changes. We have found that the additionaladdress space required is reasonable, at under 1%,even for very aggressive address change policies.

Our investigation into the trade-offs of NASRsuggests that network segments that already per-form dynamic address allocation, such as DHCPpools for broadband and wireless networks are asuitable environment for deploying NASR withoutsignificantly impairing functionality or addingadministrative overhead. Assuming that broadbandusers are less likely to be vigilant and keep their sys-tems secure, NASR appears promising. However,given that most worms so far have targeted servers,and until better defenses are put in place, we believethat the administrative overhead for implementingNASR may be worth it even for servers, as NASReffectively allows administrators to ‘‘opt-out’’ fromIP hitlists.

References

[1] CERT Advisory CA-2001-19: ‘Code Red’ Worm ExploitingBuffer Overflow in IIS Indexing Service DLL. <http://www.cert.org/advisories/CA-2001-19.html>, Jul. 2001.

[2] D. Moore, C. Shannon, J. Brown, Code-Red: a case study onthe spread and victims of an Internet worm, in: Proceedingsof the Second Internet Measurement Workshop (IMW),2002, pp. 273–284.

http://www.cert.org/advisories/CA-2001-19.html



[3] D. Moore, V. Paxson, S. Savage, C. Shannon, S. Staniford,N. Weaver, Inside the slammer worm, IEEE Security &Privacy (2003) 33–39.

[4] S. Staniford, D. Moore, V. Paxson, N. Weaver, The topspeed of flash worms, in: Proceedings of the ACM CCSWORM, 2004.

[5] S. Staniford, V. Paxson, N. Weaver, How to own the internetin your spare time, in: Proceedings of the 11th USENIXSecurity Symposium, 2002, pp. 149–167.

[6] N. Weaver, V. Paxson, A worst-case worm, in: Proceedingsof the Third Annual Workshop on Economics and Infor-mation Security (WEIS’04), 2004.

[7] J. Wu, S. Vangala, L. Gao, K. Kwiat, An effectivearchitecture and algorithm for detecting worms with variousscan techniques, in: Proceedings of the Network andDistributed System Security Symposium (NDSS), 2004, pp.143–156.

[8] J. Jung, V. Paxson, A.W. Berger, H. Balakrishnan, FastPortscan detection using sequential hypothesis Testing, in:Proceedings of the IEEE Symposium on Security andPrivacy, 2004.

[9] M. Williamson, Throttling viruses: restricting propagation todefeat malicious mobile code, Technical Report HPL-2002-172, HP Laboratories Bristol, 2002.

[10] S.E. Schechter, J. Jung, A.W. Berger, Fast detection ofscanning worm infections, in: Proceedings of the SeventhInternational Symposium on Recent Advances in IntrusionDetection (RAID), 2004, pp. 59–81.

[11] S. Staniford, Containment of scanning worms in enterprisenetworks, Journal of Computer Security, 2004.

[12] N. Weaver, S. Staniford, V. Paxson, Very Fast Containmentof Scanning Worms, in: Proceedings of the 13th USENIXSecurity Symposium, 2004, pp. 29–44.

[13] V. Yegneswaran, P. Barford, S. Jha, Global intrusiondetection in the DOMINO overlay system, in: Proceedingsof the Network and Distributed System Security Symposium(NDSS), 2004.

[14] D. Nojiri, J. Rowe, K. Levitt, Cooperative response strat-egies for large scale attack mitigation, in: Proceedings of the3rd DARPA Information Survivability Conference andExposition (DISCEX), 2003.

[15] C.C. Zou, L. Gao, W. Gong, D. Towsley, Monitoring andearly warning for internet worms, in: Proceedings of the 10thACM International Conference on Computer and Commu-nications Security (CCS), 2003, pp. 190–199.

[16] K.G. Anagnostakis, M.B. Greenwald, S. Ioannidis, A.D.Keromytis, D. Li, A Cooperative immunization system foran Untrusting internet, in: Proceedings of the 11th IEEEInternational Conference on Networking (ICON), 2003, pp.403–408.

[17] J. Xu, Z. Kalbarczyk, R. Iyer, Transparent runtime ran-domization for security, in: A. Fantechi (Ed.), Proc. 22ndSymp. on Reliable Distributed Systems –SRDS 2003, 2003,pp. 260–269.

[18] J.S. Chase, H.M. Levy, M.J. Feeley, E.D. Lazowska,Sharing and protection in a single-address-space operatingsystem, ACM Transactions on Computer Systems 12 (4)(1994) 271–307. citeseer.ist.psu.edu/chase94sharing.html.

[19] C. Yarvin, R. Bukowski, T. Anderson, Anonymous RPC:low-latency protection in a 64-bit address space, in: Pro-ceedings of the USENIX Summer 1993 Technical Confer-ence, 1993, pp. 175–186.

[20] S. Bhatkar, D. DuVarney, R. Sekar, Address obfuscation: anefficient approach to combat a broad range of memory errorexploits, in: Proceedings of the 12th USENIX SecuritySymposium, 2003, pp. 105–120.

[21] H. Shacham, M. Page, B. Pfaff, E.-J. Goh, N. Modadugu,D. Boneh, On the effectiveness of address-space randomiza-tion, in: CCS ’04: Proceedings of the 11th ACM Conferenceon Computer and Communications Security, ACM Press,NY, USA, 2004, pp. 298–307.

[22] G.S. Kc, A.D. Keromytis, V. Prevelakis, Countering code-injection attacks with instruction-set randomization, in:Proceedings of the ACM Computer and CommunicationsSecurity Conference (CCS), 2003, pp. 272–280.

[23] E.G. Barrantes, D.H. Ackley, T.S. Palmer, D. Stefanovic,D.D. Zovi, Randomized instruction set emulation to disruptbinary code injection attacks, in: Proceedings of the 10thACM Conference on Computer and Communications Secu-rity, 2003.

[24] M. Atighetchi, P. Pal, F. Webber, R. Schantz, C. Jones,Adaptive use of network-centric mechanisms in cyber-defense, in: Proceedings of the 6th IEEE InternationalSymposium on Object-oriented Real-time Distributed Com-puting, 2003.

[25] D. Kewley, J. Lowry, R. Fink, M. Dean, Dynamicapproaches to thwart adversary intelligence gathering, in:Proceedings of the DARPA Information Survivability Con-ference and Exposition (DISCEX), 2001.

[26] J. Michalski, C. Price, E. Stanton, E.L. Chua, K. Seah, W.Y.Heng, T.C. Pheng, Final Report for the Network SecurityMechanisms Utilizing Network Address Translation LDRDProject, Technical Report SAND2002-3613, Sandia NationalLaboratories (November 2002).

[27] R. Droms, Dynamic Host Configuration Protocol, RFC2131. <http://www.rfc-editor.org/>, Mar. 1997.

[28] B. Croft, J. Gilmore, Bootstrap Protocol (BOOTP), RFC951, <http://www.rfc-editor.org/>, Sep. 1985.

[29] F. Cohen, Computer viruses: theory and practice, Comput-ers & Security 6 (1987) 22–35.

[30] J.O. Kephart, A biologically inspired immune system forcomputers, in: Artificial Life IV: Proceedings of the FourthInternational Workshop on the Synthesis and Simulation ofLiving Systems, MIT Press, 1994, pp. 130–139.

[31] C.C. Zou, W. Gong, D. Towsley, Code red worm propaga-tion modeling and analysis, in: Proceedings of the NinthACM Conference on Computer and Communications Secu-rity (CCS), 2002, pp. 138–147.

[32] Cert Advisory CA-2003-04: MS-SQL Server Worm. <http://www.cert.org/advisories/CA-2003-04.html>, Jan. 2003.

[33] The Spread of the Sapphire/Slammer Worm. <http://www.silicondefense.com/research/worms/slammer.php>, Feb. 2003.

[34] C. Shannon, D. Moore, The Spread of the Witty Worm,<http://www.caida.org/analysis/security/witty/>, 2004.

[35] J. Jung, E. Sit, H. Balakrishnan, R. Morris, DNS perfor-mance and the effectiveness of caching, in: Proceedings of theFirst ACM SIGCOMM Internet Measurement Workshop(IMW), 2001.

[36] J. Ioannidis, G.Q. Maguire Jr., The design and implemen-tation of a mobile internetworking architecture, in: USENIXWinter, 1993, pp. 489–502. URL <citeseer.ist.psu.edu/ioannidis93design.html>.

[37] A.C. Snoeren, H. Balakrishnan, An end-to-end approach tohost mobility, in: MobiCom ’00: Proceedings of the Sixth

http://citeseer.ist.psu.edu/chase94sharing.html

http://www.rfc-editor.org/

http://www.rfc-editor.org/



http://www.silicondefense.com/research/worms/slammer.php

http://www.silicondefense.com/research/worms/slammer.php

http://www.caida.org/analysis/security/witty/

http://citeseer.ist.psu.edu/ioannidis93design.html

http://citeseer.ist.psu.edu/ioannidis93design.html


Annual International Conference on Mobile Computing andNetworking, ACM Press, NY, USA, 2000, pp. 155–166.

[38] R.A. Baratto, S. Potter, G. Su, J. Nieh, Mobidesk: mobilevirtual desktop computing, in: Proceedings of the 10thAnnual International Conference on Mobile Computing andNetworking (MOBICOM), ACM Press, 2004, pp. 1–15.

[39] M. Kaminsky, E. Peterson, D.B. Giffin, K. Fu, D. Mazires,M.F. Kaashoek, REX: Secure, extensible remote execution,in: Proceedings of the 2004 USENIX Technical Conference,2004, pp. 199–212.

[40] Internet Systems Consortium Inc., Dynamic Host Configu-ration Protocol (DHCP) Reference Implementation. http://www.isc.org/sw/dhcp/.

[41] T. Karagiannis, A. Broido, M. Faloutsos, K. claffy, Trans-port layer identification of P2P traffic, in: IMC ’04:Proceedings of the Fourth ACM SIGCOMM Conferenceon Internet Measurement, ACM Press, NY, USA, 2004, pp.121–134.

[42] S. Sen, O. Spatscheck, D. Wang, Accurate, scalable in-network identification of P2P traffic using applicationsignatures, in: WWW ’04: Proceedings of the 13th Interna-tional Conference on World Wide Web, ACM Press, NY,USA, 2004, pp. 512–521.

[43] THC-Amap. http://thc.org/releases.php, 2004.[44] Fingerprinting: The complete toolsbox. <http://www.l0t3k.

org/security/tools/fingerprinting/>, 2004.[45] Fingerprinting: The Complete Documentation. <http://

www.l0t3k.org/security/docs/fingerprinting/>, 2004.[46] DISCO: The Passive IP Discovery Tool. <http://www.alt-

mode.com/disco/>, 2004.[47] T. Narten, R. Draves, Privacy Extensions for Stateless

Address Autoconfiguration in IPv6, RFC 3041. <http://www.faqs.org/rfcs/rfc3041.html>, Jan. 2001.

[48] DShield: Distributed Intrusion Detection System. http://www.dshield.org.

[49] Net Worm Uses Google to Spread. <http://it.slashdot.org/it/04/12/21/2135235.shtml>, Dec. 2004.

[50] W. Chen, Y. Huang, B.F. Ribeiro, K. Suh, H. Zhang, E. deSouza e Silva, J. Kurose, D. Towsley, Exploiting the IPIDfield to infer network path and end-system characteristics, in:Proceedings of the Sixth Passive and Active MeasurementWorkshop (PAM 2005), 2005.

[51] T. Kohno, A. Broido, kc Claffy, Remote physical devicefingerprinting, in: Proceedings of the IEEE Symposium onSecurity and Privacy, 2005.

[52] NLANR-PMA Traffic Archive: Bell Labs-I trace. <http://pma.nlanr.net/Traces/Traces/long/bell/1>, 2002.

[53] NLANR-PMA Traffic Archive: Leipzig-I trace. <http://pma.nlanr.net/Traces/Traces/long/leip/1>, 2002.

[54] M. Arlitt, C. Williamson, An analysis of TCP reset behav-iour on the internet, ACM SIGCOMM Computer Commu-nication Review 35 (1) (2005) 37–44.

[55] T. Toth, C. Krugel, Accurate buffer overflow detection viaabstract payload execution, in: Proceedings of the FifthInternational Symposium on Recent Advances in IntrusionDetection (RAID), 2002.

[56] K. Wang, S.J. Stolfo, Anomalous payload-based networkintrusion detection, in: Proceedings of the Seventh Interna-tional Symposium on Recent Advanced in Intrusion Detec-tion (RAID), 2004, pp. 201–222.

[57] S. Singh, C. Estan, G. Varghese, S. Savage, Automatedworm fingerprinting, in: Proceedings of the Sixth Symposium

on Operating Systems Design & Implementation (OSDI),2004.

[58] A. Pasupulati, J. Coit, K. Levitt, S.F. Wu, S.H. Li, J.C. Kuo,K.P. Fan, Buttercup: on network-based detection of poly-morphic buffer overflow vulnerabilities, in: Proceedings ofthe Network Operations and Management Symposium(NOMS), vol. 1, 2004, pp. 235–248.

[59] S. Sidiroglou, A.D. Keromytis, A network worm vaccinearchitecture, in: Proceedings of the IEEE InternationalWorkshops on Enabling Technologies: Infrastructure forCollaborative Enterprises (WETICE), Workshop on Enter-prise Security, 2003.

[60] H.J. Wang, C. Guo, D.R. Simon, A. Zugenmaier, Shield:vulnerability-driven network filters for preventing knownvulnerability exploits, in: Proceedings of ACM SIG-COMM’04, 2004, pp. 193–204.

S. Antonatos is a Ph.D. candidate at theComputer Science Department of theUniversity of Crete. He received hisM.Sc. degree and diploma in ComputerScience from the University of Crete. Hismain research interests are in networkmonitoring, intrusion detection, andperformance evaluation.

P. Akritidis received his M.Sc. degreeand diploma in Computer Science fromthe University of Crete. His mainresearch interests are in network securityand intrusion detection.

Evangelos Markatos ([email protected]) received his diploma in Com-puter Engineering from the University ofPatras in 1988, and the M.S. and Ph.D.degrees in Computer Science from theUniversity of Rochester, NY in 1990 and1993, respectively. Since 1992, he is anassociated Researcher of the Inst. ofComputer Science of the Foundation forResearch and Technology – Hellas (ICS-FORTH) where he is currently the head

of the Distributed Computing Systems Laboratory, and the headof the W3C Office in Greece. Since 1994 he is also with the

http://www.isc.org/sw/dhcp/

http://www.isc.org/sw/dhcp/

http://thc.org/releases.php

http://www.l0t3k.org/security/tools/fingerprinting/

http://www.l0t3k.org/security/tools/fingerprinting/

http://www.l0t3k.org/security/docs/fingerprinting/

http://www.l0t3k.org/security/docs/fingerprinting/

http://www.altmode.com/disco/

http://www.altmode.com/disco/

http://www.faqs.org/rfcs/rfc3041.html

http://www.faqs.org/rfcs/rfc3041.html

http://www.dshield.org

http://www.dshield.org

http://it.slashdot.org/it/04/12/21/2135235.shtml

http://it.slashdot.org/it/04/12/21/2135235.shtml

http://pma.nlanr.net/Traces/Traces/long/bell/1

http://pma.nlanr.net/Traces/Traces/long/bell/1

http://pma.nlanr.net/Traces/Traces/long/leip/1

http://pma.nlanr.net/Traces/Traces/long/leip/1


Computer Science Department of the University of Crete, wherehe is currently a full Professor. He conducts research in severalareas including distributed and parallel systems, the World-WideWeb, Internet Systems and Technologies, as well as Computerand Communication Systems Security. He has been a reviewer forseveral prestigious Journals, Conferences, and IT projects. He isthe author of more than 70 papers and book chapters. He iscurrently the coordinator of research projects funded by theEuropean Union, by the Greek Government, and by privateorganizations.

Kostas Anagnostakis is a principalinvestigator on software security at theInstitute for Infocomm Research in Sin-gapore. He holds a Ph.D. degree inComputer and Information Science fromthe University of Pennsylvania, USA, aMaster’s degree from the same schooland a B.Sc. in Computer Science fromthe University of Crete. His main areasof interest are in distributed systemssecurity, networking, performance eval-

uation, and in problems that lie at the intersection between

computer science and economics. His current research focuses onanalyzing and countering new threats that may arise in emergingenvironments, such as an increasingly Web-based service land-scape and an increasingly wireless and mobile Internet.

defending against hitlist worms using network address space...

Documents