此内容没有您所选择的语言版本。

Chapter 2. Securing Your Network

2.1. Workstation Security

Securing a Linux environment begins with the workstation. Whether locking down a personal machine or securing an enterprise system, sound security policy begins with the individual computer. A computer network is only as secure as its weakest node.

2.1.1. Evaluating Workstation Security

When evaluating the security of a Red Hat Enterprise Linux workstation, consider the following:

BIOS and Boot Loader Security — Can an unauthorized user physically access the machine and boot into single user or rescue mode without a password?
Password Security — How secure are the user account passwords on the machine?
Administrative Controls — Who has an account on the system and how much administrative control do they have?
Available Network Services — What services are listening for requests from the network and should they be running at all?
Personal Firewalls — What type of firewall, if any, is necessary?
Security Enhanced Communication Tools — Which tools should be used to communicate between workstations and which should be avoided?

2.1.2. BIOS and Boot Loader Security

Password protection for the BIOS (or BIOS equivalent) and the boot loader can prevent unauthorized users who have physical access to systems from booting using removable media or obtaining root privileges through single user mode. The security measures you should take to protect against such attacks depends both on the sensitivity of the information on the workstation and the location of the machine.

For example, if a machine is used in a trade show and contains no sensitive information, then it may not be critical to prevent such attacks. However, if an employee's laptop with private, unencrypted SSH keys for the corporate network is left unattended at that same trade show, it could lead to a major security breach with ramifications for the entire company.

If the workstation is located in a place where only authorized or trusted people have access, however, then securing the BIOS or the boot loader may not be necessary.

2.1.2.1. BIOS Passwords

The two primary reasons for password protecting the BIOS of a computer are^[3]:

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

Because the methods for setting a BIOS password vary between computer manufacturers, consult the computer's manual for specific instructions.

If you forget the BIOS password, it can either be reset with jumpers on the motherboard or by disconnecting the CMOS battery. For this reason, it is good practice to lock the computer case if possible. However, consult the manual for the computer or motherboard before attempting to disconnect the CMOS battery.

2.1.2.1.1. Securing Non-x86 Platforms

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, see the manufacturer's instructions.

2.1.2.2. Boot Loader Passwords

The primary reasons for password protecting a Linux boot loader are as follows:

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.
Warning
Protecting access to single user mode with a password by editing the SINGLE parameter in the /etc/sysconfig/init file is not recommended. An attacker can bypass the password by specifying a custom initial command (using the init= parameter) on the kernel command line in GRUB. It is recommended to password-protect the GRUB boot loader as specified in Section 2.1.2.2.1, “Password Protecting GRUB”.
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.
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.

Red Hat Enterprise Linux 6 includes the GRUB boot loader on the x86 platform. For a detailed look at GRUB, see the Red Hat Enterprise Linux Installation Guide.

2.1.2.2.1. Password Protecting GRUB

You can configure GRUB to address the first two issues listed in Section 2.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^[4].

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

Warning

A password line must be present in the main section of the /boot/grub/grub.conf file for this method to work properly. Otherwise, an attacker can access the GRUB editor interface and remove the lock line.

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>

2.1.2.2.2. Disabling Interactive Startup

Pressing the I key at the beginning of the boot sequence allows you to start up your system interactively. During an interactive startup, the system prompts you to start up each service one by one. However, this may allow an attacker who gains physical access to your system to disable the security-related services and gain access to the system.

To prevent users from starting up the system interactively, as root, disable the PROMPT parameter in the /etc/sysconfig/init file:

PROMPT=no

2.1.3. Password Security

Passwords are the primary method that Red Hat Enterprise Linux uses to verify a user's identity. This is why password security is so important for protection of the user, the workstation, and the network.

For security purposes, the installation program configures the system to use Secure Hash Algorithm 512 (SHA512) and shadow passwords. It is highly recommended that you do not alter these settings.

If shadow passwords are deselected during installation, all passwords are stored as a one-way hash in the world-readable /etc/passwd file, which makes the system vulnerable to offline password cracking attacks. If an intruder can gain access to the machine as a regular user, he can copy the /etc/passwd file to his own machine and run any number of password cracking programs against it. If there is an insecure password in the file, it is only a matter of time before the password attacker discovers it.

Shadow passwords eliminate this type of attack by storing the password hashes in the file /etc/shadow, which is readable only by the root user.

This forces a potential attacker to attempt password cracking remotely by logging into a network service on the machine, such as SSH or FTP. This sort of brute-force attack is much slower and leaves an obvious trail as hundreds of failed login attempts are written to system files. Of course, if the attacker starts an attack in the middle of the night on a system with weak passwords, the cracker may have gained access before dawn and edited the log files to cover his tracks.

In addition to format and storage considerations is the issue of content. The single most important thing a user can do to protect his account against a password cracking attack is create a strong password.

2.1.3.1. Creating Strong Passwords

When creating a secure password, the user must remember that long passwords are stronger than short and complex ones. It is not a good idea to create a password of just eight characters, even if it contains digits, special characters and uppercase letters. Password cracking tools, such as John The Ripper, are optimized for breaking such passwords, which are also hard to remember by a person.

In information theory, entropy is the level of uncertainty associated with a random variable and is presented in bits. The higher the entropy value, the more secure the password is. According to NIST SP 800-63-1, passwords that are not present in a dictionary comprised of 50000 commonly selected passwords should have at least 10 bits of entropy. As such, a password that consists of four random words contains around 40 bits of entropy. A long password consisting of multiple words for added security is also called a passphrase, for example:

randomword1 randomword2 randomword3 randomword4

