www.archive.org
`415.561.6767
`415.840-0391 c-fax
`
`lncerner Archive
`300 Funston Avenue
`San Francisco, CA 941 18
`
`AFFIDAVIT OF CHRISTOPHER BUTLER
`
`I. I am the Office Manager at the Internet Archive, located in San Francisco,
`California. I make this declaration of my own personal knowledge.
`2. The Internet Archive is a website that provides access to a digital library of
`Internet sites and other cultural artifacts in digital form. Like a paper library, we provide
`free access to researchers, historians, scholars, and the general public. The Internet
`Archive has partnered with and receives support from various institutions, including the
`Library of Congress.
`3. The Internet Archive has created a service known as the Wayback Machine. The
`Way back Machine makes it possible to surf more than 450 billion pages stored in the
`Internet Archive's web archive. Visitors to the Wayback Machine can search archives
`by URL (i.e., a website address). If archived records for a URL are available, the visitor
`will be presented with a list of available dates. The visitor may select one of those
`dates, and then begin s urfing on an archived version of the Web. The links on the
`archived files, when served by the Wayback Machine, point to other archived files
`(whether HTML pages or images). If a visitor cl icks on a link on an archived page, the
`Wayback Machine will serve the archived file with the closest available date to the page
`upon which the link appeared and was clicked.
`4. The archived data made viewable and browseable by the Wayback Machine is
`compiled using software programs known as crawlers, which surf the Web and
`automatically store copies of web files, preserving these files as they exist at the point of
`time of capture.
`5. T he Internet Archive assigns a URL on its site to the archived files in the format
`http://web.archive.org/web/[Year in yyyy][Month in mm](Day in dd][Time code in
`hh:mm:ss]/[Archived URL). Thus, the Internet Archive URL
`http://web.archive.org/web/ I 9970126045828/http:l/www .archive.org/ would be the
`URL for the record of the Internet Archive home page HTML file
`(http://www.archive.org/) archived on January 26, 1997 at 4:58 a.m. and 28 seconds
`(1997/01 /26 at 04:58:28). A web browser may be set such that a printout from it will
`display the U RL of a web page in the printout's footer. The date assigned by the T nternet
`Archive applies to the HTML file but not to image files linked therein. Thus images that
`appear on a page may not have been archived on the same date as the HTML fi le.
`Likewise, if a website is designed with "frames," the date assigned by the Internet
`Archive applies to the frameset as a whole, and not the individual pages within each
`frame.
`6. Attached hereto as Exhibit A are true and accurate copies of printouts of the
`Internet Archive's records of the HTML files or PDF files for the URLs and the dates
`specified in the footer of the printout (HTML) or attached coversheet (PDF).
`7. I declare under penalty of perjury that the foregoing is true and correct.
`
`DATE: s /r? I, ci
`
`--+-, -----''----
`
`Christopher Butler
`
`GUEST TEK EXHIBIT 1019
`Guest Tek v. Nomadix, IPR2019-01191
`
`Page 1 of 32
`
`

`

`Exhibit A
`Exhibit A
`
`Page 2 of 32
`
`Page 2 of 32
`
`

`

`5/13/2019
`
`Internet Society (ISOC): NDSS05
`
`All About !SOC
`Organization Members
`
`All About the Internet
`Global Members
`
`Search/Site Map
`Home
`
`Publ1ca11ons
`
`Educauon & Training
`
`Public Polley
`
`Standards & Protocols
`
`Chap1ers
`
`Press Into
`
`Conlerences
`
`01scuss
`
`All About the Internet Societ
`
`Other Conferences
`
`NDSS05 Home
`
`Conference
`Proceedings
`
`Program
`
`Workshop
`
`REGISTRATION
`
`Sponsors
`
`About San Diego
`
`Hotel and
`Reservations
`
`The 12th Annual 
`Network and Distributed System Security Symposium 
`Catamaran Resort Hotel 
` 
`San Diego, California
`3­4 February 2005­Symposium
`2 February 2005­Pre­Conference Workshop 
`
`Patron Sponsor: 
`
`Conference Proceedings now available
`
`Welcome to the twelfth ANNUAL SYMPOSIUM ON NETWORK AND DISTRIBUTED
`SYSTEM SECURITY (NDSS'05) to be held in San Diego, California USA. Please join
`us to participate in what many members of the global Internet community have come
`to consider a "must attend" annual event.
`
`We are proud and honored to once again be sponsored by THE INTERNET SOCIETY
`(ISOC) in 2005.
`
`NDSS'05 brings together innovative and forward thinking members of the Internet
`community including leading­edge security researchers and implementers, globally­
`recognized security­technology experts, and users from both the private and public
`sectors who design, develop, exploit, and deploy the technologies that define network
`and distributed system security.
`
`NDSS'05 provides a balanced mix of technical papers (with a strong emphasis on
`implementation) and panels who discuss and debate new and practical approaches to
`security problems that are endemic to network and distributed systems.
`
`Perhaps best of all, NDSS'05 offers a myriad of opportunities for extended Q&A
`(during sessions) and "hallway" discussions in a relaxed, informal setting. This
`continues to be a hallmark of the SYMPOSIUM where attendance is kept to a level
`that fosters the maximum exchange of technical and practical information on the
`successful deployment of existing security solutions as well the latest on emerging,
`candidate solutions to unsolved problems.
`
`View information about previous conferences:
`
`NDSS'04
`
`NDSS'03
`
`NDSS'02
`
`NDSS'01
`
`1775 Wiehle Ave., Suite 102, Reston, VA, USA 20190­5108
`Tel: +1 703 326 9880 Fax: +1 703 326 9881 
`
`4, rue des Falaises, CH­1205, Geneva, Switzerland 
` 
`Tel: +41 22 807 1444 Fax: +41 22 807 1445
`
`This document <http://www.isoc.org/isoc/conferences/ndss/05/index.shtml> 
`was last updated Wednesday, 09­Feb­2005 13:40:31 EST. 
` 
`Copyright © 2005 Internet Society. All Rights Reserved. 
`
`Webmaster@ISOC.ORG
`Privacy Statement
`
`https://web.archive.org/web/20050307054953/http://www.isoc.org:80/isoc/conferences/ndss/05/index.shtml
`
`1/1
`
`Page 3 of 32
`
`

`

`5/13/2019
`
`NDSS Conference Proceedings: 2004
`
`s
`
`s
`
`f ~
`lnterpe -~~LJ
`Society~
`
`Organizing Committee
`General Chair's Message
`Program Chairs' Message
`
`l~ --~ I
`
`I
`
`y
`
`..
`
`,
`
`Network and Distributed System Security Symposium
`Conference Proceedings: 2005
`
`Cryptography in Network Security
`Space-Efficient Block Storage Integrity - Alina Oprea, Carnegie Mellon University ; Mike Reiter, Carnegie Mellon University ;  Ke Yang, Google
`Improved Proxy Re-Encryption Schemes with Applications to Secure Distributed Storage - Giuseppe Ateniese, Johns Hopkins University ; Kevin Fu, MIT ;
`Matthew Green, Johns Hopkins University ;   Susan Hohenberger, MIT
`Rekeying and Storage Cost for Multiple User Revocation - Sandeep S. Kulkarni, Michigan State University ; Bezawada Bruhadeshwar, Michigan State
`University
`Denial of Service Attacks
`On a New Class of Pulsing Denial-of-Service Attacks and the Defense - Xiapu Luo, Hong Kong Polytechnic University ; Rocky K. C. Chang, Hong Kong
`Polytechnic University
`MOVE:  An End-to-End Solution to Network Denial of Service - Angelos Stavrou, Columbia University ; Angelos D. Keromytis, Columbia University ;
`Jason Nieh, Columbia University ; Vishal Misra, Columbia University ;   Dan Rubenstein, Columbia University
`Security Analysis and Improvements for IEEE 802.11i - Changhua He, Stanford University ; John C. Mitchell, Stanford University
`Peer-to-Peer Approaches
`Privacy-Preserving Friends Troubleshooting Network - Qiang Huang, Princeton University; Helen J. Wang, Microsoft Research ;   Nikita Borisov, University
`of California, Berkeley
`Pretty Secure BGP, psBGP - Tao Wan, Carleton University ; Evangelos Kranakis, Carleton University ; P.C. van Oorschot, Carleton University
`Internet Defense
`New Streaming Algorithms for Fast Detection of Superspreaders - Shobha Venkataraman, Carnegie Mellon University ; Dawn Song, Carnegie Mellon
`University ; Phillip B. Gibbons, Intel Research ; Avrim Blum, Carnegie Mellon University
`The Internet Motion Sensor - A Distributed Blackhole Monitoring System - Michael Bailey, University of Michigan ; Evan Cooke, University of Michigan ;
`Farnam Jahanian, University of Michigan ; Jose Nazario, Arbor Networks ; David Watson, University of Michigan
`DNS-based Detection of Scanning Worms in an Enterprise Network - David Whyte, Carleton University ; Evangelos Kranakis, Carleton University ; P.C. van
`Oorschot, Carleton University
`Intrusion Detection
`DIRA: Automatic Detection, Identification and Repair of Control-Hijacking Attacks - Alexey Smirnov, Stony Brook University ; Tzi-cker Chiueh, Stony
`Brook University
`Dynamic Taint Analysis for Automatic Detection, Analysis, and SignatureGeneration of Exploits on Commodity Software - James Newsome, Carnegie
`Mellon University ; Dawn Song, Carnegie Mellon University
`
`https://web.archive.org/web/20050510004309/http://www.isoc.org/isoc/conferences/ndss/05/proceedings/index.htm
`
`1/2
`
`Page 4 of 32
`
`

`

`NDSS Conference Proceedings: 2004
`5/13/2019
`Enriching Intrusion Alerts Through Multi-Host Causality - Samuel T. King,, University of Michigan ; Z. Morley Mao, University of Michigan ; Dominic G.
`Lucchetti, University of Michigan ; Peter M. Chen, University of Michigan
`Platform Security
`A Black-Box Tracing Technique to Identify Causes of Least-Privilege Incompatibilities - Shuo Chen, University of Illinois, Urbana-Champaign ; John
`Dunagan, Microsoft Research ; Chad Verbowski, Microsoft Research ; Yi-Min Wang, Microsoft Research
`One-Way Isolation:  An Effective Approach for Realizing Safe Execution Environments - Weiqing Sun, Stony Brook University ; Zhenkai Liang, Stony Brook
`University ; V.N. Venkatakrishnan, Stony Brook University ; R. Sekar, Stony Brook University
`
`Copyright and Reprint Permissions: The Internet Society owns the copyrights for this publication and all of the papers contained herein.  You may freely
`reproduce all or part of any paper for noncommercial purposes if you credit the author(s), provide notice to the Internet Society, and cite the Internet Society as the
`copyright owner.  Reproduction for commercial purposes is strictly prohibited without the prior written consent of the Internet Society, the first-named author (for
`reproduction of an entire paper only), and the author's employer if the paper was prepared within the scope of employment.
`Address your correspondence to:  Director of Conferences and Education, Internet Society, 1775 Wiehle Avenue, Suite 102, Reston, Virginia  20190-5108, U.S.A.,
`tel. +1 703 326 9880, fax +1 703 326 9881, orders@isoc.org.
`The papers in this CD-Rom comprise the proceedings of the meeting mentioned above.  They reflect the authors' opinions and, in the interest of timely
`dissemination, are published as presented and without change.  Their inclusion in this publication does not necessarily constitute endorsement by the editors or
`the Internet Society.
`
`ISBN Number 1-891562-20-7 (Paper)
`
`ISBN Number 1-891562-19-3 (CD-Rom)
`
`https://web.archive.org/web/20050510004309/http://www.isoc.org/isoc/conferences/ndss/05/proceedings/index.htm
`
`2/2
`
`Page 5 of 32
`
`

`

`https://web.archive.org/web/20060114010701/http://www.isoc.org/isoc/confer
`ences/ndss/05/proceedings/papers/whytednswormv2.pdf
`
`Page 6 of 32
`
`

`

`DNS-based Detection of Scanning Worms in an Enterprise Network
`
`David Whyte
`
`P.C. van Oorschot
`Evangelos Kranakis
`School of Computer Science
`Carleton University
`Ottawa, Ontario, Canada
`dlwhyte, kranakis, paulv @scs.carleton.ca
`}
`{
`
`Abstract
`
`Worms are arguably the most serious security threat
`facing the Internet. Seeking a detection technique that is
`both sufficiently efficient and accurate to enable automatic
`containment of worm propagation at the network egress
`points, we propose a new technique for the rapid detec-
`tion of worm propagation from an enterprise network. It
`relies on the correlation of Domain Name System (DNS)
`queries with outgoing connections from an enterprise net-
`work. Improvements over existing scanning worm detec-
`tion techniques include: (1) the possibility to detect worm
`propagation after only a single infection attempt; (2) the
`capacity to detect zero-day worms; and (3) a low false
`positive rate. The precision of this first-mile detection
`technique supports the use of automated containment and
`suppression strategies to stop fast scanning worms before
`they leave the network boundary. We believe that this tech-
`nique can be applied with the same precision to identify
`other forms of malicious behavior within an enterprise
`network including: mass-mailing worms, network recon-
`naissance activity, and covert communications. Currently,
`it is unclear if our DNS-based detector will work for all
`network protocols.
`In some network environments, the
`DNS detection technique may need to be used as a sec-
`ondary input to a more sophisticated anomaly detector.
`
`1 Introduction
`Recently, a multitude of high profile worm epidemics
`has affected millions of networked computing devices.
`The Slammer Worm that emerged in January of 2003 ex-
`posed how quickly worm propagation could occur. It in-
`fected systems by exploiting a buffer overflow vulnerabil-
`ity in Microsoft SQL Server. Slammer’s infected popula-
`tion doubled in size every 8.5 seconds [14] with 90% of
`vulnerable hosts infected in just 10 minutes. This worm
`achieved its full scanning rate (i.e. over 55 million scans
`
`per second) only 3 minutes after it was released. In Au-
`gust 2003 the SoBig worm caused an estimated $5 billion
`in damage and at the height of its infection was respon-
`sible for approximately 73% of all Internet email traffic
`[6]. Unfortunately, worm outbreaks of this scale are be-
`coming commonplace. In March 2004, the Witty Worm
`began to spread by exploiting a buffer overflow in Internet
`Security Systems (ISS) products that include firewalls and
`intrusion detection systems. Although the vulnerable pop-
`ulation of Internet systems was a magnitude smaller than
`previous worms, it spread very rapidly [19]. To achieve
`the rate of propagation observed, it is believed that this
`worm used a preprogrammed hitlist or a timed release of
`the worm on previously compromised systems. Witty was
`the first widely propagated worm to contain a malicious
`payload and signifies a disturbing new trend for worm
`writers, combining skill and malice [23].
`Staniford et al. [21] hypothesized that a properly con-
`structed worm could infect vulnerable systems on the In-
`ternet at an even greater speed. Worms are evolving and
`they can employ a number of anti-detection techniques
`such as: anti-forensics, dynamic behavior, and modular-
`ity of attack tools [16]. Furthermore, worms spread so
`quickly that traditional intrusion detection methods (i.e.
`generation and deployment of attack signatures) are not
`feasible [15]. In order to make automatic containment of
`fast scanning worms feasible, a rapid and accurate detec-
`tion method is required.
`Currently, most countermeasures used to mitigate these
`attacks include some form of human intervention. Routers
`can be configured to block network traffic and vulnera-
`ble software can be patched. However, worms that prop-
`agate and infect the Internet in just minutes make these
`human-in-the-loop countermeasures impractical. The de-
`velopment of wide scale automated countermeasures is re-
`quired. Current worm propagation detection methods are
`limited in: (1) their speed of detection, (2) their inability
`to accurately detect zero-day worms, (3) their inability to
`detect slow scanning worms, and (4) their high false posi-
`
`Page 7 of 32
`
`

`

`tive rate.
`Typically, scanning worms use a pseudo random num-
`ber generator (PRNG) to generate 32 bit random numbers
`that correspond to an IPv4 address. The attacking system
`uses this numeric address as the target for its infection
`attempt. The use of a numeric IP address by the worm,
`instead of the qualified domain name of the system, ob-
`viates the need for a DNS query.
`In contrast, the vast
`majority of legitimate publicly available services are ac-
`cessed through the use the DNS protocol which provides
`the mapping between numeric IP addresses and the corre-
`sponding alphanumeric names. The translation of a host
`name to a registered IP address is called resolving. While
`there exists valid exceptions (e.g. client to client applica-
`tions, remote administration tools, etc.) typical user be-
`havior should include some form of DNS activity before a
`new connection can be initiated.
`Our Contributions. We use DNS anomalies to detect
`scanning worm propagation, relying on the observation of
`DNS responses. If we do not observe DNS activity be-
`fore a new connection is initiated, we consider this con-
`nection anomalous. This premise is based on our obser-
`vation that whereas users tend to remember alphanumeric
`strings and use the network services provided (i.e. DNS),
`almost all scanning worms directly use numeric IP ad-
`dresses. Behavioral signatures [9] are used to describe
`common aspects of worm behavior particular to a given
`worm that span infected systems in a temporal order. Our
`DNS-based detection technique can be used as a behavo-
`rial signature to detect scanning worms.
`Those legitimate applications and services that gener-
`ally do not rely on DNS are addressed through the use of
`whitelists (see Section 3.2). In an enterprise network with
`an open security policy (i.e. few or no user and service
`restrictions) the number of such applications and services
`may be so large as to make our detection technique prone
`to significant amounts of false positives and negatives (see
`Section 5.2). Even in this scenario, DNS-based detection
`may be a useful input to a more sophsticated anomaly de-
`tector. However, we believe the use of our DNS anomaly-
`based detection approach in an enterprise network that im-
`plements a conservative or restrictive security policy (i.e.
`more common in large financial organizations or govern-
`ment) is appealing for a number of reasons including:
`1. Speed: the possibility to detect an infected system
`after only a single infection attempt to the Internet.
`2. Detection of zero-day worms: possible because our
`approach does not rely on the matching of existing
`worm signatures to identify suspicious traffic.
`3. Scanning rate independence: our approach can detect
`both fast and slow (i.e. stealth) scanning worms.
`4. Reduced training period: our approach includes the
`concept of a whitelist that can be quickly generated
`
`to reduce false positives.
`5. Low-false positive rate: our approach does not rely
`on modeling normal network and user behavior pro-
`files that are prone to false positives.
`6. Ease of implementation: our approach is network-
`based, runs on commodity hardware, and relies on
`the observation of a protocol found in every network
`(i.e. DNS).
`
`We believe this new technique can both rapidly and ac-
`curately detect worm propagation within enterprise net-
`works. The precision of this first-mile detection enables
`the use of automated containment and suppression strate-
`gies to stop scanning worms before they leave the network
`boundary.
`Our detection technique can be used to detect scanning
`worm propagation both within an enterprise network and
`from the enterprise network to the Internet (i.e. local to
`remote). It does not detect worm propagation from the
`Internet to the enterprise network. It differs from exist-
`ing scanning worm detection techniques in that it does not
`rely on having to observe and correlate multiple events to
`determine that a scan is occuring. There is no concept of a
`threshold; we only maintain in state a list of IP addresses
`of valid connection destinations and each individual con-
`nection attempt from the enterprise network as it occurs.
`Our approach enables the detection of an infected system
`after a single scan has been initiated, regardless of the time
`between scans, and thus compares very favorably to pre-
`vious work (e.g. Weaver et al. [25]). Weaver et al. pro-
`pose an algorithm based on the Threshold Random Walk
`(TRW) scan detector [11] to detect a scanning host within
`an enterprise environment after only 10 scans, and it can
`detect scans as slow as 1 scan per minute.
`The sequel is structured as follows. Section 2 presents
`the description of the DNS-based scanning worm propa-
`gation detection technique. Section 3 discusses our ex-
`perimental platform. Section 4 discusses the analysis of
`our prototype. Section 5 presents detection circumvention
`and limitations. Section 6 discusses ideas for extended ap-
`plications of our detection technique. Section 7 discusses
`related work. We conclude in Section 8 with a brief sum-
`mary. Appendix A contains background information.
`
`2 Basic Methodolgy and Approach
`For an overview of worm propagation strategies and
`DNS please refer to Appendix A. In this section we give
`a high-level overview of our DNS-based anomaly scan-
`ning worm detection approach. In larger enterprise net-
`works, it is not unusual for network segments to be either
`logically or physically separated.
`In fact, an enterprise
`network may be comprised of several distinct subnets for
`a variety of reasons including security, ease of adminis-
`
`Page 8 of 32
`
`

`

`tration, and geographical location. We can leverage this
`natural separation of networks to contain worm propaga-
`tion within distinct network segments. As in Silicone De-
`fense’s CounterMalice solution [7], we purposely divide
`the enterprise network into segments called cells. Each
`cell contains a worm containment device to confine and
`contain worm infection. Our definition of a cell refers to
`all systems within the same subnet serviced by a distinct
`authoritative DNS server. Figure 1 illustrates how an en-
`terprise network can be divided into cells.
`The propagation of fast-scanning worms can be char-
`acterized as: local to local (L2L), local to remote (L2R),
`or remote to local (R2L). In L2L propagation, a scanning
`worm targets systems within the boundaries of the enter-
`prise network it resides. Topological scanning worms em-
`ploy this strategy. L2R propagation refers to a scanning
`worm within an enterprise network targeting systems out-
`side of its network boundary. Finally, R2L propagation
`refers to worm scanning from the Internet into an enter-
`prise network. In this paper, our worm propagation de-
`tection method detects L2R worm propagation and worm
`propagation between local cells, but not R2L or worm
`propagation that occurs within an individual cell.
`Systems that reside within the same cell typically do
`not use DNS to communicate. The Address Resolution
`Protocol (ARP) [17] is used when a system tries to com-
`municate with another system in the same cell. ARP is
`used by the data link layer to provide a mapping between
`the physical hardware of a system and its assigned IP ad-
`dress. L2L worm propagation can occur within a particu-
`lar cell or span multiple cells depending on the scanning
`strategy of the worm. As noted above, in the present pa-
`
`technique to an ARP-based implementation which detects
`L2L worm propagation within local cells. Figure 2 pro-
`vides an example of how our prototype could be opera-
`tionally deployed. Prototype A in Cell 1 monitors activ-
`ity between Cell 1 and Cell 2. Cell 2 contains the sole
`ingress/egress point for the enterprise network. Prototype
`B, from its vantage point in Cell 2, monitors activity from
`all cells within the enterprise network to external systems.
`Finally prototype C monitors activity between Cell 3 and
`Cell 2. A system in Cell 1 is infected with a scanning
`worm. The infected system begins scanning to locate sus-
`ceptible systems both within Cell 2 and the Internet. The
`prototype device in Cell 1 will detect the scanning activ-
`ity to Cell 2 and generate an alert. The prototype device
`in Cell 2, at the enterprise gateway, will detect scanning
`activity from Cell 1 to the Internet and generate an alert.
`
`Remote Server(cid:0)
`
`Router(cid:0)
`
`Prototype B(cid:0)
`
`DNS Server(cid:0)
`Prototype A(cid:0)
`
`Firewall(cid:0)
`DNS Server(cid:0)
`Cell 2(cid:0)
`
`Prototype C(cid:0)
`DNS Server(cid:0)
`
`Cell 1(cid:0)
`
`Router(cid:0)
`
`Switch(cid:0)
`
`Cell 3(cid:0)
`
`Enterprise Network(cid:0)
`
`Router(cid:0)
`
`Figure 2. DNS Anomaly-based Detection De-
`ployment
`
`DNS Server(cid:0)
`
`Firewall(cid:0)
`DNS Server(cid:0)
`Cell 2(cid:0)
`
`DNS Server(cid:0)
`
`Cell 1(cid:0)
`
`Router(cid:0)
`
`Switch(cid:0)
`
`Cell 3(cid:0)
`
`Enterprise Network(cid:0)
`
`Figure 1. Network Cells
`
`per, we handle L2L worm propagation only in the case
`that the propagation occurs between cells. In a related pa-
`per [26], we detail how we have adopted the DNS-based
`
`DNS Anomaly Detection Approach. In random scan-
`ning, the use of a numeric IP address by the worm, instead
`of the qualified domain name of the system, obviates the
`need for a DNS query. New connections from the net-
`work that cannot be associated with any DNS activity are
`considered anomalous. If we can observe and correlate
`all locally generated DNS activity and new connection at-
`tempts within an enterprise network, we have the means
`to detect L2L inter-cell or L2R worm propagation. The
`technique does not detect R2L or intra-cell (i.e. within the
`boundaries of a cell) worm propagation.
`However, this approach must take into account valid in-
`stances where no DNS query is required to access a par-
`ticular system or resource. Our analysis of DNS activ-
`ity within a network reveals two instances where this oc-
`curs. The first results from accessing distributed appli-
`cation and content delivery services. The HTTP protocol
`
`Page 9 of 32
`
`

`

`allows URLs consisting of numeric IP addresses to be em-
`bedded within the data payload of an HTTP packet. It is
`common practice for busy websites to maintain or out-
`source their content to larger centralized image servers to
`allow for better web page retrieval performance. When a
`user accesses a website to retrieve a webpage, they may be
`retrieving the requested material from several geographi-
`cally separated servers. It is not uncommon for the web
`page content to include an IP address of a centralized im-
`age server that the browser uses to retrieve an image or
`media file. In this instance, the browser uses this numeric
`IP address to retrieve the image and does not require a
`DNS resource record. Instead of having to perform a DNS
`request for the object, the numeric IP address is provided
`to the browser in the content of the web page. We consider
`this a valid connection attempt incidentally obtained by a
`previous DNS query.
`The second instance includes those servers and services
`that are simply not accessed with DNS. An application
`may have the numeric IP addresses of systems it needs
`to access embedded in its configuration file. A user may
`specify connections to a server by entering an IP address
`from memory at a command line. In these instances, the
`application or user has a priori knowledge of the IP ad-
`dress of the server they wish to access. This can include
`but is not limited to network server communications, re-
`mote administration tools, and certain peer to peer (P2P)
`applications. DNS, applications, and users are all legiti-
`mate sources of numeric IP addresses that can enable ac-
`cess to services and systems. Legitimate use of numeric IP
`addresses by applications and users can be identified and
`added to a whitelist for exclusion from the detection al-
`gorithm. Taking these exceptions into consideration (see
`Whitelists in Section 3.2), we consider any system that
`tries to access another system without receiving a valid
`DNS response as a possible worm infected system.
`
`3 High-Level System Design
`Our software system design uses the libpcap [5] library
`and is comprised of two logical components: the PPE and
`DCE. The Packet Processing Engine (PPE) is responsible
`for extracting the relevant features from the live network
`activity or saved network trace files (see Section 3.1). The
`DNS correlation engine (DCE) maintains in state all rel-
`evant DNS information, a whitelist, and numeric IP ad-
`dresses embedded in HTTP packets extracted by the PPE
`(see Section 3.2). This information is used to verify both
`outgoing TCP connections and UDP datagrams. In this
`context, verifying means ensuring that the destination IP
`address of an outgoing TCP connection or UDP datagram
`can be attributed to either a DNS query, an HTTP packet,
`or an entry in the whitelist. The software can process
`either live network traffic or saved network traces in the
`
`pcap [5] file format. To detect L2R worm propagation,
`the software system must be deployed at all external net-
`work egress/ingress points. To detect worm propagation
`between network cells, a system would need to be de-
`ployed in each cell at the internal ingress/egress points
`(see Figure 2).
`
`I
`
`c:::::::::Jc:::::::::J c:::::::::J
`
`Prototype(cid:0)
`
`Packet Processing Engine(cid:0)
`I
`5-tuple DNS(cid:0)
`I
`I
`I
`I
`
`5-tuple TCP(cid:0)
`
`5-tuple HTTP(cid:0)
`
`5-tuple DNS(cid:0)
`
`5-tuple DNS(cid:0)
`
`I
`
`c:::::::::J
`
`Network(cid:0)
`c:::::::::J c:::::::::J
`
`I
`l,,.
`
`.,_I
`
`I
`I
`I
`I
`I
`
`DNS Correlation Engine(cid:0)
`
`5-tuple DNS(cid:0)
`
`Connection Candidate Data Structure(cid:0)
`
`~ =
`•
`t=j
`
`I
`I
`I
`I
`
`5-tuple Connection Candidate(cid:0)
`5-tuple Connection Candidate(cid:0)
`5-tuple Connection Candidate(cid:0)
`5-tuple Connection Candidate(cid:0)
`
`5-tuple TCP(cid:0)
`
`Alert(cid:0)
`Alert(cid:0)
`Alert(cid:0)
`
`'i:::=::::'.J
`
`Figure 3. High-level System Design
`
`Figure 3 reveals the high-level design of the prototype.
`In this example, the PPE extracts the relevant features
`from live network activity and bundles these into data to-
`kens. The data tokens are comprised of the appropriate
`5-tuple of features (see Section 3.1) based on the protocol
`extracted. These tokens are consumed by the DCE. The
`DCE uses the tokens to maintain a list of destination IP
`addresses it deems valid and checks any new connection
`attempts from within the enterprise network against this
`list. The DCE will generate an alert if it determines the
`new connection is being initated to a destination IP that is
`not contained in its list.
`
`3.1 Packet Processing Engine
`The PPE is responsible for processing packets of inter-
`est from pcap files or live off the network and extracts
`a variety of information from several protocols. Specif-
`ically, the software must extract relevant features from
`new connection attempts, embedded IP addresses within
`HTTP packets, and all DNS activity occurring within the
`network cell.
`In order to discover new TCP connection attempts, all
`TCP packets with the SYN flag set are examined. TCP
`packets with the SYN only flag set indicate the start of
`the three-way handshake that signifies a new connection
`attempt. UDP is connectionless and does not have the
`concept of a session. Each UDP packet is treated as a dis-
`crete event and thus a potential new connection. Feature
`
`Page 10 of 32
`
`

`

`extraction for either new TCP connections or non-DNS
`UDP datagrams includes the 5-tuple of source IP, source
`port, destination IP, destination port, and timestamp.
`Packets that contain a source port of 80 or 8080 are cap-
`tured and categorized as HTTP packets. All HTTP pack-
`ets are decoded and the payload inspected for any em-
`bedded IP addresses. Any IP addresses discovered in the
`payload are extracted along with the previously defined
`5-tuple.
`DNS A records are generated when systems within the
`network wish to contact systems in other cells or external
`to the network. Any DNS requests originating from the
`network cells and any DNS replies coming into the net-
`work cells are extracted and decoded. Feature extraction
`for DNS datagrams includes the 5-tuple of DNS source IP,
`DNS source port, TTL, domain name, and resolved IPv4
`address.
`
`3.2 DNS Correlation Engine
`The DNS correlation engine (DCE) is responsible for
`processing information passed by the PPE. The two ma-
`jor functions of the DCE are: (1) to create and maintain a
`data structure of IP addresses and associated features that
`are considered valid connection candidates; and (2) to val-
`idate all new TCP and UDP connection attempts between
`cells or to remote systems against the connection candi-
`date data structure. A valid connection candidate data
`structure is produced by processing DNS A records, em-
`bedded IP addresses in HTTP packets, and the whitelist.
`Connection Candidate Data Structure. All DNS A
`resource record 5-tuples are parsed and added to the con-
`nection candidate data structure. The TTL from each 5-
`tuple is used just as it is in the cache of a DNS server.
`Once the TTL expires, the resource record is purged from
`the DCE’s connection candidate list. Although DNS ac-
`tivity provides the majority of IP addresses to the connec-
`tion candidate data structure, numeric IP addresses within
`HTTP packets must also be considered.
`As previously discussed, numeric IP addresses are reg-
`ularly embedded within HTTP packets. Al