ALM: Application Development 2.0 - Myths and Realities

Discover 21 Ways to Use Excel with Java Applications

Listen to the Power of IP Protection and Software Licensing Podcast

Guide to Effective Software Asset Management Strategies Download Strategic Licensing Management White Paper

CRC Career Resource Center

Listen to the Power of IP Protection and Software Licensing Podcast

The Seven Deadly Sins of Linux Security by Bob Toxen, Horizon Network Security   printer-friendly format   recommend to a colleague Avoid these common security risks like the devil Passwords

Queue Digital Edition The PDF version of the July/August issue of Queue is now online. Download here Only subscribers are able to download the Queue PDF edition. Activate your account here

Sections 1: Passwords 2: Ports 3: Programs 4: Programming 5: Procrastination

The problem with security advice is that there is too much of it and that those responsible for security certainly have too little time to implement all of it. The challenge is to determine what the biggest risks are and to worry about those first and about others as time permits. Presented here are the seven common problems - the seven deadly sins of security - most likely to allow major damage to occur to your system or bank account. If any of these are a problem on any of your systems, you will want to take care of them immediately.

These seven deadly sins are based on my research and experience, which includes too many people who wait until after their Linux or Unix systems have suffered security breaches before they take action to increase system security, and on forensics analysis and discussions with systems administrators. Most of these sins and their solutions also apply to Macs, Windows, and other platforms.

They are not ordered by risk level because committing any one of them will likely allow your system to be compromised if it is accessible from the Internet. Even if you are behind a firewall, if you receive any untrusted data from the Internet, such as Web pages, e-mail, or instant messages, your system is at great risk. Avoid these sins like the devil.

Without further ado, here are the seven deadly sins and what to do about them.

SIN ONE: Weak Passwords

As a systems administrator, you are aware of the system breaches possible on your Linux or Unix machine. You have taken the time and effort to devise a difficult-to-guess root password that uses at least 12 characters that include at least two words or no words from the dictionary, uses both letters and digits, and has upper- and lowercase letters and some punctuation characters.

I still run into clients with passwords so simple that any hacker could break them in a few minutes with a tweaked version of ssh that guesses different passwords. Such hacker tools can be found on the Web easily with Google or built by any C or C++ programmer. On Internet-accessible systems, I have seen root passwords consisting of a word followed by a small number, where that word is related to the company, what it does, who is in it, or where it is. A good hacker will go to your Web site and see all of this information, then feed it into a password-cracking program.

Another common mistake is to use the same password or very similar passwords for root accounts (or other important accounts) on different systems. Thus, a cracker who breaches one system through a means other than password guessing will then be able to install a Trojaned server for ssh, FTP, or IMAP, or a Trojaned CGI program on that system, see what passwords you use, and try them on the other systems. I have seen this happen many times.

A variation is to use ssh public keys to allow an account on one system to ssh into another system without supplying any password. At the very least, pick a moderately hard-to-crack password for your ssh keys. If you must have an automatic program use ssh without a password to ssh into another system, then create either a separate nonroot account on the target system or an alternate account with UID 0 but a login "shell" that does just what is needed, such as doing a backup.

An even better solution, say for a remote backup, would be for the system needing to be backed up to ssh into the system receiving the backups as a unique unprivileged account for this purpose and copy an encrypted version of the backup. Thus, if the backup server is compromised, no confidential data will be obtained.

Let's hope your root password is awesome and that no one could guess it in 100 years. OK, some obsessive with a program such as Crack could destroy it in a few days except that you use shadow passwords, but that's another story. It is critically important to select good passwords.

How are your users doing? Choke, cough, gag, hack. Every account is a possible entry point. Have your users followed your advice, company policy, or threats to devise good passwords? Are they being as careful as you are? Probably not. Now it is your turn to don the black hat and think like your enemy.

Can you break into your users' accounts by using a password-cracking program? You definitely will need to get written management approval to conduct this level of security audit. There are notable cases of unauthorized audits landing people in jail or at least on the unemployment rolls. (Randal Schwartz is one. The software consultant and author was brought to trial for accessing a password file at Intel in what he says was an attempt to show lapses in security.)

You might even install a module in the passwd program that automatically tries to break a user's proposed new password. Though the standard passwd program makes very simple tests, there are more sophisticated routines that include much of Crack's capability. One way to do this is to make use of the cracklib capability in the PAM (pluggable authentication modules) enhancements to the passwd program. The cracklib library analyzes passwords to determine if they can be easily cracked. PAM offers additional security for Linux and Unix systems.

Edit the /etc/pam.d/passwd file to include the code in figure 1. This will cause the PAM-enabled passwd program to load these dynamically loadable program libraries. PAM now is standard with Red Hat. On some systems these are in /lib instead of /usr/lib. (Another good source for PAM information is http://www.sun.com/software/solaris/pam/.)

On Slackware this capability will be enabled if the following line is present in /etc/login.defs (and the dictionary is installed):

CRACKLIB_DICTPATH /var/cache/cracklib/cracklib_dict

Consider restricting which remote systems can ssh into your systems' various accounts either through IP tables firewall rules or by editing your ssh server's configuration file, /etc/ssh/sshd_config, to limit which remote systems can ssh in and which accounts they can ssh into, or use both methods for additional security. Make this list very short for root (in sshd_config).

next page (2/5) Ports

Submit this story to one of the following blogs:

Discuss The Seven Deadly Sins of Linux Security

Latest Comments   NSA... - Pretty funny to use the NSA telephone number 301-688-652x in your security example :)... Post your comment now! name: email: subject: comment: note: only <b>, <i>, and <br> tags allowed Please type in the captcha number below