If the system enforces the use of uppercase letters, digits, or special characters, the passphrase that follows the above recommendation can be modified in a simple way, for example by changing the first character to uppercase and appending "1!". Note that such a modification does not increase the security of the passphrase significantly.

While there are different approaches to creating a secure password, always avoid the following bad practices:

Using a single dictionary word, a word in a foreign language, an inverted word, or only numbers.
Using less than 10 characters for a password or passphrase.
Using a sequence of keys from the keyboard layout.
Writing down your passwords.
Using personal information in a password, such as birth dates, anniversaries, family member names, or pet names.
Using the same passphrase or password on multiple machines.

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.

2.1.4. Creating User Passwords Within an Organization

If an organization has a large number of users, the system administrators have two basic options available to force the use of good passwords. They can create passwords for the user, or they can let users create their own passwords, while verifying the passwords are of acceptable quality.

Creating the passwords for the users ensures that the passwords are good, but it becomes a daunting task as the organization grows. It also increases the risk of users writing their passwords down.

For these reasons, most system administrators prefer to have the users create their own passwords, but actively verify that the passwords are good and, in some cases, force users to change their passwords periodically through password aging.

2.1.4.1. Forcing Strong Passwords

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 Modules (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. In Red Hat Enterprise Linux, the pam_cracklib PAM module can be used to check a password's strength against a set of rules. It can be stacked alongside other PAM modules in the password component of the/etc/pam.d/passwd file to configure a custom set of rules for user login. The pam_cracklib's routine consists of two parts: it checks whether the password provided is found in a dictionary, and, if that is not the case, it continues with a number of additional checks. For a complete list of these checks, see the pam_cracklib(8) manual page.

Example 2.1. Configuring password strength-checking with pam_cracklib

To require a password with a minimum length of 8 characters, including all four classes of characters, add the following line to the password section of the /etc/pam.d/passwd file:

password   required     pam_cracklib.so retry=3 minlen=8 minclass=4

To set a password strength-check for consecutive or repetitive characters, add the following line to the password section of the /etc/pam.d/passwd file:

password   required     pam_cracklib.so retry=3 maxsequence=3 maxrepeat=3

In this example, the password entered cannot contain more than 3 consecutive characters, such as "abcd" or "1234". Additionally, the number of identical consecutive characters is limited to 3.

Note

As these checks are not performed for the root user, he can set any password for a regular user, despite the warning messages.

Since PAM is customizable, it is possible to add more password integrity checkers, such as pam_passwdqc (available from http://www.openwall.com/passwdqc/) or to write a new module. For a list of available PAM modules, see http://uw714doc.sco.com/en/SEC_pam/pam-6.html. For more information about PAM, see the Managing Single Sign-On and Smart Cards guide.

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:

John The Ripper — A fast and flexible password cracking program. It allows the use of multiple word lists and is capable of brute-force password cracking. It is available online at http://www.openwall.com/john/.
Crack — Perhaps the most well known password cracking software, Crack is also very fast, though not as easy to use as John The Ripper.
Slurpie — Slurpie is similar to John The Ripper and Crack, but it is designed to run on multiple computers simultaneously, creating a distributed password cracking attack. It can be found along with a number of other distributed attack security evaluation tools online at http://www.ussrback.com/distributed.htm.

Warning

Always get authorization in writing before attempting to crack passwords within an organization.

2.1.4.2. Passphrases

Passphrases and passwords are the cornerstone to security in most of today's systems. Unfortunately, techniques such as biometrics and two-factor authentication have not yet become mainstream in many systems. If passwords are going to be used to secure a system, then the use of passphrases should be considered. Passphrases are longer than passwords and provide better protection than a password even when implemented with non-standard characters such as numbers and symbols.

2.1.4.3. Password Aging

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.

Important

Shadow passwords must be enabled to use the chage command. For more information, see the Red Hat Enterprise Linux 6 Deployment Guide.

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).

For more information on the options available with the chage command, see the table below.

Table 2.1. chage command line options
Option	Description
`-d` days	Specifies the number of days since January 1, 1970 the password was changed.
`-E` date	Specifies the date on which the account is locked, in the format YYYY-MM-DD. Instead of the date, the number of days since January 1, 1970 can also be used.
`-I` days	Specifies the number of inactive days after the password expiration before locking the account. If the value is `0`, the account is not locked after the password expires.
`-l`	Lists current account aging settings.
`-m` days	Specify the minimum number of days after which the user must change passwords. If the value is `0`, the password does not expire.
`-M` days	Specify the maximum number of days for which the password is valid. When the number of days specified by this option plus the number of days specified with the `-d` option is less than the current day, the user must change passwords before using the account.
`-W` days	Specifies the number of days before the password expiration date to warn the user.

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:

~]# chage juan
Changing the aging information for juan
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]:

You can configure a password to expire the first time a user logs in. This forces users to change passwords immediately.

Set up an initial password. There are two common approaches to this step: you can either assign a default password, or you can use a null password.
To assign a default password, type the following at a shell prompt as root:
```
passwd username
```
To assign a null password instead, use the following command:
```
passwd -d username
```
Warning
Using a null password, while convenient, is a highly insecure practice, as any third party can log in first and access the system using the insecure user name. Always make sure that the user is ready to log in before unlocking an account with a null password.
Force immediate password expiration by running the following command as root:
```
chage -d 0 username
```
This command sets the value for the date the password was last changed to the epoch (January 1, 1970). This value forces immediate password expiration no matter what password aging policy, if any, is in place.

Upon the initial log in, the user is now prompted for a new password.

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.

