Security: Linux

There are a fair number of of break-in attempts to Linux hosts in SCS (some of which have been successful). Most of these successful break-ins are to non-Dragon hosts (not built by SCS Computing Facilities). This is due to the fact that in our builds we use Kerberos for secure authentication, deploy fail2ban to minimize the impact of repeated brute force login attempts and keep Dragonized 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 Dragonized 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:

• On Ubuntu, you can use ufw for packet filtering.
• Utilize SSH Keys when connection to non-Dragonized hosts
• Guard against rogue USB devices

We enable fail2ban by default in our builds in order to enforce a delay after multiple failed login attempts. Additionally, we encourage the use of fail2ban on non-Dragon hosts. More information about fail2ban in general is available at their official website, www.fail2ban.org.

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, file permissions, and to 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 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-writeable, it most likely will be exploited by intruders for malicious activities.
• If you are using Bash or Zsh, you can set TMOUT for an automatic logout from shells after a timeout.

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 a sshd by default, and would-be intruders often connect to it and attempt brute-force logins. These logins are generally not successful if you use a strong password; however, failed login attempts are still logged.

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.