Disclaimer

This is not intended to be a tutorial on basic Unix/network security. It is only here to point out some additional security measures that you may want to take to avoid compromises to your account/machine.

Avoiding sniffed passwords
- SSH
- Kerberos
Avoiding guessed passwords
Avoiding compromises due to file permissions
Avoiding compromises due to trojan horse attacks
Avoiding compromises via the X window system

Avoiding sniffed passwords

This is probably the most common method of compromising Unix accounts at Stanford (in Oct. 1998, a packet sniffer installed on a machine in Sweet Hall gathered over 5000 username/password combinations in a two week period). Like it or not, the machines are attached directly to the internet (not hidden behind a firewall), and machines do periodically get broken into. Often the hacker sets up a packer sniffer, a program which will gather and filter all traffic over the local network looking for username/password combinations. There is virtually nothing that can you do to avoid the machine compromise (unless you are the system administrator for all machines on your local net), but you can take precautions to minimize the probability that your account will be sniffed by avoiding sending your username/password over the network.

SSH

If you don't have a SUNet ID, your only option is to use SSH. SSH also has a companion remote copy program, scp, that can be used as a replacement for rcp or ftp. SSH is quickly becoming my top choice because of the tunneling capabilities (i.e. the ability to route almost any network connection through an encrypted [and even compressed!] link).

If you are looking for a Window-based ssh client, try putty. Stanford's Secure Desktop Computing site also has pointers to other clients.

Besides sending an encrypted password over the network, most ssh clients automatically tunnel X connections over an encrypted link which makes it safer and more convenient to use xauth-style access. It is also possible to use port tunneling in via ssh to avoid passwords being sniffed via ftp or POP. See the instructions on configuring additional ports to be tunneled. SSH also supports compression, which can be useful to get better throughput over slow (dialup) links, though nothing in the world can improve latency.