Click the System menu on the Panel, point to Administration and then click Users and Groups to display the User Manager. Alternatively, type the command system-config-users at a shell prompt.
Click the Users tab, and select the required user in the list of users.
Click Properties on the toolbar to display the User Properties dialog box (or choose Properties on the File menu).
Click the Password Info tab, and select the check box for Enable password expiration.
Enter the required value in the Days before change required field, and click OK.

Figure 2.1. Specifying password aging options

screenshot needs to be updated

2.1.5. Locking Inactive Accounts

The pam_lastlog PAM module is used to lock out users who have not logged in recently enough, or to display information about the last login attempt of a user. The module does not perform a check on the root account, so it is never locked out.

The lastlog command displays the last login of the user, аs opposed to the last command, which displays all current and previous login sessions. The commands read respectively from the /var/log/lastlog and /var/log/wtmp files where the data is stored in binary format.

To display the number of failed login attempts prior to the last successful login of a user, add, as root, the following line to the session section in the /etc/pam.d/login file:
```
session     optional      pam_lastlog.so silent noupdate showfailed
```

Account locking due to inactivity can be configured to work for the console, GUI, or both:

To lock out an account after 10 days of inactivity, add, as root, the following line to the auth section of the /etc/pam.d/login file:
```
auth  required  pam_lastlog.so inactive=10
```
To lock out an account for the GNOME desktop environment, add, as root, the following line to the auth section of the /etc/pam.d/gdm file:
```
auth  required  pam_lastlog.so inactive=10
```

Note

Note that for other desktop environments, the respective files of those environments should be edited.

2.1.6. Customizing Access Control

The pam_access PAM module allows an administrator to customize access control based on login names, host or domain names, or IP addresses. By default, the module reads the access rules from the /etc/security/access.conf file if no other is specified. For a complete description of the format of these rules, see the access.conf(5) manual page. By default, in Red Hat Enterprise Linux, pam_access is included in the /etc/pam.d/crond and /etc/pam.d/atd files.

To deny the user john from accessing system from the console and the graphic desktop environment, follow these steps:

Include the following line in the account section of both /etc/pam.d/login and /etc/pam.d/gdm-* files:
```
account     required     pam_access.so
```
Specify the following rule in the /etc/security/access.conf file:
```
- : john : ALL
```
This rule prohibits all logins from user john from any location.

To grant access to all users attempting to log in using SSH except the user john from the 1.2.3.4 IP address, follow these steps:

Include the following line in the account section of /etc/pam.d/sshd:
```
account     required     pam_access.so
```
Specify the following rule in the /etc/security/access.conf file:
```
+ : ALL EXCEPT john : 1.2.3.4
```

In order to limit access from other services, the pam_access module should be required in the respective file in the /etc/pam.d directory.

It is possible to call the pam_access module for all services that call the system wide PAM configuration files (*-auth files in the /etc/pam.d directory) using the following command:

authconfig --enablepamaccess --update

Alternatively, you can enable the pam_access module using the Authentication Configuration utility. To start this utility, select System

Administration

Authentication from the top menu. From the Advanced Options tab, check the "enable local access control option". This will add the pam_access module to the systemwide PAM configuration.

2.1.7. Time-based Restriction of Access

The pam_time PAM module is used to restrict access during a certain time of the day. It can also be configured to control access based on specific days of a week, user name, usage of a system service, and more. By default, the module reads the access rules from the /etc/security/time.conf file. For a complete description of the format of these rules, see the time.conf(5) manual page.

To restrict all users except the root user from logging in from 05:30 PM to 08:00 AM on Monday till Friday and Saturday and Sunday, follow these steps:

Include the following line in the account section of the /etc/pam.d/login file:
```
account     required     pam_time.so
```
Specify the following rule in the /etc/security/time.conf file:
```
login ; tty* ; ALL ; !root ; !Wk1730-0800
```

To allow user john to use the SSH service during working hours and working days only (starting with Monday), follow these steps:

Add the following line to the /etc/pam.d/sshd file:
```
account     required     pam_time.so
```
Specify the following rule in the /etc/security/time.conf file:
```
sshd ; tty* ; john ; Wk0800-1730
```

Note

For these configurations to be applied to the desktop environment, the pam_time module should be included in the corresponding files in the /etc/pam.d directory.

2.1.8. Applying Account Limits

The pam_limits PAM module is used to:

apply limits to user login sessions, such as maximum simultaneous login sessions per user,
specify limits to be set by the ulimit utility,
and specify priority to be set by the nice utility.

By default, the rules are read from the/etc/security/limits.conf file. For a complete description of the format of these rules, see the limits.conf(5) manual page. Additionally, you can create individual configuration files in the /etc/security/limits.d directory specifically for certain applications or services. By default, the pam_limits module is included in a number of files in the/etc/pam.d/ directory. A default limit of user processes is defined in the /etc/security/limits.d/90-nproc.conf file to prevent malicious denial of service attacks, such as fork bombs. To change the default limit of user processes to 50, change the value in the /etc/security/limits.d/90-nproc.conf, following the format in the file:

* soft nproc 50

Example 2.2. Specifying a maximum number of logins per user

To set a maximum number of simultaneous logins for each user in a group called office, specify the following rule in the /etc/security/limits.conf file:
```
@office - maxlogins 4
```
The following line should be present by default in /etc/pam.d/system-auth. If not, add it manually.
```
session  required  pam_limits.so
```

2.1.9. Administrative Controls

When administering a home machine, the user must perform some tasks as the root user or by acquiring effective root privileges through a setuid program, such as sudo or su. A setuid program is one that operates with the user ID (UID) of the program's owner rather than the user operating the program. Such programs are denoted by an s in the owner section of a long format listing, as in the following example:

