Configuring System Information and Warning Banners

Presenting a warning message prior to the normal user login may assist the prosecution of trespassers on the computer system. Changing some of these login banners also has the side effect of hiding OS version information and other detailed system information from attackers attempting to target specific exploits at a system.

Guidelines published by the US Department of Defense require that warning messages include at least the name of the organization that owns the system, the fact that the system is subject to monitoring and that such monitoring is in compliance with local statutes, and that use of the system implies consent to such monitoring. It is important that the organization’s legal counsel review the content of all messages before any system modifications are made, as these warning messages are inherently site-specific. More information (including citations of relevant case law) can be found at http://www.justice.gov/criminal/cybercrime/

Note: The text provided in the remediation actions for these items is intended as an example only. Please edit to include the specific text for your organization as approved by your legal department.

8.1 Set Warning Banner for Standard Login Services

The contents of the /etc/issue file are displayed prior to the login prompt on the system’s console and serial devices, and also prior to logins via telnet. The contents of the

/etc/motd file is generally displayed after all successful logins, no matter where the user is logging in from, but is thought to be less useful because it only provides notification to the user after the machine has been accessed.

Rationale:

Warning messages inform users who are attempting to login to the system of their legal status regarding the system and must include the name of the organization that owns the system and any monitoring policies that are in place. Consult with your organization’s legal counsel for the appropriate wording for your specific organization.

Audit:

Run the following commands and ensure that the files exist and have the correct permissions.

# /bin/ls -l /etc/motd

-rw-r–r– 1 root root 2055 Jan 30 16:30 /etc/motd

# ls /etc/issue

-rw-r–r– 1 root root 2055 Jan 30 16:30 /etc/issue

# ls /etc/issue.net

-rw-r–r– 1 root root 2055 Jan 30 16:30 /etc/issue.net

The commands above simply validate the presence of the /etc/motd, /etc/issue and /etc/issue.net files. Review the contents of these files with the “cat” command and ensure that it is appropriate for your organization.

Remediation:

# touch /etc/motd

# echo “Authorized uses only. All activity may be \ monitored and reported.” > /etc/issue

# echo “Authorized uses only. All activity may be \ monitored and reported.” > /etc/issue.net

# chown root:root /etc/motd

# chmod 644 /etc/motd

# chown root:root /etc/issue

# chmod 644 /etc/issue

# chown root:root /etc/issue.net

# chmod 644 /etc/issue.net

8.2 Remove OS Information from Login Warning Banners

Unix-based systems have typically displayed information about the OS release and patch level upon logging in to the system. This information can be useful to developers who are developing software for a particular OS platform. If mingetty(8) supports the following options, they display operating system information:

\m – machine architecture (uname -m)

\r – operating system release (uname -r)

\s – operating system name

\v – operating system version (uname -v)

Rationale:

Displaying OS and patch level information in login banners also has the side effect of providing detailed system information to attackers attempting to target specific exploits of a system. Authorized users can easily get this information by running the “uname -a” command once they have logged in.

Audit:

Perform the following commands to check if OS information is set to be displayed in the system login banners:

# egrep ‘(\\v|\\r|\\m|\\s)’ /etc/issue

# egrep ‘(\\v|\\r|\\m|\\s)’ /etc/motd # egrep'(\\v|\\r|\\m|\\s)’ /etc/issue.net

Remediation:

Edit the /etc/motd, /etc/issue and /etc/issue.net files and remove any lines containing \m, \r, \s or \v.

8.3 Set GNOME Warning Banner

The GNOME Display Manager is used for login session management. See the manual page gdm(1) for more information. The remediation action for this item sets a warning message for GDM users before they log in.

Rationale:

Warning messages inform users who are attempting to login to the system of their legal status regarding the system and must include the name of the organization that owns the system and any monitoring policies that are in place. Consult with your organization’s legal counsel for the appropriate wording for your specific organization.

Audit:

# gconftool-2 -get /apps/gdm/simple-greeter/banner_message_text

Remediation:

# /bin/su -s /bin/sh gdm

# gconftool-2 -direct -config-source=xml:readwrite:$HOME/.gconf -type bool -set /apps/gdm/simple-greeter/banner_message_enable true

