1 Emulab Security. 2 Current Security Model Threat model: No malicious authenticated users, Bad Guys are all “outside” –Protect against accidents on the.

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?