On the Security of One Password Authenticated Key Exchange ...
1 Emulab Security. 2 Current Security Model Threat model: No malicious authenticated users, Bad Guys...
-
date post
19-Dec-2015 -
Category
Documents
-
view
224 -
download
1
Transcript of 1 Emulab Security. 2 Current Security Model Threat model: No malicious authenticated users, Bad Guys...
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
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
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?
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
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!
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