# gconftool-2 -direct -config-source=xml:readwrite:$HOME/.gconf -t string -s /apps/gdm/simple-greeter/banner_message_text “Your-Login-Banner”

Restart gdm for these settings to take effect.

Part-9 : System Maintenance Activities

No matter how securely a system has been installed and hardened, administrator and user activity over time can introduce security exposures. The section describes tasks to be performed on a regular, ongoing basis – perhaps in an automated fashion via the cron utility.

Note: unlike other sections, the items in this section specify an Audit action followed by a Remediation action since it is necessary to determine what the current setting is before determining remediation measures, which will vary depending on the site’s policy.

9.1 Verify System File Permissions

9.1.1 Verify System File Permissions

Level 2

The RPM package manager has a number of useful options. One of these, the -V (or verify) option, can be used to verify that system packages are correctly installed. The -V option can be used to verify a particular package or to verify all system packages (-Va). If no output is returned, the package is installed correctly. The following table describes the meaning of output from the verify option:

Code Meaning

S File size differs.

M File mode differs (includes permissions and file type).

5 The MD5 checksum differs.

D The major and minor version numbers differ on a device file.

L A mismatch occurs in a link.

U The file ownership differs.

G The file group owner differs.

T The file time (mtime) differs.

The rpm -qf command can be used to determine which package a particular file belongs to. For example the following command determines which package the /etc/passwd file belongs to:

# rpm -qf /etc/passwd setup-2.5.58-7.el5

To verify the settings for the package that controls the /etc/passwd file, run the following:

# rpm -V setup-2.5.58-7.el5

.M…… c /etc/passwd

S.5….T c /etc/printcap

Note that you can feed the output of the rpm -qf command to the rpm -V command:

# rpm -V `rpm -qf /etc/passwd`

.M…… c /etc/passwd S.5….T c /etc/printcap

Rationale:

It is important to confirm that packaged system files and directories are maintained with the permissions they were intended to have from the OS vendor.

Note: Since packages and important files may change with new updates and releases, it is recommended to verify everything, not just a finite list of files. This can be a time consuming task and is therefore not a scored benchmark item, but is provided for those interested in additional security measures.

Audit:

Run the following command to review all installed packages. Note that this may be very time consuming and may be best scheduled via the cron utility. It is recommended that the output of this command be redirected to a file that can be reviewed later.

# rpm -Va –nomtime –nosize –nomd5 –nolinkto > <filename>

Remediation:

Correct any discrepancies found and rerun the command until output is clean or risk is mitigated or accepted.

9.1.2 Verify Permissions on /etc/passwd

The /etc/passwd file contains user account information that is used by many system utilities and therefore must be readable for these utilities to operate.

Rationale:

It is critical to ensure that the /etc/passwd file is protected from unauthorized write access. Although it is protected by default, the file permissions could be changed either inadvertently or through malicious actions.

Audit:

Run the following command to determine the permissions on the /etc/passwd file.

# /bin/ls -l /etc/passwd

-rw-r–r– 1 root root 2055 Jan 30 16:30 /etc/passwd

Remediation:

If the permissions of the /etc/passwd file are incorrect, run the following command to correct them:

# /bin/chmod 644 /etc/passwd

9.1.3 Verify Permissions on /etc/shadow

The /etc/shadow file is used to store the information about user accounts that is critical to the security of those accounts, such as the hashed password and other security information.

Rationale:

If attackers can gain read access to the /etc/shadow file, they can easily run a password cracking program against the hashed password to break it. Other security information that is stored in the /etc/shadow file (such as expiration) could also be useful to subvert the user accounts.

Audit:

Run the following command to determine the permissions on the /etc/shadow file.

# /bin/ls -l /etc/shadow

———- 1 root root 633 Sep 23 2002 /etc/shadow

Remediation:

If the permissions of the /etc/shadow file are incorrect, run the following command to correct them:

# /bin/chmod 000 /etc/shadow

9.1.4 Verify Permissions on /etc/gshadow

The /etc/gshadow file contains information about group accounts that is critical to the security of those accounts, such as the hashed password and other security information.

Rationale:

If attackers can gain read access to the /etc/gshadow file, they can easily run a password cracking program against the hashed password to break it. Other security information that is stored in the /etc/gshadow file (such as expiration) could also be useful to subvert the group accounts.

