security.html 4.45 KB
Newer Older
Leigh B. Stoller's avatar
Leigh B. Stoller committed
1
2
<!--
   EMULAB-COPYRIGHT
3
   Copyright (c) 2000-2003 University of Utah and the Flux Group.
Leigh B. Stoller's avatar
Leigh B. Stoller committed
4
5
   All rights reserved.
  -->
6
7
8
9
10
11
<center>
<h1>
    Security Issues
</h1>
</center>

Chad Barb's avatar
   
Chad Barb committed
12
<p>
13
14
Here is a brief rundown of some important security issues you should
be aware of. 
Chad Barb's avatar
   
Chad Barb committed
15
</p>
16
17
18
19
20
21
22
23

<h3>Cookies</h3>

<p>
To enhance operation and security, we make use of a "Cookie" that
holds your login name. Therefor, you will need to enable cookies on
your browser. Please contact us if you have questions about how to do
that in your browser.
Chad Barb's avatar
   
Chad Barb committed
24
</p>
25
26
27
28
29
30
31

<h3>SSL</h3>

<p>
To protect data you submit, SSL is used to encrypt data as it
is transferred accross the Internet. Therefore, you will need to
access these pages with a browser that supports SSL.  We recommend
32
Netscape 4.0 or later, or presumably a recent IE.
Chad Barb's avatar
   
Chad Barb committed
33
</p>
34
35
36
37

<p>
When you first visit Emulab, you might be asked if you want to accept
the <i>server certificate</i>. Be sure to accept it!
Chad Barb's avatar
   
Chad Barb committed
38
</p>
39

40
<a NAME="SSH"></a>
41
42
<h3>SSH</h3>

Chad Barb's avatar
   
Chad Barb committed
43
<p>
44
We require all users to use Secure Shell (SSH) to log into Emulab
45
46
nodes. Experience has taught us a few things about managing keys
which we will pass on to you at no extra charge:
Chad Barb's avatar
   
Chad Barb committed
47
</p>
48

49
<p>
Chad Barb's avatar
   
Chad Barb committed
50
<blockquote>
51
52
53
54
55
56
57
58
59
60
<ul>
<li> You should <b>not</b> store your Emulab public key
     (.ssh/identity.pub) in your authorized_keys file on remote
     sites. This prevents easy logins from Emulab to your remote sites
     in case your Emulab account is ever compromised (since the Emulab
     generated private key is not protected by a passphrase).

<li> We recommend that you use ssh's RSA authentication to login to
     Emulab so that you do not have to type your password. The less
     often you type your password the better! You do this by uploading
61
62
63
64
     your own public keys to Emulab. More info on using an ssh
     agent can be found at
     <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-agent">
     www.openbsd.org</a>.
65
66
67
68
69
70
71
72
73
74

<li> When you create your private keys (ssh-keygen), pick a good passphrase!
     They can be (much) longer than Unix passwords; 10 to 30 character
     phrases are good.

<li> You should <b>not</b> copy ssh identity files (private keys) from
     other places to Emulab (or any other off-site machine, for that
     matter). Private keys should always be well protected!
</ul>
</blockquote>
Chad Barb's avatar
   
Chad Barb committed
75
</p>
76

77
78
79
80
81
<h3>Email Addresses</h3>

<p>
We require all Emulab users to provided current, non-pseudonymic email
addresses. Redirections and anonymous email addresses are not allowed.
Chad Barb's avatar
   
Chad Barb committed
82
</p>
83
84
85
86
87
88
89

<h3>Passwords</h3>

<p>
We employ a password checking library to prevent users from choosing
passwords that could be guessed by the "Crack" library. A few basic
rules are that standard english dictionary words are not permitted, as
90
91
92
well as anything deemed too short or easily guessable. Also, you
should take care not to use the same password on Emulab that you use
at other sites.
Chad Barb's avatar
   
Chad Barb committed
93
</p>
94

95
96
<h3>Firewalling</h3>

97
98
99
100
101
102
103
<p>
Emulab blocks all of the <i>low numbered</i> ports (ports below 1024), with the
exception of ports 20 and 21 (FTP), 22 (Secure Shell), and 80 (HTTP). This is
for the protection of experimentors, as well as to ensure that an errant
application cannot become the source of a Denial of Service attack to sites
outside of Emulab. If your application requires external access to other low
numbered ports, please contact us to make special arrangements.
Chad Barb's avatar
   
Chad Barb committed
104
</p>
105
106
107
108
109
110
111
<p>
Emulab also prevents machines from using IP and MAC addresses other than their
own on the control net. The control net router blocks all traffic not
originating from the proper subnet, both to prevent IP spoofing and to prevent
experimental traffic from accidentally making it to the 'real world' (say,
through routing misconfiguration.) These restrictions are not present on the
experimental net.
Chad Barb's avatar
   
Chad Barb committed
112
</p>
113
114
115
116
117
118
119
120
121
122
<h3>Accounts</h3>

<p>
We make use of Unix user and group mechansisms to provide protection
between users and projects. Each new user gets a new Unix UID, and
each new project gets a new Unix GID. Users are members of the Unix
groups that correspond to each of the projects they are working on,
and thus may share files with other members of those projects. The
default directory permissions are set so that project files are not
readable by members of other projects.
Chad Barb's avatar
   
Chad Barb committed
123
</p>
124
125
126
127
128
129
<p>
Each project gets its own directory hierachy (again, protected by the
Unix group mechanism) that is NFS-exported only to that project's
assigned test machines.  We don't currently protect against spoofing
on the control network, so there are vulnerabilities.  The test
networks are fully separated between experiments by way of VLANs.
Chad Barb's avatar
   
Chad Barb committed
130
</p>
131