Security Considerations


The first step in securing any operating system is to secure the user and group accounts. This includes, but is not limited to, the following:

  • Enforcing strong password selection

  • Restricting user access to only those files, directories, and shells that are absolutely necessary

  • Safeguarding system accounts (especially root)

  • Closing any potential backdoors, such as disabling unused or dormant accounts

These steps are discussed in the following sections. Other precautions, such as securing a user's working environment, handling filesystem security, preventing and detecting intruders, as well as system hardening are discussed in later chapters in this book

Using Strong Passwords

Like having good and secure locks on your house, you want users to pick passwords that are difficult to guess yet easy enough to remember so the users will not write down their passwords for the world to find. Difficult-to-guess passwords means they should not be associated with the user personally, such as the name of his or her spouse, names of children, pets, or the user's address. Strong passwords should also not include dictionary words. Many password-cracking programs make use of word lists to brute-force crack passwords. Many of these programs are freely available over the Internet; two of the most popular password-crackers are Crack and John the Ripper. We will discuss how you can use John the Ripper to detect weak passwords on your system in Chapter 11.

One way to select a difficult-to-guess password is to use a randomly selected string of characters, such as i2#yA9%3r. This is not a word found in any dictionary, nor is it remotely connected to a user. Unfortunately, your user probably wouldn't be able to remember such a password. The likely result is that the user will write it down on a sticky note and paste it underneath his or her keyboard!

A better way to select a strong password is to use a short phrase (commonly referred to as a passphrase) such as I missed hockey! Alternatively, you can derive a password from a long sentence such as The Adventures of Buckaroo Banzai across the Eighth Dimension! One derivation is to simply take the first letter from each word, except for the word Eighth, which is replaced by the number 8, and you get TaoBBat8D. Or you can take the second letter of each word, except again for the word Eighth, and you get hdfuach8i. As you can see, you can use many variations to come up with difficult-to-guess but rather easy-to-remember passwords.

NOTE

Given the ever-increasing computing power and the ready availability of utilities such as John the Ripper and packet sniffers (such as Ethereal), even the most difficult-to-guess passwords are fast becoming worthless. If a hacker obtains a list of your usernames and hashed passwords, he can run Crack or John the Ripper against the list until a match is found. If the user is logging in over a network, both username and password are sent in cleartext (unless the session is encrypted such as when using SSH instead of Telnet). This makes it even easier for the bad guy because all he needs is a sniffer to capture all the network traffic and look for "Login:" and "Password:" in the packets. No need for John the Ripper at all! You can take many steps discussed throughout this book to minimize the impact and even prevent these types of attacks from happening in the first place.


The standard industry recommendations on selecting strong passwords and enforcing password security are summarized in the following sections.

PROTECT YOUR PASSWORDS

The first rule of password security is that you don't ever write down your password; memorize it instead. In particular, don't write it down and leave it somewhere that is publicly or easily accessible by others, and don't place it in an unencrypted file! If you can't memorize it, you didn't choose a good password. If you must write it down, keep it on your person at all times!

If you have access to different systems and a centralized authentication mechanism (such as NIS or LDAP) is not used, use unrelated passwords on these machines. This also applies to your access to systems controlled by different organizations: You don't know how well they protect their systems and don't want to help any bad guys to get into your servers using information hacked from those other systems.

Don't give or share your password, in particular to someone claiming to be from computer support or a vendor, especially over the phone! Often, a hacker uses deception or misdirection to obtain information from an unsuspecting userespecially a new user. The hacker often pretends to be someone in authority, such as someone from IT Security or a vendor's customer support group that needs to verify a user's identity. Consider the following telephone conversation:

Hacker: Good morning! This is John at the corporate IT Security division. Are you Susan James?

Susan: Yes, this is she.

Hacker: We are in the process of setting up your mainframe access. To make things simple for you, we will make your mainframe's username and password the same as your LAN's so you don't have to memorize multiple logins.

Susan: That's great!

Hacker: Your LAN username is Sjames, correct?

Susan: Yes.

Hacker: All I need is your password so I can enter that into mainframe.

Susan: Sure; it is…