Audit:

Run the following command to determine the permissions on the /etc/gshadow file.

# /bin/ls -l /etc/gshadow

———- 1 root root 633 Sep 23 2002 /etc/gshadow

Remediation:

If the permissions of the /etc/gshadow file are incorrect, run the following command to correct them:

# /bin/chmod 000 /etc/gshadow

9.1.5 Verify Permissions on /etc/group

The /etc/group file contains a list of all the valid groups defined in the system. The command below allows read/write access for root and read access for everyone else.

Rationale:

The /etc/group file needs to be protected from unauthorized changes by non-privileged users, but needs to be readable as this information is used with many non-privileged programs.

Audit:

Run the following command to determine the permissions on the /etc/group file.

# /bin/ls -l /etc/group

-rw-r–r– 1 root root 762 Sep 23 002 /etc/group

Remediation:

If the permissions of the /etc/group file are incorrect, run the following command to correct them:

# /bin/chmod 644 /etc/group

9.1.6 Verify User/Group Ownership on /etc/passwd

The /etc/passwd file contains a list of all the valid userIDs defined in the system, but not the passwords. The command below sets the owner and group of the file to root.

Rationale:

The /etc/passwd file needs to be protected from unauthorized changes by non-privileged users, but needs to be readable as this information is used with many non-privileged programs.

Audit:

Run the following command to determine the user and group ownership on the /etc/passwd file.

# /bin/ls -l /etc/passwd

-rw-r–r– 1 root root 762 Sep 23 002 /etc/passwd

Remediation:

If the user and group ownership of the /etc/passwd file are incorrect, run the following command to correct them:

# /bin/chown root:root /etc/passwd

9.1.7 Verify User/Group Ownership on /etc/shadow

The /etc/shadow file contains the one-way cipher text passwords for each user defined in the /etc/passwd file. The command below sets the user and group ownership of the file to root.

Rationale:

If attackers can gain read access to the /etc/shadow file, they can easily run a password cracking program against the hashed password to break it. Other security information that is stored in the /etc/shadow file (such as expiration) could also be useful to subvert the user accounts.

Audit:

Run the following command to determine the permissions on the /etc/shadow file.

# /bin/ls -l /etc/shadow

———- 1 root root 762 Sep 23 2002 /etc/shadow

Remediation:

If the ownership of the /etc/shadow file are incorrect, run the following command to correct them:

# /bin/chown root:root /etc/shadow

9.1.8 Verify User/Group Ownership on /etc/gshadow

The /etc/gshadow file contains information about group accounts that is critical to the security of those accounts, such as the hashed password and other security information.

Rationale:

If attackers can gain read access to the /etc/gshadow file, they can easily run a password cracking program against the hashed password to break it. Other security information that is stored in the /etc/gshadow file (such as expiration) could also be useful to subvert the group accounts.

Audit:

Run the following command to determine the permissions on the /etc/gshadow file.

# /bin/ls -l /etc/gshadow

———- 1 root root 633 Sep 23 2002 /etc/gshadow

Remediation:

If the ownership of the /etc/gshadow file are incorrect, run the following command to correct them:

# /bin/chown root:root /etc/gshadow

9.1.9 Verify User/Group Ownership on /etc/group

The /etc/group file contains a list of all the valid groups defined in the system. The command below allows read/write access for root and read access for everyone else.

Rationale:

The /etc/group file needs to be protected from unauthorized changes by nonprivileged users, but needs to be readable as this information is used with many nonprivileged programs.

Audit:

Run the following command to determine the permissions on the /etc/group file.

# /bin/ls -l /etc/group

-rw-r–r– 1 root root 762 Sep 23 002 /etc/group

Remediation:

If the ownership of the /etc/group file are incorrect, run the following command to correct them:

# /bin/chown root:root /etc/group

9.1.10 Find World Writable Files

Unix-based systems support variable settings to control access to files. World writable files are the least secure. See the chmod(2) man page for more information.

Rationale:

Data in world-writable files can be modified and compromised by any user on the system. World writable files may also indicate an incorrectly written script or program that could potentially be the cause of a larger compromise to the system’s integrity.

Audit:

#!/bin/bash

df –local -P | awk {‘if (NR!=1) print $6’} | xargs -I ‘{}’ find ‘{}’ -xdev -type f perm -0002

Remediation:

Removing write access for the “other” category (chmod o-w <filename>) is advisable, but always consult relevant vendor documentation to avoid breaking any application dependencies on a given file.

9.1.11 Find Un-owned Files and Directories

Sometimes when administrators delete users from the password file they neglect to remove all files owned by those users from the system.

Rationale:

A new user who is assigned the deleted user’s user ID or group ID may then end up “owning” these files, and thus have more access on the system than was intended.

Audit:

#!/bin/bash

df –local -P | awk {‘if (NR!=1) print $6’} | xargs -I ‘{}’ find ‘{}’ -xdev -nouser ls

Remediation:

Locate files that are owned by users or groups not listed in the system configuration files, and reset the ownership of these files to some active user on the system as appropriate.

9.1.12 Find Un-grouped Files and Directories

Sometimes when administrators delete users from the password file they neglect to remove all files owned by those users from the system.

Rationale:

A new user who is assigned the deleted user’s user ID or group ID may then end up “owning” these files, and thus have more access on the system than was intended.

Audit:

#!/bin/bash

df –local -P | awk {‘if (NR!=1) print $6’} | xargs -I ‘{}’ find ‘{}’ -xdev -nogroup ls

Remediation:

Locate files that are owned by users or groups not listed in the system configuration files, and reset the ownership of these files to some active user on the system as appropriate.

9.1.13 Find SUID System Executables

The owner of a file can set the file’s permissions to run with the owner’s or group’s permissions, even if the user running the program is not the owner or a member of the group. The most common reason for a SUID program is to enable users to perform functions (such as changing their password) that require root privileges.

Rationale:

There are valid reasons for SUID programs, but it is important to identify and review such programs to ensure they are legitimate.

Audit:

#!/bin/bash

df –local -P | awk {‘if (NR!=1) print $6’} | xargs -I ‘{}’ find ‘{}’ -xdev -type f perm -4000 -print

Remediation:

Ensure that no rogue set-UID programs have been introduced into the system. Review the files returned by the action in the Audit section and confirm the integrity of these binaries as described below:

# rpm -V `rpm -qf /usr/bin/sudo`

…….T /usr/bin/sudo

SM5….T /usr/bin/sudoedit

9.1.14 Find SGID System Executables

The owner of a file can set the file’s permissions to run with the owner’s or group’s permissions, even if the user running the program is not the owner or a member of the group. The most common reason for a SGID program is to enable users to perform functions (such as changing their password) that require root privileges.

Rationale:

There are valid reasons for SGID programs, but it is important to identify and review such programs to ensure they are legitimate. Review the files returned by the action in the audit section and check to see if system binaries have a different md5 checksum than what from the package. This is an indication that the binary may have been replaced. The following is an example of checking the “sudo” executable:

# rpm -V `rpm -qf /usr/bin/sudo`

…….T /usr/bin/sudo SM5….T /usr/bin/sudoedit

Audit:

#!/bin/bash

df –local -P | awk {‘if (NR!=1) print $6’} | xargs -I ‘{}’ find ‘{}’ -xdev -type f perm -2000 -print

Remediation:

Ensure that no rogue set-GID programs have been introduced into the system

# /bin/rpm -V `/bin/rpm -qf sudo`

9.2 Review User and Group Settings

This section provides guidance on securing aspects of the users and groups.

9.2.1 Ensure Password Fields are Not Empty

An account with an empty password field means that anybody may log in as that user without providing a password.

Rationale:

All accounts must have passwords or be locked to prevent the account from being used by an unauthorized user.

Audit:

Run the following command and verify that no output is returned:

# /bin/cat /etc/shadow | /bin/awk -F: ‘($2 == “” ) { print $1 ” does not have a password “}’

Remediation:

If any accounts in the /etc/shadow file do not have a password, run the following command to lock the account until it can be determined why it does not have a password:

# /usr/bin/passwd -l <username>

Also, check to see if the account is logged in and investigate what it is being used for to determine if it needs to be forced off.

9.2.2 Verify No Legacy “+” Entries Exist in /etc/passwd File

