Never use a password that’s the same as (or closely related to) your user ID, name, date of birth, the name of your company, or the name of your dog. If you’re an amateur radio operator, don’t use your callsign; if you love cars, don’t use the make/model or registration number of your car—you get the idea. Always ensure that your passwords are not simple words that can be found in a dictionary. The best passwords are nonsense strings. One good practice is to use a password based on a simple rule and a phrase that you can remember. For example, you might choose a rule such as using the last letter of each word in the phrase “Mary had a little lamb, its fleece was white as snow”; hence, the password would become ydaebsesesw, certainly not something that will be easily guessed, but a password that will be easily remembered. Another common technique is to use numbers and punctuation characters in the password; indeed, some passwd programs insist upon this. A combination of the two techniques is even better. One of our collegues swears by head -c6 /dev/random | mimencode as a way to generate hard passwords. Adjust the number of random bytes to use (-c6) to taste. Six input characters give eight characters of output, the maximum some Linux distributions accept for passwords.

One of the reasons that many common desktop operating systems (such as Windows) are so vulnerable to attack through email viruses and the like is the lack of a comprehensive privilege system, or rather the user’s convenience of running applications with administrator privileges. Mind you, some broken applications require to be run with administrator rights. In such systems, any user has permission to access any file, execute any program, or reconfigure the system in any way. Because of this it’s easy to coerce a user to execute a program that can do real damage to the system. In contrast, the Linux security model limits a wide range of privileged tasks, such as installing new software or modifying configuration files, to the root user. Do not succumb to the temptation to use the root account for everything! In doing so you are throwing away one of the more powerful defenses against virus and Trojan horse attacks (not to mention accidental rm -rf * commands). Always use a normal user account, and use the su or sudo commands to temporarily obtain root access when you need to undertake privileged tasks. There is an additional benefit in this limited use of the root account: logging. The su and sudo commands write messages to the system logfile when they’re invoked, mentioning the ID of the user performing the su or sudo, as well as the date and time that the command was invoked. This is very helpful for keeping track of when root privileges are being used, and by whom.

Don’t tell anybody your passwords, ever. This also means you shouldn’t write your passwords on little sticky notes attached to your monitor, or in the diary you keep in the top drawer. If you want to allow people temporary access to your system, create an account for them to use. This allows you some convenience in monitoring what they do, and you can easily clean up afterward. If you really must trust someone with your root account, use the sudo command, which allows you to give users root access to selected commands without revealing the root password.

Although it is very convenient to retrieve and install binary copies of programs on your system, you should always question how much you trust the binary before running it. If you’re installing software packages that you’ve retrieved directly from the official sites of your distribution or from a significant development site, you can be fairly confident the software is safe. If you’re getting them from an unofficial mirror site, you need to consider how much you trust the administrators of the site. It is possible that someone is distributing a modified form of the software with back doors that would allow someone to gain access to your machine. Although this is a rather paranoid view, it is nevertheless one that many Linux distribution organizations are embracing. For example, the Debian organization is developing a means of validating a software package to confirm that it hasn’t been modified. Other distributions are sure to adopt similar techniques to protect the integrity of their own packaged software.

If you do want to install and execute a program that has been given to you in binary form, there are some things you can do to help minimize risk. Unfortunately, none of these techniques is easy if you’re new to the Linux environment. First, always run untrusted programs as a non-root user unless the program specifically requires root privileges to operate. This will contain any damage the program might do, affecting only files and directories owned by that user. If you want to get some idea of what the program might do before you execute it, you can run the strings command over the binaries. This will show you all the hardcoded strings that appear in the code. You should look for any references to important files or directories, such as /etc/passwd or /bin/login. If you see a reference to an important file, you should ask yourself whether that is in keeping with the purpose of the program in question. If not, beware. If you’re more technically inclined, you might also consider first running the program and watching what it is doing using a program such as strace or ltrace, which display the system and library calls that the program is making. Look for references to unusual file system or network activity in the traces.

Your system logfiles are your friend, and they can tell you a lot about what is happening on your system. You can find information about when network connections have been made to your system, who has been using the root account, and failed login attempts. You should check your logfiles periodically and get to know what is normal and, more usefully, what is abnormal. If you see something unusual, investigate.

It’s important to keep the software on your system fairly current. That Linux kernel 1.2 system you have running in the corner that’s been reliably serving your printers for years might be a great subject at cocktail parties, but it’s probably a security incident waiting to happen. Keeping the software on your system up-to-date helps ensure that all bug and security fixes are applied. Most Linux distributions provide a set of packages that are security fixes only, so you don’t have to worry about issues such as configuration file and feature changes in order to keep your system secure. You should at least keep track of these updates.

Most security breaches are performed by people inside the organization running the target system. The most comprehensive software security configuration in the world means nothing if someone can walk up to your machine and boot a floppy containing exploit code. If your machine uses a BIOS or system PROM that allows the device boot order to be configured, set it so that the floppy and CD-ROM drives boot after the hard drive. If your BIOS provides support for password protection of its configuration, use it. If you can padlock the machine case closed, consider doing so. If you can keep the machine in a physically secure area such as a locked room, that’s even better.