This method is referred to as social engineering. The hacker simply carries out a seemingly innocent conversation with the victim in a social setting and obtains the necessary information without having to spend days trying to crack a single MD5- or Blowfish-hashed password!

CAUTION

In recent years, such social engineering ploys (known as phishing) have been used on the Internet. The bad guys send out an email to a user falsely claiming to be an established, legitimate enterprise in an attempt to scam the user into surrendering private information that will be used for identity theft. The email directs the user to visit a website where he or she is asked to update personal information, such as passwords and credit card, Social Security, and bank account numbers that the legitimate organization already has. The website, however, is bogus and set up only to steal the user's information. Visit http://www.ftc.gov/bcp/conline/pubs/alerts/phishingalrt.htm for more information.


Don't let anyone watch you enter your password and don't enter your password into a computer you do not trust. If the password is needed only for a limited time, change it periodically. When it comes to safeguarding your password, the golden rule is practice perseverance and vigilance.

CHOOSE HARD-TO-GUESS PASSWORDS

A strong password should be something you would not find in a dictionary (in any language or jargon). You shouldn't use a name (including that of a spouse, parent, child, pet, and so on) or any variation of your personal or login name. Don't use publicly accessible information about you (such as your phone number, car license plate, or employee number) or your environment (such as office address) as part of your password. Don't use a birthday or a simple pattern (such as spelling the username backward, following the name with a digit, or preceding the name with a digit).

A good, hard-to-guess password consists of a mixture of upper- and lowercase letters as well as digits or punctuation. When choosing a new password, make sure it's unrelated to any previous passwords (such as by adding a digit to an old password). Use long passwords (say, eight characters or more). You might use a word pair with punctuation inserted (such as greAT:@Book), a passphrase, or selected letters of each word in a long sentence, as discussed previously.

BUTTON DOWN THE HATCHES!

You should never, ever, allow an account without a password. Such an account is an open invitation begging some bad guy to compromise your system. Lock all unused accountsfor users who are away for an extended period of time or users who have left your organization but you need to retain their environmentsusing the passwd -l command. You will also find many of the system accounts to have an invalid password assigned (a single * or ! in the password field in /etc/shadow). These accounts exist to allow programs to be run as the UID associated with that account; they are not direct login accounts. If you ever need to create such an account, ensure you disable its login access.

TIP

In addition to locking dormant accounts by disabling the passwords, you should also remove (or rename) all .rhosts, .netrc, and .forward files in their home directories to prevent remote access as those users via FTP or any of the r- commands (such as rlogin and rexec).

You should also change these users' shells to a dummy shell such as /dev/null, /bin/false, or /sbin/nologin. This way, even if someone is able to log in as one of these users, an immediate exit will be the result. You may not want to use nologin because it informs the user that the account is not availablea giveaway to hackers that the account does exist but is disabled.


USE PASSWORD AGING

No matter how hard a password is to guess, if it has been used for an extended period of time, someone is going to figure it out. It is not uncommon for users to brag with each other about how secure or how clever their passwords are: "I used all my three children's middle names. How's that for a tough password?" "You know the color that I really, really hate?" or "Hey, I used my wife's favorite Italian dish as my password. Try to guess that!"

Given enough talk, and some luck, a bad guy may just figure out what the password is. Therefore, it is a good idea to force the users to periodically change their passwords. Password aging may be implemented on a system-wide basis or on a per-user basis. Password-aging policy in Linux is controlled through the shadow password file and is configured automatically by SLES during installation.

BE A CRACKER JACK

Use a password-cracker yourself to audit for weak passwords. SUSE LINUX implements Pluggable Authentication Module (PAM) by default to provide flexible user authentication. One of the side benefits of PAM is its ability to help enforce strong passwords (through the pam_pwcheck module, for instance). (You can find more details about PAM in Chapter 5, "User Environment Management and Security.") There is always a possibility that another system administrator assigned a weak password without realizing it. To find out, you should periodically use a password-cracker, such as John the Ripper, to self-audit and see whether any weak passwords are reported.

CAUTION

When nonroot users change their passwords, PAM ensures a "good" password is chosen; otherwise, the password is not changed. However, for the root user, PAM gives the warning when a weak password is detected but allows it to be used.


TIP