The character + in various files used to be markers for systems to insert data from NIS maps at a certain point in a system configuration file. These entries are no longer required on RHEL6 systems, but may exist in files that have been imported from other platforms.

Rationale:

These entries may provide an avenue for attackers to gain privileged access on the system.

Audit:

Run the following command and verify that no output is returned:

# /bin/grep ‘^+:’ /etc/passwd

Remediation:

Delete these entries if they exist.

9.2.3 Verify No Legacy “+” Entries Exist in /etc/shadow File

The character + in various files used to be markers for systems to insert data from NIS maps at a certain point in a system configuration file. These entries are no longer required on RHEL6 systems, but may exist in files that have been imported from other platforms.

Rationale:

These entries may provide an avenue for attackers to gain privileged access on the system.

Audit:

Run the following command and verify that no output is returned:

# /bin/grep ‘^+:’ /etc/shadow

Remediation:

Delete these entries if they exist.

9.2.4 Verify No Legacy “+” Entries Exist in /etc/group File

The character + in various files used to be markers for systems to insert data from NIS maps at a certain point in a system configuration file. These entries are no longer required on RHEL6 systems, but may exist in files that have been imported from other platforms.

Rationale:

These entries may provide an avenue for attackers to gain privileged access on the system.

Audit:

Run the following command and verify that no output is returned:

# /bin/grep ‘^+:’ /etc/group

Remediation:

Delete these entries if they exist.

9.2.5 Verify No UID 0 Accounts Exist Other Than root

Any account with UID 0 has superuser privileges on the system.

Rationale:

This access must be limited to only the default root account and only from the system console. Administrative access must be through an unprivileged account using an approved mechanism as noted in Item 7.5 Restrict root Login to System Console.

Audit:

Run the following command and verify that only the word “root” is returned:

# /bin/cat /etc/passwd | /bin/awk -F: ‘($3 == 0) { print $1 }’ root

Remediation:

Delete any other entries that are displayed. 9.2.6 Ensure root PATH Integrity

The root user can execute any command on the system and could be fooled into executing programs unemotionally if the PATH is not set correctly.

Rationale:

Including the current working directory (.) or other writable directory in root’s executable path makes it likely that an attacker can gain superuser access by forcing an administrator operating as root to execute a Trojan horse program.

Audit:

#!/bin/bash if [ “`echo $PATH | /bin/grep :: `” != “” ]; then echo “Empty Directory in PATH (::)” fi if [ “`echo $PATH | bin/grep :$`” != “” ]; then echo “Trailing : in PATH” fi p=`echo $PATH | /bin/sed -e ‘s/::/:/’ -e ‘s/:$//’ -e ‘s/:/ /g’` set — $p while [ “$1” != “” ]; do if [ “$1” = “.” ]; then echo “PATH contains .” shift continue fi if [ -d $1 ]; then dirperm=`/bin/ls -ldH $1 | /bin/cut -f1 -d” “` if [ `echo $dirperm | /bin/cut -c6 ` != “-” ]; then echo “Group Write permission set on directory $1” fi if [ `echo $dirperm | /bin/cut -c9 ` != “-” ]; then echo “Other Write permission set on directory $1” fi dirown=`ls -ldH $1 | awk ‘{print $3}’` if [ “$dirown” != “root” ] ; then echo $1 is not owned by root fi else echo $1 is not a directory fi shift done

Remediation:

Correct or justify any items discovered in the Audit step.

9.2.7 Check Permissions on User Home Directories

While the system administrator can establish secure permissions for users’ home directories, the users can easily override these.

Rationale:

Group or world-writable user home directories may enable malicious users to steal or modify other users’ data or to gain another user’s system privileges.

Audit:

#!/bin/bash for dir in `/bin/cat /etc/passwd | /bin/egrep -v ‘(root|halt|sync|shutdown)’ |\ /bin/awk -F: ‘($8 == “PS” && $7 != “/sbin/nologin”) { print $6 }’`; do dirperm=`/bin/ls -ld $dir | /bin/cut -f1 -d” “` if [ `echo $dirperm | /bin/cut -c6 ` != “-” ]; then echo “Group Write permission set on directory $dir” fi if [ `echo $dirperm | /bin/cut -c8 ` != “-” ]; then echo “Other Read permission set on directory $dir” fi if [ `echo $dirperm | /bin/cut -c9 ` != “-” ]; then echo “Other Write permission set on directory $dir” fi if [ `echo $dirperm | /bin/cut -c10 ` != “-” ]; then echo “Other Execute permission set on directory $dir” fi done

