5 – 10 page paper due 4/5/13

CSEC640 – Week 9 Individual Assignment #2

Description : Write a Review/Critique paper of the following articles:

Collin Jackson et al., “Protecting Browsers from DNS Rebinding Attacks”, In Proceedings of ACM CCS, 2009.

Robin Sommer and Vern Paxson, “Enhancing Byte-Level Network Intrusion Detection Signatures with Context”, Proceedings of the 10th ACM Conference on Computer and Communication Security, 2003.

These articles were selected from the assigned readings, “Articles of the Week”.

Assignment Guidelines

For each article, use the following guide to structure your review:

Article Review Structure:

Article Citation: Write a complete and correct citation for the article using APA format.

Summary: At the beginning of your review, summarize each article using your own words to proficiently demonstrate an in-depth understanding of the article.

Analysis: This is the main section of your review. Your analysis should include:

What are the article’s main contributions and strengths?

Are there any weaknesses and limitations?

Are there possible improvements?

How does the article compare or contrast with other articles that the class has read so far? What concepts, ideas, or techniques read elsewhere strengthen or weaken this paper? Which articles and books in the bibliography would you recommend to your classmates to provide a better understanding of the topic?

Discussion/Conclusion: Your review of each article should end with your discussion and conclusions. For example, you can present a list of issues or questions to initiate discussion (this can be accomplished by proposing an argument for or against a given method) and/or provide your thoughts/opinions/summary of the article.

Submission Guidelines

Print format: MS Word or PDF format.

The general structure of your review/critique paper:

Name and Title

Brief Intro

Your critique/review of paper #1

Your critique/review of paper #2

References

The paper length: 5-10 double space pages (Note: you will not be penalized if your review exceeds 10 pages. However, be concise and to the point. Emphasis should be placed on good, solid content.)

Follow the APA format.

2

Protecting Browsers from DNS
Rebinding Attacks

COLLIN JACKSON, ADAM BARTH, ANDREW BORTZ,
WEIDONG SHAO, and DAN BONEH

Stanford University

DNS rebinding attacks subvert the same-origin policy of browsers, converting them into open

network proxies. Using DNS rebinding, an attacker can circumvent organizational and personal

firewalls, send spam email, and defraud pay-per-click advertisers. We evaluate the cost effectiveness

of mounting DNS rebinding attacks, finding that an attacker requires less than $100 to hijack

100,000 IP addresses. We analyze defenses to DNS rebinding attacks, including improvements

to the classic “DNS pinning,” and recommend changes to browser plug-ins, firewalls, and Web

servers. Our defenses have been adopted by plug-in vendors and by a number of open-source firewall

implementations.

Categories and Subject Descriptors: K.6.5 [Management of Computing and Information
Systems]: Security and Protection

General Terms: Security, Design, Experimentation

Additional Key Words and Phrases: Same-origin policy, DNS, firewall, spam, click fraud

ACM Reference Format:
Jackson, C., Barth, A., Bortz, A., Shao, W., and Boneh, D. 2008. Protecting browsers from

DNS rebinding attacks. ACM Trans. Web 3, 1, Article 2 (January 2009), 26 pages. DOI =
10.1145/1462148.1462150 http://doi.acm.org/10.1145/1462148.1462150

1. INTRODUCTION

Web users trust their browser to prevent malicious Web sites from leverag-
ing their machines to attack others. Organizations that permit JavaScript and
other active content through their firewall rely on the browser to protect inter-
nal network resources from attack. Modern browsers meet these expectations

A preliminary version of this article appeared in Proceedings of the 14th ACM Conference on Com-
puter and Communication Security (CCS), 421–431. This work is supported by grants from the
National Science Foundation and the U.S. Department of Homeland Security.

Authors’ addresses: C. Jackson (corresponding author), A. Barth, A. Bortz, W. Shao, D. Boneh,

Department of Computer Science, Stanford University, 450 Serra Mall, Stanford, CA 94305; email:

collinj@cs.stanford.edu.

Permission to make digital or hard copies of part or all of this work for personal or classroom use is

granted without fee provided that copies are not made or distributed for profit or direct commercial

advantage and that copies show this notice on the first page or initial screen of a display along

with the full citation. Copyrights for components of this work owned by others than ACM must be

honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers,

to redistribute to lists, or to use any component of this work in other works requires prior specific

permission and/or a fee. Permissions may be requested from Publications Dept., ACM, Inc., 2 Penn

Plaza, Suite 701, New York, NY 10121-0701 USA, fax +1 (212) 869-0481, or permissions@acm.org.
C© 2009 ACM 1559-1131/2009/01-ART02 $5.00 DOI 10.1145/1462148.1462150 http://doi.acm.org/
10.1145/1462148.1462150

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

2:2 • C. Jackson et al.

by implementing a security policy, based on the same-origin principle, that
protects honest sites from dishonest sites by isolating content from distinct
“origins.” DNS rebinding attacks subvert the same-origin principle by confus-
ing the browser into mixing content controlled by distinct entities into a single
security origin.

Using DNS rebinding, an attacker can circumvent firewalls to spider corpo-
rate intranets, exfiltrate sensitive documents, and compromise unpatched in-
ternal machines. An attacker can also hijack a user’s IP address to send spam
email and to defraud pay-per-click advertisers. DNS rebinding vulnerabilities
let the attacker read and write directly on network sockets, greatly expand-
ing on the attacks possible with existing JavaScript-based botnets [Lam et al.
2006], which can send HTTP requests to foreign hosts but cannot read the
HTTP responses.

Basic DNS rebinding attacks have been known for over a decade [Dean et al.
1996; Roskind 2001]. In the classic attack an attacker need only register a do-
main name, such as attacker.com, and attract Web traffic, for example, by run-
ning an advertisement. The attacker answers DNS queries for attacker.com
with the IP address of his or her own server and a short Time-To-Live (TTL).
The user’s browser issues an HTTP request to the attacker’s server, which re-
sponds with a malicious HTML document. The attacker’s document then issues
a second HTTP request to attacker.com. The user’s DNS cache has expired,
causing the browser to issue another DNS query for attacker.com. This time,
the attacker’s DNS server responds with the IP address of a target server. The
browser allows the attacker’s script to read HTTP responses from the target
server because the two connections share a single host name and therefore
belong to the same browser security origin. If the user is behind a firewall,
the attacker can use this attack to read sensitive documents hosted on servers
behind the firewall, as shown in Figure 1.

To mount a DNS rebinding attack, an attacker need not compromise any
DNS servers. The attacker simply provides valid, authoritative responses for
attacker.com, a domain owned by the attacker. Unlike “pharming” attacks
[Ollmann 2005] in which the attacker must compromise an honest host name,
DNS rebinding attacks can be mounted without unusual network privileges.
DNSSEC [Arends et al. 2005] provides no protection against DNS rebinding
attacks: The attacker can legitimately sign all DNS records for attacker.com
because the attacker owns the domain.

Pinning

A common DNS rebinding defense implemented in several browsers is DNS
pinning: Once the browser has resolved a host name to an IP address, the
browser caches the result for a fixed duration, regardless of TTL. With pinning,
all network connections to a given host name will be routed to the same IP
address, preventing the attacker from mixing malicious content with content
from an honest server.

Pinning is no longer an effective defense against DNS rebinding attacks be-
cause of vulnerabilities introduced by browser plug-ins. These plug-ins provide

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

Protecting Browsers from DNS Rebinding Attacks • 2:3

Fig. 1. Firewall circumvention using DNS rebinding.

additional functionality, such as socket-level network access, to Web content.
The browser and each plug-in maintain separate pin databases, creating a new
class of DNS rebinding vulnerabilities we refer to as multipin vulnerabilities.
We demonstrate, for example, how to use the interaction between the browser
and Java LiveConnect to pin the browser to one IP address while pinning Java
to another IP address. An attacker can exploit multipin vulnerabilities to read
and write directly on sockets to a host and port of the attacker’s choice. Un-
fortunately, repairing multipin vulnerabilities is not as simple as creating a
common pin database for browsers and plug-ins (see Section 5.2).

To assess the severity of these attacks, we experimentally measured the
cost and effort required to use multipin vulnerabilities to assemble a tempo-
rary, large-scale bot network. Nearly 90% of Web browsers we measured were
vulnerable to DNS rebinding attacks that required only a few hundred millisec-
onds to conduct (see Table I). These attacks do not require users to click on any
malicious links: Users need only view an attacker’s Web advertisement. Our
findings indicate that an attacker can spend less than $100 and hijack 100,000
unique IP addresses for sending spam and committing click fraud.

Defenses. The first priority for defending against DNS rebinding attacks is
to prevent a malicious Web site from obtaining socket-level access to an arbi-
trary IP address. To prevent socket-level attacks, we propose modifications to
the socket access policies of Flash Player and Java, the two most widely de-
ployed browser plug-ins. Our proposed defenses have been adopted by Adobe
for Flash Player [Mitre 2007c] and by Sun for Java [Mitre 2007a] and Live-
Connect [Mitre 2007b]. The vendors have deployed these defenses in patches,
preventing large-scale firewall circumvention and IP hijacking.

To combat firewall circumvention, we recommend that organizations deploy
DNS resolvers that prevent external host names from resolving to internal

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

2:4 • C. Jackson et al.

Table I. Time Required for DNS Rebinding Attack by

Technology (95% confidence)

Technology Attack Time

LiveConnect (JVM loaded) 47.8 ± 10.3 ms
Flash Player 9.0.48.0 192 ± 5.7 ms
Internet Explorer 6 (no plug-ins) 1000 ms

Internet Explorer 7 (no plug-ins) 1000 ms

Firefox 1.5 and 2 (no plug-ins) 1000 ms

Safari 3 (no plug-ins) 1000 ms

LiveConnect 1294 ± 37 ms
Opera 9 (no plug-ins) 4000 ms

IP addresses. Without the ability to resolve attacker.com to an internal IP
address, the attacker cannot use DNS rebinding to circumvent firewalls. We
provide an open-source implementation of such a resolver, called dnswall [Bortz
et al. 2007]. Our implementation is included in FreeBSD [Haupt 2008] and is
deployed at a number of organizations. Several open-source consumer firewall
projects [Kelley 2008; Fainelli 2008; Gottschall et al. 2008] now implement this
defense.

Individual servers can defend themselves against DNS rebinding attacks by
validating the HTTP Host header and rejecting requests that contain an unex-
pected Host header value. Without socket-level access, the attacker Web content
is unable to spoof the Host header. This defense is appropriate for servers that
place trust, either explicitly or implicitly, in the browser’s IP address. For exam-
ple, the server responsible for recording clicks on pay-per-click advertisements
ought to validate the Host header before accepting an HTTP request as a valid
advertisement click.

Organization. The remainder of the article is organized as follows. Section 2
describes the existing browser security policy for network access. Section 3 de-
tails DNS rebinding vulnerabilities, including classic DNS rebinding and mod-
ern multipin vulnerabilities. Section 4 explains two classes of attack that use
these vulnerabilities, firewall circumvention and IP hijacking, and contains our
experimental results. Section 5 investigates potential defenses based on pin-
ning. Section 6 recommends defenses against DNS rebinding attacks. Section 7
describes related work. Section 8 concludes.

2. NETWORK ACCESS IN THE BROWSER

Web content, such as HTML, JavaScript, Cascading Style Sheets (CSS), SWF
movies, and Java applets, can instruct the browser to issue network requests.
Browsers restrict this network access to prevent malicious Web sites from abus-
ing the user’s network connectivity. The browser’s security policy provides par-
tial resource isolation by restricting access to resources according to origin,
preventing content from one origin from accessing resources from another ori-
gin. The policy applies to both network access and browser state, including the
Document Object Model (DOM) interface, cookies, cache, history, and the pass-
word database. The attacks described herein circumvent the same-origin policy
for network access.

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

Protecting Browsers from DNS Rebinding Attacks • 2:5

Definition of origin. For network access, browsers enforce the same-origin
policy [Ruderman 2001] based on three components of the Uniform Resource
Locator (URL). A typical URL contains the following components.

scheme://host:port/path?query#fragment

Browsers treat two objects as belonging to the same origin if, and only
if, their URLs contain the same scheme, host name, and port number
(e.g., http://amazon.com/ is a different origin than http://amazon.co.uk/,
even though the two domains are owned by the same company).

Objects on the Internet, however, are not accessed by host name. To retrieve
an object at a given URL, the browser must first translate the URL’s host name
into an IP address and then open a socket to that IP address. If one host name
resolves to multiple IP addresses owned by multiple entities, the browser will
treat them all as if they belonged to the same origin.

Access in an origin. Within the same origin, Web content can both read
and write network resources using the HTTP protocol. Plug-ins, such as Flash
Player and Java, let Web content access network sockets directly. Using these
plug-ins, sites can make TCP connections and, in some cases, send and receive
UDP packets. Java does not restrict access based on port number, but Flash
Player 9.0.48.0 permits access to port numbers less than 1024 only if the remote
server authorizes the connection in an XML policy served from a port number
less than 1024.

Access between origins. In general, Web content from one origin can send
HTTP requests to servers in another origin, but Web content cannot read
HTTP responses from foreign origins, effectively restricting access to “send-
only.” Flash Player allows Web content to read HTTP responses from foreign
origins, but only if the remote server responds with an XML policy that au-
thorizes the read. Flash Player also allows reading and writing data on TCP
connections to arbitrary port numbers, again provided the remote server re-
sponds with a suitable XML policy on an appropriate port.

By convention, certain types of Web content are assumed to be public li-
braries, such as JavaScript, CSS, SWF movies, and Java applets. These content
types can be included from foreign origins. For example, one origin can include
a CSS file from another origin. Web content can also read certain properties of
other types of objects across origins. For example, the height and width of an
image are visible to foreign origins.

Prohibited access. Some kinds of network access are prohibited even within
the same origin. Internet Explorer 7 blocks port numbers 19 (chargen), 21
(FTP), 25 (SMTP), 110 (POP3), 119 (NNTP), and 143 (IMAP). Firefox 2 and
Safari 3 block those plus 51 additional port numbers. Some of these port re-
strictions prevent Web sites from launching denial-of-service attacks or send-
ing spam email, whereas others prevent universal cross-site scripting via the
HTML form protocol attack [Topf 2001].

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

2:6 • C. Jackson et al.

3. DNS REBINDING VULNERABILITIES

The network access security policy in Web browsers is based on host names,
which are bound by the Domain Name System (DNS) to IP addresses. An at-
tacker mounting a DNS rebinding attack subverts the browser’s security policy
by binding his or her host name to two IP addresses: one that belongs to the
attacker and one the belongs to a target server.

3.1 Standard Rebinding Vulnerabilities

A standard rebinding attack uses a single browser technology (e.g., JavaScript,
Java, or Flash Player) to connect to multiple IP addresses with the same host
name.

Multiple A records. When a browser resolves a host name, the authoritative
DNS server can respond with multiple A records indicating the IP addresses
of the host. The first DNS rebinding attack [Dean et al. 1996] in 1996 lever-
aged multiple A records to confuse the security policy of the Java Virtual Ma-
chine (JVM). The attack proceeds as follows.

(1) The user’s browser visits a malicious Web site, http://attacker.com/, that
contains a Java applet. The attacker’s DNS server (which is authoritative
for attacker.com) responds with two A records: one that contains the IP
address of the attacker’s Web server and another that contains the IP ad-
dress of the target’s Web server. The JVM chooses one of these IP addresses,
typically the first, opens a socket, and retrieves the applet.

(2) The browser runs the attacker’s applet, which requests that the JVM open
a socket to the target’s IP address. The JVM opens the socket because the
target’s IP address is contained in the DNS response for attacker.com.

Current versions of the JVM are not vulnerable to this attack because the
Java security policy has been changed. The JVM now prevents applets from
connecting to an IP address other than the IP address from which the JVM
loaded the applet. (More recent DNS rebinding attacks on Java are described
in Section 3.2.)