~]$ ls -l /bin/su
-rwsr-xr-x. 1 root root 34904 Mar 10  2011 /bin/su

Note

The s may be upper case or lower case. If it appears as upper case, it means that the underlying permission bit has not been set.

For the system administrators of an organization, however, choices must be made as to how much administrative access users within the organization should have to their machine. Through a PAM module called pam_console.so, some activities normally reserved only for the root user, such as rebooting and mounting removable media are allowed for the first user that logs in at the physical console (see Managing Single Sign-On and Smart Cards for more information about the pam_console.so module.) However, other important system administration tasks, such as altering network settings, configuring a new mouse, or mounting network devices, are not possible without administrative privileges. As a result, system administrators must decide how much access the users on their network should receive.

2.1.9.1. Allowing Root Access

If the users within an organization are trusted and computer-literate, then allowing them root access may not be an issue. Allowing root access by users means that minor activities, like adding devices or configuring network interfaces, can be handled by the individual users, leaving system administrators free to deal with network security and other important issues.

On the other hand, giving root access to individual users can lead to the following issues:

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 user names 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.
Keeping the audit trail intact — Because the root account is often shared by multiple users, so that multiple system administrators can maintain the system, it is impossible to figure out which of those users was root at a given time. When using separate logins, the account a user logs in with, as well as a unique number for session tracking purposes, is put into the task structure, which is inherited by every process that the user starts. When using concurrent logins, the unique number can be used to trace actions to specific logins. When an action generates an audit event, it is recorded with the login account and the session associated with that unique number. Use the aulast command to view these logins and sessions. The --proof option of the aulast command can be used suggest a specific ausearch query to isolate auditable events generated by a particular session.

2.1.9.2. Disallowing Root Access

If an administrator is uncomfortable allowing users to log in as root for these or other reasons, the root password should be kept secret, and access to runlevel one or single user mode should be disallowed through boot loader password protection (see Section 2.1.2.2, “Boot Loader Passwords” for more information on this topic.)

The following are four different ways that an administrator can further ensure that root logins are disallowed:

Changing the root shell

To prevent users from logging in directly as root, the system administrator can set the root account's shell to /sbin/nologin in the /etc/passwd file.

Table 2.2. Disabling the Root Shell
Effects	Does Not Affect
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: `sudo` FTP clients Email clients

Disabling root access through any console device (tty)

To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This file lists all devices the root user is allowed to log into. If the file does not exist at all, the root user can log in through any communication device on the system, whether through the console or a raw network interface. This is dangerous, because a user can log in to their machine as root through Telnet, which transmits the password in plain text over the network.

By default, Red Hat Enterprise Linux's /etc/securetty file only allows the root user to log in at the console physically attached to the machine. To prevent the root user from logging in, remove the contents of this file by typing the following command at a shell prompt as root:

echo > /etc/securetty

To enable securetty support in the KDM, GDM, and XDM login managers, add the following line:

auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so

to the files listed below:

/etc/pam.d/gdm
/etc/pam.d/gdm-autologin
/etc/pam.d/gdm-fingerprint
/etc/pam.d/gdm-password
/etc/pam.d/gdm-smartcard
/etc/pam.d/kdm
/etc/pam.d/kdm-np
/etc/pam.d/xdm

Warning

A blank /etc/securetty file does not prevent the root user from logging in remotely using the OpenSSH suite of tools because the console is not opened until after authentication.

Table 2.3. Disabling Root Logins
Effects	Does Not Affect
Prevents access to the root account using the console or the network. The following programs are prevented from accessing the root account: `login` `gdm` `kdm` `xdm` Other network services that open a tty	Programs that do not log in as root, but perform administrative tasks through setuid or other mechanisms. The following programs are not prevented from accessing the root account: `su` `sudo` `ssh` `scp` `sftp`

Disabling root SSH logins

To prevent root logins using the SSH protocol, edit the SSH daemon's configuration file, /etc/ssh/sshd_config, and change the line that reads:

#PermitRootLogin yes

to read as follows:

PermitRootLogin no

Table 2.4. Disabling Root SSH Logins
Effects	Does Not Affect
Prevents root access using the OpenSSH suite of tools. The following programs are prevented from accessing the root account: `ssh` `scp` `sftp`	Programs that are not part of the OpenSSH suite of tools.

Using PAM to limit root access to services

PAM, through the /lib/security/pam_listfile.so module, allows great flexibility in denying specific accounts. The administrator can use this module to reference a list of users who are not allowed to log in. To limit root access to a system service, edit the file for the target service in the /etc/pam.d/ directory and make sure the pam_listfile.so module is required for authentication.

The following is an example of how the module is used for the vsftpd FTP server in the /etc/pam.d/vsftpd PAM configuration file (the \ character at the end of the first line is not necessary if the directive is on a single line):

auth   required   /lib/security/pam_listfile.so   item=user \
 sense=deny file=/etc/vsftpd.ftpusers onerr=succeed

This instructs PAM to consult the /etc/vsftpd.ftpusers file and deny access to the service for any listed user. The administrator can change the name of this file, and can keep separate lists for each service or use one central list to deny access to multiple services.

If the administrator wants to deny access to multiple services, a similar line can be added to the PAM configuration files, such as /etc/pam.d/pop and /etc/pam.d/imap for mail clients, or /etc/pam.d/ssh for SSH clients.

For more information about PAM, see the chapter titled Using Pluggable Authentication Modules (PAM) in the Red Hat Enterprise Linux Managing Single Sign-On and Smart Cards guide.

