Emulab Security
23
1 Emulab Security
description
Emulab Security. 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 - PowerPoint PPT Presentation
Transcript of Emulab Security
1
Emulab Security
2
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
3
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
4
Local node security
• Protect against accidental breaches of confidentiality, integrity, and availability
• Malicious violations handled through non-technical means
5
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
6
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
7
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
8
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
9
10
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
11
Emulab SecurityThe Future
12
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
13
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
14
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?
15
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?
16
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?
17
Emulab experiment today
18
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
19
Firewalled Experiment
20
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!
21
Isolated Experiment
22
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
23
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?