Remediation:

Making global modifications to user home directories without alerting the user community can result in unexpected outages and unhappy users. Therefore, it is recommended that a monitoring policy be established to report user file permissions and determine the action to be taken in accordance with site policy.

9.2.8 Check User Dot File Permissions

While the system administrator can establish secure permissions for users’ “dot” files, the users can easily override these.

Rationale:

Group or world-writable user configuration files may enable malicious users to steal or modify other users’ data or to gain another user’s system privileges.

Audit:

#!/bin/bash for dir in `/bin/cat /etc/passwd | /bin/egrep -v ‘(root|sync|halt|shutdown)’ | /bin/awk -F: ‘($7 != “/sbin/nologin”) { print $6 }’`; do for file in $dir/.[A-Za-z0-9]*; do if [ ! -h “$file” -a -f “$file” ]; then fileperm=`/bin/ls -ld $file | /bin/cut -f1 -d” “` if [ `echo $fileperm | /bin/cut -c6 ` != “-” ]; then echo “Group Write permission set on file $file” fi if [ `echo $fileperm | /bin/cut -c9 ` != “-” ]; then echo “Other Write permission set on file $file” fi fi done done

Remediation:

Making global modifications to users’ files without alerting the user community can result in unexpected outages and unhappy users. Therefore, it is recommended that a monitoring policy be established to report user dot file permissions and determine the action to be taken in accordance with site policy.

9.2.9 Check Permissions on User .netrc Files

While the system administrator can establish secure permissions for users’ .netrc files, the users can easily override these.

Rationale:

.netrc files may contain unencrypted passwords that may be used to attack other systems.

Audit:

#!/bin/bash for dir in `/bin/cat /etc/passwd | /bin/egrep -v ‘(root|sync|halt|shutdown)’ |\ /bin/awk -F: ‘($7 != “/sbin/nologin”) { print $6 }’`; do for file in $dir/.netrc; do if [ ! -h “$file” -a -f “$file” ]; then fileperm=`/bin/ls -ld $file | /bin/cut -f1 -d” “` if [ `echo $fileperm | /bin/cut -c5 ` != “-” ] then echo “Group Read set on $file”

fi if [ `echo $fileperm | /bin/cut -c6 ` != “-” ] then echo “Group Write set on $file” fi if [ `echo $fileperm | /bin/cut -c7 ` != “-” ] then echo “Group Execute set on $file” fi if [ `echo $fileperm | /bin/cut -c8 ` != “-” ] then echo “Other Read set on $file” fi if [ `echo $fileperm | /bin/cut -c9 ` != “-” ] then echo “Other Write set on $file” fi if [ `echo $fileperm | /bin/cut -c10 ` != “-” ] then echo “Other Execute set on $file” fi fi done done

Remediation:

Making global modifications to users’ files without alerting the user community can result in unexpected outages and unhappy users. Therefore, it is recommended that a monitoring policy be established to report user .netrc file permissions and determine the action to be taken in accordance with site policy.

9.2.10 Check for Presence of User .rhosts Files

While no .rhosts files are shipped with RHEL6, users can easily create them.

Rationale:

This action is only meaningful if .rhosts support is permitted in the file /etc/pam.conf. Even though the .rhosts files are ineffective if support is disabled in /etc/pam.conf, they may have been brought over from other systems and could contain information useful to an attacker for those other systems.

Audit:

#!/bin/bash for dir in `/bin/cat /etc/passwd | /bin/egrep -v ‘(root|halt|sync|shutdown)’ |\ /bin/awk -F: ‘($7 != “/sbin/nologin”) { print $6 }’`; do for file in $dir/.rhosts; do if [ ! -h “$file” -a -f “$file” ]; then echo “.rhosts file in $dir” fi done done

Remediation:

If any users have .rhosts files determine why they have them.

9.2.11 Check Groups in /etc/passwd

Over time, system administration errors and changes can lead to groups being defined in /etc/passwd but not in /etc/group.

