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 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 Security The 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?