Table 2.5. Disabling Root Using PAM
Effects	Does Not Affect
Prevents root access to network services that are PAM aware. The following services are prevented from accessing the root account: `login` `gdm` `kdm` `xdm` `ssh` `scp` `sftp` FTP clients Email clients Any PAM aware services	Programs and services that are not PAM aware.

2.1.9.3. Enabling Automatic Logouts

When the user is logged in as root, an unattended login session may pose a significant security risk. To reduce this risk, you can configure the system to automatically log out idle users after a fixed period of time:

Make sure the screen package is installed. You can do so by running the following command as root:
```
~]# yum install screen
```
For more information on how to install packages in Red Hat Enterprise Linux, see the Installing Packages section in the Red Hat Enterprise Linux 6 Deployment Guide.
As root, add the following line at the beginning of the /etc/profile file to make sure the processing of this file cannot be interrupted:
```
trap "" 1 2 3 15
```
Add the following lines at the end of the /etc/profile file to start a screen session each time a user logs in to a virtual console or remotely:
```
SCREENEXEC="screen"
if [ -w $(tty) ]; then
  trap "exec $SCREENEXEC" 1 2 3 15
  echo -n 'Starting session in 10 seconds'
  sleep 10
  exec $SCREENEXEC
fi
```
Note that each time a new session starts, a message will be displayed and the user will have to wait ten seconds. To adjust the time to wait before starting a session, change the value after the sleep command.
Add the following lines to the /etc/screenrc configuration file to close the screen session after a given period of inactivity:
```
idle 120 quit 
autodetach off
```
This will set the time limit to 120 seconds. To adjust this limit, change the value after the idle directive.
Alternatively, you can configure the system to only lock the session by using the following lines instead:
```
idle 120 lockscreen
autodetach off
```
This way, a password will be required to unlock the session.

The changes take effect the next time a user logs in to the system.

2.1.9.4. Limiting Root Access

Rather than completely denying access to the root user, the administrator may want to allow access only by setuid programs, such as su or sudo. For more information on su and sudo, see the Red Hat Enterprise Linux 6 Deployment Guide and the su(1) and sudo(8) man pages.

2.1.9.5. Account Locking

In Red Hat Enterprise Linux 6, the pam_faillock PAM module allows system administrators to lock out user accounts after a specified number of failed attempts. Limiting user login attempts serves mainly as a security measure that aims to prevent possible brute force attacks targeted to obtain a user's account password.

With the pam_faillock module, failed login attempts are stored in a separate file for each user in the /var/run/faillock directory.

Note

The order of lines in the failed attempt log files is important. Any change in this order can lock all user accounts, including the root user account when the even_deny_root option is used.

Follow these steps to configure account locking:

To lock out any non-root user after three unsuccessful attempts and unlock that user after 10 minutes, add the following lines to the auth section of the /etc/pam.d/system-auth and /etc/pam.d/password-auth files:

auth        required       pam_faillock.so preauth silent audit deny=3 unlock_time=600
auth        sufficient     pam_unix.so nullok try_first_pass
auth        [default=die]  pam_faillock.so authfail audit deny=3 unlock_time=600

Add the following line to the account section of both files specified in the previous step:
```
account     required      pam_faillock.so
```

To apply account locking for the root user as well, add the even_deny_root option to the pam_faillock entries in the /etc/pam.d/system-auth and /etc/pam.d/password-auth files:

auth        required      pam_faillock.so preauth silent audit deny=3 even_deny_root unlock_time=600
auth        sufficient    pam_unix.so nullok try_first_pass
auth        [default=die] pam_faillock.so authfail audit deny=3 even_deny_root unlock_time=600

account     required      pam_faillock.so

When user john attempts to log in for the fourth time after failing to log in three times previously, his account is locked upon the fourth attempt:

[user@localhost ~]$ su - john
Account locked due to 3 failed logins
su: incorrect password

To prevent the system from locking users out even after multiple failed logins, add the following line just above the line where pam_faillock is called for the first time in both /etc/pam.d/system-auth and /etc/pam.d/password-auth. Also replace user1, user2, user3 with the actual user names.

auth [success=1 default=ignore] pam_succeed_if.so user in user1:user2:user3

To view the number of failed attempts per user, run, as root, the following command:

[root@localhost ~]# faillock 
john:
When                Type  Source                                           Valid
2013-03-05 11:44:14 TTY   pts/0                                                V

To unlock a user's account, run, as root, the following command:

faillock --user <username> --reset

When modifying authentication configuration using the authconfig utility, the system-auth and password-auth files are overwritten with the settings from the authconfig utility. This can be avoided by creating symbolic links in place of the configuration files, which authconfig recognizes and does not overwrite. In order to use custom settings in the configuration files and authconfig simultaneously, configure account locking using the following steps:

Rename the configuration files:

~]# mv /etc/pam.d/system-auth /etc/pam.d/system-auth-local
~]# mv /etc/pam.d/password-auth /etc/pam.d/password-auth-local

Create the following symbolic links:

~]# ln -s /etc/pam.d/system-auth-local /etc/pam.d/system-auth
~]# ln -s /etc/pam.d/password-auth-local /etc/pam.d/password-auth

The /etc/pam.d/system-auth-local file should contain the following lines:

auth        required       pam_faillock.so preauth silent audit deny=3 unlock_time=600
auth        include        system-auth-ac
auth        [default=die]  pam_faillock.so authfail silent audit deny=3 unlock_time=600

account     required       pam_faillock.so
account     include        system-auth-ac

