Transcript security-all

Emulab Security
1
Current Security Model
• Threat model: No malicious authenticated
users, Bad Guys are all “outside”
– Protect against accidents on the “inside”
– Provide prudent protection from the “outside”
• We are a research facility, must balance
security and openness
– Cannot close all network ports
– Cannot (always) take away root privilege
2
Current Security Model
(cont.)
• We can observe basic security hygiene
– No cleartext passwords
– Firewall from the outside world
– Restrict access to critical infrastructure services
• Happily, experiment isolation and security are
synergistic
– Experiment private VLANs
– Reloading disks between experiments
3
Local node security
• Protect against accidental breaches of
confidentiality, integrity, and availability
• Malicious violations handled through nontechnical means
4
Wide-area node security
• Not under our physical or administrative
control
– Limited control over who accesses a node
– Node may or may not be firewalled
– Not just us who looks bad if there is an “incident”
– Bottom line: must be more cautious!
• Use authenticated network protocols
• Restrict privilege of Emulab users on nodes
5
User Security
• Potential new users must be part of an
informal “chain of trust”
• New users verified with a key in e-mail
• All interaction with the testbed done using
secure protocols
• Projects are separated from each other
• Users allowed to access only one server,
critical services run on another
6
Node Security
• Physical nodes are not shared between
experiments
• Use a shared filesystem (NFS), but export
only appropriate directories from the server
• Node disks are reloaded and nodes rebooted
when released from an experiment
7
Network Security
• Use VLANs on the experimental network to
enforce isolation
• Control network divided into 5 subnets with
firewalling in between
– “External” VLAN for link to the outside world
– “Device” VLAN for SNMP devices
– “Private” VLAN for boss node and critical servers
– “Public” VLAN for user-accessible nodes
– “Node” VLAN for the nodes
8
9
Network Security
(cont.)
• MAC security on node control net
– Nodes cannot spoof other active MAC addresses
• Basic egress/ingress filtering
– Nodes cannot spoof external IP addresses
10
Emulab Security
The Future
11
Flaws: current threat model
• Assumption: “Only good, though sometimes
careless, people on the inside”
• Node control net
– Interface is visible, and desirable, to applications
– Shared by all nodes in all experiments
• Vulnerable services on the private VLAN
– Always-a-popular-target web server on the same
net/host as central DB, power controllers,
switches
12
Flaws: relaxed threat model
• Assumption: “Anything goes”
• Node control net
– Spoofing/interfering with infrastructure services
• Vulnerable services on the private VLAN
– Direct attacks on unauthenticated services:
TFTP, tmcc, event system
• Cracking user logins on ops node
– Exposes all user files as ops is FS server
– Exposes user ssh keys, can get to any node
13
More exotic threats
• Switch DOSin'
– Directed attacks on the switch infrastructure
– Could affect switching performance
– Could also prevent reconfiguration of a switch
(this has happened to us!)
• BIOS whackin'
– Attempt to corrupt or infect the BIOS
– Stash trojans in non-volatile memory
– Can it be done?
14
Fixing the current flaws
• Secure the control net
– Per-experiment VLANs ala the experimental net
• Address vulnerable services
–
–
–
–
Get web server off of private net
Design narrow, proxy interfaces to critical services
Eliminate local shared file storage or replace NFS
Eliminate local server logins
• Secure the hardware
– Configure a small pool of directly connected nodes
– Ensure BIOS modification requires manual labor
– PCs with Trusted Platform Modules?
15
Worms and Virii:
dealing with the Really Bad S**t
• Need to protect, not just us, but the Internet
• Cannot just fix flaws we know about, must
assume there are worse ones we don't know
• Need support for Microsoft Windows
– Cannot have chaos and destruction without it!
• What do we do?
16
Emulab experiment today
17
Solution #1: firewalls
• Create a virtual control net for an experiment
and interpose a gateway “firewall node”
• Could be implicitly or explicitly configured
• Allows external access and monitoring of an
experiment
• Flexible, but still vulnerable
18
Firewalled Experiment
19
Solution #2: “Emulab
Unplugged”
• Run an experiment in a completely
disconnected fashion
• Regular control net is used to configure the
experiment, and is then disabled
• Only access via serial line
– Might not work so hot for Windows
– Watch out for escape sequence attacks!
20
Isolated Experiment
21
Monitoring and control
• How do we observee and control the
behavior of hard cases?
• Switch statistics (if using a switch)
• Interposed “monitor nodes”
• Applications running on the nodes (how far
can you trust them?)
• Postmortem analysis
– Remote nodes into MFS, examine filesystems
22
Limitations of our environment
• Using PCs as routers in topologies
– Can they keep up?
– Will they alter the behavior of the worm/virus?
• Emulab-savvy worms
– Is Emulab too easy to detect?
– Do we need to disguise our environment?
23