Rationale:

Groups defined in the /etc/passwd file but not in the /etc/group file pose a threat to system security since group permissions are not properly managed.

Audit:

Create a script as shown below and run it:

#!/bin/bash for i in $(cut -s -d: -f4 /etc/passwd | sort -u ); do grep -q -P “^.*?:x:$i:” /etc/group if [ $? -ne 0 ]; then echo “Group $i is referenced by /etc/passwd but does not exist in /etc/group” fi done

Remediation:

Analyze the output of the Audit step above and perform the appropriate action to correct any discrepancies found.

9.2.12 Check That Users Are Assigned Valid Home Directories

Users can be defined in /etc/passwd without a home directory or with a home directory does not actually exist.

Rationale:

If the user’s home directory does not exist or is unassigned, the user will be placed in “/” and will not be able to write any files or have local environment variables set.

Audit:

This script checks to make sure that home directories assigned in the /etc/passwd file exist.

#!/bin/bash

cat /etc/passwd | awk -F: ‘{ print $1 ” ” $3 ” ” $6 }’ | while read user uid dir; do if [ $uid -ge 500 -a ! -d “$dir” -a $user != “nfsnobody” ]; then echo “The home directory ($dir) of user $user does not exist.” fi done

Remediation:

If any users’ home directories do not exist, create them and make sure the respective user owns the directory. Users without assigned should be removed or assigned a home directory as appropriate.

9.2.13 Check User Home Directory Ownership

The user home directory is space defined for the particular user to set local environment variables and to store personal files.

Rationale:

Since the user is accountable for files stored in the user home directory, the user must be the owner of the directory.

Audit:

This script checks to make sure users own the home directory they are assigned to in the /etc/passwd file.

#!/bin/bash cat /etc/passwd | awk -F: ‘{ print $1 ” ” $3 ” ” $6 }’ | while read user uid dir; do if [ $uid -ge 500 -a -d “$dir” -a $user != “nfsnobody” ]; then owner=$(stat -L -c “%U” “$dir”) if [ “$owner” != “$user” ]; then echo “The home directory ($dir) of user $user is owned by $owner.” fi fi done

Remediation:

Change the ownership any home directories that are not owned by the defined user to the correct user.

9.2.14 Check for Duplicate UIDs

Although the useradd program will not let you create a duplicate User ID (UID), it is possible for an administrator to manually edit the /etc/passwd file and change the UID field.

Rationale:

Users must be assigned unique UIDs for accountability and to ensure appropriate access protections.

Audit:

This script checks to make sure all UIDs in the /etc/passwd file are unique.

#!/bin/bash echo “The Output for the Audit of Control 9.2.15 – Check for Duplicate UIDs is” /bin/cat /etc/passwd | /bin/cut -f3 -d”:” | /bin/sort -n | /usr/bin/uniq -c |\ while read x ; do [ -z “${x}” ] && break set – $x if [ $1 -gt 1 ]; then users=`/bin/gawk -F: ‘($3 == n) { print $1 }’ n=$2 \ /etc/passwd | /usr/bin/xargs` echo “Duplicate UID ($2): ${users}” fi done

Remediation:

Based on the results of the script, establish unique UIDs and review all files owned by the shared UID to determine which UID they are supposed to belong to.

9.2.15 Check for Duplicate GIDs

Although the groupadd program will not let you create a duplicate Group ID (GID), it is possible for an administrator to manually edit the /etc/group file and change the GID field.

Rationale:

User groups must be assigned unique GIDs for accountability and to ensure appropriate access protections.

Note: In the case of extremely large groups it can become necessary to split a GID across group names due to character limits per line. Any such instances should be carefully audited, unless absolutely necessary such instances should be avoided.

Audit:

This script checks to make sure all GIDs in the /etc/group file are unique. You can also use the /usr/sbin/grpck command to check for other inconsistencies in the /etc/group file.

#!/bin/bash echo “The Output for the Audit of Control 9.2.16 – Check for Duplicate GIDs is” /bin/cat /etc/group | /bin/cut -f3 -d”:” | /bin/sort -n | /usr/bin/uniq -c |\ while read x ; do [ -z “${x}” ] && break set – $x if [ $1 -gt 1 ]; then grps=`/bin/gawk -F: ‘($3 == n) { print $1 }’ n=$2 \ /etc/group | xargs` echo “Duplicate GID ($2): ${grps}” fi done

