Download
1 / 44
440 likes | 443 Vues
Proving It CS 236 Advanced Computer Security Peter Reiher May 13, 2008. Groups for This Week. No groups this week No Thursday class No reports due. Outline. Evaluating security research Tools and approaches Some examples. Evaluating Security Solutions.
E N D
Proving ItCS 236Advanced Computer Security Peter ReiherMay 13, 2008
Groups for This Week • No groups this week • No Thursday class • No reports due
Outline • Evaluating security research • Tools and approaches • Some examples
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?
Possible Approaches • Formal methods • Prove (literally) it works • Testing • Test thoroughly • Advertising • Claim it’s great very loudly
Formal Methods • Great when they’re feasible • Challenges: • Often problem too complex for existing techniques • Demonstrating correspondence between method and real system
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
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
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
Tools You Can Use • Testbeds • Traces • Models
Testbeds • Emulab • Planetlab • Deter • Others
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
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
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
Core Emulab Characteristics • Highly configurable • System software • Application software • Network topology and characteristics • Controllable, predictable, repeatable • Good guarantees of isolation from other experiments
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
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
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
Planetlab Locations Usually two machines per location 854 nodes at 466 sites (as of 5/12/08)
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
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
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
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?
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
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 testbed • Funded by NSF and DHS
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
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
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
Some Important Model Categories • Network topology models • Network traffic models
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
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
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?
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
Some Examples • How would you verify . . . • Data tethers? • Infamy? • Onion routing?
Data Tethers File A File A If the laptop is stolen, file A isn’t there
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
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
Infamy in Operation 1.2.3.4 1.2.3.4 1.36.7.125 1.133.2.8 1.2.3.4
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
Onion Routing Source Destination Onion routers
