SCS Computing
 Services and Solutions
  links to the SCS and CMU home pages Carnegie Mellon School of Computer Science Carnegie Mellon University
 » How to… 
 » Accounts & passwords 
 » AFS 
 » AV help 
 » Backups & restores 
 » Calendaring 
 » E-mail 
 » Networking 
 » Printing 
 » Purchasing 
 » Resource management 
 » Security 
 » Software licensing 
 » Support charges 
 » Support lifecycle 
 » Web publishing 
 » Mac support 
 » Linux support 
 » Windows PC support 

Unix/Linux security

There are a fair number of break-ins to Linux hosts in SCS. Most of these break-ins are to non-Facilitized hosts, since we have modified many commonly vulnerable network services, use Kerberos for secure authentication, and keep Facilitized hosts up-to-date wrt patches for remotely-exploitable vulnerabilites.

The main things that one can do to prevent break-ins to Unix/Linux systems are:

Keep software patched

Unpatched software is the #1 cause of break-ins to Unix/Linux hosts. If you install software, you must regularly check for any security updates that may come out for the package you install (for example, by subscribing to a relevant mailing list). You must also do this for any operating systems that you have installed (Facilities is responsible for updating OS software on Facilitized Unix/Linux hosts).

Keep your passwords secure

To keep your passwords secure:

  • Always use encrypting connections when sending passwords over the network (with the possible exception of some Kerberos instance passwords explicitly meant to be insecure). Note that passwords may still be eavesdropped through keyboard and tty sniffers even if you do use encrypted network connections, and that regular NIS sends encrypted passwords over the network in the clear.
  • Avoid typing passwords at untrusted hosts.
  • Don't use the same passwords for different purposes. Your main Kerberos password should be different from your NIS, Kerberos instance, Windows domain, and other passwords.
  • Use good passwords.
  • Don't share your passwords with others.

Restrict access to your host.

There are a few things you can do to restrict access to your hosts:

  • All Facilitized hosts have tcpwrappers installed. See the section in the local Unix admins guide on restricting access for information on how to enable them.
  • On Linux, you can use ipchains/iptables for packet filtering.

Also, if you create accounts on a host, keep in mind that you are relying on the people with those accounts to be careful with their passwords and keep their hosts secure.

Be paranoid when configuring software.

Some number of break-ins to SCS hosts and other incidents are caused by poorly configured software. For example:

  • If you're installing a MySQL server, don't have it listen on the network unless absolutely necessary. If it must be network accessible, try to restrict access to a limited set of hosts. Be sure to set passwords for all accounts, including root. Don't install PHPMyAdmin unless you restrict access to it.
  • If someone can connect to your X server, they can sniff your keystrokes. For that reason, never, ever, do a "xhost +". See our X server security document for details on how to secure your X server software and sessions.
  • If your home directory is exported via NFS to an untrusted host, someone could could easily break-in to your host by changing your .login or .cshrc, modifying your path, etc).
  • If you create an anonymous FTP area that is world-writable, it will quickly be used by intruders as a warez distribution site.

You should never trust a software package's default configuration and passwords, and should be very careful when giving access to resources on a host that could lead to system or account compromise.

Be alert as to what is happening on your machine.

Keep an eye out for suspicious activity on your host. If you do notice such behavior, you should investigate and/or contact us if the host is running the Facilities environment.

Note that because we get scanned on a constant basis, many of these scans will leave traces of some kind in various log files. In particular, Facilitized hosts run an ftpd by default, and would-be intruders often connect to it and attempt anonymous logins. These logins are generally not successful because the ftp user's home directory does not exist by default; however, they do show up in the output of last.

If you do get hacked

If you do get hacked, you should contact us to have it taken care of if the host is under Facilities support. If it is not supported by SCS Facilities, please let us know about the break-in anyway, along with any details about how and from where it got broken into. That information will help us find out if other hosts may have been hacked in the same way or by the same sites. We would also be interested in any log files from sniffers or scans that the intruder may have created.

If the host contains confidential information (SSNs, grades, etc), you must report the break-in to SCS Facilities.

If the host is not supported by SCS Facilities, see our instructions on how to deal with Unix/Linux break-ins.

Related documentation

Unix/Linux support
About SCS Facilities Unix/Linux support and our environment.
Unix/Linux local administrators guide
How to locally administer a Facilitized Unix/Linux host.

Additional information

The following off-site links will open in a new browser window:
Good general Linux security site with lots of news and updates.
Hacking Linux Exposed
Along with advertising for the book, has a selection of interesting articles.