1. Lecture 7 Page 1 CS 236, Spring 2008 Proving It CS 236 Advanced Computer Security Peter Reiher May 13, 2008

2. Lecture 7 Page 2 CS 236, Spring 2008 Groups for This Week No groups this week No Thursday class No reports due

3. Lecture 7 Page 3 CS 236, Spring 2008 Outline Evaluating security research Tools and approaches Some examples

4. Lecture 7 Page 4 CS 236, Spring 2008 Evaluating Security Solutions People have proposed many responses to: –Worms –DDoS –IP spoofing –Buffer overflows –Botnets –Many other types of attacks How can we tell which ones work?

5. Lecture 7 Page 5 CS 236, Spring 2008 Possible Approaches Formal methods –Prove (literally) it works Testing –Test thoroughly Advertising –Claim it’s great very loudly

6. Lecture 7 Page 6 CS 236, Spring 2008 Formal Methods Great when they’re feasible Challenges: –Often problem too complex for existing techniques –Demonstrating correspondence between method and real system

7. Lecture 7 Page 7 CS 236, Spring 2008 Testing Approaches Generally of two flavors: –Real system testing –Simulation Each has its strengths and weaknesses May not have much choice which you use –Dictated by problem characteristics Sometimes need some of both

8. Lecture 7 Page 8 CS 236, Spring 2008 Simulation +Allows high scale testing +More reproducible +Complete control of resources involved −Questions of fidelity −Often requires lots of supporting models –E.g., a model of Internet topology −Might be computationally expensive

9. Lecture 7 Page 9 CS 236, Spring 2008 Testing +Tests real code/hardware/configurations +Can leverage existing stuff +like the Internet −Reproducibility often challenging −Can interfere with others’ work −In security, often too dangerous −Often scale is limited

10. Lecture 7 Page 10 CS 236, Spring 2008 Tools You Can Use Testbeds Traces Models

11. Lecture 7 Page 11 CS 236, Spring 2008 Testbeds Emulab Planetlab Deter Others

12. Lecture 7 Page 12 CS 236, Spring 2008 Emulab Large testbed located at University of Utah Funded initially by NSF and DARPA Designed to support experiments by researchers worldwide Probably the first really successful Internet- wide testbed http://www.emulab.net

13. Lecture 7 Page 13 CS 236, Spring 2008 Basic Philosophy of Emulab Provide large pool of machines to entire Internet community Almost all testing will be done remotely Almost all testing must be done without intervention by testbed admins Handle the widest possible kinds of experiments and testing situations

14. Lecture 7 Page 14 CS 236, Spring 2008 Basic Emulab Approach Emulab indeed provides large numbers of machines –Around 450 total nodes But also provides a rich, powerful testing environment Completely configurable remotely Designed for simultaneous sharing by many users

15. Lecture 7 Page 15 CS 236, Spring 2008 Core Emulab Characteristics Highly configurable –System software –Application software –Network topology and characteristics Controllable, predictable, repeatable Good guarantees of isolation from other experiments

16. Lecture 7 Page 16 CS 236, Spring 2008 Planetlab A testbed designed to test Internet services Using nodes deployed widely around the Internet And software to support safe and controlled sharing of the nodes Run primarily by Princeton, Berkeley, and Washington Funding seeded by NSF and DARPA Strong Intel participation –Other industry involvement, as well http://www.planet-lab.org

17. Lecture 7 Page 17 CS 236, Spring 2008 Basic Planetlab Concept Deploy testbed nodes at many locations throughout Internet –Standardized hardware and software Allow those who deploy nodes to use the testbed facility Provide virtual machines to each tester using a node Allow long-running experiments –Or even semi-permanent services

18. Lecture 7 Page 18 CS 236, Spring 2008 Planetlab Nodes Hardware deploying the Planetlab software package Which supports cheap virtual machines Otherwise, provides a typical Linux environment Pretty complete control of virtual machine But node-based mechanisms to ensure fair and safe sharing of hardware

19. Lecture 7 Page 19 CS 236, Spring 2008 Planetlab Locations Usually two machines per location 854 nodes at 466 sites (as of 5/12/08)

20. Lecture 7 Page 20 CS 236, Spring 2008 Planetlab Experiments Usually run on many Planetlab nodes By one controlling researcher Collection of resources across all nodes supporting the experiment is called a Planetlab slice –A multimachine environment for the experiment –Also an organization for cooperating researchers to use Services run in slices

21. Lecture 7 Page 21 CS 236, Spring 2008 Deter Some experiments are risky –In their potential to do unintended harm Worm experiments are a classic example –Worms try to spread as far as possible –How sure are you that your testbed really constrains them? –Even one major Internet worm incident from an escaped experiment would be a disaster

