Suggestions for Securing a Unix or Linux Computer

Following are guidelines for securing a computer that is running a version of the Unix or Linux operating system. These rules are broad in scope; the specifics of each particular operating system preclude an authoritative guide that will cover them all (check here for detailed security recommendations for your specific OS). The main focus of this guide is on using encrypted communications and avoiding running unneeded services.

Run a command like "netstat -an" to see which ports your computer is listening to. You should understand why your computer is listening to each port that is reported. Do not run telnet (port 23) or ftp (20 and 21), because authentication is done over the wire in clear text. (Even in a switched environment one is not immune to packet sniffing). For computers that house sensitive data, other services such as smtp (25) and http(s) (80, 8080, or 443), which have a poor security history and are prime targets for network abusers, should not be used either. Various services like chargen (19) and echo (7), which many systems activate by default, should not be on unless they serve a specific purpose. Some rpc services like ttdbserver also have a poor track record and should not be used. Hopefully if you are in a campus environment you will have other machines in place as DNS servers, so be sure to disable bind as well, because it has a poor record for security.
Use only encrypted authentication tools like Secure Shell version 2 (ssh2) and/or kerberos in order to protect login credentials. Very good free tools like openssh are quite robust, standards compliant, and easy to build for any Unix or Linux operating system. A good and free Windows terminal client that speaks ssh2 is Putty. Secure shell version 1 is weak and should not be used. Machines running a ssh daemon should not have it configured to failover to ssh1 if the client cannot speak ssh2. If you are building ssh2 be sure that you have the latest openssl version as well. Disable any r-services that may be in place by default such as rsh, rexec, rcp, and rlogin. These services are extremely vulnerable and should be replaced with similar ssh and scp commands.
Make use of a system logging tool like syslog and copy all of your logs to a dedicated syslog server. Running a syslog server that collects the logs from all of the other systems is a great idea. More than likely if someone is clever enough to break into your system they are clever enough to know how to purge the logs and cover their tracks. Having a syslog server allows one to at least have some confidence in knowing who has done what in the past. Syslog is the most common tool for this type of logging and comes bundled with most flavors of Unix and Linux. Review your syslog files regularly (e.g., weekly) to make sure nothing unusual is taking place.
Review your /etc/passwd and /etc/security/passwd files regularly to make sure all userids have a password (not null) and that only the root user has a UID of 0. Expiring passwords at least every three or four months will help ensure that old users lose access even when the sysadmin forgets to remove them. Requiring strong passwords is a necessity. Removal of default system userids like "guest" is also very important. Do not allow the use of shared accounts among users as this makes audit controls useless. One user, one account.
Avoid logging in as root. When logging into a system, login with a non-root userid and only su to root if absolutely necessary. Never log in to a remote host as root on a user's computer—you never know what viruses or keylogging programs may be running.
Log in to your systems often and see what processes are running. Using commands like "ps -ef" to list all processes can be very enlightening. Anything that isn't immediately obvious as a usual system or user process should be checked out. Reviewing who has logged into a system with "last" is also a great idea, and using system accounting commands like "sar" will help you find potential abuse as well.
Keep your systems patched. Make use of security information outlets like CERT by getting on their mailing list so that you receive important security alerts in a timely manner. There is no substitute for keeping up with the latest exploits and fixes on the systems for which you are responsible. Most vendors make patches available in short order once a security bug is found, so check your vendor's Web sites often. A frequent review of Web sites like SANS with their many online resources including the Top 20 List can help to keep checklists of things to do to lock down a machine. Great resources for reviewing specific vulnerabilities can be found at the CVE Dictionary and at BUGTRAQ. If you want to run a Linux box and are shopping for a secure distribution, consider the Bastille Linux hardening scripts, which are intended for use by those who want some way to lock down Red Hat, Debian, or Mandrake distributions.
Do not copy or move your sensitive data out of the secured directory or off of the secured server for any reason.

Form to describe your security plan