Remediation:

Based on the results of the script, establish unique GIDs and review all files owned by the shared GID to determine which group they are supposed to belong to.

9.2.16 Check for Duplicate User Names

Although the useradd program will not let you create a duplicate user name, it is possible for an administrator to manually edit the /etc/passwd file and change the user name.

Rationale:

If a user is assigned a duplicate user name, it will create and have access to files with the first UID for that username in /etc/passwd. For example, if “test4” has a UID of 1000 and a subsequent “test4” entry has a UID of 2000, logging in as “test4” will use UID 1000.

Effectively, the UID is shared, which is a security problem.

Audit:

This script checks to make sure all user names in the /etc/passwd file are unique.

#!/bin/bash echo “The Output for the Audit of Control 9.2.18 – Check for Duplicate User Names is” cat /etc/passwd | cut -f1 -d”:” | /bin/sort -n | /usr/bin/uniq -c |\ while read x ; do [ -z “${x}” ] && break set – $x if [ $1 -gt 1 ]; then uids=`/bin/gawk -F: ‘($1 == n) { print $3 }’ n=$2 \ /etc/passwd | xargs` echo “Duplicate User Name ($2): ${uids}” fi done

Remediation:

Based on the results of the script, establish unique user names for the users. File ownerships will automatically reflect the change as long as the users have unique UIDs.

9.2.17 Check for Duplicate Group Names

Although the groupadd program will not let you create a duplicate group name, it is possible for an administrator to manually edit the /etc/group file and change the group name.

Rationale:

If a group is assigned a duplicate group name, it will create and have access to files with the first GID for that group in /etc/group. Effectively, the GID is shared, which is a security problem.

Audit:

This script checks to make sure all group names in the /etc/group file are unique.

#!/bin/bash echo “The Output for the Audit of Control 9.2.19 – Check for Duplicate Group Names is” cat /etc/group | cut -f1 -d”:” | /bin/sort -n | /usr/bin/uniq -c |\ while read x ; do [ -z “${x}” ] && break set – $x if [ $1 -gt 1 ]; then gids=`/bin/gawk -F: ‘($1 == n) { print $3 }’ n=$2 \ /etc/group | xargs` echo “Duplicate Group Name ($2): ${gids}” fi done

Remediation:

Based on the results of the script, establish unique names for the user groups. File group ownerships will automatically reflect the change as long as the groups have unique GIDs.

9.2.18 Check for Presence of User .netrc Files

The .netrc file contains data for logging into a remote host for file transfers via FTP.

Rationale:

The .netrc file presents a significant security risk since it stores passwords in unencrypted form. Even if FTP is disabled, user accounts may have brought over .netrc files from other systems which could pose a risk to those systems.

Audit:

#!/bin/bash for dir in `/bin/cat /etc/passwd |\ /bin/awk -F: ‘{ print $6 }’`; do if [ ! -h “$dir/.netrc” -a -f “$dir/.netrc” ]; then echo “.netrc file $dir/.netrc exists” fi done

Remediation:

Making global modifications to users’ files without alerting the user community can result in unexpected outages and unhappy users. Therefore, it is recommended that a monitoring policy be established to report user .netrc files and determine the action to be taken in accordance with site policy.

9.2.19 Check for Presence of User .forward Files

The .forward file specifies an email address to forward the user’s mail to.

Rationale:

Use of the .forward file poses a security risk in that sensitive data may be inadvertently transferred outside the organization. The .forward file also poses a risk as it can be used to execute commands that may perform unintended actions.

Audit:

This script checks for the presence of .forward files that may be in violation of the site security policy.

#!/bin/bash

for dir in `/bin/cat /etc/passwd |\ /bin/awk -F: ‘{ print $6 }’`; do

if [ ! -h “$dir/.forward” -a -f “$dir/.forward” ]; then echo “.forward file $dir/.forward exists” fi done

Remediation:

Making global modifications to users’ files without alerting the user community can result in unexpected outages and unhappy users. Therefore, it is recommended that a monitoring policy be established to report user .forward files and determine the action to be taken in accordance with site policy.