password    include        system-auth-ac

session     include        system-auth-ac

The /etc/pam.d/password-auth-local file should contain the following lines:

auth        required       pam_faillock.so preauth silent audit deny=3 unlock_time=600
auth        include        password-auth-ac
auth        [default=die]  pam_faillock.so authfail silent audit deny=3 unlock_time=600

account     required       pam_faillock.so
account     include        password-auth-ac

password    include        system-auth-ac

session     include        system-auth-ac

For more information on various pam_faillock configuration options, see the pam_faillock(8) man page.

2.1.10. Session Locking

Users may need to leave their workstation unattended for a number of reasons during everyday operation. This could present an opportunity for an attacker to physically access the machine, especially in environments with insufficient physical security measures (see Section 1.1.3.1, “Physical Controls”). Laptops are especially exposed since their mobility interferes with physical security. You can alleviate these risks by using session locking features which prevent access to the system until a correct password is entered.

Note

The main advantage of locking the screen instead of logging out is that a lock allows the user's processes (such as file transfers) to continue running. Logging out would stop these processes.

2.1.10.1. Locking GNOME Using gnome-screensaver-command

The default desktop environment for Red Hat Enterprise Linux 6, GNOME, includes a feature which allows users to lock their screen at any time. There are several ways to activate the lock:

Press the key combination specified in System Preferences Keyboard Shortcuts Desktop Lock screen. The default combination is Ctrl+Alt+L.
Select System Lock screen on the panel.
Execute the following command from a command line interface:
```
gnome-screensaver-command -l
```

All of the techniques described have the same result: the screen saver is activated and the screen is locked. Users can then press any key to deactivate the screen saver, enter their password and continue working.

Keep in mind that this function requires the gnome-screensaver process to be running. You can check whether this is the case by using any command which provides information about processes. For example, execute the following command from the terminal:

pidof gnome-screensaver

If the gnome-screensaver process is currently running, a number denoting its identification number (PID) will be displayed on the screen after executing the command. If the process is not currently running, the command will provide no output at all.

Refer to the gnome-screensaver-command(1) man page for additional information.

Important

The means of locking the screen described above rely on manual activation. Administrators should therefore advise their users to lock their computers every time they leave them unattended, even if only for a short period of time.

2.1.10.1.1. Automatic Lock on Screen Saver Activation

As the name gnome-screensaver-command suggests, the locking functionality is tied to GNOME's screen saver. It is possible to tie the lock to the screen saver's activation, locking the workstation every time it is left unattended for a set period of time. This function is activated by default with a five minute timeout.

To change the automatic locking settings, select System

Preferences

Screensaver on the main panel. This opens a window which allows setting the timeout period (the Regard the computer as idle after slider) and activating or deactivating the automatic lock (the Lock screen when screensaver is active check box).

Figure 2.2. Changing the screen saver preferences

Note

Disabling the Activate screensaver when computer is idle option in the Screensaver Preferences dialog prevents the screen saver from starting automatically. Automatic locking is therefore disabled as well, but it is still possible to lock the workstation manually using the techniques described in Section 2.1.10.1, “Locking GNOME Using gnome-screensaver-command”.

2.1.10.1.2. Remote Session Locking

You can also lock a GNOME session remotely using ssh as long as the target workstation accepts connections over this protocol. To remotely lock the screen on a machine you have access to, execute the following command:

ssh -X <username>@<server> "export DISPLAY=:0; gnome-screensaver-command -l"

Replace <username> with your user name and <server> with the IP address of the workstation you want to lock.

Refer to Section 3.2.2, “Secure Shell” for more information regarding ssh.

2.1.10.2. Locking Virtual Consoles Using vlock

Users may also need to lock a virtual console. This can be done using a utility called vlock. To install this utility, execute the following command as root:

~]# yum install vlock

After installation, any console session can be locked using the vlock command without any additional parameters. This locks the currently active virtual console session while still allowing access to the others. To prevent access to all virtual consoles on the workstation, execute the following:

vlock -a

In this case, vlock locks the currently active console and the -a option prevents switching to other virtual consoles.

Refer to the vlock(1) man page for additional information.

Important

There are several known issues relevant to the version of vlock currently available for Red Hat Enterprise Linux 6:

The program does not currently allow unlocking consoles using the root password. Additional information can be found in BZ#895066.
Locking a console does not clear the screen and scrollback buffer, allowing anyone with physical access to the workstation to view previously issued commands and any output displayed in the console. Refer to BZ#807369 for more information.

2.1.11. Available Network Services

While user access to administrative controls is an important issue for system administrators within an organization, monitoring which network services are active is of paramount importance to anyone who administers and operates a Linux system.

Many services under Red Hat Enterprise Linux 6 behave as network servers. If a network service is running on a machine, then a server application (called a daemon), is listening for connections on one or more network ports. Each of these servers should be treated as a potential avenue of attack.

2.1.11.1. Risks To Services

Network services can pose many risks for Linux systems. Below is a list of some of the primary issues:

Denial of Service Attacks (DoS) — By flooding a service with requests, a denial of service attack can render a system unusable as it tries to log and answer each request.
Distributed Denial of Service Attack (DDoS) — A type of DoS attack which uses multiple compromised machines (often numbering in the thousands or more) to direct a coordinated attack on a service, flooding it with requests and making it unusable.
Script Vulnerability Attacks — If a server is using scripts to execute server-side actions, as Web servers commonly do, an attacker can attack improperly written scripts. These script vulnerability attacks can lead to a buffer overflow condition or allow the attacker to alter files on the system.
Buffer Overflow Attacks — Services that connect to ports numbered 0 through 1023 must run as an administrative user. If the application has an exploitable buffer overflow, an attacker could gain access to the system as the user running the daemon. Because exploitable buffer overflows exist, attackers use automated tools to identify systems with vulnerabilities, and once they have gained access, they use automated rootkits to maintain their access to the system.

