Here is a brief rundown of some important security issues you should be aware of.
Login IDs
We require all Emulab users to provide current, non-pseudonymic login IDs. Shared accounts are strictly forbidden! Each user should apply separately and specify their standard login name.
Cookies
To enhance operation and security, we make use of Cookies that holds your login name. Therefore, you will need to enable cookies on your browser. Please contact us if you have questions about how to do that in your browser.
SSL
To protect data you submit, SSL is used to encrypt data as it is transferred across the Internet. Therefore, you will need to access these pages with a browser that supports SSL.
When you first visit Emulab, you might be asked if you want to accept the server certificate. Be sure to accept it!
SSH
We require all users to use Secure Shell (SSH) to log into Emulab nodes. Experience has taught us a few things about managing keys which we will pass on to you at no extra charge:
- You should not 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).
- You should not mess with the Emulab generated key in your .ssh directory (.ssh/identity). This is an unencrypted key (see above) that is used by Emulab when setting up experiments. You should not delete the public part of the key from the web interface either. Failure to heed this warning will result in experiments not setting up properly!
- 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 your own public keys to Emulab.
- 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.
- You should not 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!
Email Addresses
We require all Emulab users to provide current, non-pseudonymic email addresses. Redirections and anonymous email addresses are not allowed. We do not sell or give your email addresses away!
Passwords
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. Also, you should take care not to use the same password on Emulab that you use at other sites.
Firewalling
Emulab blocks incoming connections to nodes on 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 experimenters, as well help prevent an errant application from becoming 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.
Ports used by Emulab
If you wish to do firewalling of your own on your nodes, you should be aware that there are several ports used by Emulab that you'll need to keep open if you want your nodes to be able to function as "normal" Emulab nodes.
In the table below, a direction of 'out' means that your node needs to be able to make outgoing TCP connections to a port, 'in' means that it needs to accept incoming connections on a port, and 'both' indicates UDP ports on which you must be able to send out packets and receive the replies.
| Host | Port | Protocol | Direction | Reason |
|---|---|---|---|---|
| boss | 22 | TCP | in | ssh in from boss to reboot nodes |
| boss | 53 | UDP | both | DNS queries and replies |
| ops | 111 | TCP/UDP | both | NFS portmapper (rpcbind) |
| boss | 123 | UDP | both | NTP |
| ops | 514 | UDP | out | syslog |
| ops | 900 | TCP/UDP | both | NFS mount daemon (mountd) |
| boss | 7777 | TCP/UDP | both | Emulab node configuration (tmcd) |
| ops | 2049 | UDP | both | NFS |
| ops | 4045 | TCP/UDP | both | NFS locking (lockd) |
| boss | 8509 | TCP | out | Emulab node monitor (slothd) |
| boss | 16505 | TCP | out | pubsub event system |
For some storage related services (e.g., loading of image-backed datasets or tarballs), you will also need to allow the Emulab imaging services (frisbee):
| Host | Port | Protocol | Direction | Reason |
|---|---|---|---|---|
| boss | 21700-21799 | TCP/UDP multicast | both | frisbee up/download |
| boss | 64494 | TCP | out | frisbee master server |
Accounts
We make use of Unix user and group mechanisms 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 hierarchy (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.