Phalanx: Withstanding Multimillion-Node Botnets Colin Dixon Arvind Krishnamurthy Tom Anderson University of Washington NSDI 2008

Why isn’t this a solved problem?  Solved for static content  Replicate everywhere  Large CDNs (Akamai, CoDeeN, Coral)  Potentially solved if we can replace all routers  Promising “clean slate” academic research... ... but, pervasive bots require universal deployment  Unsolved for dynamic content on the Internet today  VoIP, e-govt, e-commerce, AJAX web apps, etc.  Can we use a pervasive set of machines (i.e., a CDN) to solve the problem? Without changing every router?

Key Ideas  Tie fate of a server to a large part of the Internet  Goals  Deployable – without changing all ISPs or all routers  Scalable – to terabit attacks w/millions of attackers  Mechanisms  Packet Mailboxes  Secure Random Multipathing  Filtering Ring  Let’s go design it!

Simple Proxy  Use nodes as proxies  They can make filtering decisions  Forward remaining traffic to server  How do they make filtering decisions?  Do we trust them?  How does the network know we trust them?

Mailbox  Use nodes as mailboxes  Hold each packet for an explicit request  Policy at destination  Don’t trust mailboxes  Explicitly express trust to the network  Still, any single node is vulnerable to attack

Secure Random Multipathing  Send traffic randomly among mailboxes  According to shared secret sequence

Secure Random Multipathing  Send traffic randomly among mailboxes  According to shared secret sequence  Botnet can take down one mailbox

Secure Random Multipathing  Send traffic randomly among mailboxes  According to shared secret sequence  Botnet can take down one mailbox  But communication continues

Secure Random Multipathing  Send traffic randomly among mailboxes  According to shared secret sequence  Botnet can take down one mailbox  But communication continues  Diluted attacks against all mailboxes fail

Secure Random Multipathing  Sequence of mailboxes  Negotiate secret X at connection setup  Construct a secret sequence based on X x 0 = h(X,X), x i = h(x i-1,X)  Use x i to name that packet and select mailbox  Also a lightweight authenticator  Need a multipath congestion control algorithm

Filtering Ring  Attackers can ignore the mailboxes and just attack the server  Need to drop unrequested traffic in the network  request/response framework signals the network

blacklistwhitelistblacklistwhitelist xixi xixi blacklistwhitelist xixi Filtering Ring req: x i data: x i req: x i data: x i req: x i

Connection Setup  So far, we protect established connections  How do clients initiate connections?  Server issues “first packet” requests  Mediate access to these requests  Computational puzzles (Portcullis-style) Per-computation fair queueing  Authentication tokens For small deployments w/known principals

Example

 Get static content and applet from CDN (1)  Connection setup  Get/solve puzzle (2)  Server issues first packet request (3)  First packet & request paired and sent (4,5)  Server returns mailbox list and secret X (6)  Protected comm. (7)

Example  Get static content and applet from CDN (1)  Connection setup  Get/solve puzzle (2)  Server issues first packet request (3)  First packet & request paired and sent (4,5)  Server returns mailbox list and secret X (6)  Protected comm. (7)

Example  Get static content and applet from CDN (1)  Connection setup  Get/solve puzzle (2)  Server issues first packet request (3)  First packet & request paired and sent (4,5)  Server returns mailbox list and secret X (6)  Protected comm. (7)

Example  Get static content and applet from CDN (1)  Connection setup  Get/solve puzzle (2)  Server issues first packet request (3)  First packet & request paired and sent (4,5)  Server returns mailbox list and secret X (6)  Protected comm. (7)

Example  Get static content and applet from CDN (1)  Connection setup  Get/solve puzzle (2)  Server issues first packet request (3)  First packet & request paired and sent (4,5)  Server returns mailbox list and secret X (6)  Protected comm. (7)

Example  Get static content and applet from CDN (1)  Connection setup  Get/solve puzzle (2)  Server issues first packet request (3)  First packet & request paired and sent (4,5)  Server returns mailbox list and secret X (6)  Protected comm. (7)

Evaluation  Microbenchmarks on PlanetLab (see paper)  Simulation  Based on gathered topology data  PlanetLab node serve as stand in for server  7200 Akamai nodes as mailboxes  Attacker bandwidth from BT measurements (avg 3Mb)

Protection vs. Deployment All mailboxes see less than 30% “goodput” 60% of mailboxes see no loss 20% of mailboxes see high loss Even a moderate deployment ( Mb mailboxes and only the victim AS filtering) has huge benefit against large botnets (100k nodes)

Scalability Any fixed deployment will reach it’s limit at some point...

Scalability 40% of mailboxes see no loss even vs. 4 mil. attackers w/36k mbxes... but, a more significant deployment can deal with botnets an order of magnitude larger than those of today. 36, Mbit mailboxes.

Related Work  CDNs (Akamai, Coral, CoDeeN)  Capabilities (SIFF, TVA)  Overlays (SOS, MayDay, Spread Spectrum)  Resource Proofs (Speak Up, Portcullis)  Architecture (Secure-i3, Off By Default)  Filtering (AITF, dFence, CenterTrack, Pushback)  Wireless Frequency Hopping

Conclusions  Ties one server’s fate to the fate of the Internet  Scales to deal with attacks of today and tomorrow  Deployable  Use CDN for mailboxes  Use upstream ISP to install filtering ring  Server is in control  Explicitly asks for each packet  Implements it’s own policies locally  Is not required to trust any given mailbox

Questions?