Note

The threat of buffer overflow vulnerabilities is mitigated in Red Hat Enterprise Linux by ExecShield, an executable memory segmentation and protection technology supported by x86-compatible uni- and multi-processor kernels. ExecShield reduces the risk of buffer overflow by separating virtual memory into executable and non-executable segments. Any program code that tries to execute outside of the executable segment (such as malicious code injected from a buffer overflow exploit) triggers a segmentation fault and terminates.

Execshield also includes support for No eXecute (NX) technology on AMD64 platforms and eXecute Disable (XD) technology on Itanium and Intel® 64 systems. These technologies work in conjunction with ExecShield to prevent malicious code from running in the executable portion of virtual memory with a granularity of 4KB of executable code, lowering the risk of attack from buffer overflow exploits.

Important

To limit exposure to attacks over the network, disable all services that are unused.

2.1.11.2. Identifying and Configuring Services

To enhance security, most network services installed with Red Hat Enterprise Linux are turned off by default. There are, however, some notable exceptions:

cupsd — The default print server for Red Hat Enterprise Linux.
lpd — An alternative print server.
xinetd — A super server that controls connections to a range of subordinate servers, such as gssftp and telnet.
sendmail — The Sendmail Mail Transport Agent (MTA) is enabled by default, but only listens for connections from the localhost.
sshd — The OpenSSH server, which is a secure replacement for Telnet.

When determining whether to leave these services running, it is best to use common sense and avoid taking any risks. For example, if a printer is not available, do not leave cupsd running. The same is true for portmap. If you do not mount NFSv3 volumes or use NIS (the ypbind service), then portmap should be disabled.

Figure 2.3. Services Configuration Tool

If unsure of the purpose for a particular service, the Services Configuration Tool has a description field, illustrated in Figure 2.3, “Services Configuration Tool”, that provides additional information.

Checking which network services are available to start at boot time is not sufficient. It is recommended to also check which ports are open and listening. Refer to Section 2.2.9, “Verifying Which Ports Are Listening” for more information.

2.1.11.3. Insecure Services

Potentially, any network service is insecure. This is why turning off unused services is so important. Exploits for services are routinely revealed and patched, making it very important to regularly update packages associated with any network service. Refer to Section 1.5, “Security Updates” for more information.

Some network protocols are inherently more insecure than others. These include any services that:

Transmit Usernames and Passwords Over a Network Unencrypted — Many older protocols, such as Telnet and FTP, do not encrypt the authentication session and should be avoided whenever possible.
Transmit Sensitive Data Over a Network Unencrypted — Many protocols transmit data over the network unencrypted. These protocols include Telnet, FTP, HTTP, and SMTP. Many network file systems, such as NFS and SMB, also transmit information over the network unencrypted. It is the user's responsibility when using these protocols to limit what type of data is transmitted.
Remote memory dump services, like netdump, transmit the contents of memory over the network unencrypted. Memory dumps can contain passwords or, even worse, database entries and other sensitive information.
Other services like finger and rwhod reveal information about users of the system.

Examples of inherently insecure services include rlogin, rsh, telnet, and vsftpd.

All remote login and shell programs (rlogin, rsh, and telnet) should be avoided in favor of SSH. Refer to Section 2.1.13, “Security Enhanced Communication Tools” for more information about sshd.

FTP is not as inherently dangerous to the security of the system as remote shells, but FTP servers must be carefully configured and monitored to avoid problems. Refer to Section 2.2.6, “Securing FTP” for more information about securing FTP servers.

Services that should be carefully implemented and behind a firewall include:

finger
authd (this was called identd in previous Red Hat Enterprise Linux releases.)
netdump
netdump-server
nfs
rwhod
sendmail
smb (Samba)
yppasswdd
ypserv
ypxfrd

More information on securing network services is available in Section 2.2, “Server Security”.

The next section discusses tools available to set up a simple firewall.

2.1.12. Personal Firewalls

After the necessary network services are configured, it is important to implement a firewall.

Important

Configure the necessary services and implement a firewall before connecting to the Internet or any other network that you do not trust.

Firewalls prevent network packets from accessing the system's network interface. If a request is made to a port that is blocked by a firewall, the request is ignored. If a service is listening on one of these blocked ports, it does not receive the packets and is effectively disabled. For this reason, ensure that you block access to ports not in use when configuring a firewall, while not blocking access to ports used by configured services.

For most users, the best tool for configuring a simple firewall is the graphical firewall configuration tool which includes Red Hat Enterprise Linux: the Firewall Configuration Tool (system-config-firewall). This tool creates broad iptables rules for a general-purpose firewall using a control panel interface.

Refer to Section 2.8.2, “Basic Firewall Configuration” for more information about using this application and its available options.

For advanced users and server administrators, manually configuring a firewall with iptables is preferable. Refer to Section 2.8, “Firewalls” for more information. Refer to Section 2.8.9, “IPTables” for a comprehensive guide to the iptables command.

2.1.13. Security Enhanced Communication Tools

As the size and popularity of the Internet has grown, so has the threat of communication interception. Over the years, tools have been developed to encrypt communications as they are transferred over the network.

Red Hat Enterprise Linux 6 includes two basic tools that use high-level, public-key-cryptography-based encryption algorithms to protect information as it travels over the network.