The machines in the gloworm cluster also support RSA authentication (though it doesn't get you a Kerberos ticket-granting-ticket or an AFS token). If you want to use RSA authentication, you need to generate a private and public key pair for your client-side identity.

    ssh-keygen -b 1024 -f $HOME/.ssh/identity
      (enter your passphrase)

Needless to say, your passphrase should be something that is difficult to guess. You can (securely) transport ("securely" means over an encrypted link, not via ftp) this private identity file to other (unix) client machines from which you will be using RSA authentication. Make sure that only you can read this identity file.

Then, append the contents of $HOME/.ssh/identity.pub (the public key) to $HOME/.ssh/authorized_keys on all machines that you indend to use RSA authentication to log into. Permissions are important for this file; it should be world-readable, but writable only by the owner (not group writable). Because all machines in the gloworm cluster share a common file space, you only need to add your public key once.

If you use console logins on your workstation, you may also want to append the following to your ~/.login file

    if ( ${?SSH_CLIENT} == 0 ) then
      eval `ssh-agent`
      ssh-add
    endif

You should also kill off the agent at the termination of your login session, so you may want to add something similar to

  if ( ${?SSH_AGENT_PID} ) then
    eval `ssh-agent -k`
  endif

to your ~/.logout file. Be careful with this, because if you log in remotely from other machines, you may kill the agent prematurely. A better fragment for your ~/.logout is

set howmanyofme=`who | cut -d" " -f 1 | grep $USER | wc -l`
if ( $howmanyofme == 1 ) then
  if ( ${?SSH_AGENT_PID} ) then
    eval `ssh-agent -k`
  endif
endif

If you use CDE, to be prompted for your RSA passphrase on login to CDE, add something similar to the following to your ~/.dtprofile:

eval `/usr/pubsw/bin/ssh-agent -s`
/usr/openwin/bin/xterm -font 9x15 -geometry 80x40+250+100 \
  -bg blue -fg white -e /usr/pubsw/bin/ssh-add

You should also kill off the agent at the termination of the CDE session. To do this, create ~/.dt/sessions/sessionexit (with execute permissions) and the following contents:

#!/bin/sh
/usr/pubsw/bin/ssh-agent -k

If you don't use console logins or CDE, then you will need to figure out how to start the ssh-agent and provide the RSA passphrase on login.

Kerberos

If you have a SUNet ID, you also have the option to use Kerberos.

To set up your gloworm account to allow Kerberos authentication, create a ~/.klogin file with that contains your Kerberos principal (i.e. sunetID@IR.STANFORD.EDU; you should substitute your personal SUNet ID for sunetID and case is important [IR.STANFORD.EDU must be all caps]). Due to the way some of the Kerberos services work (you don't obtain privileges, such as the ability to read a file, until after you are authenticated), ~/.klogin should be world-readable (chmod 644 ~/.klogin) with our NFS-based home directories. Also, your home directory must be at least world-searchable (chmod a+x ~).
To use Kerberos, you will need to obtain a Kerberos ticket granting ticket.
- Under Unix, kinit -t (if your gloworm username is the same as your SUNet ID) or kinit -t sunetID (if your gloworm username differs from your SUNet ID). Note that this obtains both a Kerberos ticket granting ticket and an AFS token.
- With PC-Leland, see the documentation
- With MacLeland, see the documentation
Note that these tickets expire after 24 hours, so you will have to renew (or obtain a new one) periodically.
Don't use telnet. telnet passes the username/password over the network in the clear. Alternatives include:
- klogin: This is a kerberized equivalent of rlogin with the added benefit that everything transferred over the network is encrypted. (If your SUNet ID isn't the same as your gloworm username, you need to klogin machine -l username)
- ktelnet: This is a kerberized equivalent of telnet with the added benefit that everything transferred over the network is encrypted. (If your SUNet ID isn't the same as your gloworm username, you need to klogin machine -l username)
- MacSampson/PC-Sampson: These programs are part of the MacStanford and PC-Stanford software distributions. If used in conjunction with MacLeland/PC-Leland, Sampson will provide a Kerberos-authenticated and encrypted telnet connection.
Don't use authenticated ftp to transfer files. ftp also passes the username/password over the network in the clear. Alternatives include:
- Within the (nearly) completely cross-mounted cluster, you should be able to cp files from anywhere to anywhere.
- To transfer files in and out of the cluster,
  - if the remote machine supports incoming ssh connections, use scp
  - if the other machine is a kerberized Unix machine, you can use the kerberized rcp. Unfortunately, rcp doesn't seem to support the -l user for specifying which remote account to use, so your SUNet ID and gloworm username must be the same.
  - if the other machine is a Unix machine, but not kerberized, you can use the stock rcp (along with a ~/.rhosts, if needed)
  - if the other machine is not a kerberized Unix machine, then you need to use more extreme tactics such as
    - sending the file as an email attachment
    - dropping the file in your personal web space (i.e. ~/WWW) and transferring it with a web browser
Don't use POP (e.g. under Eudora or Netscape) to read your mail. POP also transfers username password combinations in the clear.
Eudora supports a kerberized POP (on gloworm, the Service Name is rcmd, not pop and can be changed in the kerberos settings.
There is currently no kerberized POP available for Netscape. It is possible to use SSH to tunnel your POP connection to gloworm.

Avoiding guessed passwords

The goal here to to pick an easily remembered, but uncrackable password. There are hackers out there that try to `crack' accounts by comparing encrypted passwords against the results of encrypting simple variations on words in dictionaries. See the article "Picking an unguessable password" for some guidelines.

Account compromises by cracking passwords are becoming less common (especially on systems where the encrypted passwords are stored in a shadow file, instead of being readable to everyone on the system). Although shadow passwords are the norm on Solaris, certain features of our cluster prevent them from being implemented for our network password database.

Avoiding compromises due to file permissions

Never chmod your home directory to be world-writable. If you want to give someone else permission to write files into your account, change the permissions on a subdirectory.
Never chmod your login startup scripts (~/.cshrc and ~/.login), application scripts (e.g. ~/.xsession, ~/.twmrc, ~/.mailrc, etc.), or other potentially exploitable files (e.g. ~/.rhosts, ~/.forward, etc.) to be world-writable.
The default umask (file creation mask) permits everyone on the machine to read your files and permits both the owner and the file's group to write the file. This is a reasonable umask for virtually everyone because each user is also in their own group. Files under your home directory will take on your unique group ownership, and others won't be able to write to them unless you explicitly change the group ownership.
If you want to restrict read access for a set of files/directories , the recommended approach is to create a directory and chmod it to the appropriate restriction, then store the files/directories under that directory. For example,
```
          mkdir ~/private
          chmod 2710 ~/private
          cd ~/private
          touch secret
      
```
Note that using 2710 (drwx--s---) is encouraged over 700 (drwx------) to ensure that group ownership of files/directories below that directory take on the group ownership of the parent directory. This assumes BSD setgid directory semantics (Solaris) which are subtly different from POSIX file creation semantics. POSIX semantics specify that the group owner of a newly created file/directory is always either that of the parent directory (if the user is a member of the group for the parent) or the user's default group (if the user is not a member of the group for the parent), regardless of the state of the setgid bit on the parent directory.

Avoiding compromises due to trojan horse attacks

Don't put "." in your $PATH.
If you believe that you must have "." in your path, add it as the last component.
Never, ever, put "." as the first component of your $PATH.
If you use a MIME-enabled email program, make sure that it guards against mime buffer overflow attacks in email attachments.
Don't enable java or javascript in your browser. I don't care that the browser vendors say the current releases are secure. The next java or javascript hole is yet to be discovered.
If you do run a browser with java, javascript, or ActiveX enabled, use a reasonable security level. Don't blindly trust remote sites that ask you to change your security settings to something more permissive.
On a PC or Mac, don't run anything that you download from the net until you have run a virus scanner on it. Even well-known and well-trusted sites have been compromised and had bogus virus-infected files dropped on them.
This also applies to any Microsoft Word files that you download (they could be infected with the Word macro virus).

Avoiding compromises via the X window system

The answer is simple, never use "xhost"-based authentication. Use xauth, instead.

With CDE, or the PUBSW "x" or "openwin" scripts, this should already be set up, provided you stay within the cluster. If you run X applications on machines not in the cluster, you will need to transfer your key ("xauth list" on the local machine to find the key, then "xauth add" on the remote machine to transfer the key).

For those using X software on a Mac or PC, xauth-style access is often tricky to set up, but it is usually possible. Check the documentation that came with your X emulation software.

Also see Securing X Windows.

action@gloworm.stanford.edu

Last modified: Tue May 20 11:45:41 PDT 2004