22. Lecture 7 Page 22 CS 236, Spring 2008 Confining Risky Experiments That’s the point of the Deter testbed Builds on functionality from Emulab But adds extra precautions to keep bad stuff from escaping the testbed Also includes set of tools speficially useful for these kinds of experiments

23. Lecture 7 Page 23 CS 236, Spring 2008 Why Do We Need More Isolation? DDoS experiments have been run on Emulab –With no known problems Why not just be careful? Question is, how careful? Especially if you’re running real malicious code –Do you really understand it as well as you think?

24. Lecture 7 Page 24 CS 236, Spring 2008 What Is Deter For? Security testing, especially of risky code –Worms –DDoS attacks –Botnets –Attacks on routing protocols Other important element is network scale –Meant for problems of Internet scale –Or at least really big networks

25. Lecture 7 Page 25 CS 236, Spring 2008 Status of Deter Working testbed Similar model to Emulab Two clusters of nodes –At ISI and UC Berkeley Connected via high speed link Has over 300 nodes http://www.isi.deterlab.net –http://www.isi.edu/deter gets you to a lot of information about the testbedhttp://www.isi.edu/deter Funded by NSF and DHS

26. Lecture 7 Page 26 CS 236, Spring 2008 Traces Experiments require a workload Traces are a realistic way to get it Many kinds of traces are hard to gather for yourself In some cases, traces are publicly available Sometimes you can use those

27. Lecture 7 Page 27 CS 236, Spring 2008 Some Useful Traces NLANR packet header traces CAIDA traces and data sets U. of Oregon Routeviews traces File system traces Web traces Crawdad wireless traces

28. Lecture 7 Page 28 CS 236, Spring 2008 Useful Experimental Models In many cases, we can’t test in real conditions Typically try to mimic real conditions by using models –Workload models –Network topology models –Models of other experimental conditions There are already useful models for many things –Often widely accepted as valid within certain research communities –Might be better using them than trying to create your own

29. Lecture 7 Page 29 CS 236, Spring 2008 Some Important Model Categories Network topology models Network traffic models

30. Lecture 7 Page 30 CS 236, Spring 2008 Network Topology Models Many experiments nowadays investigate network/distributed systems behavior They need a realistic network to test the system –Usually embedded in testbed hardware Where do you get that from? In some cases, it’s obvious or you have a map of a suitable network In other cases, more challening

31. Lecture 7 Page 31 CS 236, Spring 2008 Some Popular Topology Generators GT-ITM –Supports various ways to randomly generate network graphs BRITE –Parameterizable network generation tool –Tool of choice for Emulab INET –Topology generator specifically intended to produce Internet-like graphs

32. Lecture 7 Page 32 CS 236, Spring 2008 Network Traffic Models Frequently necessary to feed network traffic into an experiment Could use a trace But sometimes better to use a generator The generator needs a model to tell it how to generate traffic What kind of model?

33. Lecture 7 Page 33 CS 236, Spring 2008 Different Network Traffic Model Approaches Trace analysis –Derive properties from traces of network behavior –E.g., Harpoon and Swing Structural models –Pretend you’re running an application –Generate traffic as it would do –E.g., Netspec

34. Lecture 7 Page 34 CS 236, Spring 2008 Some Examples How would you verify... –Data tethers? –Infamy? –Onion routing?

35. Lecture 7 Page 35 CS 236, Spring 2008 Data Tethers File A If the laptop is stolen, file A isn’t there File A

36. Lecture 7 Page 36 CS 236, Spring 2008 Basic Data Tethers Operations Tie policies to pieces of data –E.g., “file X cannot leave the office” Observe environmental conditions –E.g., “leaving the office” Apply policies to remove files when necessary

37. Lecture 7 Page 37 CS 236, Spring 2008 So, How Do We Evaluate Data Tethers? ?

38. Lecture 7 Page 38 CS 236, Spring 2008 Infamy Handles botnets by marking traffic from known bots Lives “somewhere in the network” Gets reliable list of bot addresses Marks all packets from those addresses Destination hosts/border routers can do what they want with marked packets

39. Lecture 7 Page 39 CS 236, Spring 2008 Infamy in Operation 1.2.3.4 1.36.7.125 1.133.2.8 1.2.3.4

40. Lecture 7 Page 40 CS 236, Spring 2008 So, How Do We Evaluate Infamy? ?

41. Lecture 7 Page 41 CS 236, Spring 2008 Onion Routing Conceal sources and destinations for Internet communications Using crypo-protected multihop packets A group of nodes agree to be onion routers Plan is that many users send many packets through the onion routers

42. Lecture 7 Page 42 CS 236, Spring 2008 Onion Routing SourceDestination Onion routers

43. Lecture 7 Page 43 CS 236, Spring 2008 Delivering the Message

44. Lecture 7 Page 44 CS 236, Spring 2008 So, How Do We Evaluate Onion Routing? ?