Carnegie Mellon University School of Computer Science

Security: Linux

There are a fair number of of break-in attempts to Linux hosts in SCS (with some successful ones). Most of these break-ins are to non-Dragon (not built by SCS Computing Facilities) hosts. This is due to the fact that in our builds we have modified many commonly vulnerable network services, use Kerberos for secure authentication, and keep Facilitized hosts up-to-date with patches for remotely-exploitable vulnerabilities.

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

  • Keep software patched.
  • Keep your passwords secure.
  • Restrict access to your host.
  • Be mindful of security when configuring software.
  • Be alert as to what is happening on your machine.

Keep software patched

Unpatched software is the #1 cause of break-ins to 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 Linux hosts).

Keep your passwords secure

To keep your passwords secure:

  • Always use encrypted connections (such as SSH) 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 hosts other than your own.
  • Don't use the same passwords for different purposes. Your passwords should be unique for each distinct system or service they are created for.
  • Use complex 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 Dragon hosts have tcpwrappers installed. See the section in the local Linux 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 mindful of security 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 page 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-twistable, 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 computer.

Keep an eye out for suspicious activity on your host. If you do notice strange behavior, daemons, or processes, you should investigate and/or contact us if the host is running on the SCS network.

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, SCS Dragon 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 registered for support with us. 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 Computing Facilities.