Phalanx: Withstanding Multimillion-Node Botnets

1. Phalanx: WithstandingMultimillion-Node Botnets Colin Dixon Arvind Krishnamurthy Tom Anderson University of Washington NSDI 2008

3. 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?

4. 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!

5. 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?

6. 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

7. Secure Random Multipathing • Send traffic randomly among mailboxes • According to shared secret sequence

8. Secure Random Multipathing • Send traffic randomly among mailboxes • According to shared secret sequence • Botnetcan take down one mailbox

9. Secure Random Multipathing • Send traffic randomly among mailboxes • According to shared secret sequence • Botnetcan take down one mailbox • But communication continues

10. Secure Random Multipathing • Send traffic randomly among mailboxes • According to shared secret sequence • Botnetcan take down one mailbox • But communication continues • Diluted attacks against all mailboxes fail

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

12. 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

13. Filtering Ring data: xi req: xi data: xi req: xi req: xi data: xi

14. 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

15. Example

16. 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)

17. 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)

18. 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)

19. 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)

20. 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)

21. 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)

22. 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)

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

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

25. 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,000 100 Mbit mailboxes.

26. 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

27. 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 incontrol • Explicitly asks for each packet • Implements it’s own policies locally • Is not required to trust any given mailbox

28. Questions?