In the JavaScript variation of this attack, the attacker responds with an
HTML document containing malicious JavaScript that instructs the browser to
load another URL from attacker.com. The attacker’s server refuses this second
TCP connection, forcing the browser to fail over to the target IP address [Johns
2006]. By using a RST packet to refuse the connection, the attacker can cause
some browsers to fail over to the new IP address after one second. Subsequent
network requests issued by the attacker’s script will connect to the new IP
address, which points to the target.

Time-varying DNS. In 2001, security researchers discovered an extension
to the original DNS rebinding attack using time-varying DNS [Roskind 2001].

(1) The user’s browser visits a malicious Web site, http://attacker.com/. The
attacker’s DNS server responds with a single A record binding attacker.com
to the attacker’s IP address with a very short TTL.

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

Protecting Browsers from DNS Rebinding Attacks • 2:7

(2) The HTML document from the attacker’s server contains a script that issues
an XMLHttpRequest to another URL on attacker.com. The DNS cache has
expired, causing the browser to issue another DNS query for attacker.com.
The attacker’s DNS server now responds with a single A record binding
attacker.com to the target’s IP address.

(3) The browser connects to the target server and retrieves the specified URL.
Because the request was issued to the same host name as the original
malicious script, the browser delivers the HTTP response to the attacker’s
script, which then exfiltrates the data back to the attacker’s server.

Pinning in current browsers. Current browsers defend against standard
rebinding attacks by “pinning” host names to IP address, preventing host names
from referring to multiple IP addresses.

— Internet Explorer 7 pins DNS bindings for 30 minutes.1 Unfortunately, if the
attacker’s host name resolves to multiple A records and the current server
becomes unavailable, the browser will fail over to another IP address within
one second.

— Internet Explorer 6 also pins DNS bindings for 30 minutes, but an attacker
can cause the browser to release its pin after one second by forcing a connec-
tion to the current IP address to fail, for example, by loading an image from a
closed port via the HTML element .

— Firefox 1.5 and 2 cache DNS entries for between 60 and 120 seconds. DNS
entries expire after the value of the current minute increments twice.2 To
compute when the pin will expire, the attacker can use JavaScript to read
the user’s clock. Using multiple A records, an attacker can mount an DNS
rebinding attack in approximately one second.

— Opera 9 behaves similarly to Internet Explorer 6, pinning for approximately
12 minutes, but the browser can be tricked into releasing its pin after
4 seconds by connecting to a closed port.

— Safari 3 pins DNS bindings for one second. Because the pinning time is so
low, the attacker may need to send a “Connection: close” HTTP header to
ensure that the browser does not re-use the existing TCP connection to the
attacker.

Flash Player. Flash Player 9.0.48.0 lets SWF movies open TCP sockets to
arbitrary hosts, provided the recipient authorizes the connection by serving an
appropriate XML policy [Adobe 2006]. According to Adobe, Flash Player 9 is
installed on 55.8% of Web browsers as of December 2006 [Adobe 2008]; our
experiment in April 2007 observes Flash Player 9 on 86.9% of browsers. Flash
Player 9.0.48.0 is vulnerable to the following rebinding attack, which is shown
in Figure 2.

1The duration is set by the registry keys DnsCacheTimeout and ServerInfoTimeOut in

HKEY CURRENT USER\SOFTWARE\Microsoft Windows\CurrentVersion\Internet Settings.
2The duration is set by the network.dnsCacheExpiration preference value.

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

2:8 • C. Jackson et al.

Fig. 2. DNS rebinding attack using the Flash Player policy file.

(1) The user’s browser visits a malicious Web site that embeds a SWF movie.

(2) The SWF movie opens a socket on a port less than 1024 to attacker.com,
which the attacker’s authoritative DNS server binds to the IP address of
the attacker’s server with a short TTL.

(3) Flash Player sends on the socket.

(4) The attacker responds with the following XML.

This XML policy authorizes all domains to make socket connections to all
ports.

(5) The SWF movie opens a socket to a port number of the attacker’s choice
on attacker.com. Because the DNS cache has expired, Flash Player makes
another DNS query for attacker.com, which the attacker’s authoritative
DNS server now binds to the IP address of the target.

Flash Player 9.0.48.0 permits the socket connection to the target server be-
cause it does not pin host names to a single IP address. If the attacker were
to serve the policy file from port number 1024 or above, Flash Player would
authorize connections only to port numbers 1024 or above.

3.2 Multipin Vulnerabilities

Current browsers use a number of plug-ins to render Web pages, several of
which provide Web content some form of direct socket access. These plug-ins
restrict socket access based on the origin of the content opening the connection.
Even if each plug-in pins host names to IP addresses, there is no guarantee that

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

Protecting Browsers from DNS Rebinding Attacks • 2:9

Fig. 3. DNS rebinding using LiveConnect.

all the technologies will pin the attacker’s host name to the same IP address.
If one component pins attacker.com to the attacker’s IP address and another
pins attacker.com to the target’s IP address, the attacker can make use of
intercomponent communication to circumvent the restrictions on network ac-
cess. Some of these attacks have been discussed previously in the full-disclosure
community [Anvil 2007].

Java. Java, installed on 87.6%3 of Web browsers [Adobe 2008], lets Web con-
tent open TCP connections back to its origin. The Java Virtual Machine (JVM)
pins DNS host names to IP addresses using a different pin database than the
browser, opening up the possibility of multipin DNS rebinding vulnerabilities.
Java applets themselves are not vulnerable because the JVM retrieves applets
directly from the network, letting the JVM pin the origin of the applet to the cor-
rect IP address. However, the JVM (JRE 6 Update 2 and earlier [Mitre 2007a,
2007b]) is vulnerable to the following attacks.

— LiveConnect bridges JavaScript and the JVM in Firefox and Opera, permit-
ting script access to the Java standard library, including the Socket class,
without an accompanying applet. The browser pins attacker.com to the at-
tacker’s IP address, but the JVM spawned by LiveConnect does a second
DNS resolve and pins attacker.com to the target’s IP address. As shown in
Figure 3, the attacker can exploit this pin mismatch to open and communi-
cate on a socket from the user’s machine to an IP address and port of the
attacker’s choice. Additionally, the attacker can use this technique to com-
municate on UDP sockets with high-numbered source ports.

— Applets behind HTTP proxies are also vulnerable to a multipin attack. If the
user accesses the Web via an HTTP proxy, there is yet another DNS resolver

3We observed 98.1% penetration in our experiment.

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

2:10 • C. Jackson et al.

involved: the proxy. When the JVM retrieves an applet via a proxy, the JVM
requests the applet by host name, not by IP address. If the applet opens a
socket, the JVM does a second DNS resolve and the attacker can cause the
JVM to pin to the target’s IP address.

— Relative paths can cause multipin vulnerabilities. If a server hosts an HTML
document that embeds an applet using a relative path, that server can be
the target of a multipin attack. The attacker first binds attacker.com to the
target server’s IP address, pinning the browser to the target. The browser
retrieves the target’s HTML document, which embeds an applet via a rela-
tive path. The browser completes the relative path to an absolute path on
attacker.com and instructs the JVM to load the applet. The JVM does a sec-
ond DNS resolve, pins to the attacker, and retrieves an applet from the at-
tacker. The malicious applet then instructs the browser, using a javascript:
URL, to issue XMLHttpRequests to attacker.com, which the browser has
pinned to the target’s IP address.

Flash Player. Flash Player would still be vulnerable to multipin attacks,
even if it strictly pinned host names to IP addresses. In some embeddings,
Flash Player does not retrieve SWF movies directly from the network. Instead,
the browser downloads the movie and spawns the Flash Player, transferring the
movie’s origin by URL. When the attacker’s movie attempts to open a socket,
Flash Player does a second DNS resolution and could receive a different IP
address than the browser.

In addition to sockets, Flash Player provides a facility for retrieving URL, the
URLLoader class. URLLoader is not vulnerable to multipin attacks because Flash
Player fulfills URL requests using the browser’s network stack, providing the
attacker little additional leverage over the browser’s native XMLHttpRequest.

4. ATTACKS USING DNS REBINDING

An attacker can exploit the DNS rebinding vulnerabilities described in Section 3
to mount a number of attacks. For some of these attacks, the attacker requires
the direct socket access afforded by DNS rebinding with Flash Player and Java.
Other attacks require only the ability to read HTTP responses from the target.
The attacks fall into two broad categories, according to the attacker’s goal.

— Firewall Circumvention. Using DNS rebinding, the attacker can connect to
otherwise inaccessible machines behind firewalls. With direct socket access,
the attacker can interact with a number of internal services besides HTTP.

— IP Hijacking. The attacker can also use DNS rebinding to access publicly
available servers from the user’s IP address. This allows the attacker to take
advantage of the target server’s implicit or explicit trust in the user’s IP
address.

To mount these attacks, the attacker must first attract the user to attacker.com,
causing the browser to render the attacker’s active content. Section 4.3
discusses a number of techniques an attacker can use to drive traffic to
attacker.com. Once loaded onto the client’s machine, the attacker’s code can

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

Protecting Browsers from DNS Rebinding Attacks • 2:11

exploit DNS rebinding vulnerabilities to communicate with any machine reach-
able by the user’s machine.

4.1 Firewall Circumvention

A firewall restricts traffic between computer networks in different zones of
trust. Typically, organizations deploy firewalls to block connections from the
public Internet to internal machines and to mediate connections from internal
machines to Internet servers with application-level proxies. Firewall circum-
vention attacks bypass the prohibition on inbound connections, allowing the
attacker to connect to internal servers while the user is visiting attacker.com
(see Figure 1).

Spidering the intranet. The attacker need not specify the target machine
by IP address. Instead, the attacker can guess the internal host name of the
target, for example hr.corp.company.com, and rebind attacker.com to a CNAME
record pointing to that host name. The browser’s own recursive DNS resolver
will complete the resolution and return the IP address of the target. Intranet
host names are often guessable and occasionally disclosed publicly [Microsoft
2004; Edwards 2005]. Using this technique, the attacker need not scan IP ad-
dresses to find an interesting target. However, this technique is incompatible
with vulnerabilities that require the attacker’s DNS server to return multiple
A records.

Having found a machine on the intranet, the attacker can connect to the ma-
chine over HTTP and request the / document. If the server responds with an
HTML document, the attacker can follow the document’s hyperlinks, eventually
spidering the organization’s intranet. Web servers behind corporate firewalls
often host confidential documents, relying on the firewall to prevent untrusted
users from accessing the documents. Using a DNS rebinding attack, the at-
tacker can leverage the user’s browser to read these documents and exfiltrate
them to the attacker, for example, by submitting an HTML form to the attacker’s
Web server.

Compromising unpatched machines. Network administrators often do not
patch internal machines as quickly as Internet-facing machines because the
patching process is time consuming, expensive, and can have unpredictable
effects. Using DNS rebinding, an attacker can attempt to exploit known vul-
nerabilities in machines on the internal network. In particular, the attacker
can attempt to exploit the user’s machine itself. The attacks against the client
itself originate from localhost and so bypass software firewalls and other se-
curity checks, including many designed to mitigate serious vulnerabilities. If
an exploit succeeds, the attacker can establish a presence within the firewall
that persists even after the user closes his or her browser.

Abusing internal open services. Internal networks contain many open ser-
vices intended for internal use only. For example, network printers often accept
print jobs from internal machines without additional authentication. The at-
tacker can use direct socket access to command network printers to exhaust

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

2:12 • C. Jackson et al.

their toner and paper supplies. Similarly, users behind firewalls often feel com-
fortable creating file shares or FTP servers accessible to anonymous users un-
der the assumption that the servers will be available only to users within the
network. With the ability to read and write arbitrary sockets, the attacker can
exfiltrate the shared documents and use these servers to store illicit information
for later retrieval. Additionally, consumer routers are often installed without
changing the default password, making them an attractive target for reconfig-
uration attacks by malicious Web sites [Stamm et al. 2006]. Firmware patches
have attempted to secure routers against cross-site scripting and cross-site re-
quest forgery, in an effort to prevent reconfiguration attacks. DNS rebinding
attacks bypass these defenses and let an attacker access the router’s configu-
ration interface as if the attacker was behind the firewall.

4.2 IP Hijacking

Attackers can also use DNS rebinding attacks against machines on the public
Internet. In these attacks, the attacker does not leverage the user’s machine
to connect to otherwise inaccessible services. Instead, the attacker abuses the
implicit or explicit trust that public services place in the user’s IP address.
After hijacking the user’s IP address, the attacker can perpetrate a number of
attacks.

Click fraud. Web publishers are often paid by Web advertisers per adver-
tisement click. Fraudulent publishers can increase their advertising revenue
by generating fake advertisement clicks, and advertisers can drain competi-
tors’ budgets by clicking on their advertisements. The exact algorithms used
by advertising networks to detect these “invalid” clicks are proprietary, but
the IP address initiating the click is widely believed to be an essential input.
In fact, one common use of bot networks is to generate clicks [Daswani et al.
2007]. Although generating a fraudulent click appears require only the ability
to send an HTTP request to the advertisement network, many networks defend
against send-only attacks by including a unique nonce with every advertising
impression. Clicks lacking the correct nonce are rejected as invalid, requiring
the attacker to read the nonce from an HTTP response in order to register a
click. Using DNS rebinding to commit click fraud is highly cost effective because
the attacker can buy advertising impressions, which cost tens of cents per thou-
sand, and convert them into clicks, worth tens of cents each. In fact, the attack
is sufficiently cost effective that the attacker need not convert every purchased
impression into a click. Instead, the fraudster can use the vast majority of the
purchased impressions to generate fake impressions on the publisher’s site,
maintaining a believable click-through rate.

Spam. Many email servers blacklist IP addresses that are known to send
spam email [Spamhaus 2007]. By hijacking a user’s IP address, an attacker
can send spam email from an IP address with a clean reputation. To send spam
email, the attacker must send packets to SMTP servers on port 25, an action
blocked by most browsers but permitted by Flash Player and Java. Addition-
ally, an attacker can often send spam email using the user’s actual mail relay.

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

Protecting Browsers from DNS Rebinding Attacks • 2:13

Even service providers that require successful authentication via POP3 before
sending email are not protected because users typically leave their desktop mail
clients open and polling their POP3 servers.

IP-based authentication. Although discouraged by security profession-
als [Fenzi and Wreski 2004], many Internet services still employ IP-based au-
thentication. For example, the ACM Digital Library makes the full text of ar-
ticles available only to subscribers, who are often authenticated by IP address.
After hijacking an authorized IP address, the attacker can access the protected
service, defeating the authentication mechanism. Because the communication
originates from an IP address actually authorized to use the service, the attack
can be difficult for the service provider to detect.

Framing users. An attacker who hijacks a user’s IP address can perform
misdeeds and frame the user. For example, an attacker can attempt to gain
unauthorized access to another computer system using a hijacked IP address
as a proxy. As the attack originates from the hijacked IP address, the target
system’s logs will implicate the user, not the attacker, in the crime. Moreover,
if the attacker hosts the malicious Web site over HTTPS, the user’s browser
will not cache the responses and the user might be left without exculpatory
evidence.

4.3 Proof-of-Concept Experiment

We developed proof-of-concept exploits for DNS rebinding vulnerabilities in
Flash Player 9.0.48.0, LiveConnect, Java applets with proxy servers, and the
browser itself. Our system consists of a custom DNS server (authoritative for
a domain we control), a custom Flash Player policy server, and a standard
Apache Web server. The various technologies issue DNS queries that encode
the attacker and target IP addresses, together with a nonce, in the subdomain.
For each nonce, the DNS server first responds with the attacker’s IP address
(with a zero TTL) and thereafter with the target’s IP address.

Methodology. We used our proof-of-concept to test experimentally the prac-
ticality of mounting DNS rebinding attacks. We ran a SWF advertisement on
an advertising network targeting the keywords “Firefox,” “game,” “Internet Ex-
plorer,” “video,” and “YouTube.” One machine in our laboratory played the role
of the attacker and another played the role of a target. The attack server ran a
custom DNS server, a custom Flash Player policy server, and a standard Apache
Web server hosting the advertisement. The target ran a standard Apache Web
server to log successful attacks. The SWF advertisement exploited the DNS
rebinding vulnerability described in Section 3.1 to retrieve an XML document
from the target server in our lab. To succeed, the attack requires only the user’s
browser view our advertisement. No user interaction is required.

The experiment lasted until the user navigated away from the advertise-
ment, at which time we lost the ability to use the user’s network connection.
For privacy, we collected only properties typically disclosed by browsers when
viewing Web pages (e.g., plug-in support, user agent, and external IP address).

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

2:14 • C. Jackson et al.

Table II. Percentage of Impressions by

Vulnerability

Vulnerability Impressions

Flash Player 9 86.9%

LiveConnect 24.4%

Java+Proxy 2.2%
Total Multi-Pin 90.6%

The experiment conformed to the terms of service of the advertising network
and to the guidelines of the independent review board at our institution. Ev-
ery network operation produced by the advertisement could have been pro-
duced by a legitimate SWF advertisement, but we produced the operations
through the Socket API, demonstrating the ability to make arbitrary TCP
connections.

Results. We ran the ad beginning at midnight EDT on three successive
nights in late April 2007. We bid $0.50 per 1000 impressions and spent $10
per day, garnering approximately 20,000 impressions per day. Due to a server
misconfiguration, we disregarded approximately 10,000 impressions. We also
disregarded 19 impressions from our university. We in total counted 50,951
impressions from 44,924 unique IP addresses (40.2% IE7, 32.3% IE6, 23.5%
Firefox, 4% Other).

We ran the DNS rebinding experiment on the 44,301 (86.9%) impressions
that reported support for Flash Player 9. We did not attempt to exploit other re-
binding vulnerabilities (see Table 2). The experiment was successful on 30,636
(60.1%) impressions and 27,480 unique IP addresses. The attack was less suc-
cessful on the 1,672 impressions served to Mac OS, succeeding 36.4% of the
time, compared to a success rate of 70.0% on the 49,535 (97.2%) Windows
impressions.4 Mac OS is more resistant to this DNS rebinding attack because
the Mac OS caches DNS entries despite their zero TTL.

For each successful experiment, we measured how long an attacker could
have used the user’s network access by loading the target document at exponen-
tially longer intervals, as shown in Figure 4. The median impression duration
was 32 seconds, with 25% of the impressions lasting longer than 256 seconds.
We observed 9 impressions with a duration of at least 36.4 hours, 25 at least
18.2 hours, and 81 at least 9.1 hours. In aggregate, we obtained 100.3 machine-
days of network access. These observations are consistent with those of Lam
et al. [2006]. The large number of attacks ending between 4.2 and 8.5 minutes
suggests that this is a common duration of time for users to spend viewing a
Web page.

Discussion. Our experimental results show that DNS rebinding vulnerabil-
ities are widespread and cost effective to exploit on a large scale. Each impres-
sion costs $0.0005 and 54% of the impressions convert to successful attacks from
unique IP addresses. For the impressions that reported a vulnerable version of

4We succeeded in opening a socket with 2 of the 11 PlayStation 3 impressions (those with Flash

Player 9), but none of the 12 Nintendo Wii impressions were vulnerable.

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

Protecting Browsers from DNS Rebinding Attacks • 2:15

Fig. 4. Duration of successful attacks.

Flash Player but did not lead to a successful attack, we speculate the attack
was unsuccessful due to firewalls that blocked outbound connections to our pol-
icy server, insufficient impression duration, or users who have disabled Flash
Player.

To temporarily hijack 100,000 IP addresses an attacker would need to spend
less than $100. This technique compares favorably to renting a traditional bot
network for sending spam email and committing click fraud, for two reasons.
First, these applications require large numbers of “fresh” IP addresses for short
durations because compromised machines are quickly blacklisted. Second, al-
though estimates of the rental cost of bot networks vary [Warner 2004; Goodin
2005; Daswani et al. 2007], this technique appears to be at least one or two
orders of magnitude less expensive.

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

2:16 • C. Jackson et al.

5. PINNING

Historically, browsers have used pinning to defend against DNS rebinding at-
tacks. In this section, we explore improvements to pinning and discuss several
disadvantages to the pinning approach.

5.1 Smarter Pinning

Pinning trades-off availability for security. RFC 1035 [Mockapetris 1987] pro-
vides for small (and even zero) TTLs to enable dynamic DNS and robust be-
havior in the case of server failure, but respecting these TTLs allows rebinding
attacks. Over the last decade, browsers have experimented with different pin
durations and pin release heuristics, leading some vendors to shorten their pin
duration to improve robustness [Fisher et al. 2003]. However, duration is not
the only parameter that can be varied in a pinning policy.

Pin width. Browsers can vary the “width” of their pins by permitting host
names to be rebound within a set of IP addresses that meet some similar-
ity heuristic. Selecting an optimal width as well as duration enables a better
trade-off between security and robustness than optimizing duration alone. One
promising policy is to allow rebinding within a /24 network. For example, if a
host name resolved to 171.64.78.10, then the browser could let the host name
resolve to any IP address beginning with 171.64.78. The developers of the
NoScript Firefox extension [Maone 2007b] announced plans [Maone 2007a] to
adopt this pinning heuristic.

Security. When browsers use /24 network pinning, the attacker must locate
the attack server on the same /24 network as the target, making the rebinding
attack much more difficult to mount. The attack is possible only if the attacker
colocates a server at the same hosting facility or leverages a cross-site scripting
vulnerability on a colocated server. This significantly raises the bar for the at-
tacker and provides better recourses for the target because the target typically
has a business relationship with the operator of the /24 network.

