Commit c0ef6451 authored by Mike Hibler's avatar Mike Hibler

Update firewall doc, add beginnings of a section on the transparent use

of Elabinelab and firewalls.
parent d6fdc20e
This diff is collapsed.
Copyright (c) 2005 University of Utah and the Flux Group.
All rights reserved.
<h1>Running an Experiment in a ''Secure'' Environment</h1>
<li> <a href="#Overview">Overview</a>
<li> <a href="#Use">Use</a>
<li> <a href="#Limitations">Current Limitations</a>
<li> <a href="#KnownBugs">Known Bugs</a>
<li> <a href="#Example">A Complete Example</a>
<a NAME="Overview"></a><h2>Overview</h2>
Originally, the goal of an Emulab experiment was to provide an isolated
environment in which to run tests. Isolation here primarily meant resource
isolation--preventing artifacts in an experiment due to other experiments or
outside influences. While basic authentication and protection mechanisms
were used, the threat model being addressed was accidental "attacks" on
isolation; e.g., a misconfigured interface causing flooding of another
experiment's network.
We are now building up the Emulab infrastructure to allow experimentation
with more potent threats, in particular ''malware'', which attempts to
actively exploit weaknesses on nodes and in the network.
Since Emulab is intended for use by researchers, we did not unnecessarily
want to restrict access from the Internet to experimental nodes and visa-versa.
Thus the central Emulab firewall is fairly permissive. For high-risk
experiments, this is not acceptable. To address this, we have added
<a href="docwrapper.php3?docname=firewall.html">per-experiment control net
Another decision made early on, for the convenience of users, was for extensive
use of shared infrastructure such as a shared filesystem and a central login
machine within Emulab allowing for efficient control of experiments. Such
shared infrastructure provides an easy target for malware, so through the
use of <a href="elabinelab.php3">''Emulab in Emulab''</a>
we provide per-experiment Emulab infrastructure.
By combining the two facilities, we enable containment of high-risk experiments
without sacrificing the features that make Emulab so easy to use.
<a NAME="Use"></a><h2>Use</h2>
<a NAME="Limitations"></a><h2>Limitations</h2>
<a NAME="KnownBugs"></a><h2>Known Bugs</h2>
<a NAME="Example"></a><h2>A Complete Example</h2>
Copyright (c) 2000-2004 University of Utah and the Flux Group.
Copyright (c) 2000-2005 University of Utah and the Flux Group.
All rights reserved.
......@@ -40,9 +40,15 @@
Multiplexed Virtual Nodes</a>
<li> <a href="docwrapper.php3?docname=ixp.html">
Using IXP network processors</a>
<li> <a href="docwrapper.php3?docname=secure.html">
Running an experiment in a ''secure'' environment</a>
<img src="../new.gif" alt="&lt;NEW&gt;">
<li> <a href="docwrapper.php3?docname=firewall.html">
Experiment Firewalling in Emulab</a>
<img src="../new.gif" alt="&lt;NEW&gt;">
<li> <a href="elabinelab.php3">
Running an instance of Emulab inside Emulab</a>
<img src="../new.gif" alt="&lt;NEW&gt;">
<li> <a href="#BatchMode">Batch Mode Experiments</a>
<li> <a href="#CustomOS">Creating your own disk image</a>
Markdown is supported
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment