Example of SCAP Security Guidance

3.1.1.1. Disk Partitioning

Some system directories should be placed on their own partitions (or logical volumes). This allows for better separation and protection of data.
The installer’s default partitioning scheme creates separate partitions (or logical volumes) for /, /boot, and swap.

• If starting with any of the default layouts, check the box to “Review and modify partitioning.” This allows for the easy creation of additional logical volumes inside the volume group already created, though it may require making /’s logical volume smaller to create space. In general, using logical volumes is preferable to using partitions because they can be more easily adjusted later.

• If creating a custom layout, create the partitions mentioned in the previous paragraph (which the installer will require anyway), as well as separate ones described in the following sections.

If a system has already been installed, and the default partitioning scheme was used, it is possible but nontrivial to modify it to create separate logical volumes for the directories listed above. The Logical Volume Manager (LVM) makes this possible. See the LVM HOWTO at http://tldp.org/HOWTO/LVM-HOWTO/ for more detailed information on LVM.

link | previous | next | up | toc | home

3.1.1.2. Boot Loader Configuration

Check the box to "Use a boot loader password" and create a password. Once this password is set, anyone who wishes to change the boot loader configuration will need to enter it. Assigning a boot loader password prevents a local user with physical access from altering the boot loader configuration at system startup.

link | previous | next | up | toc | home

3.1.1.3. First-boot Configuration

The system presents more configuration options during the first boot after installation. For the screens listed, implement the security-related recommendations:

• Set Up Software Updates - If the system is connected to the Internet now, click 'Yes, I'd like to register now.' This will require a connection to either the Red Hat Network servers or their proxies or satellites.

• Create User - If the system will require a local user account, it can be created here. Even if the system will be using a network-wide authentication system, do not click on the 'Use Network Login...' button. Manually applying configuration later is preferable.

• Kdump - Leave Kdump off unless the feature is required, such as for kernel development and testing.

• Firewall - Leave set to 'Enabled.' Only check the 'Trusted Services' that this system needs to serve. Uncheck the default selection of SSH if the system does not need to serve SSH.

• SELinux - Leave SELinux set to 'Enforcing' mode.

link | previous | next | up | toc | home

3.1.2.1. Ensure Red Hat GPG Keys are Installed

To ensure that the system can cryptographically verify update packages (and also connect to the Red Hat Network to receive them if desired) run the following command to ensure that the system has the Red Hat GPG keys properly installed:

$ rpm -q gpg-pubkey

The command should return the strings:

gpg-pubkey-fd431d51-4ae0493b
gpg-pubkey-2fa658e0-45700c69
corresponding to these keys:
gpg(Red Hat, Inc. (release key 2) <security@redhat.com>)
gpg(Red Hat, Inc. (auxiliary key) <security@redhat.com>)

link | previous | next | up | toc | home

3.1.2.2. Configure Connection to the RHN RPM Repositories

The first step in configuring a system for updates is to register with the Red Hat Network (RHN). For most systems, this is done during the initial installation. Successfully registered systems will appear on the RHN web site. If the system is not listed, run the Red Hat Subscription Manager tool, which can be found in the System => Administration menu in the top management bar. or on the command line:

# subscription-manager register --username admin-example --password secret

Follow the prompts on the screen. If successful, the system will appear on the RHN web site and be subscribed to one or more software update channels. Additionally, a new daemon, rhnsd, will be enabled.

If the system will not have access to the Internet, it will not be able to directly subscribe to the RHN update repository. Updates will have to be downloaded from the RHN web site manually. The command line tool yum and the graphical front-end PackageKit can be configured to handle this situation.

link | previous | next | up | toc | home

3.1.2.3. Disable the rhnsd Daemon

The rhnsd daemon polls the Red Hat Network web site for scheduled actions. Unless it is actually necessary to schedule updates remotely through the RHN website, it is recommended that the service be disabled.

The rhnsd daemon is enabled by default, but until the system has been registered with the Red Hat Network, it will not run. However, once the registration process is complete, the rhnsd daemon will run in the background and periodically call the rhn check utility. It is the rhn check utility that communicates with the Red Hat Network web site.

This utility is not required for the system to be able to access and install system updates. Once the system has been registered, either use the provided yum-updatesd service or create a cron job to automatically apply updates.

link | previous | next | up | toc | home

3.1.2.4. Obtain Software Package Updates with yum

The yum update utility can be run by hand from the command line, called through one of the provided front-end tools, or configured to run automatically at specified intervals.

link | previous | next | up | toc | home

3.1.3.1. Verify Package Integrity Using RPM

The RPM package management system includes the ability to verify the integrity of installed packages by comparing the installed files with information about the files taken from the package metadata stored in the RPM database. Although an attacker could corrupt the RPM database (analogous to attacking the AIDE database as described above), this check can still reveal modification of important files.

To determine which files on the system differ from what is expected by the RPM database:

# rpm -Va

A “c” in the second column indicates that a file is a configuration file (and may be expected to change). In order to exclude configuration files from this list, run:

# rpm -Va | awk '$2!="c" {print $0}'

The man page rpm(8) describes the format of the output. Any files that do not match the expected output demand further investigation if the system is being seriously examined. This check could also be run as a cron job.

link | previous | next | up | toc | home

3.2.1.1. Verify Permissions on passwd, shadow, group and gshadow Files

Many utilities need read access to the passwd file in order to function properly, but read access to the shadow file allows malicious attacks against system passwords, and should never be enabled.

link | previous | next | up | toc | home

3.2.1.2. Verify that All World-Writable Directories Have Sticky Bits Set

When the so-called 'sticky bit' is set on a directory, only the owner of a given file may remove that file from the directory. Without the sticky bit, any user with write access to a directory may remove any file in the directory. Setting the sticky bit prevents users from removing each other's files. In cases where there is no reason for a directory to be world-writable, a better solution is to remove that permission rather than to set the sticky bit. However, if a directory is used by a particular application, consult that application's documentation instead of blindly changing modes.

link | previous | next | up | toc | home

3.2.1.3. Find Unauthorized World-Writable Files

Data in world-writable files can be modified by any user on the system. In almost all circumstances, files can be configured using a combination of user and group permissions to support whatever legitimate access is needed without the risk caused by world-writable files.

It is generally a good idea to remove global (other) write access to a file when it is discovered. However, check with documentation for specific applications before making changes. Also, monitor for recurring world-writable files, as these may be symptoms of a misconfigured application or user account.

link | previous | next | up | toc | home

3.2.1.4. Find Unauthorized SUID/SGID System Executables

The following command discovers and prints any setuid or setgid files on local partitions. Run it once for each local partition:

find PART -xdev \( -perm -4000 -o -perm -2000 \) -type f -print

If the file does not require a setuid or setgid bit, then these bits can be removed with the command:

chmod -s file

The following table contains all setuid and setgid files which are expected to be on a stock system. To reduce system risk, the packages containing these files may be removed in some cases; alternatively, the setuid or setgid bit on these files may be disabled to reduce system risk if only an administrator requires their functionality.

link | previous | next | up | toc | home

3.2.1.5. Find and Repair Unowned Files

The following command will discover and print any files on local partitions which do not belong to a valid user and a valid group. Run it once for each local partition PART:

# find PART -xdev \( -nouser -o -nogroup \) -print

If this command prints any results, investigate each reported file and either assign it to an appropriate user and group or remove it. Unowned files are not directly exploitable, but they are generally a sign that something is wrong with some system process. They may be caused by an intruder, by incorrect software installation or draft software removal, or by failure to remove all files belonging to a deleted account. The files should be repaired so that they will not cause problems when accounts are created in the future, and the problem which led to unowned files should be discovered and addressed.

link | previous | next | up | toc | home

3.2.1.6. Verify that All World-Writable Directories Have Proper Ownership

Locate any directories in local partitions which are world-writable and ensure that they are owned by root or another system account. The following command will discover and print these (assuming only system accounts have a uid lower than 500). Run it once for each local partition PART:

# find PART -xdev -type d -perm -0002 -uid +500 -print

If this command produces any output, investigate why the current owner is not root or another system account.

Allowing a user account to own a world-writeable directory is undesirable because it allows the owner of that directory to remove or replace any files that may be placed in the directory by other users.

link | previous | next | up | toc | home

3.2.2.1. Set Daemon umask

The file /etc/rc.d/init.d/functions which is used by most or all shell scripts in the /etc/init.d directory, set an umask. The system umask must be set to at least 022, or daemon processes may create world-writable files. The more restrictive setting 027 protects files, including temporary files and log files, from unauthorized reading by unprivileged users on the system.

If a particular daemon needs a less restrictive umask, consider editing the startup script or sysconfig file of that daemon to make a specific exception.

link | previous | next | up | toc | home

3.2.2.2. Disable Core Dumps

A core dump file is the memory image of an executable program when it was terminated by the operating system due to errant behavior. In most cases, only software developers would legitimately need to access these files. The core dump files may also contain sensitive information, or unnecessarily occupy large amounts of disk space.

By default, the system sets a soft limit to stop the creation of core dump files for all users. However, compliance with this limit is voluntary; it is a default intended only to protect users from the annoyance of generating unwanted core files. Users can increase the allowed core file size up to the hard limit, which is unlimited by default. Once a hard limit is set in /etc/security/limits.conf,

* hard core 0

the user cannot increase that limit within his own session. If access to core dumps is required, consider restricting them to only certain users or groups. See the limits.conf man page for more information.

link | previous | next | up | toc | home

3.2.2.3. Ensure SUID Core Dumps are Disabled

The sysctl variable fs.suid_dumpable controls whether the kernel allows core dumps from these programs at all. It should be checked to ensure that it has not been enabled at any time during system operation. To check this, issue the command:

# sysctl fs.suid_dumpable

The output should indicate that the setting is 0. (Use of the -n option causes output to consist of only the value, which may make automated checking easier.)

link | previous | next | up | toc | home

3.2.2.4. Enable ExecShield

ExecShield comprises a number of kernel features to provide protection against buffer overflows. These features include random placement of the stack and other memory regions, prevention of execution in memory that should only hold data, and special handling of text buffers. This protection is enabled by default, but the sysctl variables kernel.exec-shield and kernel.randomize va space should be checked to ensure that it has not been disabled.

To check that ExecShield (including random placement of virtual memory regions) is currently running, issue the following commands:

# sysctl kernel.exec-shield
# sysctl kernel.randomize_va_space

The output should indicate that the setting of kernel.exec-shield is 1 and the setting of kernel.randomize_va_space is 2. (Use of the -n option causes output to consist of only the value, which may make automated checking easier.)

link | previous | next | up | toc | home

3.3.1.1. Restrict Root Logins to System Console

Edit the file /etc/securetty. Ensure that the file contains only the following lines:

• The primary system console device:
  console

• The virtual console devices:
  tty1 tty2 tty3 tty4 tty5 tty6 ...

• If required by your organization, the deprecated virtual console interface may be retained for backwards compatibility:
  vc/1 vc/2 vc/3 vc/4 vc/5 vc/6 ...

• If required by your organization, the serial consoles may be added:
  ttyS0 ttyS1

Direct root logins should be allowed only for emergency use. In normal situations, the administrator should access the system via a unique unprivileged account, and use su or sudo to execute privileged commands. Discouraging administrators from accessing the root account directly ensures an audit trail in organizations with multiple administrators. Locking down the channels through which root can connect directly reduces opportunities for password-guessing against the root account. The login program uses the file /etc/securetty to determine which interfaces should allow root logins. The virtual devices /dev/console and /dev/tty* represent the system consoles (accessible via the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default installation). The default securetty file also contains /dev/vc/*. These are likely to be deprecated in most environments, but may be retained for compatibility. Root should also be prohibited from connecting via network protocols.

link | previous | next | up | toc | home

3.3.1.2. Configure su to Restrict the Root Access

The su command allows a user to gain the privileges of another user by entering the password for that user's account. It is desirable to restrict the root user so that only known administrators are ever allowed to access the root account. This restricts password-guessing against the root account by unauthorized users or by accounts which have been compromised.

By convention, the group wheel contains all users who are allowed to run privileged commands. The PAM module pam_wheel.so is used to restrict root access to this set of users.

link | previous | next | up | toc | home

3.3.1.3. Configure sudo to Improve Auditing of Root Access

The sudo command allows fine-grained control over which users can execute commands using other accounts. The primary benefit of sudo when configured as above is that it provides an audit trail of every command run by a privileged user. It is possible for a malicious administrator to circumvent this restriction, but, if there is an established procedure that all root commands are run using sudo, then it is easy for an auditor to detect unusual behavior when this procedure is not followed.

Editing /etc/sudoers by hand can be dangerous, since a configuration error may make it impossible to access the root account remotely. The recommended means of editing this file is using the visudo command, which checks the file's syntax for correctness before allowing it to be saved.

Note that sudo allows any attacker who gains access to the password of an administrator account to run commands as root. This is a downside which must be weighed against the benefits of increased audit capability and of being able to heavily restrict the use of the high-value root password (which can be logistically difficult to change often). As a basic precaution, never use the NOPASSWD directive, which would allow anyone with access to an administrator account to execute commands as root without knowing the administrator's password.

The sudo command has many options which can be used to further customize its behavior. See the sudoers(5) man page for details.

link | previous | next | up | toc | home

3.3.1.4. Block Shell and Login Access for Non-Root System Accounts

Using /etc/passwd, obtain a listing of all users, their UIDs, and their shells, for instance by running:

# awk -F: '{print $1 ":" $3 ":" $7}' /etc/passwd

Identify the system accounts from this listing. These will primarily be the accounts with UID numbers less than 500, other than root.

For each identified system account SYSACCT , lock the account:

# usermod -L SYSACCT
and disable its shell:

# usermod -s /sbin/nologin SYSACCT

These are the accounts which are not associated with a human user of the system, but which exist to perform some administrative function. Make it more difficult for an attacker to use these accounts by locking their passwords and by setting their shells to some non-valid shell. The default non-valid shell is /sbin/nologin, but any command which will exit with a failure status and disallow execution of any further commands, such as /bin/false or /dev/null, will work.

link | previous | next | up | toc | home

3.3.1.5. Verify that No Accounts Have Empty Password Fields

If an account has an empty password, anybody may log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.

Run the command:

# awk -F: '($2 == "") {print}' /etc/shadow

If this produces any output, fix the problem by locking each account or by setting a password.

link | previous | next | up | toc | home

3.3.1.6. Verify that All Account Password Hashes are Shadowed

The hashes for all user account passwords should be stored in the file /etc/shadow and never in /etc/passwd, which is readable by all users.

To ensure that no password hashes are stored in /etc/passwd, the following command should have no output:

# awk -F: '($2 != "x") {print}' /etc/passwd

link | previous | next | up | toc | home

3.3.1.7. Verify that No Non-Root Accounts Have UID 0

In general, the best practice solution for auditing use of the root account is to restrict the set of cases in which root must be accessed anonymously by requiring use of su or sudo in almost all cases. Some sites choose to have more than one account with UID 0 in order to differentiate between administrators, but this practice may have unexpected side effects, and is therefore not recommended.

This command will print all password file entries for accounts with UID 0:

# awk -F: '($3 == "0") {print}' /etc/passwd

This should print only one line, for the user root. If any other lines appear, ensure that these additional UID-0 accounts are authorized, and that there is a good reason for them to exist.

link | previous | next | up | toc | home

3.3.1.8. Set Password Expiration Parameters

Edit the file /etc/login.defs to specify password expiration settings for new accounts. Add or correct the following lines:

PASS_MAX_DAYS=180
PASS_MIN_DAYS=7
PASS_WARN_AGE=7

For each existing human user USER , modify the current expiration settings to match these:

# chage -M 180 -m 7 -W 7 USER

Users should be forced to change their passwords, in order to decrease the utility of compromised passwords. However, the need to change passwords often should be balanced against the risk that users will reuse or write down passwords if forced to change them too often. Forcing password changes every 90-360 days, depending on the environment, is recommended. Set the appropriate value as PASS_MAX_DAYS and apply it to existing accounts with the -M flag.

The PASS_MIN_DAYS (-m) setting prevents password changes for 7 days after the first change, to discourage password cycling. If you use this setting, train users to contact an administrator for an emergency password change in case a new password becomes compromised. The PASS_WARN_AGE (-W) setting gives users 7 days of warnings at login time that their passwords are about to expire.

link | previous | next | up | toc | home

3.3.2.1. Set Password Quality Requirements

The default pam_cracklib PAM module provides strength checking for passwords. It performs a number of checks, such as making sure passwords are not similar to dictionary words, are of at least a certain length, are not the previous password reversed, and are not simply a change of case from the previous password. It can also require passwords to be in certain character classes.

The pam_passwdqc PAM module provides the ability to enforce even more stringent password strength requirements. It is provided in an RPM of the same name.

The man pages pam_cracklib(8) and pam_passwdqc(8) provide information on the capabilities and configuration of each.

link | previous | next | up | toc | home

3.3.2.2. Set Lockouts for Failed Password Attempts

The pam_tally2 PAM module provides the capability to lock out user accounts after a number of failed login attempts. Its documentation is available in the man page pam_tally2(8).

If locking out accounts after a number of incorrect login attempts is required by your security policy, implement use of pam_tally2.so for the relevant PAM-aware programs such as login, sshd, and vsftpd.

Find the following line in /etc/pam.d/system-auth:

auth sufficient pam_unix.so nullok try_first_pass

and then change it so that it reads as follows:

auth required pam_unix.so nullok try_first_pass

In the same file, comment out or delete the lines:

auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
After changing /etc/pam.d/system-auth as described above, perform the same set of changes in /etc/pam.d/password-auth as well.
To enforce password lockout, add the following to the individual programs' configuration files in /etc/pam.d. First, add to end of the auth lines:

auth required pam_tally2.so deny=5 onerr=fail

Second, add to the end of the account lines:

account required pam_tally2.so

Adjust the deny argument to conform to your system security policy. The pam_tally2 utility can be used to unlock user accounts as follows:

# /sbin/pam_tally2 --user username --reset


link | previous | next | up | toc | home

3.3.2.3. Use pam_deny.so to Quickly Deny Access to a Service

In order to deny access to a service SVCNAME via PAM, edit the file /etc/pam.d/SVCNAME . Prepend this line to the beginning of the file:

auth requisite pam_deny.so

Under most circumstances, there are better ways to disable a service than to deny access via PAM. However, this should suffice as a way to quickly make a service unavailable to future users (existing sessions which have already been authenticated, are not affected). The requisite tag tells PAM that, if the named module returns failure, authentication should fail, and PAM should immediately stop processing the configuration file. The pam_deny.so module always returns failure regardless of its input.

link | previous | next | up | toc | home

3.3.2.4. Ensure the Password Hashing Algorithm is SHA-512

The default algorithm for storing password hashes in /etc/shadow is SHA-512, but a weaker algorithm could have been configured.

In order to configure the system to use the SHA-512 algorithm, issue the command:

# /usr/sbin/authconfig --passalgo=sha512 --update

When users changes their passwords, hashes for the new passwords will be generated using the SHA-512 algorithm.

link | previous | next | up | toc | home

3.3.2.5. Limit Password Reuse

Do not allow users to reuse recent passwords. This can be accomplished by using the remember option for the pam_unix PAM module. In order to prevent a user from re-using any of his or her last 5 passwords, locate the
password requisite pam_cracklib.so ...
or
password requisite pam_passwdqc.so ...
line in /etc/pam.d/system-auth, and add the following line immediately below:
password requisite pam_pwhistory.so use_authtok remember=5
Old (and thus no longer valid) passwords are stored in the file /etc/security/opasswd.

link | previous | next | up | toc | home

3.3.3.1. Ensure that No Dangerous Directories Exist in Root's Path

The active path of the root account can be obtained by starting a new root shell and running:

# echo $PATH
This will produce a colon-separated list of directories in the path. For each directory DIR in the path, ensure that DIR is not equal to a single . character. Also ensure that there are no 'empty' elements in the path, such as in these examples:

PATH=:/bin
PATH=/bin:
PATH=/bin::/sbin

These empty elements have the same effect as a single . character.

For each element in the path, run:

# ls -ld DIR

and ensure that write permissions are disabled for group and other.

It is important to prevent root from executing unknown or untrusted programs, since such programs could contain malicious code. Therefore, root should not run programs installed by unprivileged users. Since root may often be working inside untrusted directories, the . character, which represents the current directory, should never be in the root path, nor should any directory which can be written to by an unprivileged or semi-privileged (system) user.

It is a good practice for administrators to always execute privileged commands by typing the full path to the command.

link | previous | next | up | toc | home

3.3.3.2. Ensure that User Home Directories are not Group-Writable or World-Readable

For each human user USER of the system, view the permissions of the user's home directory:

# ls -ld /home/USER

Ensure that the directory is not group-writable and that it is not world-readable. If necessary, repair the permissions:

# chmod g-w /home/USER
# chmod o-rwx /home/USER

User home directories contain many configuration files which affect the behavior of a user's account. No user should ever have write permission to another user's home directory. Group shared directories can be configured in subdirectories or elsewhere in the filesystem if they are needed. Typically, user home directories should not be world-readable. If a subset of users need read access to one another's home directories, this can be provided using groups.

link | previous | next | up | toc | home

3.3.3.3. Ensure that User Dot-Files are not World-writable

For each human user USER of the system, view the permissions of all dot-files in the user's home directory:

# ls -ld /home/USER/.[A-Za-z0-9]*

Ensure that none of these files are group- or world-writable. Correct each misconfigured file FILE by executing:

# chmod go-w /home/USER/FILE

A user who can modify another user's configuration files can likely execute commands with the other user's privileges, including stealing data, destroying files, or launching further attacks on the system.

link | previous | next | up | toc | home

3.3.3.4. Ensure that Users Have Sensible Umask Values

With a default umask setting of 077, files and directories created by users will not be readable by any other user on the system. Users who wish to make specific files group- or world-readable can accomplish this using the chmod command. Additionally, users can make all their files readable to their group by default by setting a umask of 027 in their shell configuration files. If default per-user groups exist (that is, if every user has a default group whose name is the same as that user's username and whose only member is the user), then it may even be safe for users to select a umask of 007, making it very easy to intentionally share files with group s of which the user is a member.

In addition, it may be necessary to change root's umask temporarily in order to install software or files which must be readable by other users, or to change the default umasks of certain service accounts such as the FTP user. However, setting a restrictive default protects the files of users who have not taken steps to make their files more available, and preventing files from being inadvertently shared.

link | previous | next | up | toc | home

3.3.3.5. Ensure that Users do not Have .netrc Files

For each human user USER of the system, ensure that the user has no .netrc file. The command:

# ls -l /home/USER/.netrc

should return the error 'No such file or directory'. If any user has such a file, approach that user to discuss removing this file.

The .netrc file is a configuration file used to make unattended logins to other systems via FTP. When this file exists, it frequently contains unencrypted passwords which may be used to attack other systems.

link | previous | next | up | toc | home

3.3.4.1. Set BIOS Password

The BIOS (on x86 systems) is the first code to execute during system startup and controls many important system parameters, including which devices the system will try to boot from, and in which order. Assign a password to prevent any unauthorized changes to the BIOS configuration. The exact steps will vary depending on your machine, but are likely to include:

The exact process will be system-specific and the system's hardware manual may provide detailed instructions. This password should prevent attackers with physical access from attempting to change important parameters. However, an attacker with physical access can usually clear the BIOS password. The password should be written down and stored in a physically-secure location, such as a safe, in the event that it is forgotten and must be retrieved.

link | previous | next | up | toc | home

3.3.4.2. Boot Loader Password

During the boot process, the boot loader is responsible for starting the execution of the kernel and passing options to it. The boot loader allows for the selection of different kernels – possibly on different partitions or media. Options it can pass to the kernel include 'single-user mode,' which provides root access without any authentication, and the ability to disable SELinux. To prevent local users from modifying the boot parameters and endangering security, the boot loader configuration should be protected with a password.

The default RHEL boot loader for x86 systems is called GRUB. To protect its configuration:

Boot loaders for other platforms should offer a similar password protection feature.

link | previous | next | up | toc | home

3.3.4.3. Require Authentication for Single-User Mode

Single-user mode is intended as a system recovery method, providing a single user root access to the system by providing a boot option at startup. By default, no authentication is performed if single-user mode is selected. This provides a trivial mechanism of bypassing security on the machine and gaining root access.

To require entry of the root password even if the system is started in single-user mode, change the SINGLE value in /etc/sysconfig/init as follows:

SINGLE=/sbin/sulogin

link | previous | next | up | toc | home

3.3.4.4. Disable Interactive Boot

Edit the file /etc/sysconfig/init. Add or correct the setting:

PROMPT=no
The PROMPT option allows the console user to perform an interactive system startup, in which it is possible to select the set of services which are started on boot. Using interactive boot, the console user could disable auditing, firewalls, or other services, weakening system security.

link | previous | next | up | toc | home

3.3.4.5. Implement Inactivity Time-out for Login Shells

If the system does not run X Windows, then the login shells can be configured to automatically log users out after a period of inactivity. The following instructions are not practical for systems which run X Windows, as they will close terminal windows in the X environment.

To implement a 15-minute idle time-out for the default /bin/bash shell, create a new file tmout.sh in the directory /etc/profile.d with the following lines:

TMOUT=900
readonly TMOUT
export TMOUT

To implement a 15-minute idle time-out for the tcsh shell, create a new file autologout.csh in the directory /etc/profile.d with the following line:

set -r autologout=15

Similar actions should be taken for any other login shells used.

The example time-out here of 15 minutes should be adjusted to whatever your security policy requires. The readonly line for bash and the -r option for tcsh can be omitted if policy allows users to override the value.

The automatic shell logout only occurs when the shell is the foreground process. If, for example, a vi session is left idle, then automatic logout would not occur.

When logging in through a remote connection, as with SSH, it may be more effective to set the timeout value directly through that service.

link | previous | next | up | toc | home

3.3.4.6. Configure Screen Locking

When a user must temporarily leave an account logged-in, screen locking should be employed to prevent passersby from abusing the account. User education and training is particularly important for screen locking to be effective.

A policy should be implemented that trains all users to lock the screen when they plan to temporarily step away from a logged-in account. Automatic screen locking is only meant as a safeguard for those cases where a user forgot to lock the screen.

link | previous | next | up | toc | home

3.3.4.7. Disable Unnecessary Ports

Though unusual, some systems may be managed only remotely and yet also exposed to risk from attackers with direct physical access to them. In these cases, reduce an attacker’s access to the system by disabling unnecessary external ports (e.g. USB, FireWire, NIC) in the system’s BIOS.

Disable ports on the system which are not necessary for normal system operation. The exact steps will vary depending on your machine, but are likely to include:

link | previous | next | up | toc | home

3.3.6.1. Modify the System Login Banner

The contents of the file /etc/issue are displayed on the screen just above the login prompt for users logging directly into a terminal. Remote login programs such as SSH or FTP can be configured to display /etc/issue as well.

By default, the system will display the version of the OS, the kernel version, and the host name.

Edit /etc/issue. Replace the default text with a message compliant with the local site policy or a legal disclaimer.

link | previous | next | up | toc | home

3.3.6.2. Implement a GUI Warning Banner

In the default graphical environment, users logging directly into the system are greeted with a login screen provided by the GNOME display manager. The warning banner should be displayed in this graphical environment for these users.

Configure the banner using the following commands:
# gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set /apps/gdm/simple-greeter/banner_message_enable true
# gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type string --set /apps/gdm/simple-greeter/banner_message_text 'YOUR_TEXT'

link | previous | next | up | toc | home

3.4.2.4. Ensure SELinux is Properly Enabled

Run the command:

$ /usr/sbin/sestatus

If the system is properly configured, the output should indicate:

• SELinux status: enabled

• Current mode: enforcing

• Mode from config file: enforcing

• Policy from config file: targeted

link | previous | next | up | toc | home

3.4.3.1. Remove SETroubleshoot if Possible

Is there a mission-critical reason to allow users to view SELinux denial information using the sealert GUI? If not, remove the setroubleshoot packages:
$ yum remove setroubleshoot-\*


The setroubleshoot, which is newly D-Bus system service, is a facility for notifying the desktop user of SELinux denials in a user-friendly fashion. SELinux errors may provide important information about intrusion attempts in progress, or may give information about SELinux configuration problems which are preventing correct system operation. In order to maintain a secure and usable SELinux installation, error logging and notification is necessary.
However, setroubleshoot is a service which has complex functionality, which runs a daemon and uses D-Bus to distribute information which may be sensitive, or even to allow users to modify SELinux settings. This guide recommends removing setroubleshoot and using the kernel audit functionality to monitor SELinux's behavior.

link | previous | next | up | toc | home

3.4.3.2. Disable MCS Translation Service (mcstrans) if Possible

Unless there is some overriding need for the convenience of category label translation, disable the MCS translation service:

# chkconfig mcstrans off

The mcstransd daemon provides the category label translation information defined in /etc/selinux/targeted/setrans.conf to client processes which request this information.

Category labelling is unlikely to be used except in sites with special requirements. Therefore, it should be disabled in order to reduce the amount of potentially vulnerable code running on the system.

link | previous | next | up | toc | home

3.4.3.3. Restorecon Service (restorecond)

The restorecond daemon monitors a list of files which are frequently created or modified on running systems, and whose SELinux contexts are not set correctly. It looks for creation events related to files listed either in /etc/selinux/restorecond.conf or restorecond_user.conf , and sets the contexts ofthose files when they are discovered.

The restorecond program is fairly simple, so it brings low risk, but, in its default configuration, does not add much value to a system. An automated program such as restorecond may be used to monitor problematic files for context problems, or system administrators may be trained to check file contexts of newly-created files using the command ls -lZ, and to repair contexts manually using the restorecon command.

This guide makes no recommendation either for or against the use of restorecond.

link | previous | next | up | toc | home

3.4.7.1. Strengthen the Default SELinux Boolean Configuration

SELinux booleans are used to enable or disable segments of policy to comply with site policy. Booleans may apply to the entire system or to an individual daemon. For instance, the boolean allow execstack, if enabled, allows programs to make part of their stack memory region executable. The boolean ftp home dir allows ftpd processes to access user home directories, and applies only to daemons which implement FTP.

The command

$ getsebool -a

$ semanage boolean -l


lists the values of all SELinux booleans on the system. Section 2.4.5 discussed loosening boolean values in order to debug functionality problems which occur under more restrictive defaults. It is also useful to examine and strengthen the boolean settings, to disable functionality which is not required by legitimate programs on your system, but which might be symptomatic of an attack.

See the manpages booleans(8), getsebool(8), setsebool(8) and semanage(8) for general information about booleans. There are also manual pages for several subsystems which discuss the use of SELinux with those systems. Examples include ftpd selinux(8), httpd selinux(8), and nfs_selinux(8). Another good reference is the html documentation distributed with the selinux-policy RPM. This documentation is stored under

/usr/share/doc/selinux-policy-version/html/

The pages global tunables.html and global booleans.html may be useful when examining booleans.

link | previous | next | up | toc | home

3.4.7.2. Use a Stronger Policy

Using a stronger policy can greatly enhance security, but will generally require customization to be compatible with the particular system's purpose, and this may be costly or time consuming. Under the targeted policy, interactive processes are given the type unconfined t, so interactive users are not constrained by SELinux even if they attempt to take strange or malicious actions.
Previously, in RHEL5, we had strict policy which could be installed using selinux-policy-strict package. In RHEL6, we combine strict and targeted policy together. There exist two SELinux policy modules - unconfined.pp and unconfineduser.pp policy modules. These two modules are optional, and removing it gives you the equivalent of strict policy. Firstly, you can just remove unconfined.pp policy module. You will be closer to strict policy but this leaves only user domains unconfined, along with some domains that do not make sense to confine (anaconda, firstboot, kernel,rpm) and also unconfined_t user will be exist.
# semodule -d unconfined
# seinfo -aunconfined_domain_type -x | tail -n +2 | wc -l
Then you can disable all unconfined domains by disabling unconfineduser module which is equal strict policy. In this case, you need to setup all your users as confined users, before removing the unconfineduser module using semanage tool
# semanage login -m -s staff_u root
# semanage login -m -s staff_u __default__
# semanage user -d unconfined_u
# semanage user -m -R "staff_r system_r sysadm_r" staff_u
# semodule -d unconfineduser

Note: One of the RHEL6 features are Confined Users. This means, unconfined.pp and unconfineduser.pp policy modules can be used and an user can be confined even so. All this magic lie in adding login mappings between linux users and SELinux confined users.
# semanage login -a -s user_u -r s0-s0:c0.c1023 USERNAME1
# semanage login -a -s staff_u -r s0-s0:c0.c1023 USERNAME2


The mls policy type can be used to enforce sensitivity or category labelling, and requires site-specific configuration of these labels in order to be useful. To use this policy, install the appropriate policy module:
# yum install selinux-policy-mls
Then edit /etc/selinux/config and correct the line:
SELINUXTYPE=mls
Configure the system to boot into run level 3 by default:
sed -i "s/^id:5:initdefault:/id:3:initdefault:/g" /etc/inittab
Note: Switching between policies typically requires the entire disk to be relabelled, so that files get the appropriate SELinux contexts under the new policy. Add autorelabel flag
touch /.autorelabel; reboot
and boot with the additional grub command-line options
enforcing=0
to relabel the disk, then reboot normally.

link | previous | next | up | toc | home

3.5.1.1. Network Parameters for Hosts Only

Is this system going to be used as a firewall or gateway to pass IP traffic between different networks?
If not, edit the file /etc/sysctl.conf and add or correct the following lines:

net.ipv4.ip forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
These settings disable hosts from performing network functionality which is only appropriate for routers.

link | previous | next | up | toc | home

3.5.1.2. Network Parameters for Hosts and Routers

Edit the file /etc/sysctl.conf and add or correct the following lines:

net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.all.log_martians = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.conf.default.log_martians = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

These options improve Linux's ability to defend against certain types of IPv4 protocol attacks.

The accept source route, accept redirects, and secure redirects options are turned off to disable IPv4 protocol features which are considered to have few legitimate uses and to be easy to abuse.

The net.ipv4.conf.all.log martians option logs several types of suspicious packets, such as spoofed packets, source-routed packets, and redirects.

The icmp echo ignore broadcasts icmp ignore bogus error messages options protect against ICMP attacks.

The tcp syncookies option uses a cryptographic feature called SYN cookies to allow machines to continue to accept legitimate connections when faced with a SYN flood attack. See [12] for further information on this option.

The rp filter option enables RFC-recommended source validation. It should not be used on machines which are routers for very complicated networks, but is helpful for end hosts and routers serving small networks.

For more information on any of these, see the kernel source documentation file /Documentation/networking/ip-sysctl.txt.

link | previous | next | up | toc | home

3.5.2.1. Remove Wireless Hardware if Possible

Identifying the wireless hardware is the first step in removing it. The system's hardware manual should contain information on its wireless capabilities.

Wireless hardware included with a laptop typically takes the form of a mini-PCI card or PC card. Other forms include devices which plug into USB or Ethernet ports, but these should be readily apparent and easy to remove from the base system.

A PC Card (originally called a PCMCIA card) is designed to be easy to remove, though it may be hidden when inserted into the system. Frequently, there will be one or more buttons near the card slot that, when pressed, eject the card from the system. If no card is ejected, the slot is empty.

A mini-PCI card is approximately credit-card sized and typically accessible via a removable panel on the underside of the laptop. Removing the panel may require simple tools.

In addition to manually inspecting the hardware, it is also possible to query the system for its installed hardware devices. The commands /sbin/lspci and /sbin/lsusb will show a list of all recognized devices on their respective buses, and this may indicate the presence of a wireless device.

link | previous | next | up | toc | home

3.5.2.2. Disable Wireless in BIOS

Some laptops that include built-in wireless support offer the ability to disable the device through the BIOS. This is system-specific; consult your hardware manual or explore the BIOS setup during boot.

link | previous | next | up | toc | home

3.5.2.3. Deactivate Wireless Interfaces

Deactivating the wireless interfaces should prevent normal usage of the wireless capability.

First, identify the interfaces available with the command:

# ip link ls

Additionally,the following command may also be used to determine whether wireless support ('extensions') is included for a particular interface, though this may not always be a clear indicator:

# iwconfig

After identifying any wireless interfaces (which may have names like wlan0, ath0, wifi0, or eth0), deactivate the interface with the command:

# ip link set interface down

These changes will only last until the next reboot. To disable the interface for future boots, locate its configuration file /etc/sysconfig/network-scripts/ifcfg-interface and add or replace configuration directives to match the following:
ONBOOT=no
USERCTL=no
NM_CONTROLLED=no

link | previous | next | up | toc | home

3.5.3.1. Disable Support for IPv6 unless Needed

Because the IPv6 networking code is relatively new and complex, it is particularly important that it be disabled unless needed. Despite configuration that suggests support for IPv6 has been disabled, link-local IPv6 address autoconfiguration occurs even when only an IPv4 address is assigned. The only way to effectively prevent execution of the IPv6 networking stack is to prevent the kernel from loading the IPv6 kernel module.

link | previous | next | up | toc | home

3.5.3.2. Configure IPv6 Settings if Necessary

A major feature of IPv6 is the extent to which systems implementing it can automatically configure their networking devices using information from the network. From a security perspective, manually configuring important configuration information is always preferable to accepting it from the network in an unauthenticated fashion.

link | previous | next | up | toc | home

3.5.4.1. How TCP Wrapper Protects Services

TCP Wrapper provides access control for the system's network services using two configuration files. When a connection is attempted:

In the simplest case, each rule in /etc/hosts.allow and /etc/hosts.deny takes the form:

daemon : client

where daemon is the name of the server process for which the connection is destined, and client is the partial or full hostname or IP address of the client. It is valid for daemon and client to contain one item, a comma-separated list of items, or a special keyword like ALL, which matches any service or client. (See the hosts_access(5) manpage for a list of other keywords.)

Note: Partial hostnames start at the root domain and are delimited by the . character. So the client machine host03.dev.example.com, with IP address 10.7.2.3, could be matched by any of the specifications:

.example.com
.dev.example.com
10.7.2.

link | previous | next | up | toc | home

3.5.4.2. Reject All Connections From Other Hosts if Appropriate

Restrict all connections to non-public services to localhost only. Suppose pubsrv1 and pubsrv2 are the names of daemons which must be accessed remotely. Configure TCP Wrapper as follows.

Edit /etc/hosts.allow. Add the following lines:

pubsrv1 ,pubsrv2 : ALL
ALL: localhost

Edit /etc/hosts.deny. Add the following line:

ALL: ALL

These rules deny connections to all TCP Wrapper enabled services from any host other than localhost, but allow connections from anywhere to the services which must be publicly accessible. (If no public services exist, the first line in /etc/hosts.allow may be omitted.)

link | previous | next | up | toc | home

3.5.4.3. Allow Connections Only From Hosts in This Domain if Appropriate

For each daemon, domainsrv , which only needs to be contacted from inside the local domain, example.com , configure TCP Wrapper to deny remote connections.

Edit /etc/hosts.allow. Add the following line:

domainsrv : .example.com

Edit /etc/hosts.deny. Add the following line:

domainsrv : ALL

There are many possible examples of services which need to communicate only within the local domain. If a machine is a local compute server, it may be necessary for users to connect via SSH from their desktop workstations, but not from outside the domain. In that case, you should protect the daemon sshd using this method. As another example, RPC-based services such as NFS might be enabled within the domain only, in which case the daemon portmap should be protected.

link | previous | next | up | toc | home

3.5.4.4. Monitor Syslog for Relevant Connections and Failures

Ensure that the following line exists in /etc/rsyslog.conf. (This is the default, so it is likely to be correct if the configuration has not been modified):

authpriv.* /var/log/secure

Configure logwatch or other log monitoring tools to periodically summarize failed connections reported by TCP Wrapper at the facility authpriv.info.

By default, TCP Wrapper audits all rejected connections at the facility authpriv, level info. In the log file, TCP Wrapper rejections will contain the substring:

daemon [pid ]: refused connect from ipaddr

These lines can be used to detect malicious scans, and to debug failures resulting from an incorrect TCP Wrapper configuration.

If appropriate, it is possible to change the syslog facility and level used by a given TCP Wrapper rule by adding the severity option to each desired configuration line in /etc/hosts.deny:

daemon : client : severity facility.level

By default, successful connections are not logged by TCP Wrapper.

link | previous | next | up | toc | home

3.5.4.5. Further Resources

For more information about TCP Wrapper, see the tcpd(8) and hosts_access(5) manpages and the documentation directory /usr/share/doc/tcp_wrappers-version.

Some information may be available from the Tools section of the author's website, http://www.porcupine.org, and from the RHEL6 Security Guide.

link | previous | next | up | toc | home

3.5.5.1. Inspect and Activate Default Rules

View the currently-enforced iptables rules by running the command:

# iptables -nL --line-numbers

The command is analogous for the ip6tables program.

If the firewall does not appear to be active (i.e., no rules appear), activate it and ensure that it starts at boot by issuing the following commands (and analogously for ip6tables):

# service iptables restart
# chkconfig iptables on

The default iptables rules are:

Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
5 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
num target prot opt source destination
1 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
The ip6tables default rules are similar, with its input rules 2 and 5 and forward rule 1 reflecting protocol naming and addressing differences.

link | previous | next | up | toc | home

3.5.5.2. Understand the Default Ruleset

Understanding and creating firewall rules can be a challenging activity, filled with corner cases and difficult-to debug problems. Because of this, administrators should develop a thorough understanding of the default ruleset before carefully modifying it.

The default ruleset is divided into three sections, each of which is called a chain: INPUT, FORWARD and OUTPUT. Each of these chains is built-in.

• The INPUT chain is activated on packets destined for (i.e., addressed to) the system.

• The OUTPUT chain is activated on packets which are originating from the system.

• The FORWARD chain is activated for packets that the system will process and send through another interface, if so configured.

A packet starts at the first rule in the appropriate chain and proceeds until it matches a rule. If a match occurs, then control will jump to the specified target. The default ruleset uses the built-in targets ACCEPT and REJECT. Jumping to the target ACCEPT means to allow the packet through, while REJECT means to drop the packet and send an error message to the sending host. A related target called DROP means to drop the packet without even sending an error message.

The default policy for all of the built-in chains (shown after their names in the rule output above) is set to ACCEPT. This means that if no rules in the chain match the packets, they are allowed through. Because no rules at all are written for the OUTPUT chain, this means that iptables does not stop any packets originating from the system.

The INPUT chain tries to match, in order, the following rules for both iptables and ip6tables:

• Rule 1, allows inbound packets that are part of a session initiated by the system.

• Rule 2 explicitly allows all icmp packet types.

• Rule 3 appears to accept all packets. However, this appears true only because the rules are not presented in verbose mode. Executing the command
  
  # iptables -vnL --line-numbers

  reveals that this rule applies only to the loopback (lo) interface (see column in), while all other rules apply to all interfaces. Thus, packets not coming from the loopback interface do not match and proceed to the next rule.

• Rule 4 allows inbound connections in tcp port 22, which is the SSH protocol.

• Rule 5 rejects all other packets and sends an error message to the sender. Because this is the last rule and matches any packet, it effectively prevents any packet from reaching the chain's default ACCEPT target. Preventing the acceptance of any packet that is not explicitly allowed is proper design for a firewall.

link | previous | next | up | toc | home

3.5.5.3. Strengthen the Default Ruleset

The default rules can be strengthened. The system scripts that activate the firewall rules expect them to be defined in the configuration files iptables and ip6tables in the directory /etc/sysconfig. Many of the lines in these files are similar to the command line arguments that would be provided to the programs /sbin/iptables or /sbin/ip6tables – but some are quite different.

The following recommendations describe how to strengthen the default ruleset configuration file. An alternative to editing this configuration file is to create a shell script that makes calls to the iptables program to load in rules, and then invokes service iptables save to write those loaded rules to /etc/sysconfig/iptables. If the construction of the default ruleset meets your requirements, system-config-firewall-tui may be used to customize it, to the extent the tool allows it.

The following alterations can be made directly to /etc/sysconfig/iptables and /etc/sysconfig/ip6tables. Instructions apply to both unless otherwise noted. Language and address conventions for regular iptables are used throughout this section; configuration for ip6tables will be either analogous or explicitly covered.

link | previous | next | up | toc | home

3.5.5.4. Further Strengthening

Further strengthening, particularly as a result of customization to a particular environment, is possible for the iptables rules. Consider the following options, though their practicality depends on the network environment and usage scenario:

• Restrict outgoing traffic. As shown above, the OUTPUT chain's default policy can be changed to DROP, and rules can be written to specifically allow only certain types of outbound traffic. Such a policy could prevent casual usage of insecure protocols such as ftp and telnet, or even disrupt spyware. However, it would still not prevent a sophisticated user or program from using a proxy to circumvent the intended effects, and many client programs even try to automatically tunnel through port 80 to avoid such restrictions.

• SYN flood protection. SYN flood protection can be provided by iptables, but might run into limiting issues for servers. For example, the iplimit match can be used to limit simultaneous connections from a given host or class. Similarly, the recent match allows the firewall to deny additional connections from any host within a given period of time (e.g. more than 3 –state NEW connections on port 22 within a minute to prevent dictionary login attacks).
  
  A more precise option for DoS protection is using TCP SYN cookies.

link | previous | next | up | toc | home

3.5.5.5. Further Resources

More complex, restrictive, and powerful rulesets can be created, but this requires careful customization that relies on knowledge of the particular environment. The following resources provide more detailed information:

• The iptables(8) man page

• The Netfilter Project's documentation at http://www.netfilter.org

• The Red Hat Enterprise Linux 6 Security Guide

link | previous | next | up | toc | home

3.5.6.1. Create a CA to Sign Certificates

The following instructions apply to OpenSSL. The security of certificates depends on the security of the CA that signed them, so performing these steps on a secure machine is critical. The system used as a CA should be physically secure and not connected to any network. It should receive any certificate signing requests (CSRs) via removable media and output certificates onto removable media.

The script /etc/pki/tls/misc/CA is included to assist in the process of setting up a CA. This script uses many settings in /etc/pki/tls/openssl.cnf. The settings in this file can be changed to suit your needs and allow easier selection of default settings, particularly in the [req distinguished name] section.

To create the CA:

# cd /etc/pki/tls/misc
# ./CA -newca

• When prompted, press enter to create a new CA key with the default name cakey.pem.

• When prompted, enter a password that will protect the private key, then enter the same password again to verify it.

• At the prompts, fill out as much of the CA information as is relevant for your site. You must specify a common name, or generation of the CA certificate will fail.

• Next, you will be prompted for the password, so that the script can re-open the private key in order to write the certificate.

This step performs the following actions:

• creates the directory /etc/pki/CA (by default), which contains files necessary for the operation of a certificate authority. These are:

• creates a public-private key pair for the CA in the file /etc/pki/CA/private/cakey.pem. The private key must be kept private in order to ensure the security of the certificates the CA will later sign.

• signs the public key (using the corresponding private key, in a process called self-signing) to create the CA certificate, which is then stored in /etc/pki/CA/cacert.pem.

When the CA later signs a server certificate using its private key, it means that it is vouching for the authenticity of that server. A client can then use the CA's certificate (which contains its public key) to verify the authenticity of the server certificate. To accomplish this, it is necessary to distribute the CA certificate to any clients.

link | previous | next | up | toc | home

3.5.6.2. Create X.509 Certificates for Servers

Creating an X.509 certificate for a server involves the following steps:

link | previous | next | up | toc | home

3.5.6.3. Enable Client Support

The system ships with certificates from well-known commercial CAs. If your server certificates were signed by one of these established CAs, then this step is not necessary since the clients should include the CA certificate already.

If your servers use certificates signed by your own CA, some user applications will warn that the server's certificate cannot be verified because the CA is not recognized. Other applications may simply fail to accept the certificate and refuse to operate, or continue operating without ever having properly verified the server certificate.

To avoid this warning, and properly authenticate the servers, your CA certificate must be exported to every application on every client system that will be connecting to an TLS-enabled server.

link | previous | next | up | toc | home

3.5.6.4. Further Resources

• The OpenSSL Project home page at http://www.openssl.org

• The openssl(1) man page

link | previous | next | up | toc | home

3.5.7.1. Disable Support for DCCP

To prevent the DCCP kernel module from being loaded, create /etc/modprobe.d/dccp.conf with the following content:

install dccp /bin/true

The Datagram Congestion Control Protocol (DCCP) is a relatively new transport layer protocol, designed to support streaming media and telephony.

link | previous | next | up | toc | home

3.5.7.2. Disable Support for SCTP

To prevent the SCTP kernel module from being loaded, create /etc/modprobe.d/sctp.conf with the following content:

install sctp /bin/true

The Stream Control Transmission Protocol (SCTP) is a transport layer protocol, designed to support the idea of message-oriented communication, with several streams of messages within one connection.

link | previous | next | up | toc | home

3.5.7.3. Disable Support for RDS

To prevent the RDS kernel module from being loaded, create /etc/modprobe.d/rds.conf with the following content:

install rds /bin/true

The Reliable Datagram Sockets (RDS) protocol is a transport layer protocol designed to provide reliable high-bandwidth, low-latency communications between nodes in a cluster.

link | previous | next | up | toc | home

3.6.1.2. Ensure All Important Messages are Captured

The default RHEL6 rsyslog configuration stores the facilities authpriv, cron, and mail in named logs. This guide describes the implementation of the following configuration, but any configuration which stores the important facilities and is usable by the administrators will suffice:

• Store each of the facilities kern, daemon, and syslog in its own log, so that it will be easy to access information about messages from those facilities.

• Restrict the information stored in /var/log/messages to only the facilities auth and user, and store all messages from those facilities. Messages can easily become cluttered otherwise.

• Store information about all facilities which should not be in use at this site in a file called /var/log/unused.log. If any messages are logged to this file at some future point, this may be an indication that an unknown service is running, and should be investigated. In addition, if news and uucp are not in use at this site, remove the directive from the default syslog.conf which stores those facilities.

Making use of the local facilities is also recommended. Specific configuration is beyond the scope of this guide, but applications such as SSH can easily be configured to log to a local facility which is not being used for anything else. If this is done, reconfigure /etc/syslog.conf to store this facility in an appropriate named log or in /var/log/messages, rather than in /var/log/unused.log.

link | previous | next | up | toc | home

3.6.1.3. Confirm Existence and Permissions of System Log Files

For each log file LOGFILE referenced in /etc/rsyslog.conf, run the commands:

# touch LOGFILE
# chown root:root LOGFILE
# chmod 0600 LOGFILE

Some logs may contain sensitive information, so it is better to restrict permissions so that only administrative users can read or write logfiles.

link | previous | next | up | toc | home

3.6.1.4. Syslog logs should be sent to a remote loghost

If system logs are to be useful in detecting malicious activities, it is necessary to send logs to a remote server. An intruder who has compromised the root account on a machine may delete the log entries which indicate that the system was attacked before they are seen by an administrator.

link | previous | next | up | toc | home

3.6.1.5. Rsyslog shouldn't be run in a compatibility mode

Rsyslog can be run in a compatibility mode which simulates the behavior of its older versions. The version to be compatible with is specified with a command line option. It is advisable to run the daemon in a mode that matches its current version. Using an older mode may alter your configuration in an unexpected way. The mode can be configured by changing the value of the SYSLOGD_OPTIONS variable in /etc/sysconfig/rsyslog.

link | previous | next | up | toc | home

3.6.1.6. Ensure All Logs are Rotated by logrotate

Edit the file /etc/logrotate.d/syslog. Find the first line, which should look like this:

/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron {

Edit this line so that it contains a one-space-separated listing of each log file referenced in /etc/rsyslog.conf.
All logs in use on a system must be rotated regularly, or the log files will consume disk space over time, eventually interfering with system operation. The file /etc/logrotate.d/syslog is the configuration file used by the logrotate program to maintain all log files written by syslog. By default, it rotates logs weekly and stores four archival copies of each log. These settings can be modified by editing /etc/logrotate.conf, but the defaults are sufficient for purposes of this guide.

Note that logrotate is run nightly by the cron job /etc/cron.daily/logrotate. If particularly active logs need to be rotated more often than once a day, some other mechanism must be used.

link | previous | next | up | toc | home

3.6.1.7. Monitor Suspicious Log Messages using Logwatch

The system includes an extensible program called Logwatch for reporting on unusual items in syslog. Logwatch is valuable because it provides a parser for the syslog entry format and a number of signatures for types of lines which are considered to be mundane or noteworthy. Logwatch has a number of downsides: the signatures can be inaccurate and are not always categorized consistently, and you must be able to program in Perl in order to customize the signature database. However, it is recommended that all Linux sites which do not have time to deploy a third-party log monitoring application run Logwatch in its default configuration. This provides some useful information about system activity in exchange for very little administrator effort.

This guide recommends that Logwatch be run only on the central logserver, if your site has one, in order to focus administrator attention by sending all daily logs in a single e-mail.

link | previous | next | up | toc | home

3.6.2.1. Enable the auditd Service

Ensure that the auditd service is enabled (this is the default):

# chkconfig auditd on

By default, auditd logs only SELinux denials, which are helpful for debugging SELinux and discovering intrusion attempts, and certain types of security events, such as modifications to user accounts (useradd, passwd, etc), login events, and calls to sudo.

Data is stored in /var/log/audit/audit.log. By default, auditd rotates 4 logs by size (5MB), retaining a maximum of 20MB of data in total, and refuses to write entries when the disk is too full. This minimizes the risk of audit data filling its partition and impacting other services. However, it is possible to lose audit data if the system is busy.

link | previous | next | up | toc | home

3.6.2.2. Configure auditd Data Retention

• Determine STOREMB , the amount of audit data (in megabytes) which should be retained in each log file. Edit the file /etc/audit/auditd.conf. Add or modify the following line:
  
  max_log_file = STOREMB

• Use a dedicated partition (or logical volume) for log files. It is straightforward to create such a partition or logical volume during system installation time. The partition should be larger than the maximum space which auditd will ever use, which is the maximum size of each log file (max log file) multiplied by the number of log files (num logs). Ensure the partition is mounted on /var/log/audit.

• If your site requires that the machine be disabled when auditing cannot be performed, configure auditd to halt the system when disk space for auditing runs low. Edit /etc/audit/auditd.conf, and add or correct the following lines:
  
  space_left_action = email
  action_mail_acct = root
  admin_space_left_action = halt
  

The default action to take when the logs reach their maximum size is to rotate the log files, discarding the oldest one. If it is more important to retain all possible auditing information, even if that opens the possibility of running out of space and taking the action defined by admin space left action, add or correct the line:

max_log_file_action = keep_logs

By default, auditd retains 4 log files of size 5Mb apiece. For a busy system or a system which is thoroughly auditing system activity, this is likely to be insufficient.

The log file size needed will depend heavily on what types of events are being audited. First configure auditing to log all the events of interest. Then monitor the log size manually for a while to determine what file size will allow you to keep the required data for the correct time period.

Using a dedicated partition for /var/log/audit prevents the auditd logs from disrupting system functionality if they fill the partition, and, more importantly, prevents other activity in /var from filling the partition and stopping the audit trail. (The audit logs are size-limited and therefore unlikely to grow without bound unless configured to do so.) Some machines may have requirements that no actions occur which cannot be audited. If this is the case, then auditd can be configured to halt the machine if it runs out of space.

Note: Since older logs are rotated, configuring auditd this way does not prevent older logs from being rotated away before they can be viewed.

link | previous | next | up | toc | home

3.6.2.3. Enable Auditing for Processes Which Start Prior to the Audit Daemon

To ensure that all processes can be audited, even those which start prior to the audit daemon, add the argument audit=1 to the kernel line in /boot/grub/grub.conf, in the manner below:

kernel /vmlinuz-version ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet audit=1

Each process on the system carries an ”auditable” flag which indicates whether its activities can be audited. Although auditd takes care of enabling this for all processes which launch after it does, adding the kernel argument ensures that it is set for every process during boot.

link | previous | next | up | toc | home

3.6.2.4. Configure auditd Rules for Comprehensive Auditing

The auditd program can perform comprehensive monitoring of system activity. This section describes recommended configuration settings for comprehensive auditing, but a full description of the auditing system’s capabilities is beyond the scope of this guide. The mailing list linux-audit@redhat.com may be a good source of further information.

The audit subsystem supports extensive collection of events, including:

• Tracing of arbitrary system calls (identified by name or number) on entry or exit.

• Filtering by PID, UID, call success, system call argument (with some limitations), etc.

• Monitoring of specific files for modifications to the file’s contents or metadata.

Auditing rules are controlled in the file /etc/audit/audit.rules. Add rules to it to meet the auditing requirements for your organization. Each line in /etc/audit/audit.rules represents a series of arguments that can be passed to auditctl and can be individually tested as such. See documentation in /usr/share/doc/audit-version and in the related man pages for more details.

Recommended audit rules are provided in /usr/share/doc/audit-version/stig.rules. In order to activate those rules:

# cp /usr/share/doc/audit-version/stig.rules /etc/audit/audit.rules

and then edit /etc/audit/audit.rules and comment out the lines containing arch= which are not appropriate for your system’s architecture. Then review and understand the following rules, ensuring rules are activated as needed for the appropriate architecture.

After reviewing all the rules, reading the following sections, and editing as needed, activate the new rules:

# service auditd restart

link | previous | next | up | toc | home