A set of cron scripts called seccheck is included and installed by default as of SuSE 6.3. Seccheck performs daily, weekly, and monthly checks of your system's security and compares them to the last run. The results are emailed to the root account. Weak password checks are performed weekly using John the Ripper. For more information, refer to /usr/share/doc/packages/seccheck/README.


USE A STRONG PASSWORD-HASHING ALGORITHM

The previous recommendations of using passphrases and long passwords are fine if the password-hashing algorithm you use supports long strings. By default, SLES 9 (and many other Linux distributions) uses a DES-based algorithm, which supports passwords up to eight characters in length; any string longer than eight characters is truncated to eight characters in size. Fortunately, SUSE ships with the option of encrypting passwords with the stronger MD5 hash algorithm or with Blowfish. (For more information on the MD5 hash algorithm, consult RFC 1321; see http://www.schneier.com/blowfish.html for more information about the Blowfish encryption algorithm.) Although MD5 and Blowfish passwords do not eliminate the threat of password cracking, they do make cracking your passwords much more difficult.

NOTE

SLES uses DES as the password-hashing method by default. However, you can change it to either MD5 or Blowfish during install as discussed in the "Detailed Installation Steps" section in Chapter 1, "Installing SUSE LINUX Enterprise Server." Or you can change it any time after the server is up and running, as discussed next.


If you didn't change the password-hashing algorithm from DES to MD5 or Blowfish during install, you can easily change it at a later time. This is easily done using YaST because it will make changes to all the related configuration files for you (such as /etc/security/pam_unix2.conf and /etc/security/pam_pwcheck.conf). You can make the change either via the User and Group Administration module or the Local Security Configuration module as follows:

  • From the YaST Control Center, select Security and Users, Edit and Create Users to launch the User and Group Administration module. Click Expert Options, Password Encryption. From the displayed Set Password Encryption dialog box (see Figure 4.4), select the desired method and click OK. Click Finish for the change to take effect.

    Figure 4.4. Changing the password-hashing method.


  • From the YaST Control Center, select Security and Users, Security Settings to launch the Local Security Configuration module. If the Current Security Setting is one of Level 1 through Level 3, click Details. If the selection is Custom Settings, click Next. The first screen is Password Settings (see Figure 4.5). From the Password Encryption Method drop-down list, select the desired method. Make any other changes if desired. Click Next until the Miscellaneous Settings screen is displayed. Click Finish for the new change(s) to take effect. (From a terminal session, you can launch the Local Security Configuration module directly using yast security or yast2 security.)

    Figure 4.5. Changing the password-hashing method via the Local Security Configuration module.


WARNING

There appears to be a cosmetic bug with the User and Group Administration module when setting passwords. Regardless of your current password-hashing algorithm, when you try to use a password longer than eight characters, YaST always warns you that the password is too long and asks if it should be truncated. When you click Yes, it is truncated when using DES. However, with MD5 and Blowfish, the password is not truncated even though you are led to believe it will be after you click Yes; if you click No, you're returned to the screen to enter the password again.


CAUTION

Changing the password-hashing method used does not change the existing password hash values to the new one. For instance, switching from the default DES to MD5 leaves existing password hashes as DES. However, new passwords will be hashed using MD5. Therefore, if you want all user passwords to be hashed using the new algorithm, change the method and then expire all passwords. This way, the next time a user logs in, that user will be prompted to change his or her password, and it will be hashed using the new method.


You can determine what hashing algorithm was used for a given password hash by examining /etc/shadowanother reason why this file is accessible by root only because you don't want to give any hackers hints on what hashing algorithm you are using:

  • DES-hashed passwords are always 13 characters in length, where the first two characters are the salt.

  • MD5-hashed passwords can be up to 34 characters in length, including the salt. The salt for an MD5 hash begins with the prefix $1$, and the salt itself is a string that can be up to eight characters and is followed by a dollar sign to indicate the end of the salt (for example, $1$abcdefgh$).

  • Blowfish-hashed passwords can be up to 60 characters in length, including the salt. The salt for a Blowfish hash begins with the prefix $2a$, and the salt itself is just a two-character string followed by a dollar sign to indicate the end of the salt.

KEYS AND SALTS

On Linux (and Unix) systems, different hash algorithms are supported through the crypt library call. Crypt takes two parameters, a key and a salt, and returns the hashed value. A salt is simply a text string (whose length depends on the algorithm in question) that is combined with the key ("password") to generate the hash value. Hashing the same password with different salts results in different hashed values.

When passwd (or one of the many password-changing utilities) changes a password, a random salt is used. This way, even if two users have the same password, they will likely have two different salts, thus two different hash values. This is easily illustrated using the following Perl snippet:

[View full width]

Athena:/home/admin # perl -e 'print crypt("password", "s1"), " \n"' s1bASGcvcc/W. Athena:/home/admin # perl -e 'print crypt("password", "s2"), " \n"' s21GZTaOBHOFc

The algorithm used depends on the salt used. The preceding example shows the result of hashing the same text string (password) with two different salts (s1 and s2) using the DES algorithm: The two hashed values are radically different. Note that the salt itself is prefixed to the resulting hash, which indicates what hashing algorithm was used. This allows applications, such as passwd, to use the same salt and algorithm to verify a password at a later time.


Each of the DES, MD5, and Blowfish algorithms has its pros and cons, and you should give them some careful thought before picking one. For instance, the Linux (and Unix) implementation of the DES hashing method limits the password to only eight characters, but because all versions of Linux/Unix and most other Unix-like operating systems support it, it is a good choice for cross- platform compatibility. On the other hand, MD5 and Blowfish allow for much longer passwords (127 characters for MD5 and 72 characters for Blowfish), but the algorithms are computational-intensive. So if you have an underpowered server that needs to perform many user authentications per second (such as an LDAP authentication server), performance will suffer. There are also some networking protocols that do not play well with passwords longer than eight characters. For example, only the first eight characters are significant in NIS+ passwords because the underlying secure-RPC protocol uses DES.

Consider the following suggestions when choosing a password-hashing algorithm for your system:

  • When using DES, set the minimum password length to be at least six; use an eight-character password for root.

  • If all interconnected systems support MD5, use MD5 as the password-hashing algorithm and set the minimum password length to be at least six.

  • Consider using Blowfish for all system accounts that require a password. (However, this means you need to switch the password-hashing method from the current setting to Blowfish, change the password, and restore the setting. An alternative is to install the Blowfish-aware version of Perlthe version included with SLES 9 supports only DES and MD5so you can use a simple script to first generate the hashed value using Perl and then set the password using usermod -p hashed_value.)

TIP

You can find the RPM for a version of Perl that supports Blowfish at http://rpmfind.net/linux/RPM/contrib/libc6/i386/perl-Crypt-Blowfish-2.09-1.i386.html and at http://rpmfind.net/linux/RPM/suse/8.2/i386/suse/i586/perl-Crypt-Blowfish-2.09-188.i586.html. The Perl crypt home page is at http://cpan.org/modules/by-module/Crypt.


In most cases, MD5 provides the best balance between performance and security.

Auditing Default Accounts

As mentioned earlier, a number of system accounts exist to allow programs to be run as the UID associated with that account; they are not direct login accounts. FTP, named (for DNS), mail, and news are some examples of such system accounts. Make sure such accounts are prevented from a terminal login by setting their shell to /bin/false or similar.

If the services for these accounts are not in use, uninstall them and remove the accountsor at the very least, disable unused services (see Chapter 8 for more information). Periodically, you should check the contents of /etc/passwd and /etc/shadow to ensure that the removed system accounts didn't "spontaneously resurrect" themselves or new system accounts were not added without your knowledge, and nonlogin system accounts don't "suddenly" get assigned valid password hashes and shells.

The Root Account

The root account is the key to your entire server kingdom (and to your entire network if the server in question serves as the central authentication server). Nothing is more important than the password to the root account in the Linux/Unix world. For this reason, you will not want to make your root password known to anyone else but yourself. Well, this is often easier said than done.

As you may already have found out, many of the administrative tasks, such as resetting a user's forgotten password, changing system configuration, and so on, require you to be root. If you're the lone ranger who looks after the system(s) at your organization, keeping the root password safe is relatively easy: Follow the recommendations given earlier in this chapter about selecting strong passwords, change it often, never write it down, and so on. However, it is not uncommon in a company for system administration tasks to be shared by two or more people. In such cases, how do you safeguard the root password effectively? The more people who know it, the higher the likelihood it will be leaked to someone who shouldn't know about it!

TIP

If you are the sole system administrator at your organization, it might be a good idea to record the root password in a sealed envelope and keep it in a secure location where only trusted company officers (such as the accountant or CTO) have access to it; a bank safety deposit box is a good choice. The idea here is that although you would want to keep the root password secret from others, you need to provide a way for "continuity" should you be unavailable, due to illness or any other reasons.


There are a number of ways to address the multiple administrator requirements, and we discuss two of them here:

  • Setting up multiple root users Instead of providing the root password to the people who need access, you can set up multiple root accounts. Suppose, for example, both Tasha and Carol require administrative access as part of their job. One way to track their root activities is to set up two separate accounts, say tasha-root for Tasha and carol-root for Carol, each with a unique (strong) password and each with a UID of 0. Whenever Tasha needs root privileges, she would log in as tasha-root or su as tasha-root. Carol would do so as carol-root. This method has the advantage of having an audit trail in the forms of process accounting and system logging for each administrator and without having to share the root password. The disadvantage is that each duplicate UID 0 account is another potential vulnerability.

    Because adding another UID 0 account is also a common hacker practice, you should review /etc/passwd frequently to check for illegal UID 0 accounts. You can also use Bastille (see Chapter 13) to automatically detect unauthorized duplicate root accounts.

    CAUTION

    You should not name the root-equivalent accounts with "-root" as that makes it easy for the hackers to zero in on accounts to attack.


  • Using sudo The best way of granting multiple users root access is via the sudo (superuser do) utility. sudo allows you to grant certain users (or groups of users) the ability to run some (or all) commands as root while logging all commands and arguments used, regardless of whether the command was successful. All sudo commands are logged in the log file /var/log/messages, which can be very helpful in determining how user error may have contributed to a problem. All the sudo log entries have the word sudo in them, so you can easily get a thread of commands used by using the grep command to selectively filter the output accordingly. sudo operates on a per-command basis, and it is not a replacement for the shell.

NOTE

Further discussion about sudo can be found in Chapter 5.


Running as root all the time is not a very good idea. Because it grants you all-powerful, unlimited access to the server and its files, one little mistake may render the whole system useless. For example, before you execute rm -r * (or even just rm *), make very sure you are in the right directory! In general, think twice before you perform certain actions as root. Here are some tips regarding using the root account:

  • Become root only when absolusely necessary.

  • Gain root access only through su or sudo.

  • Restrict from which terminal console(s) root can log in. (See man securetty and refer to the "Authentication Using PAM" section in Chapter 5 for more information.)

  • Exercise extreme care when executing potentially destructive commands (such as rm) while being root.

  • Use absolute pathnames when invoking commands. This helps to eliminate executing a Trojan Horse program that may have been installed in one of the nonsystem directories that is pointed to by the PATH environment variable.

    TIP

    When setting up root's environment, do not put user-writable directories in root's PATH. This reduces the chance of running a Trojan Horse program placed (knowingly or not) by a user.


  • Whenever you need to remotely administer a system as root, use SSH (discussed in the "Securing Network Services" section in Chapter 13) and sudo.

User in Too Many Groups?

Linux and most other recent Unix systems support at least 32 groups per user. However, because the NFS protocol supports only 16 groups, most of them (SUSE included) have imposed a soft limit of 16 groups per user. There are very rarely circumstances that require more than 16 groups, but it is usually possible to use more if the system will not be exporting or using NFS-mounted filesystems; NFS has a hard-coded limit of 16 groups in its underlying RPC protocol. The first 16 groups are passed to the NFS server for permission checking, while the others are ignored. In other words, a user might appear to belong to a group, but if the 16-group limit is exceeded, the user might not have the access privileges of that group.



    SUSE LINUX Enterprise Server 9 Administrator's Handbook
    SUSE LINUX Enterprise Server 9 Administrators Handbook
    ISBN: 067232735X
    EAN: 2147483647
    Year: 2003
    Pages: 134

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net