OpenSSH — A free implementation of the SSH protocol for encrypting network communication.
Gnu Privacy Guard (GPG) — A free implementation of the PGP (Pretty Good Privacy) encryption application for encrypting data.

OpenSSH is a safer way to access a remote machine and replaces older, unencrypted services like telnet and rsh. OpenSSH includes a network service called sshd and three command line client applications:

ssh — A secure remote console access client.
scp — A secure remote copy command.
sftp — A secure pseudo-ftp client that allows interactive file transfer sessions.

Refer to Section 3.2.2, “Secure Shell” for more information regarding OpenSSH.

Important

Although the sshd service is inherently secure, the service must be kept up-to-date to prevent security threats. Refer to Section 1.5, “Security Updates” for more information.

GPG is one way to ensure private email communication. It can be used both to email sensitive data over public networks and to protect sensitive data on hard drives.

2.1.14. Enforcing Read-Only Mounting of Removable Media

To enforce read-only mounting of removable media (such as USB flash disks), the administrator can use a udev rule to detect removable media and configure them to be mounted read-only using the blockdev utility. Starting with Red Hat Enterprise Linux 6.7, a special parameter can be also passed to the udisks disk manager to force read-only mounting of file systems.

While the udev rule that triggers the blockdev utility is sufficient for enforcing read-only mounting of physical media, the udisks parameter can be used to enforce read-only mounting of filesystems on read-write mounted media.

Using blockdev to Force Read-Only Mounting of Removable Media

To force all removable media to be mounted read-only, create a new udev configuration file named, for example, 80-readonly-removables.rules in the /etc/udev/rules.d/ directory with the following content:

SUBSYSTEM=="block",ATTRS{removable}=="1",RUN{program}="/sbin/blockdev --setro %N"

The above udev rule ensures that any newly connected removable block (storage) device is automatically configured as read-only using the blockdev utility.

Using udisks to Force Read-Only Mounting of Filesystems

To force all file systems to be mounted read-only, a special udisks parameter needs to be set through udev. Create a new udev configuration file named, for example, 80-udisks.rules in the /etc/udev/rules.d/ directory with the following content (or add the following lines to this file if it already exists):

ENV{UDISKS_MOUNT_OPTIONS}="ro,noexec"
ENV{UDISKS_MOUNT_OPTIONS_ALLOW}="noexec,nodev,nosuid,atime,noatime,nodiratime,ro,sync,dirsync"

Note that a default 80-udisks.rules file is installed with the udisks package in the /lib/udev/rules.d/ directory. This file contains the above rules, but they are commented out.

The above udev rules instruct the udisks disk manager to only allow read-only mounting of file systems. Also, the noexec parameter forbids direct execution of any binaries on the mounted file systems. This policy is enforced regardless of the way the actual physical device is mounted. That is, file systems are mounted read-only even on read-write mounted devices.

Applying New udev and udisks Settings

For these settings to take effect, the new udev rules need to be applied. The udev service automatically detects changes to its configuration files, but new settings are not applied to already existing devices. Only newly connected devices are affected by the new settings. Therefore, you need to unmount and unplug all connected removable media to ensure that the new settings are applied to them when they are next plugged in.

To force udev to re-apply all rules to already existing devices, enter the following command as root:

~# udevadm trigger

Note that forcing udev to re-apply all rules using the above command does not affect any storage devices that are already mounted.

To force udev to reload all rules (in case the new rules are not automatically detected for some reason), use the following command:

~# udevadm control --reload

^[3] Since system BIOSes differ between manufacturers, some may not support password protection of either type, while others may support one type but not the other.

^[4] GRUB also accepts unencrypted passwords, but it is recommended that an MD5 hash be used for added security.

此内容没有您所选择的语言版本。

Chapter 2. Securing Your Network

2.1. Workstation Security

2.1.1. Evaluating Workstation Security

2.1.2. BIOS and Boot Loader Security

2.1.2.1. BIOS Passwords

2.1.2.1.1. Securing Non-x86 Platforms

2.1.2.2. Boot Loader Passwords

2.1.2.2.1. Password Protecting GRUB

2.1.2.2.2. Disabling Interactive Startup

2.1.3. Password Security

2.1.3.1. Creating Strong Passwords

2.1.4. Creating User Passwords Within an Organization

2.1.4.1. Forcing Strong Passwords

2.1.4.2. Passphrases

2.1.4.3. Password Aging

2.1.5. Locking Inactive Accounts

2.1.6. Customizing Access Control

2.1.7. Time-based Restriction of Access

2.1.8. Applying Account Limits

2.1.9. Administrative Controls

2.1.9.1. Allowing Root Access

2.1.9.2. Disallowing Root Access

2.1.9.3. Enabling Automatic Logouts

2.1.9.4. Limiting Root Access

2.1.9.5. Account Locking

2.1.10. Session Locking

2.1.10.1. Locking GNOME Using gnome-screensaver-command

2.1.10.1.1. Automatic Lock on Screen Saver Activation

2.1.10.1.2. Remote Session Locking

2.1.10.2. Locking Virtual Consoles Using vlock

2.1.11. Available Network Services

2.1.11.1. Risks To Services

2.1.11.2. Identifying and Configuring Services

2.1.11.3. Insecure Services

2.1.12. Personal Firewalls

2.1.13. Security Enhanced Communication Tools

2.1.14. Enforcing Read-Only Mounting of Removable Media

Using blockdev to Force Read-Only Mounting of Removable Media

Using udisks to Force Read-Only Mounting of Filesystems

Applying New udev and udisks Settings

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links