42.1. Workstation Security

1. Preventing Changes to BIOS Settings — If an intruder has access to the BIOS, they can set it to boot from a diskette or CD-ROM. This makes it possible for them to enter rescue mode or single user mode, which in turn allows them to start arbitrary processes on the system or copy sensitive data.

2. Preventing System Booting — Some BIOSes allow password protection of the boot process. When activated, an attacker is forced to enter a password before the BIOS launches the boot loader.

Other architectures use different programs to perform low-level tasks roughly equivalent to those of the BIOS on x86 systems. For instance, Intel® Itanium™ computers use the Extensible Firmware Interface (EFI) shell.

For instructions on password protecting BIOS-like programs on other architectures, refer to the manufacturer's instructions.

1. Preventing Access to Single User Mode — If attackers can boot the system into single user mode, they are logged in automatically as root without being prompted for the root password.

2. Preventing Access to the GRUB Console — If the machine uses GRUB as its boot loader, an attacker can use the GRUB editor interface to change its configuration or to gather information using the cat command.

3. Preventing Access to Insecure Operating Systems — If it is a dual-boot system, an attacker can select an operating system at boot time (for example, DOS), which ignores access controls and file permissions.

You can configure GRUB to address the first two issues listed in Section 42.1.2.2, “Boot Loader Passwords” by adding a password directive to its configuration file. To do this, first choose a strong password, open a shell, log in as root, and then type the following command:

/sbin/grub-md5-crypt

When prompted, type the GRUB password and press Enter. This returns an MD5 hash of the password.

Next, edit the GRUB configuration file /boot/grub/grub.conf. Open the file and below the timeout line in the main section of the document, add the following line:

password --md5 <password-hash>

Replace <password-hash> with the value returned by /sbin/grub-md5-crypt^[16].

The next time the system boots, the GRUB menu prevents access to the editor or command interface without first pressing p followed by the GRUB password.

Unfortunately, this solution does not prevent an attacker from booting into an insecure operating system in a dual-boot environment. For this, a different part of the /boot/grub/grub.conf file must be edited.

Look for the title line of the operating system that you want to secure, and add a line with the lock directive immediately beneath it.

For a DOS system, the stanza should begin similar to the following:

title DOS lock

To create a different password for a particular kernel or operating system, add a lock line to the stanza, followed by a password line.

Each stanza protected with a unique password should begin with lines similar to the following example:

title DOS lock password --md5 <password-hash>

• Do Not Use Only Words or Numbers — Never use only numbers or words in a password.

  Some insecure examples include the following:

  • 8675309

  • juan

  • hackme

• Do Not Use Recognizable Words — Words such as proper names, dictionary words, or even terms from television shows or novels should be avoided, even if they are bookended with numbers.

  Some insecure examples include the following:

  • john1

  • DS-9

  • mentat123

• Do Not Use Words in Foreign Languages — Password cracking programs often check against word lists that encompass dictionaries of many languages. Relying on foreign languages for secure passwords is not secure.

  Some insecure examples include the following:

  • cheguevara

  • bienvenido1

  • 1dumbKopf

• Do Not Use Hacker Terminology — If you think you are elite because you use hacker terminology — also called l337 (LEET) speak — in your password, think again. Many word lists include LEET speak.

  Some insecure examples include the following:

  • H4X0R

  • 1337

• Do Not Use Personal Information — Avoid using any personal information in your passwords. If the attacker knows your identity, the task of deducing your password becomes easier. The following is a list of the types of information to avoid when creating a password:

  Some insecure examples include the following:

  • Your name

  • The names of pets

  • The names of family members

  • Any birth dates

  • Your phone number or zip code

• Do Not Invert Recognizable Words — Good password checkers always reverse common words, so inverting a bad password does not make it any more secure.

  Some insecure examples include the following:

  • R0X4H

  • nauj

  • 9-DS

• Do Not Write Down Your Password — Never store a password on paper. It is much safer to memorize it.

• Do Not Use the Same Password For All Machines — It is important to make separate passwords for each machine. This way if one system is compromised, all of your machines are not immediately at risk.

• Make the Password at Least Eight Characters Long — The longer the password, the better. If using MD5 passwords, it should be 15 characters or longer. With DES passwords, use the maximum length (eight characters).

