- 0. Basics
- 1. Control network services
- 2. Apply patches regularly
- 3. Take other common-sense measures
- Use strong, unique passwords
- Use SSH
- Don't allow unsecured remote logins
- Configure X-Windows restrictively
- Don't allow remote root login
- Configure NFS restrictively
- Keep your system physically secure
- Install an intrusion detector
- Implement a firewall
- Take regular backups
- 4. Additional Tools and Resources
- Appendix: Configure X-Windows securely
This page is a guide for hardening a desktop Linux system (making it less vulnerable to compromise by ignorance, accident, or hostile vandalism). This is just a starting point. A good next step is the RedHat Security Guide http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Security_Guide/.
The focus here is on Red Hat Linux, but the same principles apply to other Linux systems, although the specific tools and directory paths may be different. A generalized Security Quick-Start HOWTO for Linux is available for systems other than Red Hat (http://www.faqs.org/docs/Linux-HOWTO/Security-Quickstart-HOWTO.html). Another general document is The Linux Administrator's Security Guide, (http://www.seifried.org/lasg/).
Administering a Linux system in a networked environment like the Princeton University campus carries responsibilities toward other users and systems. Unsecured Linux systems attract hackers (and automated scans) very quickly. A Linux system which is on the network for more than a few minutes, without steps taken to secure it, is very likely to be compromised. In addition, it can give malicious intruders a platform from which to attack other systems on campus and around the world.
Before attaching a new Linux system to the network, disable all of its network services (sometimes called local 'servers' or 'daemons'). Very few are required to make full use of a desktop system. For example, the ftp daemon (ftpd) isn't needed in order to be able to ftp to other systems. It might be used to allow users of other systems to move files to or from your system, but there are more secure methods to do that.
Steps for battening down a system:
A. Use TCP wrapping
Access control through tcpwrappers is implemented by two files, /etc/hosts.allow and /etc/hosts.deny. When an attempt is made to connect to a system, the file /etc/hosts.allow is checked. If the entry matches conditions in the file, the connection is permitted. Afterwards the /etc/hosts.deny file is checked; any match will result in a denied connection. If no match occurs in any of the two files the connection is automatically allowed. To deal with this, the file /etc/hosts.deny must exist, and contain just the entry: "ALL: ALL" to prevent access by all "wrapped" applications. See the manpage hosts_access for details.
B. Start only a limited number of basic services at boot-time
Use the command 'chkconfig --list | grep on' to get a list of what services exist and are being started at system boot. Services you probably need include:
- crond: Enables cron daemon used for scheduling jobs
- iptables: Loads the iptables host based firewall
- keytable: Loads keyboard map for the system
- network: Starts network interfaces
- ntpd: Controls system clock synchronization
- random: Increases the quality of random generation (used by applications encrypting network data)
- rhnsd: Periodically checks RH Network for available updates
- syslog: Activates daemon that other daemons use for logging messages
- xinetd (sgi_fam): Monitors the filesystem for changes and notifies interested applications (such as the Nautilus file manager)
C. Turn off boot-time initialization of unneeded services
The command is 'chkconfig [service] off', e.g., 'chkconfig talk off'. Be aggressive in turning services off; you can easily turn them back on later. In particular, it is very unlikely that you need sendmail; it is much safer to configure your mail client to use the University's mail servers. Err in the direction of turning off everything you don't recognize.
Services that you probably don't need include exec, finger, ftp, httpd, login, lpd, nfs, ntalk, rexd, sendmail, shell, talk, telnet, tftp, and uucp.
D. Reboot and run 'chkconfig --list' again, to check that you've done what you intended to do.
If a specific service is needed later, review the Security Quick-Start HOWTO for guidance before enabling it. If the service is a "wrapped" one (these are listed in /etc/xinetd.d), make an entry for it in /etc/hosts.allow that is as restrictive as possible. For example, if you need to allow SSH login by anyone in the Princeton domain: sshd: ALL@.Princeton.EDU But if you can get away with listing specific hosts that are allowed access, rather than everybody in the domain, that is much better.
Once you have installed your system and secured it as above, attach it to the network and apply all of the patches for your system level. Continue to do this on a regular basis. It is very important to keep your system current. New exploits are discovered all the time and are used by hackers the moment they become known. OIT’s schedule is to patch all Linux servers on a quarterly basis.
Red Hat maintains an errata page listing current security patches for each of its systems: http://rhn.redhat.com/errata/.
Use strong, unique passwords. Use a very strong password for your root account (mixed-case with special characters and not resembling a name or other word from a dictionary). Don't use that password for anything else, particularly not across a network.
Use SSH rather than the "r*" commands. SSH ("Secure Shell") provides "secure, encrypted communications between two untrusted hosts over an insecure network" (issue man ssh2 for more on SSH). Open-SSH comes with Red Hat. It replaces a number of insecure commands:
- ssh <-l netid> remotehost provides a secure remote login (in place of the rlogin command).
- ssh <-l netid> remotehost command provides a secure method to issue a remote command (in place of the rsh command).
- scp localfile netid@remotehost:remotefile provides a secure method to copy a local file to a remote host (in place of the rcp command).
Don't allow unsecured remote access. Don't create an /etc/hosts.equiv file or a .rhosts file (they enable remote login without a password). Don't run rlogind or rshd (which enable remote login with the password sent as plaintext). Run sshd to allow access via SSH if you need remote login at all.
Configure the X Windows System restrictively. See Appendix for details.
Configure NFS restrictively, if at all. Unless you really need to provide NFS service to other systems, disable nfsd (using chkconfig). If your system must be an NFS server, see man exports and specify the most restrictive options you can can. Where possible, export your local filesystems in read-only mode. When mounting remote filesystems on your system, specify o=nosuid,nodev.
Keep your system physically secure. Use the Control Panel to configure your screen-saver to require a password. The boot loader should be password protected (see man lilo.conf if you are using lilo as your loader). The BIOS settings should disable booting from anything other than the internal hard disk; the BIOS should also be password protected.
Institute measures to detect intrusions. A tool for this, Tripwire (http://www.tripwire.org/), comes with Red Hat; it can be used to detect unauthorized changes to files. Also, system logs should be checked regularly for signs of trouble. You might wish to install a log-checking tool to automate this.
Consider implementing a firewall. Red Hat comes with a simple firewall. See man iptables and the RedHat Security Guide (http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Security_Guide/) for details.
Take regular backups. OIT provides Tivoli Storage Manager (TSM) backup service to anyone in the University community who requests it. (See http://helpdesk.princeton.edu/kb/display.plx?ID=9969 and see the README file that comes with the client for instructions). Once configured, the system will be backed up overnight automatically whenever it is attached to the network. Use the TSM client to restore files on demand.
Remove unused or unnecessary rpms. If there are some services, i.e. telnet, r*, that are not used, it's a good idea to remove them completely. The manual page for 'rpm' will explain how to do so.
Along with disabling unwanted services via chkconfig, do the same for services started by xinetd. See the RedHat Security Guide for details.
- RedHat Security Center: http://www.redhat.com/solutions/businessneeds/security/
- Red Hat Linux Security Guide: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Security_Guide/
- Princeton University Information Technology Policy: http://www.princeton.edu/itpolicy/
- Princeton IT Security: http://www.princeton.edu/itsecurity/
- Secure password storage: http://www.techradar.com/news/software/applications/8-of-the-best-linux-password-managers-916152
The X Windows System on Linux is very powerful but can be a hole into your system (allowing, for example, a user somewhere on the network to see your keystrokes as you enter them). Red Hat Linux 7.0 and higher come with the correct X security options asserted by default. The X server is using X Authority to control client access to the X display server, and the X display session managers (xdm, gdm, kdm) are configured not to accept remote requests. Leave these settings as they are; don't use the xhost and xauth commands and don't change the Xaccess file. Instead, you should require any incoming or outgoing X connections to be tunnelled through SSH.
If you want to be able to run X applications on other systems with the display on your own machine, you must be running an X display server and have the DISPLAY environmental variable set. (If you are using a Linux windowing system, both of these will be true.) In addition, take these steps:
- Turn on X11 forwarding. This can be done on the command line but to set it permanently, you should update the system-wide default ssh client configuration file (/etc/ssh_config or /etc/ssh2/ssh2_config or similar) to specify "ForwardAgent yes" and "ForwardX11 yes" or make a similar change to .ssh/ssh2_config in your home directory.
- Issue your X commands with ssh, e.g., ssh < hostname > /usr/X11R6/bin/xterm.
- Similarly, if you want to be able to run an X application on your system with the display going to another system, take these steps:
- Enable sshd on your system (with chkconfig) and make a suitable entry for sshd in your /etc/hosts.allow.
- Add an entry to /etc/hosts.allow that says: "sshdfwd-X11: [IPaddress]" (where [IPaddress] is the IP address of your system).
- Update the configuration file for your sshd (/etc/sshd_config or /etc/ssh2/sshd2_config or similar) to specify "X11Forwarding yes" (or "AllowX11Forwarding yes" for some implementations).
- On the remote system, issue your X commands with ssh, e.g., ssh [hostname] /usr/X11R6/bin/xterm. Don't allow remote root login. Force anyone who has root access to your system to login as a real user and then su to root. Make sure that the /etc/securetty file contains no entry starting with "ttyp" or "pts". Configure your SSH daemon to deny remote root logins by setting PermitRootLogin to "no".
Posted Sept. 2007; Rev. Oct. 2009; Dec. 2011; April 2012
(c) 2007-2012 by The Trustees of Princeton University