Transcript Introduction CS 239 Security for Networks and System Software

Proving It
CS 236
Advanced Computer Security
Peter Reiher
May 13, 2008
CS 236, Spring 2008
Lecture 7
Page 1
Groups for This Week
•
•
•
No groups this week
No Thursday class
No reports due
CS 236, Spring 2008
Lecture 7
Page 2
Outline
• Evaluating security research
• Tools and approaches
• Some examples
CS 236, Spring 2008
Lecture 7
Page 3
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?
CS 236, Spring 2008
Lecture 7
Page 4
Possible Approaches
• Formal methods
– Prove (literally) it works
• Testing
– Test thoroughly
• Advertising
– Claim it’s great very loudly
CS 236, Spring 2008
Lecture 7
Page 5
Formal Methods
• Great when they’re feasible
• Challenges:
– Often problem too complex for
existing techniques
– Demonstrating correspondence
between method and real system
CS 236, Spring 2008
Lecture 7
Page 6
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
CS 236, Spring 2008
Lecture 7
Page 7
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
CS 236, Spring 2008
Lecture 7
Page 8
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
CS 236, Spring 2008
Lecture 7
Page 9
Tools You Can Use
• Testbeds
• Traces
• Models
CS 236, Spring 2008
Lecture 7
Page 10
Testbeds
•
•
•
•
Emulab
Planetlab
Deter
Others
CS 236, Spring 2008
Lecture 7
Page 11
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 Internetwide testbed
• http://www.emulab.net
CS 236, Spring 2008
Lecture 7
Page 12
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
CS 236, Spring 2008
Lecture 7
Page 13
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
CS 236, Spring 2008
Lecture 7
Page 14
Core Emulab Characteristics
• Highly configurable
– System software
– Application software
– Network topology and characteristics
• Controllable, predictable, repeatable
• Good guarantees of isolation from
other experiments
CS 236, Spring 2008
Lecture 7
Page 15
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
CS 236, Spring 2008
Lecture 7
Page 16
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
CS 236, Spring 2008
Lecture 7
Page 17
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
CS 236, Spring 2008
Lecture 7
Page 18
Planetlab Locations
Usually two machines per location
854 nodes at 466 sites (as of 5/12/08)
CS 236, Spring 2008
Lecture 7
Page 19
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
CS 236, Spring 2008
Lecture 7
Page 20
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
CS 236, Spring 2008
Lecture 7
Page 21
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
CS 236, Spring 2008
Lecture 7
Page 22
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?
CS 236, Spring 2008
Lecture 7
Page 23
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
CS 236, Spring 2008
Lecture 7
Page 24
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
CS 236, Spring 2008
Lecture 7
Page 25
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
CS 236, Spring 2008
Lecture 7
Page 26
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
CS 236, Spring 2008
Lecture 7
Page 27
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
CS 236, Spring 2008
Lecture 7
Page 28
Some Important Model Categories
• Network topology models
• Network traffic models
CS 236, Spring 2008
Lecture 7
Page 29
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
CS 236, Spring 2008
Lecture 7
Page 30
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
• CS 236, Spring 2008
Lecture 7
Page 31
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?
CS 236, Spring 2008
Lecture 7
Page 32
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
CS 236, Spring 2008
Lecture 7
Page 33
Some Examples
• How would you verify . . .
– Data tethers?
– Infamy?
– Onion routing?
CS 236, Spring 2008
Lecture 7
Page 34
Data Tethers
File
A
CS 236, Spring 2008
File
A
If the laptop is
stolen, file A isn’t
Lecture 7
there
Page 35
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
CS 236, Spring 2008
Lecture 7
Page 36
So, How Do We Evaluate Data
Tethers?
• ?
CS 236, Spring 2008
Lecture 7
Page 37
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
CS 236, Spring 2008
Lecture 7
Page 38
Infamy in Operation
1.2.3.4
1.2.3.4
1.36.7.125
1.133.2.8
1.2.3.4
CS 236, Spring 2008
Lecture 7
Page 39
So, How Do We Evaluate
Infamy?
• ?
CS 236, Spring 2008
Lecture 7
Page 40
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
CS 236, Spring 2008
Lecture 7
Page 41
Onion Routing
Source
Destination
Onion routers
CS 236, Spring 2008
Lecture 7
Page 42
Delivering the Message
CS 236, Spring 2008
Lecture 7
Page 43
So, How Do We Evaluate Onion
Routing?
• ?
CS 236, Spring 2008
Lecture 7
Page 44