• Mix Upper and Lower Case Letters — Red Hat Enterprise Linux is case sensitive, so mix cases to enhance the strength of the password.

• Mix Letters and Numbers — Adding numbers to passwords, especially when added to the middle (not just at the beginning or the end), can enhance password strength.

• Include Non-Alphanumeric Characters — Special characters such as &, $, and > can greatly improve the strength of a password (this is not possible if using DES passwords).

• Pick a Password You Can Remember — The best password in the world does little good if you cannot remember it; use acronyms or other mnemonic devices to aid in memorizing passwords.

There are many methods that people use to create secure passwords. One of the more popular methods involves acronyms. For example:

While creating secure passwords is imperative, managing them properly is also important, especially for system administrators within larger organizations. The following section details good practices for creating and managing user passwords within an organization.

To protect the network from intrusion it is a good idea for system administrators to verify that the passwords used within an organization are strong ones. When users are asked to create or change passwords, they can use the command line application passwd, which is Pluggable Authentication Manager (PAM) aware and therefore checks to see if the password is too short or otherwise easy to crack. This check is performed using the pam_cracklib.so PAM module. Since PAM is customizable, it is possible to add more password integrity checkers, such as pam_passwdqc (available from www.openwall.com/passwdqc/) or to write a new module. For a list of available PAM modules, refer to www.kernel.org/pub/linux/libs/pam/modules.html. For more information about PAM, refer to Section 42.4, “Pluggable Authentication Modules (PAM)”.

The password check that is performed at the time of their creation does not discover bad passwords as effectively as running a password cracking program against the passwords.

Many password cracking programs are available that run under Red Hat Enterprise Linux, although none ship with the operating system. Below is a brief list of some of the more popular password cracking programs:

Password aging is another technique used by system administrators to defend against bad passwords within an organization. Password aging means that after a specified period (usually 90 days), the user is prompted to create a new password. The theory behind this is that if a user is forced to change his password periodically, a cracked password is only useful to an intruder for a limited amount of time. The downside to password aging, however, is that users are more likely to write their passwords down.

There are two primary programs used to specify password aging under Red Hat Enterprise Linux: the chage command or the graphical User Manager (system-config-users) application.

The -M option of the chage command specifies the maximum number of days the password is valid. For example, to set a user's password to expire in 90 days, use the following command:

chage -M 90 <username>

In the above command, replace <username> with the name of the user. To disable password expiration, it is traditional to use a value of 99999 after the -M option (this equates to a little over 273 years).

You can also use the chage command in interactive mode to modify multiple password aging and account details. Use the following command to enter interactive mode:

chage <username>

The following is a sample interactive session using this command:

[root@interch-dev1 ~]# chage davido
Changing the aging information for davido
Enter the new value, or press ENTER for the default

        Minimum Password Age [0]: 10
        Maximum Password Age [99999]: 90
        Last Password Change (YYYY-MM-DD) [2006-08-18]:
        Password Expiration Warning [7]:
        Password Inactive [-1]:
        Account Expiration Date (YYYY-MM-DD) [1969-12-31]:
[root@interch-dev1 ~]#

Refer to the man page for chage for more information on the available options.

You can also use the graphical User Manager application to create password aging policies, as follows. Note: you need Administrator privileges to perform this procedure.

For more information about user and group configuration (including instructions on forcing first time passwords), refer to Chapter 32, Users and Groups.

• Machine Misconfiguration — Users with root access can misconfigure their machines and require assistance to resolve issues. Even worse, they might open up security holes without knowing it.

• Running Insecure Services — Users with root access might run insecure servers on their machine, such as FTP or Telnet, potentially putting usernames and passwords at risk. These services transmit this information over the network in plain text.

• Running Email Attachments As Root — Although rare, email viruses that affect Linux do exist. The only time they are a threat, however, is when they are run by the root user.

Method	Description	Effects	Does Not Affect
Changing the root shell.	Edit the /etc/passwd file and change the shell from /bin/bash to /sbin/nologin.	Prevents access to the root shell and logs any such attempts. The following programs are prevented from accessing the root account: · login · gdm · kdm · xdm · su · ssh · scp · sftp	Programs that do not require a shell, such as FTP clients, mail clients, and many setuid programs. The following programs are not prevented from accessing the root account: ·