Security Issues

Here is a brief rundown of some important security issues you should be aware of.


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.


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 Netscape 4.0 or later, or presumably a recent IE.

When you first visit Emulab, you might be asked if you want to accept the server certificate. Be sure to accept it!


We require all users to use Secure Shell (SSH) to log into Emulab nodes.

Email Addresses

We require all Emulab users to provided current, non-pseudonymic email addresses. Redirections and anonymous email addresses are not allowed.


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 well as anything deemed too short or easily guessable.


Emulab blocks all of the low numbered 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.

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.


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.

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.