All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

Commit 3edbaf45 authored by Mike Hibler's avatar Mike Hibler

Update some.

parent f1206314
......@@ -26,7 +26,7 @@ This is <b>not</b> a firewall
between nodes within an experiment, that is, the firewall is not part of
your NS-specified network topology.
The purpose of an Emulab firewall is to prevent experimental traffic from
escaping, via the control network, to the internet due to a mis-configured
escaping, via the control network, to the Internet due to a mis-configured
application or router within an experiment. Control net firewalls are also
a key component of Emulab ``high-security'' experiment environments.
</p><p>
......@@ -38,12 +38,38 @@ infrastructure or Internet hosts in general) must pass through the firewall
node. The firewall is setup as a filtering layer2 bridge using IPFW2
on FreeBSD and can be configured in a number
of ways to block or allow certain types of traffic.
</p><p>
</p>
<p>
<a NAME="Swapin"></a><h3>Swapin actions</h3>
When a firewalled experiment is swapped in, the firewall is setup and
activated before any experiment nodes are allowed to setup.
activated before any experiment nodes are allowed to setup. Currently
this adds approximately five more minutes to swapin time, as the firewall
node must first be loaded with the FBSD-IPFW2 image.
</p>
<a NAME="Swapout"></a><h3>Swapout actions</h3>
<p>
When a firewalled experiment is swapped out, extra precautions are taken
to ensure that the nodes are decontaminated before the firewall is taken
down.
down. The nodes, including the firewall itself, are scheduled to boot into
a network-loaded, memory-based version of FreeBSD (the "MFS") which will run
a script to zero all the known bootblocks on the disk. This prevents a node
from accidentally booting from its disk prior to being reloaded.
</p><p>
The "boot to MFS" process is done not by issuing a reboot command or even by
doing a power cycle, but rather by simultaneously powering off all nodes
and then later powering them back on. Reboot is not used since the reboot
command could be spoofed on a contaminated node. Power cycling is not used
since cycling is normally performed in batches to avoid network (or power)
overload on restart. Skewed reboots like this open a window of vulnerability
where nodes rebooted later might be able, before they are rebooted, to spoof
the reload server for nodes that have just rebooted.
So we first turn everyone off so that later batched power-ons are safe.
</p><p>
Only when all nodes are known to be running in the MFS and their disks
neutered, will the nodes be released to the reloading experiment.
Any failure in the above process results in all nodes for the experiment
being left powered off, with the control net disabled, and marked as "paniced"
so that only a testbed admin can swap it out.
</p>
<a NAME="Use"></a><h2>Use</h2>
<p>
......
......@@ -49,32 +49,40 @@ without sacrificing the features that make Emulab so easy to use.
</p>
<a NAME="Use"></a><h2>Use</h2>
<p>
In your ns file you can specify a <emph>security level</emph> at which an
In your NS file you can specify a <emph>security level</emph> at which an
experiment should be run. Security levels are specified as colors
(oh, now that is real original!)
with the <code>tb-set-security-level</code> command. Eventually, the
colors will provide different styles of firewalls, potentially in combination
with a per-experiment Emulab environment, to provide increasing levels of
security.
However, currently the colors are only an implicit way of allocating a
firewall of a particular type. Since the firewall is implicitly specified,
there is no way to add additional rules. The current color mappings are:
with the <code>tb-set-security-level</code> command. Colors are a way to
conveniently configure a firewall with a known, fixed ruleset. If you use
<code>tb-set-security-level</code> then you cannot modify the implied
firewall (e.g., by using "add-rule"), nor can you allocate your own firewall.
The exact configuration of the firewalls implied by the security level, is
still a work-in-progress, but the current meanings are:
<ul>
<li>Green.
The default for all experiments. No firewall is allocated.
Hence all nodes are still on the shared control network.
<li>Blue.
An <a href="docwrapper.php3?docname=firewall.html#Styles">open style</a>
firewall is allocated. This is largely worthless since you cannot add
any rules to the firewall. However, you can use it to gauge the performance
impact of placing a firewall node between your experiment and the outside
world.
<li>Yellow.
A <a href="docwrapper.php3?docname=firewall.html#Styles">basic style</a>
firewall is allocated.
firewall is allocated. This configuration is intended for preventing
bad stuff from getting in, not to prevent it from getting out. The only
practical implication right now is that, at swapout time, nodes in a Blue
experiment do not undergo
<a href="docwrapper.php3?docname=firewall.html#Swapout">
the rigorous decontamination process</a>
that all higher security levels (and explicit firewalls) require.
This security
level is appropriate for running a Windows node in while you customize it,
without needing to worry about it becoming infected.
<li>Yellow.
Currently allocates a
<a href="docwrapper.php3?docname=firewall.html#Styles">basic style</a>
firewall.
All nodes going through the swapout decontamination process.
<li>Orange.
A <a href="docwrapper.php3?docname=firewall.html#Styles">closed style</a>
firewall is allocated.
firewall is allocated.
All nodes going through the swapout decontamination process.
<li>Red.
Not currently implemented. This will eventually be an experiment for which
the control network has been completely disabled. The only outside access
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment