01-05-2013, 03:19 PM
WRAPS: Denial-of-Service Defense through Web Referrals
WRAPS Denial-of-Service.pdf (Size: 158.38 KB / Downloads: 21)
Abstract
The web is a complicated graph, with millions of websites
interlinked together. In this paper, we propose to use
this web sitegraph structure to mitigate flooding attacks on a
website, using a new web referral architecture for privileged
service (“WRAPS”). WRAPS allows a legitimate client to
obtain a privilegeURL through a click on a referral hypherlink,
from a website trusted by the target website. Using that
URL, the client can get privileged access to the target website
in a manner that is far less vulnerable to a DDoS flooding
attack. WRAPS does not require changes to web client
software and is extremely lightweight for referrer websites,
which eases its deployment. The massive scale of the web
sitegraph could deter attempts to isolate a website through
blocking all referrers. We present the design of WRAPS,
and the implementation of a prototype system used to evaluate
our proposal. Our empirical study demonstrates that
WRAPS enables legitimate clients to connect to a website
smoothly in spite of an intensive flooding attack, at the cost
of small overheads on the website’s ISP’s edge routers.
Introduction
The web is a complicated referral graph, in which a node
(website) refers its visitors to others through hyperlinks.
In this paper, we propose to use this graph (called a sitegraph
[37]) as a resilient infrastructure to defend against
distributed denial-of-service (DDoS) attacks that plague
websites today. Suppose eBay allows its trusted neighbors
(websites linking to it) such as PayPal to refer legitimate
clients to its privileged service through a privileged referral
channel. A trusted client need only click on a privileged
referral hyperlink on Paypal to obtain a privilege URL for
eBay, which certifies the client’s service privilege. When
eBay is undergoing a DDoS attack and not accessible directly,
routers in its local network will drop unprivileged
packets to protect privileged clients’ flows.
Related work
Numerous DDoS countermeasures have been proposed
in the last decade [23, 16, 13, 24, 12, 22, 32, 17, 39, 9, 7,
27, 29, 11, 3, 28, 18, 35, 36]. In this section, we focus on
the mechanisms which are most related to our proposal, in
particular, overlay-based and capability-based approaches,
and compare them with WRAPS.
Overlay networks have been applied to proactively defend
against DoS attacks. Keromytis et al. propose a secure
overlay services (SOS) architecture [19], which has
been generalized by Anderson [4] to take into account different
filtering techniques and overlay routing mechanisms.
Morein et al. further propose to protect web services using
SOS [25]. In these approaches, an overlay network is
composed of a set of nodes arranged in a virtual topology.
The routers around the protected web server admit http traffic
from only trusted locations known to overlay nodes. A
client who wants to connect to the web server has to first
pass a CAPTCHA posed by an overlay node, which then
tunnels the client’s connection to an approved location so
as to reach the web server. Similar work is that of Adkins
et al. [2], which employs the Internet Indirection Infrastructure
(i3) to enable the victim to selectively stop individual
flows by removing senders’ forwarding pointers.
Attack model
We assume that adversaries can modify at most a small
fraction of the legitimate packets destined for the target
website. Attackers capable of tampering with these packets
on a large scale do not need to flood the target’s bandwidth.
Instead, they can launch a DDoS attack by simply
destroying these packets.
We assume that adversaries cannot eavesdrop on most legitimate
clients’ flows. In practice, monitoring a large fraction
of legitimate clients’ flows is difficult in wide area networks.
However, WRAPS still works when adversaries are
capable of eavesdropping on some privileged clients’ flows.
In this case, a defender could control the damage caused by
these clients through standard rate limiting.
We assume that routers inside a website’s protection
perimeter are trusted. In practice, routers usually enjoy
better protection than end hosts. We further assume that
a DoS flooding attack on a website does not significantly
affect the flows from the website to clients. This is generally
true in today’s routers which employ full-duplex links
and switched architectures.
Design
In WRAPS, a website grants a client greater privilege to
access its service by assigning to it a secret fictitious URL
called privilege URL (Section 4.1) with a capability token
embedded in part of the IP and port number fields. Through
that URL, the client can establish a privileged channel with
that website (referred to as the target website) even in the
presence of flooding attacks.
A client may obtain a privilege URL either directly from
the target website or indirectly from the website’s trusted
neighbors. A website offers a client a privilege URL if the
client is referred by one of the site’s trusted neighbors, or
is otherwise qualified by the site’s policies that are used to
identify valued clients, for example, those who have paid
or who are regular visitors. A qualified client will be redirected
to the privilege URL generated automatically using
that client’s identity, service information and a server secret.
A privilege URL leads its holder to the target website
through a protection mechanism (Section 4.2) which protects
the website from unauthorized flows. The border of
this mechanism is the site’s ISP’s edge routers, which classify
traffic into privileged and unprivileged flows, and translate
fictitious addresses in privilege URLs into the website’s
real address. Within the protection perimeter, routers protect
privileged traffic by dropping unprivileged packets during
congestion.
Protection mechanism
A website (the target) is protected by the edge routers of
its ISP or organization, the routers inside its local network,
and a firewall directly connected to or installed on the site’s
web server.
The target website shares a secret long-term key k with
its edge routers on the protection perimeter. Using this key,
the website periodically updates to all its edge routers a
shared verification key. We call a period between updates
a privilege period. Specifically, the verification key used in
the privilege period t is computed as k(t) = hk(t) where h
is a pseudorandom function family indexed by the key k.
Referral protocol
When a website is under a flooding attack, legitimate but
as-yet-unprivileged clients will be unable to visit that site
directly, even merely to apply for privileged service. The
central idea ofWRAPS is to let the trusted neighbors of the
website refer legitimate clients to it, even while the website
is under a flooding attack. The target website will grant
these trusted neighbors privilegeURLs, and may allow transitive
referrals: a referrer can refer its trusted neighbor’s
clients to the target website.
Brute-force attacks on a short capability
token
An adversary may perform an exhaustive search on the
short MAC in a privilege URL. Specifically, the adversary
first chooses a random MAC to produce a privilege URL
for the target website. Then, it sends a TCP packet to that
URL. If the target website sends back some response, such
as syn-ack or reset, the adversary knows that it made a correct
guess. Otherwise, it chooses another MAC and tries
again.
This threat has been nullified by our protection mechanism.
The firewall of the target website keeps records of all
the website’s privileged clients and only admits packets to
privilege port from these clients. If the adversary uses its
real IP address for sending probe packets, the website will
not respond to the probe unless the adversary has already
become the site’s privileged client. If the adversary spoofs
a privileged client’s IP address to penetrate the firewall, the
website’s response only goes to that client, not the adversary.
Therefore, the adversary will never know whether it
makes a correct guess or not.
Implementation of the protection
mechanism
WRAPS depends on the target’s ISP’s edge routers to
classify inbound traffic into privileged and unprivileged,
and to translate fictitious addresses of privileged packets to
the real location of the service. It also depends on routers inside
the website’s local network to protect privileged flows.
We implemented these functions in a Click software router.
Click is a modular software architecture for creating
routers [21, 20]. A Click router is built from a set of packet
processing modules called elements. Individual elements
implement certain router functions such as packet classification,
queuing and scheduling. A router is configured as a
directed packet-forwarding graph, with elements on its vertices
and packet flows traversing its edges. A prominent
property of Click is its modularity, which makes a Click
router extremely easy to extend.