Robustness. To study the robustness of /24 network pinning, we investi-
gated the IP addresses reported by the 100 most visited English-language
sites according to Alexa [2007]. We visited the homepage of these sites
and compiled a list of the 336 host names used for embedded content
(e.g., http://www.yahoo.com/ embeds images from us.i1.yimg.com). We then
issued DNS queries for these hosts every 10 minutes for 24 hours, recording the
IP addresses reported. In this experiment, 58% reported a single IP address con-
sistently across all queries. Note that geographic load balancing is not captured
in our data because we issued our queries from a single machine, mimicking
the behavior of a real user. Averaged over the 42% of hosts reporting multiple
IP addresses, if a browser pinned to an IP address at random, the expected
fraction of IP addresses available for rebinding under /24 network pinning is
81.3% compared with 16.4% under strict IP address pinning, suggesting that
/24 pinning is significantly more robust to server failure.

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

Protecting Browsers from DNS Rebinding Attacks • 2:17

Width heuristics. Other heuristics for pin width are possible. The browser
could prevent rebinding between public IP addresses and the RFC 1918
[Rekhter et al. 1996] private IP addresses. This provides greater robustness
for fail-overs across data centers and for dynamic DNS. LocalRodeo [Johns and
Winter 2007; Winter and Johns 2007] is a Firefox extension that implements
RFC 1918 pinning. As for security, RFC 1918 pinning largely prevents firewall
circumvention but does not protect against IP hijacking, nor does it prevent
firewall circumvention in the case where a firewall protects nonprivate IP ad-
dresses, which is the case for many real-life protected networks and personal
software firewalls.

Even the widest possible pinning heuristic prevents some legitimate rebind-
ing of host names. For example, public host names controlled by an organization
often have two IP addresses: a private IP address used by machines within the
firewall and a public IP address used by browsers on the Internet. Pinning
prevents employees from properly connecting to these servers after joining the
organization’s Virtual Private Network (VPN) because these host names appear
to rebind from public to private IP addresses.

Instead of using unpinning heuristics, browsers could consult server-
supplied policies to determine whether it is safe to repin a host name from
one IP address to another, providing robustness without degrading security. To
repin safely, the browser must obtain a policy from both the old and the new IP
address (because some attacks first bind to the attacker’s IP address, whereas
others first bind to the target’s IP address). Servers can supply this policy at a
well-known location, such as /crossdomain.xml, or in reverse DNS.

5.2 Pinning Pitfalls

Correctly implementing pinning has several subtleties that are critical to its
ability to defend against DNS rebinding attacks.

Common pin database. To eliminate multipin attacks, pinning-based de-
fenses require that all browser technologies that access the network share a
common pin database. Many plug-ins, including Flash Player and Silverlight,
already use the browser’s pins when issuing HTTP requests because they issue
these requests through the browser. To share DNS pins for other kinds of net-
work access, either the browser could expose an interface to its pin database
or the operating system could pin in its DNS resolver. Unfortunately, browser
vendors appear reluctant to expose such an interface [Fisher 2007; Nuuja 2007]
because changes to the plug-in interface are fragile and difficult to modify with-
out introducing forwards or backwards compatibility issues. Pinning in the op-
erating system either changes the semantics of DNS for other applications or
requires that the OS treat browsers and their plug-ins differently from other
applications.

Cache. The browser’s cache and all plug-in caches must be modified to pre-
vent DNS rebinding attacks. Currently, objects stored in the cache are retrieved
by URL, irrespective of the originating IP address, creating a DNS rebind-
ing vulnerability: A cached script from the attacker might run later when

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

2:18 • C. Jackson et al.

Fig. 5. The attacker’s Web page can read confidential information from the inner frame, which

points to an intranet site.

attacker.com is bound to the target [Soref 2003]. To prevent this attack, objects
in the cache must be retrieved by both URL and IP address. This degrades per-
formance when the browser pins to a new IP address, which might occur when
the host at the first IP address fails, the user starts a new browsing session, or
the user’s network connectivity changes.

document.domain. Even with the strictest pinning, a server is vulnerable
to rebinding attacks if the sever hosts an HTML document that executes the
following, seemingly innocuous, JavaScript.

document.domain = document.domain;

Setting document.domain to document.domain is not an NOP. Instead, this
loosens the browser’s enforcement of the same-origin policy for the current
document because the document has invited cross-origin script interactions
from any other document that has set its document.domain to the same
value [Veditz et al. 2002; Grimm et al. 2002]. This idiom is used by an
number of JavaScript libraries, such as the Struts servlet/JSP-based Web
application framework, the jsMath AJAX Mathematics library, and Sun’s
“Ultimate client-side JavaScript client sniff ” library. Using the idiom, how-
ever, renders a site vulnerable to the following attack, as shown in Fig-
ure 5. The attacker points subdomain.attacker.com at the attacker’s Web
server (e.g., 66.66.66.66) and points attacker.com at the target server (e.g.,
196.168.1.100). The target server, if it uses the aforesaid idiom, sets its
document.domain to the value attacker.com. The attacker’s server also sets
its document.domain to attacker.com and can read documents on the tar-
get server. The “Dojo” AJAX library was also affected by this issue, but
was fixed in version 0.9.0 after we explained the vulnerability to a Dojo
developer.

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

Protecting Browsers from DNS Rebinding Attacks • 2:19

6. RECOMMENDED DEFENSES

To defend against DNS rebinding attacks, we recommend changes to plug-ins,
firewalls, and servers. Plug-ins can repair their socket-level DNS rebinding
vulnerabilities by adding additional policy checks before opening sockets. Fire-
walls can unilaterally defend against their own circumvention by preventing
external host names from resolving to internal IP addresses. After the plug-ins
have repaired the socket-level vulnerabilities, individual servers can protect
themselves from DNS rebinding by validating the HTTP Host header.

6.1 Securing Socket Access

Plug-ins comprise a particular source of complexity in defending against DNS
rebinding attacks because they enable subsecond attacks, provide socket-level
network access, and operate independently from browsers. Plug-ins that grant
socket-level access to Web content either default to allowing socket connection
or they default to denying socket-level access. Different DNS rebinding defenses
are appropriate for these different socket access paradigms.

Default allow. Java defaults to allowing socket connections back the con-
tent’s origin server. In situations in which the JVM did not retrieve the content
directly from an IP address, the JVM can defend against DNS rebinding attacks
by validating that the destination server is willing to accept socket connections
from the content’s host name. Essentially, the defense requires an oracle that
determines, for a given IP address and host name, whether the server at that IP
addresses authorizes that host name. Unlike forward DNS queries in which the
host name is authoritative for responding to queries, DNS rebinding requires
that the IP address is authoritative for authorizing host names.

The reverse DNS system can be extended to authorize host names with-
out sacrificing backwards compatibility. In the simple case, the owner of
an IP address, such as 171.64.78.146, can authorize a host name, such as
www.example.com, by including the following PTR record in DNS.

146.78.64.171.in-addr.arpa. IN PTR www.example.com

This record follows the format of existing reverse DNS deployments, leveraging
the existing deployment of reverse DNS to bootstrap policy deployment. Unfor-
tunately, this record format can encode only one host name per IP address.
Many large-scale deployments host a Web server for more than one host name
on a single IP address using virtual hosting. We also propose that the JVM
consult reverse DNS records of the form given next.

www.example.com.auth.146.78.64.171.in-addr.arpa. IN A 171.64.78.146

This scheme uses the auth subdomain to authorize a set of host names for an
IP address.

One disadvantage of storing policy information in reverse DNS is that the
owner of the reverse delegation of an IP address, the ISP, might not be the
owner of the machine at that IP address. The machine can advertise the cor-
rect set of authorized host names only if the ISP is willing to delegate the auth

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

2:20 • C. Jackson et al.

subdomain to the owner or is willing to insert appropriate DNS records. Al-
ternatively, machines could advertise authorized host names over HTTP in a
well-known location, similar to crossdomain.xml, but this has several disad-
vantages: Servers accepting socket connections must run an HTTP server and
policy files served over HTTP will not be cached by the DNS infrastructure,
resulting in extra traffic comparable to favicon.ico.

Default deny. By default, Flash Player denies SWF movies socket-level ac-
cess. The destination server can opt into accepting socket connections by pro-
viding an XML policy. Flash Player can defend against DNS rebinding by con-
sidering these XML policies valid only for the IP address from which they were
obtained. If a SWF movie attempts to connect to another IP address, even one
with the same host name, Flash Player should request another policy file. If
an attacker attempts to rebind attacker.com to a target server, Flash Player
will request another XML policy from the target server to determine whether
to open the socket. This modification to the policy behavior is backwards com-
patible with existing policy deployments because all honest servers that share
a host name are expected to serve the same XML policy.

For port numbers greater than or equal to 1024, Flash Player 9.0.48.0 de-
faults to allowing socket access to the SWF movies origin server. Although
the majority of services an attacker can profitably target (e.g., SMTP, HTTP,
HTTPS, SSH, FTP, NNTP) are hosted on low-numbered ports, other services,
such as MySQL, BitTorrent, IRC, and HTTP proxies, typically listen on high-
numbered ports. We propose that Flash Player default to denying socket-
level access in these cases and use the XML policy mechanism to prevent
DNS rebinding attacks. This change breaks backwards compatibility with
existing deployments who are not hosting XML policies on high-numbered
ports.

Adoption. Sun has adopted our proposal in the JVM, both for applets behind
proxies [Mitre 2007a] and for LiveConnect [Mitre 2007b]. In both cases, the up-
dated JVM blocks network requests if the host name is not explicitly authorized
in reverse DNS. Adobe has adopted both of our proposals and has patched Flash
Player to prevent socket-level DNS rebinding vulnerabilities [Mitre 2007c]. Mi-
crosoft also adopted our proposed defense for Flash Player to secure Silverlight’s
Socket API [Microsoft 2008].

6.2 Firewall Defenses

Networks can protect themselves against firewall circumvention by forbidding
external host names from resolving to internal IP addresses, preventing the
attacker from naming an internal target server attacker.com. Without the
ability to name the target, the attacker cannot aggregate the target server into a
browser security origin under his or her control. These malicious DNS bindings
can be blocked unilaterally, either by filtering packets at the firewall [Cheswick
and Bellovin 1996] or by modifying the DNS resolvers used by machines on the
network.

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

Protecting Browsers from DNS Rebinding Attacks • 2:21

Internal IP addresses. Which IP addresses are “internal” varies by network
configuration. Although some internal networks use publicly routable IP ad-
dresses, most use RFC 1918 [Rekhter et al. 1996] private IP addresses. In
addition to the RFC 1918 addresses, many machines will respond to other IP
addresses. In some deployments, an attacker can mount a DNS rebinding at-
tack by returning a DNS record as described next.

— CNAME. Unless the filter blocks CNAME records that refer to internal host
names, an attacker can use the following DNS record to bind to an internal
IP address: attacker.com. IN CNAME www.corp.example.com. By examining
DNS responses after the external DNS resolver completes a recursive DNS
resolution, the filter can block all CNAME records.

— Localhost. In addition to 127.0.0.1, many machines listen on the entire
class A subnet 127.*.*.*.

— Zero Configuration. In the absence of DHCP, many machines will allocate
themselves an unused address in the class B subnet 169.254.*.* [Cheshire
et al. 2005]. These addresses can remain valid even after the machine receives
an address from DHCP.

— Multicast. Although not commonly used, multicast lets many machines re-
ceive data sent to a single IP address. Internal machines could respond to
IP addresses in the subnets 224-239.*.*.*, which are reserved for multi-
cast [Reynolds and Postel 1994; Meyer 1998].

— IPv6. Some machines respond to IPv6 addresses, contained in AAAA
records. The filter blocks loopback, ::1/128, link-local, fe80::/10, site-local,
fec0::/10, multicast, ff00::/8, and “globally unique local.” fc00::/7, ad-
dresses [Hinden and Deering 2003; Hinden and Haberman 2005]. To assist
backwards compatibility, the IPv4 address space is embedded into the IPv6
address space twice [Hinden and Deering 2003]; specifically, once at ::/96
and once at ::ffff:00:00:00:00/96. The filter should block undesirable
IPv4 addresses from both embeddings because some machines listen for their
IPv4 addresses at both of their embedded IPv6 addresses.

Deployment. There are three classes of firewall which can defend against
DNS rebinding by preventing external host names from resolving to internal
IP addresses.

— Enterprise. By blocking outbound traffic on port 53, a firewall administrator
for an organization can force all internal machines, including HTTP proxies
and VPN clients, to use a hardened DNS server that prevents external names
from resolving to internal IP addresses. We implemented this approach in
a 300-line C program, called dnswall [Bortz et al. 2007]. Running alongside
BIND, dnswall modifies DNS responses that attempt to bind external names
to internal IP addresses. A number of organizations have deployed dnswall to
protect their corporate networks, and dnswall is included in FreeBSD [Haupt
2008].

— Consumer. Consumer firewalls can also defend their private networks from
firewall circumvention by using dnswall to block DNS responses that contain

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

2:22 • C. Jackson et al.

private IP addresses. These firewalls, such as those produced by Linksys,
can implement this defense without user configuration because these de-
vices often manage the allocation of private IP addresses. Moreover, the ven-
dors of these devices have an incentive to patch their products because DNS
rebinding attacks can be used to access the private configuration interface
of these devices and potentially reconfigure them to mount further attacks
on their owners. A number of open-source consumer firewall projects have
adopted dnswall-like protection, including Dnsmasq [Kelley 2008], Open-
Wrt [Fainelli 2008], and DD-WRT [Gottschall et al. 2008].

— Software. Software firewalls can defend the local loopback interface from
DNS rebinding attacks by blocking DNS resolutions to 127.*.*.*. This tech-
nique does not protect services that bind to the external network interface,
even if the software firewall blocks inbound packets. The technique does,
however, defend services that bind to the local loopback interface. Window
and Linux both have a number of sensitive services, such as RPC, that listen
on ports on the local loopback interface.

6.3 Server Defense: Host Header Checking

HTTP 1.1 requires that user agents include a Host header in HTTP requests
that specifies the host name of the server [Fielding et al. 1999]. This feature
is used extensively by HTTP proxies and by Web servers to host many virtual
hosts on one IP address. Now that plug-in vendors have repaired the socket-
level vulnerabilities, servers can use the Host header to protect themselves
against DNS rebinding attacks.

During a DNS rebinding attack, the browser sends a Host header with
the attacker’s host name to the target server. Using browser APIs such as
XMLHttpRequest, Web content can specify HTTP headers but cannot modify
the Host header. A server can protect itself from DNS rebinding attacks by
rejecting HTTP requests that contain an unrecognized or unexpected Host
header [Megacz 2002; Ross 2007]. For example, Apache servers can defend
themselves using the ModSecurity following rule.

SecRule REQUEST_HEADERS:Host !^www\.example\.com(:\d+)?$ deny,
status:403

This rule validates that the Host header contains the expected value, rejecting
requests with unexpected or absent Host headers.

Limitations. Checking the Host header is inconvenient for servers that do
not know their host name. For example, most home routers to not know the
host name of their Web configuration interface. Because these servers are typ-
ically behind firewalls, the firewall defenses described in Section 6.2 are more
appropriate. Older versions of Flash Player and the JVM have DNS rebinding
vulnerabilities that allow an attacker to spoof the Host header [Klein 2006].
These outdated plug-ins also have other vulnerabilities that can be used to by-
pass the browser’s same-origin policy entirely [Mitre 2008, 2007d], preventing
any of defenses presented in this article from protecting servers or firewalls.
We recommend that users of these older versions update immediately.

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

Protecting Browsers from DNS Rebinding Attacks • 2:23

7. RELATED WORK

IP-based origins. Another approach to repairing DNS rebinding vulnera-
bilities is to refine the browser’s definition of a security origin to include the re-
mote server’s IP address [Megacz 2002]. In this approach, an attacker’s script,
retrieved when attacker.com was bound to the IP address of the attacker’s
server, will be unable to access content retrieved when attacker.com is bound
to the IP address of the target. IP-based origins are more robust than pinning
because a single browsing session can fail-over from one IP address to an-
other. Such a fail-over, however, will likely break long-lived AJAX applications,
such as Gmail, because the browser will prevent the application from issuing
XMLHttpRequests to the new IP address.

There are a number of challenges to implementing IP-based origins.
(1) Proxies. Browsers behind a proxy server do not know the actual IP address

of the remote server and thus cannot properly refine origins. There are two
proposals [Megacz 2002; Megacz and Meketa 2003] for including IP addresses
in proxy responses, but neither has been adopted.

(2) Cache. Browsers typically do not store the IP address of cached resources.
IP-based origins require augmenting the browser cache with IP addresses, as
described in Section 5.1.

(3) Plug-Ins. All browser technologies, including plug-ins, must implement
IP-based origins and interacting technologies must hand-off refined origins cor-
rectly.

(4) Relative Paths. IP-based origins do not prevent DNS rebinding attacks if
the target server embeds active content, such as a script, a SWF movie, or a
Java applet, via a relative path [Jackson and Barth 2008].

Using browsers as bots. To create a Puppetnet [Lam et al. 2006], an at-
tacker lures Web users to an malicious site and then distracts them while their
browsers participate in a coordinated attack. Puppetnets can be used for dis-
tributed denial of service, but cannot be used to mount the attacks described
in Section 4 because Puppetnets cannot read HTTP responses from different
origins nor can they connect to forbidden ports such as 25. Browsers can also
be misused to scan behind firewalls [Grossman and Niedzialkowski 2006] and
reconfigure home routers [Stamm et al. 2006]. These techniques often rely on
guessing a device’s default passwords or on an underlying cross-site scripting
or cross-site request forgery vulnerability.

Dynamic pharming. Some attacks [Karlof et al. 2007; Gajek et al. 2008]
combine DNS rebinding with compromised DNS servers. These “dynamic”
pharming attacks use DNS rebinding to rebind a trusted host name from the
IP address of the attacker’s server to the IP address of the target server. If the
site employs HTTPS, this attack typically requires the user to dismiss common-
name mismatch certificate errors. However, DNS rebinding is not required for
these attacks because the attacker can simply forward the TLS session to the
target server at the TCP layer. Instead of rebinding the trusted host name, the
attacker can simply cease to forward TCP packets.

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

2:24 • C. Jackson et al.

8. CONCLUSIONS

DNS rebinding has been a recurring source of browser vulnerabilities for the
past decade. The classic defense, pinning, reduces robustness and has difficulty
scaling to modern browsers, which use a number of plug-ins to render Web
content. If each plug-in maintains a separate pin database, an attacker can use
intratechnology communication to mount a multipin DNS rebinding attack.
Plug-ins create additional security challenges because they expose additional
functionality to Web content, including the ability to communicate directly on
sockets. Using DNS rebinding, an attacker can use this functionality to obtain
socket-level access to an arbitrary host from the user’s machine, circumventing
firewalls and hijacking the user’s IP address.

Because DNS rebinding attacks do not require the attacker to compromise
DNS, these vulnerabilities can be exploited on a large scale at low cost. By
running a Web advertisement, an attacker can supply content to a large num-
ber of browsers at a fraction of a cent per impression. The simple act of ren-
dering the attacker’s rich-media advertisement is sufficient to mount a DNS
rebinding attack. Our experiments indicate that this technique is an order of
magnitude more cost effective than creating and operating a traditional bot
network.

To prevent these attacks, we recommend specific changes to the security
policies of plug-ins such as Flash Player and Java. The vendors of these plug-
ins have adopted our suggestions and deployed patches to their users, pre-
venting widespread exploitation of socket-level DNS rebinding vulnerabilities.
To prevent firewall circumvention, we recommend that organizations deploy a
circumvention-resistant DNS resolver, such as dnswall, that prevents external
host names from resolving to internal IP addresses. These resolvers are now
part of several open-source distributions, including FreeBSD, and have been
deployed at a number of organizations.

Even with these defenses deployed, servers on the public Internet can still
be targeted by DNS rebinding attacks. A server can defend itself against these
attacks by validating the HTTP Host header because the header contains the
attacker’s host name during an attack. Upon receiving an unexpected Host
header, a server should respond with a redirect to a URL containing the correct
host name. This defense is especially important for servers that place trust,
either explicitly or implicitly, in the browser’s IP address.

ACKNOWLEDGMENTS

We thank D. Dean, D. Fisher, J. Grossman, M. Johns, D. Kaminsky, C. Karlof,
J. Roskind, and D. Wallach for their helpful suggestions and feedback. We thank
Google for providing the resources to implement dnswall.

REFERENCES

ADOBE. 2006. Adobe Flash Player 9 security. http://www.adobe.com/devnet/flashplayer/articles/

flash player 9 security.

pdf.

ADOBE. 2008. Flash Player penetration. http://www.adobe.com/products/player census/flash-

player/.

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

Protecting Browsers from DNS Rebinding Attacks • 2:25

ALEXA. 2007. Top sites. http://www.alexa.com/site/ds/top sites?ts mode=global.

ANVIL, K. 2007. Anti-DNS pinning + socket in flash. http://www.jumperz.net/.

ARENDS, R., AUSTEIN, R., LARSON, M., MASSEY, D., AND ROSE, S. 2005. DNS security introduction

and requirements. RFC 4033.

BORTZ, A., BARTH, A., AND JACKSON, C. 2007. Google dnswall. http://code.google.com/p/google-

dnswall/.

CHESHIRE, S., ABOBA, B., AND GUTTMAN, E. 2005. Dynamic configuration of IPv4 link-local ad-

dresses. IETF RFC 3927.

CHESWICK, W. AND BELLOVIN, S. 1996. A DNS filter and switch for packet-filtering gateways. In

Proceedings of the USENIX Annual Technical Conference.
DASWANI, N. AND STOPPELMAN, M. 2007. The anatomy of Clickbot.A. In Proceedings of 1st Workshop

on Hot Topics in Understanding Botnets (HotBots).
DEAN, D., FELTEN, E. W., AND WALLACH, D. S. 1996. Java security: From HotJava to Netscape and

beyond. In IEEE Symposium on Security and Privacy.
EDWARDS, D. 2005. Your MOMA knows best. http://xooglers.blogspot.com/2005/12/your-moma-

knows-best.html.

FAINELLI, F. 2008. The OpenWrt embedded development framework. In Free and Open Source
Software Developers’ European Meeting.

FENZI, K. AND WRESKI, D. 2004. Linux security HOWTO.

FIELDING, R., GETTYS, J., MOGUL, J., FRYSTYK, H., MASINTER, L., LEACH, P., AND BERNERS-LEE, T. 1999.

Hypertext Transfer Protocol—HTTP/1.1. RFC 2616.

FISHER, D. 2007. Personal communication.

FISHER, D. ET AL. 2003. Problems with new DNS cache (“pinning” forever).

https://bugzilla.mozilla.org/show bug.cgi?id=162871.

GAJEK, S., SCHWENK, J., AND XUAN, C. 2008. On the insecurity of Microsoft’s identity metasystem.

Tech. Rep. HGI-TR-2008-003, Horst Görtz Institute for IT Security, Ruhr University Bochum.

May. http://demo.nds.rub.de/cardspace/.

GOODIN, D. 2005. Calif. man pleads guilty to felony hacking. Assoc. Press.
GOTTSCHALL, S. ET AL. 2008. DD-WRT (version 24). http://www.dd-wrt.com/.

GRIMM, S. ET AL. 2002. Setting document.domain doesn’t match an implicit parent domain.

https://bugzilla.mozilla.org/show bug.cgi?id=183143.
GROSSMAN, J. AND NIEDZIALKOWSKI, T. 2006. Hacking intranet Websites from the outside:

JavaScript malware just got a lot more dangerous. In Blackhat USA. Invited talk.
HAUPT, E. 2008. dnswall FreeBSD port. http://www.freebsd.org/cgi/cvsweb.cgi/ports/dns/dnswall/.

HINDEN, R. AND DEERING, S. 2003. Internet protocol version 6 (IPv6) addressing architecture. IETF

RFC 3513.

HINDEN, R. AND HABERMAN, B. 2005. Unique local IPv6 unicast addresses. IETF RFC 4193.

JACKSON, C. AND BARTH, A. 2008. Beware of finer-grained origins. In Web 2.0 Security and Privacy.
JOHNS, M. 2006. (Somewhat) breaking the same-origin policy by undermining DNS pinning.

http://shampoo.antville.org/stories/1451301/.

JOHNS, M. AND WINTER, J. 2007. Protecting the Intranet against “JavaScript Malware” and related

attacks. In Proceedings of the GI International Conference on Detection of Intrusions and Malware,
and Vulnerability Assessment (DIMVA).

KARLOF, C. K., SHANKAR, U., TYGAR, D., AND WAGNER, D. 2007. Dynamic pharming attacks and the

locked same-origin policies for Web browsers. In Proceedings of the ACM Conference on Computer
and Communications Security (CCS).

KELLEY, S. 2008. Dnsmasq (version 2.41). http://www.thekelleys.org.uk/dnsmasq/doc.html.

KLEIN, A. 2006. Host header cannot be trusted as an anti anti DNS-pinning measure.

http://www.securityfocus.com/archive/1/445490.

LAM, V. T., ANTONATOS, S., AKRITIDIS, P., AND ANAGNOSTAKIS, K. G. 2006. Puppetnets: Misusing

Web browsers as a distributed attack infrastructure. In Proceedings of the ACM Conference on
Computer and Communications Security (CCS).

MAONE, G. 2007a. DNS spoofing/pinning. http://sla.ckers.org/forum/read.php?6,4511,14500.

MAONE, G. 2007b. NoScript. http://noscript.net/.

MEGACZ, A. 2002. XWT Foundation security advisory. http://www.megacz.com/research/sop.txt.

MEGACZ, A. AND MEKETA, D. 2003. X-RequestOrigin. http://www.xwt.org/x-requestorigin.txt.

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

2:26 • C. Jackson et al.

MEYER, D. 1998. Administratively scoped IP multicast. IETF RFC 2365.

MICROSOFT. 2004. Microsoft Web enterprise portal. http://www.microsoft.com/technet/itshowcase/

content/MSWebTWP.mspx.

MICROSOFT. 2008. Socket class (System.Net.Sockets). http://msdn.microsoft.com/en-us/library/

system.net.sockets.socket(VS.95).aspx.

MITRE. 2007a. CVE-2007-5273.

MITRE. 2007b. CVE-2007-5274.

MITRE. 2007c. CVE-2007-5275.

MITRE. 2007d. CVE-2007-6244.

MITRE. 2008. CVE-2008-1192.

MOCKAPETRIS, P. 1987. Domain names—Implementation and specification. IETF RFC 1035.

NUUJA, C. 2007. Personal communication.

OLLMANN, G. 2005. The pharming guide. http://www.ngssoftware.com/papers/ThePharmingGuide.

pdf.

REKHTER, Y., MOSKOWITZ, B., KARRENBERG, D., DE GROOT, G. J., AND LEAR, E. 1996. Address allocation

for private Internets. IETF RFC 1918.

REYNOLDS, J. AND POSTEL, J. 1994. Assigned numbers. IETF RFC 1700.

ROSKIND, J. 2001. Attacks against the Netscape browser. In RSA Conference. Invited talk.
ROSS, D. 2007. Notes on DNS pinning. http://blogs.msdn.com/dross/archive/2007/07/09/notes-on-

dns-pinning.aspx.

RUDERMAN, J. 2001. JavaScript security: Same origin. http://www.mozilla.org/projects/security/

components/same-origin.html.

SOREF, J. 2003. DNS: Spoofing and pinning. http://viper.haque.net/ timeless/blog/11/.

SPAMHAUS. 2007. The Spamhaus block list. http://www.spamhaus.org/sbl/.

STAMM, S., RAMZAN, Z., AND JAKOBSSON, M. 2006. Drive-By pharming. Tech. Rep. 641, Computer

Science Department, Indiana University. December.

TOPF, J. 2001. HTML form protocol attack. http://www.remote.org/jochen/sec/hfpa/hfpa .

VEDITZ, D. ET AL. 2002. Document.domain abused to access hosts behind firewall. https://bugzilla.

mozilla.org/show bug.cgi?id=154930.
WARNER, B. 2004. Home PCs rented out in sabotage-for-hire racket. Reuters.
WINTER, J. AND JOHNS, M. 2007. LocalRodeo: Client-Side protection against JavaScript Malware.

http://databasement.net/labs/localrodeo/.

Received June 2008; revised September 2008; accepted October 2008

ACM Transactions on the Web, Vol. 3, No. 1, Article 2, Publication date: January 2009.

Enhancing Byte-Level
Network Intrusion Detection Signatures with Context

Robin Sommer
TU München

Germany

sommer@in.tum.de

Vern Paxson
International Computer Science Institute and

Lawrence Berkeley National Laboratory
Berkeley, CA, USA

vern@icir.org

ABSTRACT
Many network intrusion detection systems (NIDS) use byte sequen-
ces as signatures to detect malicious activity. While being highly
efficient, they tend to suffer from a high false-positive rate. We
develop the concept of contextual signatures as an improvement of
string-based signature-matching. Rather than matching fixed strings
in isolation, we augment the matching process with additional con-
text. When designing an efficient signature engine for the NIDS
Bro, we provide low-level context by using regular expressions for
matching, and high-level context by taking advantage of the se-
mantic information made available by Bro’s protocol analysis and
scripting language. Therewith, we greatly enhance the signature’s
expressiveness and hence the ability to reduce false positives. We
present several examples such as matching requests with replies,
using knowledge of the environment, defining dependencies be-
tween signatures to model step-wise attacks, and recognizing ex-
ploit scans.

To leverage existing efforts, we convert the comprehensive sig-
nature set of the popular freeware NIDS Snort into Bro’s language.
While this does not provide us with improved signatures by itself,
we reap an established base to build upon. Consequently, we evalu-
ate our work by comparing to Snort, discussing in the process sev-
eral general problems of comparing different NIDSs.

Categories and Subject Descriptors: C.2.0 [Computer-Communi-
cation Networks]: General – Security and protection.

General Terms: Performance, Security.

Keywords: Bro, Network Intrusion Detection, Pattern Matching,
Security, Signatures, Snort, Evaluation

1. INTRODUCTION
Several different approaches are employed in attempting to detect

computer attacks. Anomaly-based systems derive (usually in an au-
tomated fashion) a notion of “normal” system behavior, and report
divergences from this profile, an approach premised on the notion
that attacks tend to look different in some fashion from legitimate
computer use. Misuse detection systems look for particular, explicit
indications of attacks (Host-based IDSs inspect audit logs for this
while network-based IDSs, or NIDSs, inspect the network traffic).

Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
CCS’03, October 27–31, 2003, Washington, DC, USA.
Copyright 2003 ACM 1-58113-738-9/03/0010 …$5.00.

In this paper, we concentrate on one popular form of misuse de-
tection, network-based signature matching in which the system in-
spects network traffic for matches against exact, precisely-described
patterns. While NIDSs use different abstractions for defining such
patterns, most of the time the term signature refers to raw byte se-
quences. Typically, a site deploys a NIDS where it can see network
traffic between the trusted hosts it protects and the untrusted exterior
world, and the signature-matching NIDS inspects the passing pack-
ets for these sequences. It generates an alert as soon as it encounters
one. Most commercial NIDSs follow this approach [19], and also
the most well-known freeware NIDS, Snort [29]. As an example,
to detect the buffer overflow described in CAN-2002-0392 [9],
Snort’s signature #1808 looks for the byte pattern 0xC0505289-
E150515250B83B000000CD80 [2] in Web requests. Keeping
in mind that there are more general forms of signatures used in in-
trusion detection as well—some of which we briefly discuss in §2—
in this paper we adopt this common use of the term signature.

Signature-matching in this sense has several appealing proper-
ties. First, the underlying conceptual notion is simple: it is easy
to explain what the matcher is looking for and why, and what sort
of total coverage it provides. Second, because of this simplicity,
signatures can be easy to share, and to accumulate into large “at-
tack libraries.” Third, for some signatures, the matching can be
quite tight: a match indicates with high confidence that an attack
occurred.

On the other hand, signature-matching also has significant lim-
itations. In general, especially when using tight signatures, the
matcher has no capability to detect attacks other than those for
which it has explicit signatures; the matcher will in general com-
pletely miss novel attacks, which, unfortunately, continue to be de-
veloped at a brisk pace. In addition, often signatures are not in fact
“tight.” For example, the Snort signature #1042 to detect an exploit
of CVE-2000-0778 [9] searches for “Translate: F” in Web
requests; but it turns out that this header is regularly used by certain
applications. Loose signatures immediately raise the major problem
of false positives: alerts that in fact do not reflect an actual attack.
A second form of false positive, which signature matchers likewise
often fail to address, is that of failed attacks. Since at many sites
attacks occur at nearly-continuous rates, failed attacks are often of
little interest. At a minimum, it is important to distinguish between
them and successful attacks.

A key point here is that the problem of false positives can po-
tentially be greatly reduced if the matcher has additional context at
its disposal: either additional particulars regarding the exact activ-
ity and its semantics, in order to weed out false positives due to
overly general “loose” signatures; or the additional information of
how the attacked system responded to the attack, which often indi-
cates whether the attack succeeded.

262

In this paper, we develop the concept of contextual signatures,
in which the traditional form of string-based signature matching is
augmented by incorporating additional context on different levels
when evaluating the signatures. First of all, we design and imple-
ment an efficient pattern matcher similar in spirit to traditional sig-
nature engines used in other NIDS. But already on this low-level
we enable the use of additional context by (i) providing full regu-
lar expressions instead of fixed strings, and (ii) giving the signature
engine a notion of full connection state, which allows it to corre-
late multiple interdependent matches in both directions of a user
session. Then, if the signature engine reports the match of a sig-
nature, we use this event as the start of a decision process, instead
of an alert by itself as is done by most signature-matching NIDSs.
Again, we use additional context to judge whether something alert-
worthy has indeed occurred. This time the context is located on a
higher-level, containing our knowledge about the network that we
have either explicitly defined or already learned during operation.

In §3.5, we will show several examples to demonstrate how the
concept of contextual signatures can help to eliminate most of the
limitations of traditional signatures discussed above. We will see
that regular expressions, interdependent signatures, and knowledge
about the particular environment have significant potential to reduce
the false positive rate and to identify failed attack attempts. For
example, we can consider the server’s response to an attack and
the set of software it is actually running—its vulnerability profile—
to decide whether an attack has succeeded. In addition, treating
signature matches as events rather than alerts enables us to analyze
them on a meta-level as well, which we demonstrate by identifying
exploit scans (scanning multiple hosts for a known vulnerability).

Instrumenting signatures to consider additional context has to be
performed manually. For each signature, we need to determine what
context might actually help to increase its performance. While this
is tedious for large sets of already-existing signatures, it is not an
extra problem when developing new ones, as such signatures have
to be similarly adjusted to the specifics of particular attacks anyway.
Contextual signatures serve as a building block for increasing the
expressivess of signatures; not as a stand-alone solution.

We implemented the concept of contextual signatures in the
framework already provided by the freeware NIDS Bro [25]. In
contrast to most NIDSs, Bro is fundamentally neither an anomaly-
based system nor a signature-based system. It is instead partitioned
into a protocol analysis component and a policy script component.
The former feeds the latter via generating a stream of events that
reflect different types of activity detected by the protocol analy-
sis; consequently, the analyzer is also referred to as the event en-
gine. For example, when the analyzer sees the establishment of
a TCP connection, it generates a connection established
event; when it sees an HTTP request it generates http request
and for the corresponding reply http reply; and when the event
engine’s heuristics determine that a user has successfully authenti-
cated during a Telnet or Rlogin session, it generates login suc-
cess (likewise, each failed attempt results in a login failure
event).

Bro’s event engine is policy-neutral: it does not consider any
particular events as reflecting trouble. It simply makes the events
available to the policy script interpreter. The interpreter then ex-
ecutes scripts written in Bro’s custom scripting language in order
to define the response to the stream of events. Because the lan-
guage includes rich data types, persistent state, and access to timers
and external programs, the response can incorporate a great deal of
context in addition to the event itself. The script’s reaction to a par-
ticular event can range from updating arbitrary state (for example,
tracking types of activity by address or address pair, or grouping re-

lated connections into higher-level “sessions”) to generating alerts
(e.g., via syslog) or invoking programs for a reactive response.

More generally, a Bro policy script can implement signature-style
matching—for example, inspecting the URIs in Web requests, the
MIME-encoded contents of email (which the event engine will first
unpack), the user names and keystrokes in login sessions, or the
filenames in FTP sessions—but at a higher semantic level than as
just individual packets or generic TCP byte streams.

Bro’s layered approach is very powerful as it allows a wide range
of different applications. But it has a significant shortcoming:
while, as discussed above, the policy script is capable of perform-
ing traditional signature-matching, doing so can be cumbersome for
large sets of signatures, because each signature has to be coded as
part of a script function. This is in contrast to the concise, low-level
languages used by most traditional signature-based systems. In ad-
dition, if the signatures are matched sequentially, then the overhead
of the matching can become prohibitive. Finally, a great deal of
community effort is already expended on developing and dissemi-
nating packet-based and byte-stream-based signatures. For exam-
ple, the 1.9.0 release of Snort comes with a library of 1,715 signa-
tures [2]. It would be a major advantage if we could leverage these
efforts by incorporating such libraries.

Therefore, one motivation for this work is to combine Bro’s flexi-
bility with the capabilities of other NIDSs by implementing a signa-
ture engine. But in contrast to traditional systems, which use their
signature matcher more or less on its own, we tightly integrate it
into Bro’s architecture in order to provide contextual signatures. As
discussed above, there are two main levels on which we use addi-
tional context for signature matching. First, at a detailed level, we
extend the expressiveness of signatures. Although byte-level pattern
matching is a central part of NIDSs, most only allow signatures to
be expressed in terms of fixed strings. Bro, on the other hand, al-
ready provides regular expressions for use in policy scripts, and we
use them for signatures as well. The expressiveness of such patterns
provides us with an immediate way to express syntactic context.
For example, with regular expressions it is easy to express the no-
tion “string XYZ but only if preceded at some point earlier by string
ABC”. An important point to keep in mind regarding regular expres-
sion matching is that, once we have fully constructed the matcher,
which is expressed as a Deterministic Finite Automaton (DFA), the
matching can be done in O(n) time for n characters in the input,
and also Ω(n) time. (That is, the matching always takes time linear
in the size of the input, regardless of the specifics of the input.) The
“parallel Boyer-Moore” approaches that have been explored in the
literature for fast matching of multiple fixed strings for Snort [12, 8]
have a wide range of running times—potentially sublinear in n, but
also potentially superlinear in n. So, depending on the particulars
of the strings we want to match and the input against which we do
the matching, regular expressions might prove fundamentally more
efficient, or might not; we need empirical evaluations to determine
the relative performance in practice. In addition, the construction of
a regular expression matcher requires time potentially exponential
in the length of the expression, clearly prohibitive, a point to which
we return in §3.1.

Second, on a higher level, we use Bro’s rich contextual state to
implement our improvements to plain matching described above.
Making use of Bro’s architecture, our engine sends events to the
policy layer. There, the policy script can use all of Bro’s already
existing mechanisms to decide how to react. We show several such
examples in §3.5.

Due to Snort’s large user base, it enjoys a comprehensive and
up-to-date set of signatures. Therefore, although for flexibility we
have designed a custom signature language for Bro, we make use

263

of the Snort libraries via a conversion program. This program takes
an unmodified Snort configuration and creates a corresponding Bro
signature set. Of course, by just using the same signatures in Bro as
in Snort, we are not able to improve the resulting alerts in terms of
quality. But even if we do not accompany them with additional
context, they immediately give us a baseline of already widely-
deployed signatures. Consequently, Snort serves us as a reference.
Throughout the paper we compare with Snort both in terms of qual-
ity and performance. But while doing so, we encountered several
general problems for evaluating and comparing NIDSs. We be-
lieve these arise independently of our work with Bro and Snort, and
therefore describe them in some detail. Keeping these limitations
in mind, we then evaluate the performance of our signature engine
and find that it performs well.

§2 briefly summarizes related work. In §3 we present the main
design ideas behind implementing contextual signatures: regular
expressions, integration into Bro’s architecture, some difficulties
with using Snort signatures, and examples of the power of the Bro
signature language. In §4 we discuss general problems of evaluating
NIDSs, and then compare Bro’s signature matching with Snort’s. §5
summarizes our conclusions.

2. RELATED WORK
[4] gives an introduction to intrusion detection in general, defin-

ing basic concepts and terminology.
In the context of signature-based network intrusion detection,

previous work has focussed on efficiently matching hundreds of
fixed strings in parallel: [12] and [8] both present implementations
of set-wise pattern matching for Snort [29]. For Bro’s signature en-
gine, we make use of regular expressions [18]. They give us both
flexibility and efficiency. [17] presents a method to incrementally
build the underlying DFA, which we can use to avoid the potentially
enormous memory and computation required to generate the com-
plete DFA for thousands of signatures. An extended form of regular
expressions has been used in intrusion detection for defining se-
quences of events [30], but to our knowledge no NIDS uses them
for actually matching multiple byte patterns against the payload of
packets.

In this paper, we concentrate on signature-based NIDS. Snort is
one of the most-widely deployed systems and relies heavily on its
signature set. Also, most of the commercial NIDSs are signature-
based [19], although there are systems that use more powerful con-
cepts to express signatures than just specifying byte patterns.
NFR [28], for example, uses a flexible language called N-Code to
declare its signatures. In this sense, Bro already provides sophisti-
cated signatures by means of its policy language. But the goal of our
work is to combine the advantages of a traditional dedicated pattern
matcher with the power of an additional layer abstracting from the
raw network traffic. IDS like STAT [35] or Emerald [26] are more
general in scope than purely network-based systems. They con-
tain misuse-detection components as well, but their signatures are
defined at a higher level. The STAT framework abstracts from low-
level details by using transitions on a set of states as signatures. A
component called NetSTAT [36] defines such state transitions based
on observed network-traffic. Emerald, on the other hand, utilizes
P-BEST [20], a production-based expert system to define attacks
based on a set of facts and rules. Due to their general scope, both
systems use a great deal of context to detect intrusions. On the other
hand, our aim is to complement the most common form of signa-
ture matching—low-level string matching—with context, while still
keeping its efficiency.

The huge number of generated alerts is one of the most impor-
tant problems of NIDS (see, for example, [23]). [3] discusses some

statistical limits, arguing in particular that the false-alarm rate is the
limiting factor for the performance of an IDS.

Most string-based NIDSs use their own signature language, and
are therefore incompatible. But since most languages cover a com-
mon subset, it is generally possible to convert the signatures of one
system into the syntax of another. ArachNIDS [1], for example,
generates signatures dynamically for different systems based on a
common database, and [32] presents a conversion of Snort signa-
tures into STAT’s language, although it does not compare the two
systems in terms of performance. We take a similar approach, and
convert Snort’s set into Bro’s new signature language.

For evaluation of the new signature engine, we take Snort as a
reference. But while comparing Bro and Snort, we have encoun-
tered several difficulties which we discuss in §4. They are part of
the general question of how to evaluate NIDSs. One of the most
comprehensive evaluations is presented in [21, 22], while [24] of-
fers a critique of the methodology used in these studies. [14] further
extends the evaluation method by providing a user-friendly environ-
ment on the one hand, and new characterizations of attack traffic
on the other hand. More recently, [10] evaluates several commer-
cial systems, emphasizing the view of an analyst who receives the
alerts, finding that these systems ignore relevant information about
the context of the alerts. [15] discusses developing a benchmark for
NIDSs, measuring their capacity with a representative traffic mix.
(Note, in §4.2 we discuss our experiences with the difficulty of find-
ing “representative” traces.)

3. CONTEXTUAL SIGNATURES
The heart of Bro’s contextual signatures is a signature engine de-

signed with three main goals in mind: (i) expressive power, (ii) the
ability to improve alert quality by utilizing Bro’s contextual state,
and (iii) enabling the reuse of existing signature sets. We discuss
each in turn. Afterwards, we present our experiences with Snort’s
signature set, and finally show examples which demonstrate appli-
cations for the described concepts.

3.1 Regular Expressions
A traditional signature usually contains a sequence of bytes that

are representative of a specific attack. If this sequence is found
in the payload of a packet, this is an indicator of a possible at-
tack. Therefore, the matcher is a central part of any signature-based
NIDS. While many NIDSs only allow fixed strings as search pat-
terns, we argue for the utility of using regular expressions. Regular
expressions provide several significant advantages: first, they are
far more flexible than fixed strings. Their expressiveness has made
them a well-known tool in many applications, and their power arises
in part from providing additional syntactic context with
which to sharpen textual searches. In particular, character classes,
union, optional elements, and closures prove very useful for speci-
fying attack signatures, as we see in §3.5.1.

Surprisingly, given their power, regular expressions can be
matched very efficiently. This is done by compiling the expres-
sions into DFAs whose terminating states indicate whether a match
is found. A sequence of n bytes can therefore be matched with
O(n) operations, and each operation is simply an array lookup—
highly efficient.

The total number of patterns contained in the signature set of
a NIDSs can be quite large. Snort’s set, for example, contains
1,715 distinct signatures, of which 1,273 are enabled by default.
Matching these individually is very expensive. However, for fixed
strings, there are algorithms for matching sets of strings simulta-
neously. Consequently, while Snort’s default engine still works it-
eratively, there has been recent work to replace it with a “set-wise”

264

matcher [8, 12].1 On the other hand, regular expressions give us set-
wise matching for free: by using the union operator on the individ-
ual patterns, we get a new regular expression which effectively com-
bines all of them. The result is a single DFA that again needs O(n)
operations to match against an n byte sequence. Only slight modifi-
cations have been necessary to extend the interface of Bro’s already-
existing regular expression matcher to explicitly allow grouping of
expressions.

Given the expressiveness and efficiency of regular expressions,
there is still a reason why a NIDS might avoid using them: the
underlying DFA can grow very large. Fully compiling a regular ex-
pression into a DFA leads potentially to an exponential number of
DFA states, depending on the particulars of the patterns [18]. Con-
sidering the very complex regular expression built by combining
all individual patterns, this straight-forward approach could easily
be intractable. Our experience with building DFAs for regular ex-
pressions matching many hundreds of signatures shows that this is
indeed the case. However, it turns out that in practice it is possible
to avoid the state/time explosion, as follows.

Instead of pre-computing the DFA, we build the DFA “on-the-
fly” during the actual matching [17]. Each time the DFA needs to
transit into a state that is not already constructed, we compute the
new state and record it for future reuse. This way, we only store
DFA states that are actually needed. An important observation is
that for n new input characters, we will build at most n new states.
Furthermore, we find in practice (§4.3) that for normal traffic the
growth is much less than linear.

However, there is still a concern that given inauspicious traffic—
which may actually be artificially crafted by an attacker—the state
construction may eventually consume more memory than we have
available. Therefore, we also implemented a memory-bounded DFA
state cache. Configured with a maximum number of DFA states,
it expires old states on a least-recently-used basis. In the sequel,
when we mention “Bro with a limited state cache,” we are referring
to such a bounded set of states (which is a configuration option for
our version of Bro), using the default bound of 10,000 states.

Another important point is that it’s not necessary to combine all
patterns contained in the signature set into a single regular expres-
sion. Most signatures contain additional constraints like IP address
ranges or port numbers that restrict their applicability to a subset of
the whole traffic. Based on these constraints, we can build groups
of signatures that match the same kind of traffic. By collecting only
those patterns into a common regular expression for matching the
group, we are able to reduce the size of the resulting DFA dras-
tically. As we show in §4, this gives us a very powerful pattern
matcher still efficient enough to cope with high-volume traffic.

3.2 Improving Alert Quality by Using Context
Though pattern matching is a central part of any signature-based

NIDSs, as we discussed above there is potentially great utility in
incorporating more context in the system’s analysis prior to gener-
ating an alert, to ensure that there is indeed something alert-worthy
occurring. We can considerably increase the quality of alerts, while
simultaneously reducing their quantity, by utilizing knowledge
about the current state of the network. Bro is an excellent tool for
this as it already keeps a lot of easily accessible state.

The new signature engine is designed to fit nicely into Bro’s lay-
ered architecture as an adjunct to the protocol analysis event en-
gine (see Figure 1). We have implemented a custom language for
defining signatures. It is mostly a superset of other, similar lan-

1The code of [12] is already contained in the Snort distribution, but
not compiled-in by default. This is perhaps due to some subtle bugs,
some of which we encountered during our testing as well.

Figure 1: Integrating the signature engine (adapted from [25])

Event Control

Event Engine

Event stream

Real−time notification

Signature Control

Packet filter

Policy script

Filtered packet stream

Packet stream

Signature
Engine

Signatures

Network

Policy Layer

Packet capture

guages, and we describe it in more detail in §3.3. A new component
placed within Bro’s middle layer matches these signatures against
the packet stream. Whenever it finds a match, it inserts a new event
into the event stream. The policy layer can then decide how to re-
act. Additionally, we can pass information from the policy layer
back into the signature engine to control its operation. A signature
can specify a script function to call whenever a particular signature
matches. This function can then consult additional context and in-
dicate whether the corresponding event should indeed be generated.
We show an example of this later in §3.5.4.

In general, Bro’s analyzers follow the communication between
two endpoints and extract protocol-specific information. For exam-
ple, the HTTP analyzer is able to extract URIs requested by Web
clients (which includes performing general preprocessing such as
expanding hex escapes) and the status code and items sent back
by servers in reply, whereas the FTP analyzer follows the applica-
tion dialog, matching FTP commands and arguments (such as the
names of accessed files) with their corresponding replies. Clearly,
this protocol-specific analysis provides significantly more context
than does a simple view of the total payload as an undifferentiated
byte stream.

The signature engine can take advantage of this additional in-
formation by incorporating semantic-level signature matching. For
example, the signatures can include the notion of matching against
HTTP URIs; the URIs to be matched are provided by Bro’s HTTP
analyzer. Having developed this mechanism for interfacing the sig-
nature engine with the HTTP analyzer, it is now straight forward
to extend it to other analyzers and semantic elements (indeed, we
timed how long it took to add and debug interfaces for FTP and
Finger, and the two totalled only 20 minutes).

Central to Bro’s architecture is its connection management. Each
network packet is associated with exactly one connection. This no-
tion of connections allows several powerful extensions to traditional
signatures. First of all, Bro reassembles the payload stream of TCP
connections. Therefore, we can perform all pattern matching on the
actual stream (in contrast to individual packets). While Snort has a
preprocessor for TCP session reassembling, it does so by combin-
ing several packets into a larger “virtual” packet. This packet is then
passed on to the pattern matcher. Because the resulting analysis
remains packet-based, it still suffers from discretization problems
introduced by focusing on packets, such as missing byte sequences
that cross packet boundaries. (See a related discussion in [25] of the
problem of matching strings in TCP traffic in the face of possible
intruder evasion [27].)

In Bro, a signature match does not necessarily correspond to an
alert; as with other events, that decision is left to the policy script.
Hence, it makes sense to remember which signatures have matched
for a particular connection so far. Given this information, it is then
possible to specify dependencies between signatures like “signature

265

A only matches if signature B has already matched,” or “if a host
matches more than N signatures of type C, then generate an alert.”
This way, we can for example describe multiple steps of an attack.
In addition, Bro notes in which direction of a connection a particular
signature has matched, which gives us the notion of request/reply
signatures: we can associate a client request with the corresponding
server reply. A typical use is to differentiate between successful and
unsuccessful attacks. We show an example in §3.5.3.

More generally, the policy script layer can associate arbitrary
kinds of data with a connection or with one of its endpoints. This
means that any information we can deduce from any of Bro’s other
components can be used to improve the quality of alerts. We demon-
strate the power of this approach in §3.5.2.

Keeping per-connection state for signature matching naturally
raises the question of state management: at some point in time we
have to reclaim state from older connections to prevent the system
from exhausting the available memory. But again we can leverage
the work already being done by Bro. Independently of our signa-
tures, it already performs a sophisticated connection-tracking using
various timeouts to expire connections. By attaching the matching
state to the already-existing per-connection state, we assure that the
signature engine works economically even with large numbers of
connections.

3.3 Signature Language
Any signature-based NIDS needs a language for actually defining

signatures. For Bro, we had to choose between using an already
existing language and implementing a new one. We have decided
to create a new language for two reasons. First, it gives us more
flexibility. We can more easily integrate the new concepts described
in §3.1 and §3.2. Second, for making use of existing signature sets,
it is easier to write a converter in some high-level scripting language
than to implement it within Bro itself.

Snort’s signatures are comprehensive, free and frequently up-
dated. Therefore, we are particularly interested in converting them
into our signature language. We have written a corresponding Py-
thon script that takes an arbitrary Snort configuration and outputs
signatures in Bro’s syntax. Figure 2 shows an example of such a
conversion.

Figure 2: Example of signature conversion
alert tcp any any -> [a.b.0.0/16,c.d.e.0/24] 80

( msg:”WEB-ATTACKS conf/httpd.conf attempt”;
nocase; sid:1373; flow:to_server,established;
content:”conf/httpd.conf”; […] )

(a) Snort

signature sid-1373 {
ip-proto == tcp
dst-ip == a.b.0.0/16,c.d.e.0/24
dst-port == 80
# The payload below is actually generated in a
# case-insensitive format, which we omit here
# for clarity.
payload /.*conf\/httpd\.conf/
tcp-state established,originator
event “WEB-ATTACKS conf/httpd.conf attempt”

}%

(b) Bro

It turns out to be rather difficult to implement a complete parser
for Snort’s language. As far as we have been able to determine, its
syntax and semantics are not fully documented, and in fact often
only defined by the source code. In addition, due to different inter-
nals of Bro and Snort, it is sometimes not possible to keep the exact
semantics of the signatures. We return to this point in §4.2.

As the example in Figure 2 shows, our signatures are defined by
means of an identifier and a set of attributes. There are two main

types of attributes: (i) conditions and (ii) actions. The conditions
define when the signature matches, while the actions declare what
to do in the case of a match. Conditions can be further divided into
four types: header, content, dependency, and context.

Header conditions limit the applicability of the signature to a sub-
set of traffic that contains matching packet headers. For TCP, this
match is performed only for the first packet of a connection. For
other protocols, it is done on each individual packet. In general,
header conditions are defined by using a tcpdump-like [33] syntax
(for example, tcp[2:2] == 80 matches TCP traffic with desti-
nation port 80). While this is very flexible, for convenience there
are also some short-cuts (e.g., dst-port == 80).

Content conditions are defined by regular expressions. Again,
we differentiate two kinds of conditions here: first, the expression
may be declared with the payload statement, in which case it is
matched against the raw packet payload (reassembled where appli-
cable). Alternatively, it may be prefixed with an analyzer-specific
label, in which case the expression is matched against the data as
extracted by the corresponding analyzer. For example, the HTTP
analyzer decodes requested URIs. So, http /(etc\/(passwd
|shadow)/ matches any request containing either etc/passwd
or etc/shadow.

Signature conditions define dependencies between signatures.
We have implemented requires-signature, which specifies
another signature that has to match on the same connection first,
and requires-reverse-signature, which additionally re-
quires the match to happen for the other direction of the connection.
Both conditions can be negated to match only if another signature
does not match.

Finally, context conditions allow us to pass the match decision
on to various components of Bro. They are only evaluated if all
other conditions have already matched. For example, we have im-
plemented a tcp-state condition that poses restrictions on the
current state of the TCP connection, and eval, which calls an ar-
bitrary script policy function.

If all conditions are met, the actions associated with a signature
are executed: event inserts a signature match event into the
event stream, with the value of the event including the signature
identifier, corresponding connection, and other context. The policy
layer can then analyze the signature match.

3.4 Snort’s Signature Set
Snort comes with a large set of signatures, with 1,273 enabled

by default [2]. Unfortunately, the default configuration turns out to
generate a lot of false positives. In addition, many alerts belong to
failed exploit attempts executed by attackers who scan networks for
vulnerable hosts. As noted above, these are general problems of
signature-based systems.

The process of selectively disabling signatures that are not appli-
cable to the local environment, or “tuning,” takes time, knowledge
and experience. With respect to Snort, a particular problem is that
many of its signatures are too general. For example, Snort’s signa-
ture #1560:

alert tcp $EXTERNAL_NET any
-> $HTTP_SERVERS $HTTP_PORTS

(msg:”WEB-MISC /doc/ access”;
uricontent:”/doc/”; flow:to_server,established;
nocase; sid:1560; […])

searches for the string /doc/ within URIs of HTTP requests.
While this signature is indeed associated with a particular vulner-
ability (CVE-1999-0678 [9]), it only makes sense to use it if you
have detailed knowledge about your site (for example, that there is
no valid document whose path contains the string /doc/). Other-
wise, the probability of a signature match reflecting a false alarm

266

is much higher than that it indicates an attacker exploiting an old
vulnerability.

Another problem with Snort’s default set is the presence of over-
lapping signatures for the same exploit. For example, signatures
#1536, #1537, #1455, and #1456 (the latter is disabled by default)
all search for CVE-2000-0432, but their patterns differ in the
amount of detail. In addition, the vulnerability IDs given in Snort’s
signatures are not always correct. For example, signature #884 ref-
erences CVE-1999-0172 and Buqtraq [6] ID #1187. But the lat-
ter corresponds to CVE-2000-0411.

As already noted, we cannot expect to avoid these limitations
of Snort’s signatures by just using them semantically unmodified in
Bro. For example, although we convert the Snort’s fixed strings into
Bro’s regular expressions, naturally they still represent fixed sets of
characters. Only manual editing would give us the additional power
of regular expressions. We give an example for such an improve-
ment in §3.5.1.

3.5 The Power of Bro Signatures
In this section, we show several examples to convey the power

provided by our signatures. First, we demonstrate how to define
more “tight” signatures by using regular expressions. Then, we
show how to identify failed attack attempts by considering the set of
software a particular server is runnning (we call this its vulnerabil-
ity profile and incorporate some ideas from [22] here) as well as the
response of the server. We next demonstrate modelling an attack in
multiple steps to avoid false positives, and finally show how to use
alert-counting for identifying exploit scans. We note that none of
the presented examples are supported by Snort without extending
its core significantly (e.g. by writing new plug-ins).

3.5.1 Using Regular Expressions
Regular expressions allow far more flexibility than fixed strings.

Figure 3 (a) shows a Snort signature for CVE-1999-0172 that
generates a large number of false positives at Saarland University’s
border router. (See §4.1 for a description of the university.) Fig-
ure 3 (b) shows a corresponding Bro signature that uses a regular
expression to identify the exploit more reliably. CVE-1999-0172
describes a vulnerability of the formmail CGI script. If an at-
tacker constructs a string of the form “…; ”
(a | instead of the ; works as well), and passes it on as argument
of the recipient CGI parameter, vulnerable formmails will ex-
ecute the included shell commands. Because CGI parameters can
be given in arbitrary order, the Snort signature has to rely on iden-
tifying the formmail access by its own. But by using a regular
expression, we can explicitly define that the recipient parame-
ter has to contain a particular character.

Figure 3: Two signatures for CVE-1999-0172
alert tcp any any -> a.b.0.0/16 80

(msg:”WEB-CGI formmail access”;
uricontent:”/formmail”;
flow:to_server,established;
nocase; sid:884; […])

(a) Snort using a fixed string

signature formmail-cve-1999-0172 {
ip-proto == tcp
dst-ip == a.b.0.0/16
dst-port = 80
# Again, actually expressed in a
# case-insensitive manner.
http /.*formmail.*\?.*recipient=[ˆ&]*[;|]/
event “formmail shell command”

}

(b) Bro using a regular expression

3.5.2 Vulnerability Profiles
Most exploits are aimed at particular software, and usually only

some versions of the software are actually vulnerable. Given
the overwhelming number of alerts a signature-matching NIDS can
generate, we may well take the view that the only attacks of interest
are those that actually have a chance of succeeding. If, for example,
an IIS exploit is tried on a Web server running Apache, one may
not even care. [23] proposes to prioritize alerts based on this kind of
vulnerability information. We call the set of software versions that
a host is running its vulnerability profile. We have implemented this
concept in Bro. By protocol analysis, it collects the profiles of hosts
on the network, using version/implementation information that the
analyzer observes. Signatures can then be restricted to certain ver-
sions of particular software.

As a proof of principle, we have implemented vulnerability pro-
files for HTTP servers (which usually characterize themselves via
the Server header), and for SSH clients and servers (which iden-
tify their specific versions in the clear during the initial protocol
handshake). We intend to extend the software identification to other
protocols.

We aim in future work to extend the notion of developing a pro-
file beyond just using protocol analysis. We can passively finger-
print hosts to determine their operating system version information
by observing specific idiosyncrasies of the header fields in the traffic
they generate, similar to the probing techniques described in [13], or
we can separately or in addition employ active techniques to explic-
itly map the properties of the site’s hosts and servers [31]. Finally,
in addition to automated techniques, we can implement a configu-
ration mechanism for manually entering vulnerability profiles.

3.5.3 Request/Reply Signatures
Further pursuing the idea to avoid alerts for failed attack attempts,

we can define signatures that take into account both directions of a
connection. Figure 4 shows an example. In operational use, we
see a lot of attempts to exploit CVE-2001-0333 to execute the
Windows command interpreter cmd.exe. For a failed attempt, the
server typically answers with a 4xx HTTP reply code, indicating an
error.2 To ignore these failed attempts, we first define one signature,
http-error, that recognizes such replies. Then we define a sec-
ond signature, cmdexe-success, that matches only if cmd.exe
is contained in the requested URI (case-insensitive) and the server
does not reply with an error. It’s not possible to define this kind of
signature in Snort, as it lacks the notion of associating both direc-
tions of a connection.

Figure 4: Request/reply signature
signature cmdexe-success {

ip-proto == tcp
dst-port == 80
http /.*[cC][mM][dD]\.[eE][xX][eE]/
event “WEB-IIS cmd.exe success”
requires-signature-opposite ! http-error
tcp-state established

}
signature http-error {
ip-proto == tcp
src-port == 80
payload /.*HTTP\/1\.. *4[0-9][0-9]/
event “HTTP error reply”
tcp-state established
}

2There are other reply codes that reflect additional types of errors,
too, which we omit for clarity.

267

3.5.4 Attacks with Multiple Steps
An example of an attack executed in two steps is the infection

by the Apache/mod ssl worm [7] (also known as Slapper),
released in September 2002. The worm first probes a target for
its potential vulnerability by sending a simple HTTP request and
inspecting the response. It turns out that the request it sends is in
fact in violation of the HTTP 1.1 standard [11] (because it does not
include a Host header), and this idiosyncracy provides a somewhat
“tight” signature for detecting a Slapper probe.

If the server identifies itself as Apache, the worm then tries
to exploit an OpenSSL vulnerability on TCP port 443. Figure 5
shows two signatures that only report an alert if these steps are
performed for a destination that runs a vulnerable OpenSSL ver-
sion. The first signature, slapper-probe, checks the payload
for the illegal request. If found, the script function is vulnera-
ble to slapper (omitted here due to limited space, see [2]) is
called. Using the vulnerability profile described above, the func-
tion evaluates to true if the destination is known to run Apache
as well as a vulnerable OpenSSL version.3 If so, the signature
matches (depending on the configuration this may or may not gen-
erate an alert by itself). The header conditions of the second sig-
nature, slapper-exploit, match for any SSL connection into
the specified network. For each, the signature calls the script func-
tion has slapper probed. This function generates a signa-
ture match if slapper-probe has already matched for the same
source/destination pair. Thus, Bro alerts if the combination of prob-
ing for a vulnerable server, plus a potential follow-on exploit of the
vulnerability, has been seen.

Figure 5: Signature for Apache/mod sslworm
signature slapper-probe {

ip-proto == tcp
dst-ip == x.y.0.0/16 # sent to local net
dst-port == 80
payload /.*GET \/ HTTP\/1\.1\x0d\x0a\x0d\x0a/
eval is_vulnerable_to_slapper # call policy fct.
event “Vulner. host possibly probed by Slapper”

}
signature slapper-exploit {

ip-proto == tcp
dst-ip == x.y.0.0/16
dst-port == 443 # 443/tcp = SSL/TLS
eval has_slapper_probed # test: already probed?
event “Slapper tried to exploit vulnerable host”

}

3.5.5 Exploit Scanning
Often attackers do not target a particular system on the Internet,

but probe a large number of hosts for vulnerabilities (exploit scan-
ning). Such a scan can be executed either horizontally (several hosts
are probed for a particular exploit), vertically (one host is probed
for several exploits), or both. While, by their own, most of these
probes are usually low-priority failed attempts, the scan itself is an
important event. By simply counting the number signature alerts
per source address (horizontal) or per source/destination pair (ver-
tical), Bro can readily identify such scans. We have implemented
this with a policy script which generates alerts like:

a.b.c.d triggered 10 signatures on host e.f.g.h
i.j.k.l triggered signature sid-1287 on 100 hosts
m.n.o.p triggered signature worm-probe on 500 hosts
q.r.s.t triggered 5 signatures on host u.v.x.y

3Note that it could instead implement a more conservative policy,
and return true unless the destination is known to not run a vulner-
able version of OpenSSL/Apache.

4. EVALUATION
Our approach for evaluating the effectiveness of the signature en-

gine is to compare it to Snort in terms of run-time performance and
generated alerts, using semantically equivalent signature sets. We
note that we do not evaluate the concept of conceptual signatures by
itself. Instead, as a first step, we validate that our implementation
is capable of acting as an effective substitute for the most-widely
deployed NIDS even when we do not use any of the advanced fea-
tures it provides. Building further on this base by thoroughly evalu-
ating the actual power of contextual signatures when deployed op-
erationally is part of our ongoing work.

During our comparision of Bro and Snort, we found several pe-
culiarities that we believe are of more general interest. Our re-
sults stress that the performance of a NIDS can be very sensitive
to semantics, configuration, input, and even underlying hardware.
Therefore, after discussing our test data, we delve into these in some
detail. Keeping these limitations in mind, we then assess the overall
performance of the Bro signature engine.

4.1 Test Data
For our testing, we use two traces:

USB-Full A 30-minute trace collected at Saarland University,
Germany (USB-Full), consisting of all traffic (including
packet contents) except for three high-volume peer-to-peer
applications (to reduce the volume). The university has 5,500
internal hosts, and the trace was gathered on its 155 Mbps
access link to the Internet. The trace totals 9.8 GB, 15.3M
packets, and 220K connections. 35% of the trace packets be-
long to HTTP on port 80, 19% to eDonkey on port 4662, and
4% to ssh on port 22, with other individual ports being less
common than these three (and the high-volume peer-to-peer
that was removed).

LBL-Web A two-hour trace of HTTP client-side traffic, including
packet contents, gathered at the Lawrence Berkeley National
Laboratory (LBL), Berkeley, USA (LBL-Web). The labora-
tory has 13,000 internal hosts, and the trace was gathered on
its Gbps access link to the Internet. The trace totals 667MB,
5.5M packets, and 596K connections.

Unless stated otherwise, we performed all measurements on
550MHz Pentium-3 systems containing ample memory (512MB or
more). For both Snort and Bro’s signature engine, we used Snort’s
default signature set. We disabled Snort’s “experimental” set of sig-
natures as some of the latest signatures use new options which are
not yet implemented in our conversion program. In addition, we
disabled Snort signature #526, BAD TRAFFIC data in TCP
SYN packet. Due to Bro matching stream-wise instead of packet-
wise, it generates thousands of false positives. We discuss this in
§4.2. In total, 1,118 signatures are enabled. They contain 1,107
distinct patterns and cover 89 different service ports. 60% of the
signatures cover HTTP traffic. For LBL-Web, only these were acti-
vated.

For Snort, we enabled the preprocessors for IP defragmentation,
TCP stream reassembling on its default ports, and HTTP decoding.
For Bro, we have turned on TCP reassembling for the same ports
(even if otherwise Bro would not reassemble them because none of
the usual event handlers indicated interest in traffic for those ports),
enabled its memory-saving configuration (“@load reduce-
memory”), and used an inactivity timeout of 30 seconds
(in correspondence with Snort’s default session timeout). We con-
figured both systems to consider all packets contained in the traces.
We used the version 1.9 branch of Snort, and version 0.8a1 of Bro.

268

4.2 Difficulties of Evaluating NIDSs
The evaluation of a NIDS is a challenging undertaking, both in

terms of assessing attack recognition and in terms of assessing per-
formance. Several efforts to develop objective measures have been
made in the past (e.g., [21, 22, 15]), while others stress the diffi-
culties with such approaches [24]. During our evaluation, we en-
countered several additional problems that we discuss here. While
these arose in the specific context of comparing Snort and Bro, their
applicability is more general.

When comparing two NIDSs, differing internal semantics can
present a major problem. Even if both systems basically perform
the same task—capturing network packets, rebuilding payload, de-
coding protocols—that task is sufficiently complex that it is almost
inevitable that the systems will do it somewhat differently. When
coupled with the need to evaluate a NIDS over a large traffic trace
(millions of packets), which presents ample opportunity for the dif-
fering semantics to manifest, the result is that understanding the
significance of the disagreement between the two systems can en-
tail significant manual effort.

One example is the particular way in which TCP streams are re-
assembled. Due to state-holding time-outs, ambiguities (see [27,
16] and [25] for discussion of how these occur for benign reasons in
practice) and non-analyzed packets (which can be caused by packet
filter drops, or by internal sanity checks), TCP stream analyzers will
generally wind up with slightly differing answers for corner cases.

Snort, for example, uses a preprocessor that collects a number of
packets belonging to the same session until certain thresholds are
reached and then combines them into “virtual” packets. The rest of
Snort is not aware of the reassembling and still only sees packets.
Bro, on the other hand, has an intrinsic notion of a data stream.
It collects as much payload as needed to correctly reconstruct the
next in-sequence chunk of a stream and passes these data chunks
on as soon as it is able to. The analyzers are aware of the fact that
they get their data chunk-wise, and track their state across chunks.
They are not aware of the underlying packetization that lead to those
chunks. While Bro’s approach allows true stream-wise signatures,
it also means that the signature engine loses the notion of “packet
size”: packets and session payload are decoupled for most of Bro’s
analyzers. However, Snort’s signature format includes a way of
specifying the packet size. Our signature engine must fake up an
equivalent by using the size of the first matched payload chunk for
each connection, which can lead to differing results.

Another example of differing semantics comes from the behavior
of protocol analyzers. Even when two NIDS both decode the same
protocol, they will differ in the level-of-detail and their interpreta-
tion of protocol corner cases and violations (which, as mentioned
above, are in fact seen in non-attack traffic [25]). For example, both
Bro and Snort extract URIs from HTTP sessions, but they do not
interpret them equally in all situations. Character encodings within
URIs are sometimes decoded differently, and neither contains a full
Unicode decoder. The anti-IDS tool Whisker [37] can actively ex-
ploit these kinds of deficiencies. Similarly, Bro decodes pipelined
HTTP sessions; Snort does not (it only processes the first URI in a
series of pipelined HTTP requests).

Usually, the details of a NIDS can be controlled by a number of
options. But frequently for a Bro option there is no equivalent Snort
option, and vice versa. For example, the amount of memory used
by Snort’s TCP reassembler can be bounded to a fixed value. If this
limit is reached, old data is expired aggressively. Bro relies solely
on time-outs. Options like these often involve time-memory trade-
offs. The more memory we have, the more we can spend for Snort’s
reassembler, and the larger we can make Bro’s time-outs. But how
to choose the values, so that both will utilize the same amount of

memory? And even if we do, how to arrange that both expire the
same old data? The hooks to do so simply aren’t there.

The result of these differences is differing views of the same net-
work data. If one NIDS reports an alert while the other does not,
it may take a surprisingly large amount of effort to tell which one
of them is indeed correct. More fundamentally, this depends on
the definition of “correct,” as generally both are correct within their
own semantics. From a user’s point of the view, this leads to differ-
ent alerts even when both systems seem to use the same signatures.
From an evaluator’s point of view, we have to (i) grit our teeth and
be ready to spend substantial effort in tracking down the root cause
when validating the output of one tool versus another, and (ii) be
very careful in how we frame our assessment of the differences, be-
cause there is to some degree a fundamental problem of “comparing
apples and oranges”.

The same applies for measuring performance in terms of effi-
ciency. If two systems do different things, it is hard to compare
them fairly. Again, the HTTP analyzers of Snort and Bro illustrate
this well. While Snort only extracts the first URI from each packet,
Bro decodes the full HTTP session, including tracking multiple re-
quests and replies (which entails processing the numerous ways in
which HTTP delimits data entities, including “multipart MIME”
and “chunking”). Similarly, Bro provides much more information
at various other points than the corresponding parts of Snort.

But there are still more factors that influence performance. Even
if one system seems to be significantly faster than another, this can
change by modifying the input or even the underlying hardware.
One of our main observations along these lines is that the perfor-
mance of NIDSs can depend heavily on the particular input trace.
On a Pentium-3 system, Snort needs 440 CPU seconds for the trace
LBL-Web (see Figure 6). This only decreases by 6% when us-
ing the set-wise pattern matcher of [12]. In addition, we devised
a small modification to Snort that, compared to the original ver-
sion, speeds it up by factor of 2.6 for this particular trace. (The
modification is an enhancement to the set-wise matcher: the orig-
inal implementation first performs a set-wise search for all of the
possible strings, caching the results, and then iterates through the
lists of signatures, looking up for each in turn whether its particular
strings were matched. Our modification uses the result of the set-
wise match to identify potential matching signatures directly if the
corresponding list is large, avoiding the iteration.)

Figure 6: Run-times on different hardware

Pentium−3, 512Mhz Pentium−4, 1.5Ghz

Snort
Snort−[FV01]
Snort−Modified
Bro w/o DFA cache
Bro w/ DFA cache

Run−times on Web trace

S
e
co

n
d
s

0
1

0
0

2
0

0
3

0
0

4
0

0
5

0
0

Using the trace USB-Full, however, the improvement realized
by our modified set-wise matcher for Snort is only a factor of 1.2.
Even more surprisingly, on a trace from another environment (a re-
search laboratory with 1,500 workstations and supercomputers), the
original version of Snort is twice as fast as the set-wise implemen-
tation of [12] (148 CPU secs vs. 311 CPU secs), while our patched
version lies in between (291 CPU secs). While the reasons remain
to be discovered in Snort’s internals, this demonstrates the difficulty
of finding representative traffic as proposed, for example, in [15].

269

Furthermore, relative performance does not only depend on the
input but even on the underlying hardware. As described above, the
original Snort needs 440 CPU seconds for LBL-Web on a Pentium-
3 based system. Using exactly the same configuration and input
on a Pentium-4 based system (1.5GHz), it actually takes 29 CPU
seconds more. But now the difference between stock Snort and our
modified version is a factor of 5.8! On the same system, Bro’s run-
time decreases from 280 to 156 CPU seconds.4

Without detailed hardware-level analysis, we can only guess why
Snort suffers from the upgrade. To do so, we ran valgrind’s [34]
cache simulation on Snort. For the second-level data cache, it shows
a miss-rate of roughly 10%. The corresponding value for Bro is be-
low 1%. While we do not know if valgrind’s values are airtight,
they could at least be the start of an explanation. We have heard
other anecdotal comments that the Pentium-4 performs quite poorly
for applications with lots of cache-misses. On the other hand, by
building Bro’s regular expression matcher incrementally, as a side
effect the DFA tables will wind up having memory locality that
somewhat reflects the dynamic patterns of the state accesses, which
will tend to decrease cache misses.

4.3 Performance Evaluation
We now present measurements of the performance of the Bro sig-

nature engine compared with Snort, keeping in mind the difficulties
described above. Figure 7 shows run-times on trace subsets of dif-
ferent length for the USB-Full trace. We show CPU times for the
original implementation of Snort, for Snort using [12] (virtually no
difference in performance), for Snort modified by us as described in
the previous section, for Bro with a limited DFA state cache, and for
Bro without a limited DFA state cache. We see that our modified
Snort runs 18% faster than the original one, while the cache-less
Bro takes about the same amount of time. Bro with a limited state
cache needs roughly a factor of 2.2 more time.

We might think that the discrepancy between Bro operating with
a limited DFA state cache and it operating with unlimited DFA state
memory is due to it having to spend considerable time recomputing
states previously expired from the limited cache. This, however,
turns out not to be the case. Additional experiments with essentially
infinite cache sizes indicate that the performance decrease is due to
the additional overhead of maintaining the cache.

While this looks like a significant impact, we note that it is not
clear whether the space savings of a cache is in fact needed in opera-
tional use. For this trace, only 2,669 DFA states had to be computed,
totaling roughly 10MB. When running Bro operationally for a day
at the university’s gateway, the number of states rapidly climbs to
about 2,500 in the first hour, but then from that point on only slowly
rises to a bit over 4,000 by the end of the day.

A remaining question, however, is whether an attacker could cre-
ate traffic specifically tailored to enlarge the DFAs (a “state-holding”
attack on the IDS), perhaps by sending a stream of packets that
nearly trigger each of the different patterns. Additional research
is needed to further evaluate this threat.

Comparing for USB-Full the alerts generated by Snort to the
signature matches reported by Bro, all in all we find very good
agreement. The main difference is the way they report a match.
By design, Bro reports all matching signatures, but each one only
once per connection. This is similar to the approach suggested
in [10]. Snort, on the other hand, reports the first matching sig-
nature for each packet, independently of the connection it belongs

4This latter figure corresponds to about 35,000 packets per second,
though we strongly argue that measuring performance in PPS rates
implies undue generality, since, as developed above, the specifics of
the packets make a great difference in the results.

to. This makes it difficult to compare the matches. We account
for these difference by comparing connections for which at least
one match is generated by either system. With USB-Full, we get
2,065 matches by Bro in total on 1,313 connections. Snort reports
4,147 alerts. When counting each alert only once per connection,
Snort produces 1,320 on 1,305 connections.5 There are 1,296 con-
nections for which both generate at least one alert, and 17 (9) for
which Bro (Snort) reports a match but not Snort (Bro).

Looking at individual signatures, we see that Bro misses 10
matches of Snort. 5 of them are caused by Snort ID #1013 (WEB-
IIS fpcount access). The corresponding connections con-
tain several requests, but an idle time larger than the defined in-
activity timeout of 30 seconds. Therefore, Bro flushes the
state before it can encounter the match which would happen later
in the session. On the other hand, Bro reports 41 signature matches
for connections for which Snort does not report anything. 37 of
them are Web signatures. The discrepancy is due to different TCP
stream semantics. Bro and Snort have slightly different definitions
of when a session is established. In addition, the semantic differ-
ences between stream-wise and packet-wise matching discussed in
§4.2 cause some of the additional alerts.

Figure 7: Run-time comparison on 550MHz Pentium-3

0 5 10 15 20 25 30

0
5
0
0

1
0
0
0

1
5
0
0

2
0
0
0

Runtime for USB−Full on Pentium−3

Trace length (mins)

S
e
co
n
d
s

Bro w/o state cache
Bro w/ state cache
Snort
Snort [FV01]
Snort patched

We have done similar measurements with LBL-Web. Due to lim-
ited space, we omit the corresponding plot here. While the original
Snort takes 440 CPU seconds for the trace, Bro without (with) a lim-
ited state cache needs 280 (328) CPU seconds, and Snort as modi-
fied by us needs only 164 CPU seconds. While this suggests room
for improvement in some of Bro’s internal data structures, Bro’s
matcher still compares quite well to the typical Snort configuration.

For this trace, Bro (Snort) reports 2,764 (2,049) matches in total.
If we count Snort’s alerts only once per connection, there are 1,472
of them. There are 1,395 connections for which both report at least
one alert. For 133 (69) connections, Bro (Snort) reports a match
but Snort (Bro) does not. Again, looking at individual signatures,
Bro misses 73 of Snort’s alerts. 25 of them are matches of Snort
signature #1287 (WEB-IIS scripts access). These are all
caused by the same host. The reason is packets missing from the
trace, which, due to a lack of in-order sequencing, prevent the TCP
stream from being reassembled by Bro. Another 19 are due to sig-
nature #1287 (CodeRed v2 root.exe access). The ones of
these we inspected further were due to premature server-side resets,
which Bro correctly identifies as the end of the corresponding con-
nections, while Snort keeps matching on the traffic still being send
by the client. Bro reports 186 signature matches for connections for
which Snort does not report a match at all. 68 of these connections
simultaneously trigger three signatures (#1002, #1113, #1287). 46

5Most of the duplicates are ICMP Destination Unreach-
able messages. Using Bro’s terminology, we define all ICMP
packets between two hosts as belonging to one “connection.”

270

are due to simultaneous matches of signatures #1087 and #1242.
Looking at some of them, one reason is SYN-packets missing from
the trace. Their absence leads to different interpretations of estab-
lished sessions by Snort and Bro, and therefore to different matches.

5. CONCLUSIONS
In this work, we develop the general notion of contextual sig-

natures as an improvement on the traditional form of string-based
signature-matching used by NIDS. Rather than matching fixed
strings in isolation, contextual signatures augment the matching pro-
cess with both low-level context, by using regular expressions for
matching rather than simply fixed strings, and high-level context,
by taking advantage of the rich, additional semantic context made
available by Bro’s protocol analysis and scripting language.

By tightly integrating the new signature engine into Bro’s event-
based architecture, we achieve several major improvements over
other signature-based NIDSs such as Snort, which frequently suf-
fer from generating a huge number of alerts. By interpreting a
signature-match only as an event, rather than as an alert by itself,
we are able to leverage Bro’s context and state-management mech-
anisms to improve the quality of alerts. We showed several exam-
ples of the power of this approach: matching requests with replies,
recognizing exploit scans, making use of vulnerabilty profiles, and
defining dependencies between signatures to model attacks that span
multiple connections. In addition, by converting the freely available
signature set of Snort into Bro’s language, we are able to build upon
existing community efforts.

As a baseline, we evaluated our signature engine using Snort as
a reference, comparing the two systems in terms of both run-time
performance and generated alerts using the signature set archived
at [2]. But in the process of doing so, we encountered several gen-
eral problems when comparing NIDSs: differing internal semantics,
incompatible tuning options, the difficulty of devising “representa-
tive” input, and extreme sensitivity to hardware particulars. The last
two are particularly challenging, because there are no a priori indi-
cations when comparing performance on one particular trace and
hardware platform that we might obtain very different results using
a different trace or hardware platform. Thus, we must exercise great
caution in interpreting comparisons between NIDSs.

Based on this work, we are now in the process of deploying Bro’s
contextual signatures operationally in several educational, research
and commercial enviroments.

Finally, we have integrated our work into version 0.8 of the Bro
distribution, freely available at [5].

6. ACKNOWLEDGMENTS
We would like to thank the Lawrence Berkeley National Labora-

tory (LBL), Berkeley, USA; the National Energy Research Scien-
tific Computing Center (NERSC), Berkeley, USA; and the Saarland
University, Germany. We are in debt to Anja Feldmann for making
this work possible. Finally, we would like to thank the anonymous
reviewers for their valuable suggestions.

7. REFERENCES
[1] arachNIDS. http://whitehats.com/ids/.
[2] Web archive of versions of software and signatures used in this paper.

http://www.net.in.tum.de/˜robin/ccs03.
[3] S. Axelsson. The base-rate fallacy and the difficulty of intrusion detection.

ACM Transactions on Information and System Security, 3(3):186–205, August
2000.

[4] R. G. Bace. Intrusion Detection. Macmillan Technical Publishing,
Indianapolis, IN, USA, 2000.

[5] Bro: A System for Detecting Network Intruders in Real-Time.
http://www.icir.org/vern/bro-info.html.

[6] Bugtraq. http://www.securityfocus.com/bid/1187.
[7] CERT Advisory CA-2002-27 Apache/mod ssl Worm.

http://www.cert.org/advisories/CA-2002-27.html.
[8] C. J. Coit, S. Staniford, and J. McAlerney. Towards Faster Pattern Matching for

Intrusion Detection or Exceeding the Speed of Snort. In Proc. 2nd DARPA
Information Survivability Conference and Exposition, June 2001.

[9] Common Vulnerabilities and Exposures. http://www.cve.mitre.org.
[10] H. Debar and B. Morin. Evaluation of the Diagnostic Capabilities of

Commercial Intrusion Detection Systems. In Proc. Recent Advances in
Intrusion Detection, number 2516 in Lecture Notes in Computer Science.
Springer-Verlag, 2002.

[11] R. F. et. al. Hypertext transfer protocol – http/1.1. Request for Comments 2616,
June 1999.

[12] M. Fisk and G. Varghese. Fast Content-Based Packet Handling for Intrusion
Detection. Technical Report CS2001-0670, UC San Diego, May 2001.

[13] Fyodor. Remote OS detection via TCP/IP Stack Finger Printing. Phrack
Magazine, 8(54), 1998.

[14] J. Haines, L. Rossey, R. Lippmann, and R. Cunnigham. Extending the 1999
Evaluation. In Proc. 2nd DARPA Information Survivability Conference and
Exposition, June 2001.

[15] M. Hall and K. Wiley. Capacity Verification for High Speed Network Intrusion
Detection Systems. In Proc. Recent Advances in Intrusion Detection, number
2516 in Lecture Notes in Computer Science. Springer-Verlag, 2002.

[16] M. Handley, C. Kreibich, and V. Paxson. Network intrusion detection: Evasion,
traffic normalization, and end-to-end protocol semantics. In Proc. 10th
USENIX Security Symposium, Washington, D.C., August 2001.

[17] J. Heering, P. Klint, and J. Rekers. Incremental generation of lexical scanners.
ACM Transactions on Programming Languages and Systems (TOPLAS),
14(4):490–520, 1992.

[18] J. E. Hopcroft and J. D. Ullman. Introduction to Automata Theory, Languages,
and Computation. Addison Wesley, 1979.

[19] K. Jackson. Intrusion detection system product survey. Technical Report
LA-UR-99-3883, Los Alamos National Laboratory, June 1999.

[20] U. Lindqvist and P. A. Porras. Detecting computer and network misuse through
the production-based expert system toolset (P-BEST). In Proc. IEEE
Symposium on Security and Privacy. IEEE Computer Society Press, May 1999.

[21] R. Lippmann, R. K. Cunningham, D. J. Fried, I. Graf, K. R. Kendall, S. E.
Webster, and M. A. Zissman. Results of the 1998 DARPA Offline Intrusion
Detection Evaluation. In Proc. Recent Advances in Intrusion Detection, 1999.

[22] R. Lippmann, J. W. Haines, D. J. Fried, J. Korba, and K. Das. The 1999
DARPA off-line intrusion detection evaluation. Computer Networks,
34(4):579–595, October 2000.

[23] R. Lippmann, S. Webster, and D. Stetson. The Effect of Identifying
Vulnerabilities and Patching Software on the Utility of Network Intrusion
Detection. In Proc. Recent Advances in Intrusion Detection, number 2516 in
Lecture Notes in Computer Science. Springer-Verlag, 2002.

[24] J. McHugh. Testing Intrusion detection systems: A critique of the 1998 and
1999 DARPA intrusion detection system evaluations as performed by Lincoln
Laboratory. ACM Transactions on Information and System Security,
3(4):262–294, November 2000.

[25] V. Paxson. Bro: A system for detecting network intruders in real-time.
Computer Networks, 31(23–24):2435–2463, 1999.

[26] P. A. Porras and P. G. Neumann. EMERALD: Event monitoring enabling
responses to anomalous live disturbances. In National Information Systems
Security Conference, Baltimore, MD, October 1997.

[27] T. H. Ptacek and T. N. Newsham. Insertion, evasion, and denial of service:
Eluding network intrusion detection. Technical report, Secure Networks, Inc.,
January 1998.

[28] M. J. Ranum, K. Landfield, M. Stolarchuk, M. Sienkiewicz, A. Lambeth, and
E. Wall. Implementing a generalized tool for network monitoring. In Proc. 11th
Systems Administration Conference (LISA), 1997.

[29] M. Roesch. Snort: Lightweight intrusion detection for networks. In Proc. 13th
Systems Administration Conference (LISA), pages 229–238. USENIX
Association, November 1999.

[30] R. Sekar and P. Uppuluri. Synthesizing fast intrusion prevention/detection
systems from high-level specifications. In Proc. 8th USENIX Security
Symposium. USENIX Association, August 1999.

[31] U. Shankar and V. Paxson. Active Mapping: Resisting NIDS Evasion Without
Altering Traffic. In Proc. IEEE Symposium on Security and Privacy, 2003.

[32] Steven T. Eckmann. Translating Snort rules to STATL scenarios. In Proc.
Recent Advances in Intrusion Detection, October 2001.

[33] tcpdump. http://www.tcpdump.org.
[34] Valgrind. http://developer.kde.org/˜sewardj.
[35] G. Vigna, S. Eckmann, and R. Kemmerer. The STAT Tool Suite. In Proc. 1st

DARPA Information Survivability Conference and Exposition, Hilton Head,
South Carolina, January 2000. IEEE Computer Society Press.

[36] G. Vigna and R. A. Kemmerer. Netstat: A network-based intrusion detection
system. Journal of Computer Security, 7(1):37–71, 1999.

[37] Whisker. http://www.wiretrip.net/rfp.

271