## Guide to the Secure Configuration of Red Hat Enterprise Linux 5

> with profile Upstream STIG for Red Hat Enterprise Linux 5 Server
> This profile is being developed under the DoD consensus model to become a STIG in coordination with DISA FSO.

The SCAP Security Guide Project
https://www.open-scap.org/security-policies/scap-security-guide
This guide presents a catalog of security-relevant configuration settings for Red Hat Enterprise Linux 5. It is a rendering of content structured in the eXtensible Configuration Checklist Description Format (XCCDF) in order to support security automation. The SCAP content is is available in the `scap-security-guide` package which is developed at https://www.open-scap.org/security-policies/scap-security-guide.
Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG for Red Hat Enterprise Linux 5, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance.

This benchmark is a direct port of a SCAP Security Guide benchmark developed for Red Hat Enterprise Linux. It has been modified through an automated process to remove specific dependencies on Red Hat Enterprise Linux and to function with CentOS. The result is a generally useful SCAP Security Guide benchmark with the following caveats:

- CentOS is not an exact copy of Red Hat Enterprise Linux. There may be configuration differences that produce false positives and/or false negatives. If this occurs please file a bug report.
- CentOS has its own build system, compiler options, patchsets, and is a community supported, non-commercial operating system. CentOS does not inherit certifications or evaluations from Red Hat Enterprise Linux. As such, some configuration rules (such as those requiring FIPS 140-2 encryption) will continue to fail on CentOS.

Members of the CentOS community are invited to participate in OpenSCAP and SCAP Security Guide development. Bug reports and patches can be sent to GitHub: https://github.com/OpenSCAP/scap-security-guide. The mailing list is at https://fedorahosted.org/mailman/listinfo/scap-security-guide.

Do not attempt to implement any of the settings in this guide without first testing them in a non-operational environment. The creators of this guidance assume no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic.

Profile Title | Upstream STIG for Red Hat Enterprise Linux 5 Server
Profile ID | xccdf_org.ssgproject.content_profile_stig-rhel5-server-upstream

## Revision History

Current version: 0.1.31

- draft (as of 2017-08-11)

## Platforms

- cpe:/o:redhat:enterprise_linux:4
- cpe:/o:centos:centos:4
- cpe:/o:redhat:enterprise_linux:5
- cpe:/o:centos:centos:5

## Table of Contents

1. System Settings

1. Installing and Maintaining Software
2. File Permissions and Masks
3. SELinux
4. Account and Access Control
5. Network Configuration and Firewalls
6. Configure Syslog
7. System Accounting with auditd

2. Services

1. Obsolete Services
2. Base Services
3. Cron and At Daemons
4. SSH Server
5. X Window System
6. DHCP
7. Network Time Protocol
8. Mail Server Software
9. LDAP
10. NFS and RPC
11. FTP Server
12. Samba(SMB) Microsoft Windows File Sharing Server
13. SNMP Server

## Checklist

contains 456 rules

### System Settings [ref]group

Contains rules that check correct system settings.

contains 370 rules

### Installing and Maintaining Software [ref]group

The following sections contain information on security-relevant choices during the initial operating system installation process and the setup of software updates.

contains 12 rules

### Disk Partitioning [ref]group

To ensure separation and protection of data, there are top-level system directories which should be placed on their own physical partition or logical volume. The installer's default partitioning scheme creates separate 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.

contains 4 rules

#### Ensure /tmp Located On Separate Partition [ref]rule

The `/tmp` directory is a world-writable directory used for temporary file storage. Ensure it has its own partition or logical volume at installation time, or migrate it using LVM.

Rationale:

The `/tmp` partition is used as temporary storage by many programs. Placing `/tmp` in its own partition enables the setting of more restrictive mount options, which can help protect programs which use it.

Severity: low

Identifiers: GEN003624

References: ECSC-1, 1208

#### Ensure /var Located On Separate Partition [ref]rule

The `/var` directory is used by daemons and other system services to store frequently-changing data. Ensure that `/var` has its own partition or logical volume at installation time, or migrate it using LVM.

Rationale:

Ensuring that `/var` is mounted on its own partition enables the setting of more restrictive mount options. This helps protect system services such as daemons or other programs which use it. It is not uncommon for the `/var` directory to contain world-writable directories, installed by other software packages.

Severity: low

Identifiers: GEN003621

References: ECSC-1, 1208

#### Ensure /var/log/audit Located On Separate Partition [ref]rule

Audit logs are stored in the `/var/log/audit` directory. Ensure that it has its own partition or logical volume at installation time, or migrate it later using LVM. Make absolutely certain that it is large enough to store all audit logs that will be created by the auditing daemon.

Rationale:

Placing `/var/log/audit` in its own partition enables better separation between audit files and other files, and helps ensure that auditing cannot be halted due to the partition running out of space.

Severity: low

Identifiers: GEN003623

References: ECSC-1, 1208

#### Ensure /home Located On Separate Partition [ref]rule

If user home directories will be stored locally, create a separate partition for `/home` at installation time (or migrate it later using LVM). If `/home` will be mounted from another system such as an NFS server, then creating a separate partition is not necessary at installation time, and the mountpoint can instead be configured later.

Rationale:

Ensuring that `/home` is mounted on its own partition enables the setting of more restrictive mount options, and also helps ensure that users cannot trivially fill partitions used for log or audit data storage.

Severity: low

Identifiers: GEN003620

References: ECSC-1, 1208

### Updating Software [ref]group

The `yum` command line tool is used to install and update software packages. The system also provides a graphical software update tool in the System menu, in the Administration submenu, called Software Update.
Red Hat Enterprise Linux systems contain an installed software catalog called the RPM database, which records metadata of installed packages. Consistently using `yum` or the graphical Software Update for all software installation allows for insight into the current inventory of installed software on the system.

contains 1 rule

#### Ensure gpgcheck Enabled For All Yum Package Repositories [ref]rule

To ensure signature checking is not disabled for any repos, remove any lines from files in `/etc/yum.repos.d` of the form:

    gpgcheck=0

Rationale:

Ensuring all packages' cryptographic signatures are valid prior to installation ensures the authenticity of the software and protects against malicious tampering.

Severity: low

Identifiers: GEN008800

References: ECSC-1, 351

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    grep -R gpgcheck /etc/yum.repos.d/* /etc/yum.conf /root/rpmrc /usr/lib/rpm/redhat/rpmrc /usr/lib/rpm/rpmrc /etc/rpmrc 2>/dev/null | grep -v 'gpgcheck=1' | cut -d: -f1 | sort -u | while read YUM_FILE; do
    	sed -i 's/gpgcheck=.*/gpgcheck=1/g' ${YUM_FILE}
    done

### Software Integrity Checking [ref]group

Both the AIDE (Advanced Intrusion Detection Environment) software and the RPM package management system provide mechanisms for verifying the integrity of installed software. AIDE uses snapshots of file metadata (such as hashes) and compares these to current system files in order to detect changes. The RPM package management system can conduct integrity checks by comparing information in its metadata database with files installed on the system.
Integrity checking cannot prevent intrusions, but can detect that they have occurred. Requirements for software integrity checking may be highly dependent on the environment in which the system will be used. Snapshot-based approaches such as AIDE may induce considerable overhead in the presence of frequent software updates.

contains 7 rules

### Verify Integrity with AIDE [ref]group

AIDE conducts integrity checks by comparing information about files with previously-gathered information. Ideally, the AIDE database is created immediately after initial system configuration, and then again after any software update. AIDE is highly configurable, with further configuration information located in `/usr/share/doc/aide-VERSION`.

contains 2 rules

#### Build and Test AIDE Database [ref]rule

Run the following command to generate a new database:

    # /usr/sbin/aide --init

By default, the database will be written to the file `/var/lib/aide/aide.db.new.gz`. Storing the database, the configuration file `/etc/aide.conf`, and the binary `/usr/sbin/aide` (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity. The newly-generated database can be installed as follows:

    # cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

To initiate a manual check, run the following command:

    # /usr/sbin/aide --check

If this check produces any unexpected output, investigate. Rationale:

For AIDE to be effective, an initial database of "known-good" information about files must be captured and it should be able to be verified against the installed files.

Severity: low

Identifiers: GEN000140-2

References: DCSW-1, 293

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    /usr/sbin/aide --init
    /bin/cp -p /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

#### Configure Periodic Execution of AIDE [ref]rule

To implement a daily execution of AIDE at 4:05am using cron, add the following line to `/etc/crontab`:

    05 4 * * * root /usr/sbin/aide --check

AIDE can be executed periodically through other means; this is merely one example. Rationale:

By default, AIDE does not install itself for periodic execution. Periodically running AIDE is necessary to reveal unexpected changes in installed files.

Severity: medium

Identifiers: GEN000220

References: DCSL-1, 1069

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    echo "/usr/sbin/aide --config=/etc/aide.conf --check" > /etc/cron.weekly/aide
    chmod 700 /etc/cron.weekly/aide

### Additional Security Software [ref]group

Additional security software that is not provided or supported by Red Hat can be installed to provide complementary or duplicative security capabilities to those provided by the base platform. Add-on software may not be appropriate for some specialized systems.

contains 5 rules

#### Install Intrusion Detection Software [ref]rule

The Red Hat platform includes a sophisticated auditing system and SELinux, which provide host-based intrusion detection capabilities.

Rationale:

Host-based intrusion detection tools provide a system-level defense when an intruder gains access to a system or network.

Severity: medium

Identifiers: GEN006480

References: ECID-1, 1259

#### Install Virus Scanning Software [ref]rule

Install virus scanning software, which uses signatures to search for the presence of viruses on the filesystem. The McAfee uvscan virus scanning tool is provided for DoD systems. Ensure virus definition files are no older than 7 days, or their last release. Configure the virus scanning software to perform scans dynamically on all accessed files. If this is not possible, configure the system to scan all altered files on the system on a daily basis. If the system processes inbound SMTP mail, configure the virus scanner to scan all received mail.

Rationale:

Virus scanning software can be used to detect if a system has been compromised by computer viruses, as well as to limit their spread to other systems.

Severity: low

Identifiers: GEN006640

References: ECVP-1, 1668

#### Create a Baseline For Device Files [ref]rule

A baseline of device files needs to be generated, and verified on at least a weekly basis.

Rationale:

If an unauthorized device is allowed to exist on the system, there is the possibility the system may perform unauthorized operations.

Severity: low

Identifiers: GEN002260

References: DCSW-1, ECSC-1, 318

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    # Generate a device file baseline
    find / -type b -o -type c 2>/dev/null | sort  > /var/log/device-file-list
    chmod 640 /var/log/device-file-list
    chown root:root /var/log/device-file-list

    # Generate a weekly cron job to check the device file baseline and report differences
    cat > /etc/cron.weekly/baseline_checker.sh <<'STOP_HERE'
    #!/bin/sh
    echo "Baseline check started on $(date +"%m-%d-%Y") at $(date +"%H:%M:%S")" | tee -a /var/log/baseline.log
    echo -e \\n | tee -a /var/log/baseline.log
    echo "Gathering current baseline." | tee -a /var/log/baseline.log
    echo -e \\n | tee -a /var/log/baseline.log
    rm -f /tmp/*BASELINE.tmp /tmp/*list.tmp
    find / -perm -4000 2>/dev/null | sort > /tmp/suid-file-list.tmp
    find / -perm -2000 2>/dev/null | sort > /tmp/sgid-file-list.tmp
    find / -type b -o -type c 2>/dev/null | sort  > /tmp/device-file-list.tmp
    echo "Comparing the current baseline with the last known good configuration." | tee -a /var/log/baseline.log
    echo -e \\n | tee -a /var/log/baseline.log
    diff /var/log/suid-file-list /tmp/suid-file-list.tmp > /tmp/SUID_BASELINE.tmp
    diff /var/log/sgid-file-list /tmp/sgid-file-list.tmp > /tmp/SGID_BASELINE.tmp
    diff /var/log/device-file-list /tmp/device-file-list.tmp > /tmp/DEVICE_BASELINE.tmp
    if [ -s /tmp/SUID_BASELINE.tmp ]; then
       if [ $(grep -c "^>" /tmp/SUID_BASELINE.tmp) != 0 ]; then
    		echo "The following files were detected to have the suid bit added:" | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    		grep "^>" /tmp/SUID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    	fi
    	if [ $(grep -c "^<" /tmp/SUID_BASELINE.tmp) != 0 ]; then
    		echo "The following files were detected to have the suid bit removed:" | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    		grep "^<" /tmp/SUID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    	fi
    fi
    if [ -s /tmp/SGID_BASELINE.tmp ]; then
       if [ $(grep -c "^>" /tmp/SGID_BASELINE.tmp) != 0 ]; then
    		echo "The following files were detected to have the sgid bit added:" | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    		grep "^>" /tmp/SGID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    	fi
    	if [ $(grep -c "^<" /tmp/SGID_BASELINE.tmp) != 0 ]; then
    		echo "The following files were detected to have the sgid bit removed:" | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    		grep "^<" /tmp/SGID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    	fi
    fi
    if [ -s /tmp/DEVICE_BASELINE.tmp ]; then
       if [ $(grep -c "^>" /tmp/DEVICE_BASELINE.tmp) != 0 ]; then
    		echo "The following device files were detected to have been added:" | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    		grep "^>" /tmp/DEVICE_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    	fi
    	if [ $(grep -c "^<" /tmp/DEVICE_BASELINE.tmp) != 0 ]; then
    		echo "The following device files were detected to have removed:" | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    		grep "^<" /tmp/DEVICE_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    	fi
    fi
    rm -f /tmp/*BASELINE.tmp /tmp/*list.tmp
    echo "Baseline check completed on $(date +"%m-%d-%Y") at $(date +"%H:%M:%S")" | tee -a /var/log/baseline.log
    echo -e \\n | tee -a /var/log/baseline.log
    echo "####################################################################" | tee -a /var/log/baseline.log
    echo -e \\n | tee -a /var/log/baseline.log
    chmod 640 /var/log/baseline.log
    chown root:root /var/log/baseline.log
    STOP_HERE
    chmod 700 /etc/cron.weekly/baseline_checker.sh
    chown root:root /etc/cron.weekly/baseline_checker.sh

#### Create a Baseline For SGID Files [ref]rule

A baseline of sgid files needs to be generated, and verified on at least a weekly basis.

Rationale:

Files with the setgid bit set will allow anyone running these files to be temporarily assigned the group id of the file. While many system files depend on these attributes for proper operation, security problems can result if setgid is assigned to programs allowing reading and writing of files, or shell escapes.

Severity: medium

Identifiers: GEN002460

References: DCSL-1, 318

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    # Generate a sgid file baseline
    find / -perm -2000 -type f  2>/dev/null | sort > /var/log/sgid-file-list
    chmod 640 /var/log/sgid-file-list
    chown root:root /var/log/sgid-file-list

    # Generate a weekly cron job to check the sgid file baseline and report differences
    cat > /etc/cron.weekly/baseline_checker.sh <<'STOP_HERE'
    #!/bin/sh
    echo "Baseline check started on $(date +"%m-%d-%Y") at $(date +"%H:%M:%S")" | tee -a /var/log/baseline.log
    echo -e \\n | tee -a /var/log/baseline.log
    echo "Gathering current baseline." | tee -a /var/log/baseline.log
    echo -e \\n | tee -a /var/log/baseline.log
    rm -f /tmp/*BASELINE.tmp /tmp/*list.tmp
    find / -perm -4000 2>/dev/null | sort > /tmp/suid-file-list.tmp
    find / -perm -2000 2>/dev/null | sort > /tmp/sgid-file-list.tmp
    find / -type b -o -type c 2>/dev/null | sort  > /tmp/device-file-list.tmp
    echo "Comparing the current baseline with the last known good configuration." | tee -a /var/log/baseline.log
    echo -e \\n | tee -a /var/log/baseline.log
    diff /var/log/suid-file-list /tmp/suid-file-list.tmp > /tmp/SUID_BASELINE.tmp
    diff /var/log/sgid-file-list /tmp/sgid-file-list.tmp > /tmp/SGID_BASELINE.tmp
    diff /var/log/device-file-list /tmp/device-file-list.tmp > /tmp/DEVICE_BASELINE.tmp
    if [ -s /tmp/SUID_BASELINE.tmp ]; then
       if [ $(grep -c "^>" /tmp/SUID_BASELINE.tmp) != 0 ]; then
    		echo "The following files were detected to have the suid bit added:" | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    		grep "^>" /tmp/SUID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    	fi
    	if [ $(grep -c "^<" /tmp/SUID_BASELINE.tmp) != 0 ]; then
    		echo "The following files were detected to have the suid bit removed:" | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    		grep "^<" /tmp/SUID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    	fi
    fi
    if [ -s /tmp/SGID_BASELINE.tmp ]; then
       if [ $(grep -c "^>" /tmp/SGID_BASELINE.tmp) != 0 ]; then
    		echo "The following files were detected to have the sgid bit added:" | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    		grep "^>" /tmp/SGID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    	fi
    	if [ $(grep -c "^<" /tmp/SGID_BASELINE.tmp) != 0 ]; then
    		echo "The following files were detected to have the sgid bit removed:" | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    		grep "^<" /tmp/SGID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    	fi
    fi
    if [ -s /tmp/DEVICE_BASELINE.tmp ]; then
       if [ $(grep -c "^>" /tmp/DEVICE_BASELINE.tmp) != 0 ]; then
    		echo "The following device files were detected to have been added:" | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    		grep "^>" /tmp/DEVICE_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    	fi
    	if [ $(grep -c "^<" /tmp/DEVICE_BASELINE.tmp) != 0 ]; then
    		echo "The following device files were detected to have removed:" | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    		grep "^<" /tmp/DEVICE_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    	fi
    fi
    rm -f /tmp/*BASELINE.tmp /tmp/*list.tmp
    echo "Baseline check completed on $(date +"%m-%d-%Y") at $(date +"%H:%M:%S")" | tee -a /var/log/baseline.log
    echo -e \\n | tee -a /var/log/baseline.log
    echo "####################################################################" | tee -a /var/log/baseline.log
    echo -e \\n | tee -a /var/log/baseline.log
    chmod 640 /var/log/baseline.log
    chown root:root /var/log/baseline.log
    STOP_HERE
    chmod 700 /etc/cron.weekly/baseline_checker.sh
    chown root:root /etc/cron.weekly/baseline_checker.sh

#### Create a Baseline For SUID Files [ref]rule

A baseline of suid files needs to be generated, and verified on at least a weekly basis.

Rationale:

Files with the setuid bit set will allow anyone running these files to be temporarily assigned the UID of the file. While many system files depend on these attributes for proper operation, security problems can result if setuid is assigned to programs allowing reading and writing of files, or shell escapes.

Severity: medium

Identifiers: GEN002400

References: DCSL-1, 318

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    # Generate a suid file baseline
    find / -perm -4000 -type f 2>/dev/null | sort > /var/log/suid-file-list
    chmod 640 /var/log/suid-file-list
    chown root:root /var/log/suid-file-list

    # Generate a weekly cron job to check the suid file baseline and report differences
    cat > /etc/cron.weekly/baseline_checker.sh <<'STOP_HERE'
    #!/bin/sh
    echo "Baseline check started on $(date +"%m-%d-%Y") at $(date +"%H:%M:%S")" | tee -a /var/log/baseline.log
    echo -e \\n | tee -a /var/log/baseline.log
    echo "Gathering current baseline." | tee -a /var/log/baseline.log
    echo -e \\n | tee -a /var/log/baseline.log
    rm -f /tmp/*BASELINE.tmp /tmp/*list.tmp
    find / -perm -4000 2>/dev/null | sort > /tmp/suid-file-list.tmp
    find / -perm -2000 2>/dev/null | sort > /tmp/sgid-file-list.tmp
    find / -type b -o -type c 2>/dev/null | sort  > /tmp/device-file-list.tmp
    echo "Comparing the current baseline with the last known good configuration." | tee -a /var/log/baseline.log
    echo -e \\n | tee -a /var/log/baseline.log
    diff /var/log/suid-file-list /tmp/suid-file-list.tmp > /tmp/SUID_BASELINE.tmp
    diff /var/log/sgid-file-list /tmp/sgid-file-list.tmp > /tmp/SGID_BASELINE.tmp
    diff /var/log/device-file-list /tmp/device-file-list.tmp > /tmp/DEVICE_BASELINE.tmp
    if [ -s /tmp/SUID_BASELINE.tmp ]; then
       if [ $(grep -c "^>" /tmp/SUID_BASELINE.tmp) != 0 ]; then
    		echo "The following files were detected to have the suid bit added:" | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    		grep "^>" /tmp/SUID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    	fi
    	if [ $(grep -c "^<" /tmp/SUID_BASELINE.tmp) != 0 ]; then
    		echo "The following files were detected to have the suid bit removed:" | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    		grep "^<" /tmp/SUID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    	fi
    fi
    if [ -s /tmp/SGID_BASELINE.tmp ]; then
       if [ $(grep -c "^>" /tmp/SGID_BASELINE.tmp) != 0 ]; then
    		echo "The following files were detected to have the sgid bit added:" | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    		grep "^>" /tmp/SGID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    	fi
    	if [ $(grep -c "^<" /tmp/SGID_BASELINE.tmp) != 0 ]; then
    		echo "The following files were detected to have the sgid bit removed:" | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    		grep "^<" /tmp/SGID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    	fi
    fi
    if [ -s /tmp/DEVICE_BASELINE.tmp ]; then
       if [ $(grep -c "^>" /tmp/DEVICE_BASELINE.tmp) != 0 ]; then
    		echo "The following device files were detected to have been added:" | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    		grep "^>" /tmp/DEVICE_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    	fi
    	if [ $(grep -c "^<" /tmp/DEVICE_BASELINE.tmp) != 0 ]; then
    		echo "The following device files were detected to have removed:" | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    		grep "^<" /tmp/DEVICE_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log
    		echo -e \\n | tee -a /var/log/baseline.log
    	fi
    fi
    rm -f /tmp/*BASELINE.tmp /tmp/*list.tmp
    echo "Baseline check completed on $(date +"%m-%d-%Y") at $(date +"%H:%M:%S")" | tee -a /var/log/baseline.log
    echo -e \\n | tee -a /var/log/baseline.log
    echo "####################################################################" | tee -a /var/log/baseline.log
    echo -e \\n | tee -a /var/log/baseline.log
    chmod 640 /var/log/baseline.log
    chown root:root /var/log/baseline.log
    STOP_HERE
    chmod 700 /etc/cron.weekly/baseline_checker.sh
    chown root:root /etc/cron.weekly/baseline_checker.sh

### File Permissions and Masks [ref]group

Traditional Unix security relies heavily on file and directory permissions to prevent unauthorized users from reading or modifying files to which they should not have access.
Several of the commands in this section search filesystems for files or directories with certain characteristics, and are intended to be run on every local partition on a given system. When the variable PART appears in one of the commands below, it means that the command is intended to be run repeatedly, with the name of each local partition substituted for PART in turn.
The following command prints a list of all xfs partitions on the local system, which is the default filesystem for Red Hat Enterprise Linux 7 installations:

    $ mount -t xfs | awk '{print $3}'

For any systems that use a different local filesystem type, modify this command as appropriate.

contains 235 rules

### Restrict Partition Mount Options [ref]group

System partitions can be mounted with certain options that limit what files on those partitions can do. These options are set in the `/etc/fstab` configuration file, and can be used to make certain types of malicious behavior more difficult.

contains 2 rules

#### Add nodev Option to Removable Media Partitions [ref]rule

The `nodev` mount option prevents files from being interpreted as character or block devices. Legitimate character and block devices should exist only in the `/dev` directory on the root partition or within chroot jails built for system services. Add the `nodev` option to the fourth column of `/etc/fstab` for the line which controls mounting of any removable media partitions.

Rationale:

The only legitimate location for device files is the `/dev` directory located on the root partition. An exception to this is chroot jails, and it is not advised to set `nodev` on partitions which contain their root filesystems.

Severity: low

Identifiers: GEN002430

References: ECSC-1, 366

#### Add nosuid Option to Removable Media Partitions [ref]rule

The `nosuid` mount option prevents set-user-identifier (suid) and set-group-identifier (sgid) permissions from taking effect. These permissions allow users to execute binaries with the same permissions as the owner and group of the file respectively. Users should not be allowed to introduce suid and guid files into the system via partitions mounted from removeable media. Add the `nosuid` option to the fourth column of `/etc/fstab` for the line which controls mounting of any removable media partitions.

Rationale:

The presence of suid and sgid executables should be tightly controlled. Allowing users to introduce suid or sgid binaries from partitions mounted off of removable media would allow them to introduce their own highly-privileged programs.

Severity: low

Identifiers: GEN002420

References: ECLP-1, 225

### Restrict Dynamic Mounting and Unmounting of Filesystems [ref]group

Linux includes a number of facilities for the automated addition and removal of filesystems on a running system. These facilities may be necessary in many environments, but this capability also carries some risk -- whether direct risk from allowing users to introduce arbitrary filesystems, or risk that software flaws in the automated mount facility itself could allow an attacker to compromise the system.
This command can be used to list the types of filesystems that are available to the currently executing kernel:

    # find /lib/modules/`uname -r`/kernel/fs -type f -name '*.ko'

If these filesystems are not required then they can be explicitly disabled in a configuratio file in `/etc/modprobe.d`.

contains 3 rules

#### Disable Modprobe Loading of USB Storage Driver [ref]rule

To prevent USB storage devices from being used, configure the kernel module loading system to prevent automatic loading of the USB storage driver. To configure the system to prevent the `usb-storage` kernel module from being loaded, add the following line to a file in the directory `/etc/modprobe.d`:

    install usb-storage /bin/true

This will prevent the `modprobe` program from loading the `usb-storage` module, but will not prevent an administrator (or another program) from using the `insmod` program to load the module manually.Rationale:

USB storage devices such as thumb drives can be used to introduce malicious software.

Severity: low

Identifiers: GEN008480

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | medium
Reboot: | true
Strategy: | disable

    if [ -d /etc/modprobe.d/ ]; then
    	echo "install usb-storage /bin/true" >> /etc/modprobe.d/disabled_modules.conf
    else
    	echo "install usb-storage /bin/true" >> /etc/modprobe.conf
    fi

#### Disable Kernel Support for USB via Bootloader Configuration [ref]rule

All USB support can be disabled by adding the `nousb` argument to the kernel's boot loader configuration. To do so, append "nousb" to the kernel line in `/etc/grub.conf` as shown:

    kernel /vmlinuz-VERSION ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet nousb

WARNING: Disabling all kernel support for USB will cause problems for systems with USB-based keyboards, mice, or printers. This configuration is infeasible for systems which require USB devices, which is common.Rationale:

Disabling the USB subsystem within the Linux kernel at system boot will protect against potentially malicious USB devices, although it is only practical in specialized systems.

Severity: low

Identifiers: GEN008460

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    USB_KEYBOARD=$(grep 'Product=' /proc/bus/usb/devices 2>/dev/null| egrep -ic '(ps2 to usb adapter|keyboard|kvm|sc reader)')
    if [ "${USB_KEYBOARD}" = "0" ]; then
    	sed -i '/^[ |\t]*kernel/s/$/ nousb/' /boot/grub/grub.conf
    # else
    	# A USB keyboard was detected so this fix has been skipped.
    fi

#### Disable the Automounter [ref]rule

The `autofs` daemon mounts and unmounts filesystems, such as user home directories shared via NFS, on demand. In addition, autofs can be used to handle removable media, and the default configuration provides the cdrom device as `/misc/cd`. However, this method of providing access to removable media is not common, so autofs can almost always be disabled if NFS is not in use. Even if NFS is required, it may be possible to configure filesystem mounts statically by editing `/etc/fstab` rather than relying on the automounter.
The `autofs` service can be disabled with the following command:

    $ sudo chkconfig autofs off

Rationale:

Disabling the automounter permits the administrator to statically control filesystem mounting through `/etc/fstab`.

Severity: low

Identifiers: GEN008440

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | medium
Reboot: | true
Strategy: | disable

    #
    # Disable autofs for all run levels
    #
    /sbin/chkconfig --level 0123456 autofs off

    #
    # Stop autofs if currently running
    #
    /sbin/service autofs stop 1>/dev/null

### Verify Permissions on Important Files and Directories [ref]group

Permissions for many files on a system must be set restrictively to ensure sensitive information is properly protected. This section discusses important permission restrictions which can be verified to ensure that no harmful discrepancies have arisen.

contains 227 rules

### Verify Permissions on Files with Local Account Information and Credentials [ref]group

The default restrictive permissions for files which act as important security databases such as `passwd`, `shadow`, `group`, and `gshadow` files must be maintained. 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.

contains 15 rules

#### Verify User Who Owns shadow File [ref]rule

To properly set the owner of `/etc/shadow`, run the command:

    $ sudo chown root /etc/shadow

Rationale:

The `/etc/shadow` file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture.

Severity: medium

Identifiers: GEN001400

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/shadow

#### Verify Permissions on shadow File [ref]rule

To properly set the permissions of `/etc/shadow`, run the command:

    $ sudo chmod 0400 /etc/shadow

Rationale:

The `/etc/shadow` file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture.

Severity: medium

Identifiers: GEN001420

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0400 /etc/shadow

#### Verify Extended ACLs on shadow File [ref]rule

No extended ACLs should be applied.

Rationale:

The `/etc/shadow` file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture.

Severity: medium

Identifiers: GEN001430

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/shadow

#### Verify User Who Owns group File [ref]rule

To properly set the owner of `/etc/group`, run the command:

    $ sudo chown root /etc/group

Rationale:

The `/etc/group` file contains information regarding groups that are configured on the system. Protection of this file is important for system security.

Severity: medium

Identifiers: GEN001391

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    chown root /etc/group

#### Verify Group Who Owns group File [ref]rule

To properly set the group owner of `/etc/group`, run the command:

    $ sudo chgrp root /etc/group

Rationale:

The `/etc/group` file contains information regarding groups that are configured on the system. Protection of this file is important for system security.

Severity: medium

Identifiers: GEN001392

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    chgrp root /etc/group

#### Verify Permissions on group File [ref]rule

To properly set the permissions of `/etc/group`, run the command:

    $ sudo chmod 644 /etc/group

Rationale:

The `/etc/group` file contains information regarding groups that are configured on the system. Protection of this file is important for system security.

Severity: medium

Identifiers: GEN001393

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    chmod 0644 /etc/group

#### Verify Extended ACLs on group File [ref]rule

No extended ACLs should be applied.

Rationale:

The `/etc/group` file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture.

Severity: medium

Identifiers: GEN001394

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/group

#### Verify User Who Owns gshadow File [ref]rule

To properly set the owner of `/etc/gshadow`, run the command:

    $ sudo chown root /etc/gshadow

Rationale:

The `/etc/gshadow` file contains group password hashes. Protection of this file is critical for system security.

Severity: medium

Identifiers: GEN000000-LNX001431

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    chown root /etc/gshadow

#### Verify Group Who Owns gshadow File [ref]rule

To properly set the group owner of `/etc/gshadow`, run the command:

    $ sudo chgrp root /etc/gshadow

Rationale:

The `/etc/gshadow` file contains group password hashes. Protection of this file is critical for system security.

Severity: medium

Identifiers: GEN000000-LNX001432

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    chgrp root /etc/gshadow

#### Verify Permissions on gshadow File [ref]rule

To properly set the permissions of `/etc/gshadow`, run the command:

    $ sudo chmod 0400 /etc/gshadow

Rationale:

The `/etc/gshadow` file contains group password hashes. Protection of this file is critical for system security.

Severity: medium

Identifiers: GEN000000-LNX001433

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    chmod 0400 /etc/gshadow

#### Verify Extended ACLs on gshadow File [ref]rule

No extended ACLs should be applied.

Rationale:

The `/etc/gshadow` file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture.

Severity: medium

Identifiers: GEN000000-LNX001434

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/gshadow

#### Verify User Who Owns passwd File [ref]rule

To properly set the owner of `/etc/passwd`, run the command:

    $ sudo chown root /etc/passwd

Rationale:

The `/etc/passwd` file contains information about the users that are configured on the system. Protection of this file is critical for system security.

Severity: medium

Identifiers: GEN001378

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    chown root /etc/passwd

#### Verify Group Who Owns passwd File [ref]rule

To properly set the group owner of `/etc/passwd`, run the command:

    $ sudo chgrp root /etc/passwd

Rationale:

The `/etc/passwd` file contains information about the users that are configured on the system. Protection of this file is critical for system security.

Severity: medium

Identifiers: GEN001379

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    chgrp root /etc/passwd

#### Verify Permissions on passwd File [ref]rule

To properly set the permissions of `/etc/passwd`, run the command:

    $ sudo chmod 0644 /etc/passwd

Rationale:

If the `/etc/passwd` file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the list of accounts on the system and associated information, and protection of this file is critical for system security.

Severity: medium

Identifiers: GEN001380

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    chmod 0644 /etc/passwd

#### Verify Extended ACLs on passwd File [ref]rule

No extended ACLs should be applied.

Rationale:

The `/etc/passwd` file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture.

Severity: medium

Identifiers: GEN001390

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/passwd

### Verify File Permissions Within Some Important Directories [ref]group

Some directories contain files whose confidentiality or integrity is notably important and may also be susceptible to misconfiguration over time, particularly if unpackaged software is installed. As such, an argument exists to verify that files' permissions within these directories remain configured correctly and restrictively.

contains 6 rules

#### Verify that Shared Library Files Have Restrictive Permissions [ref]rule

System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default:

    /lib
    /lib64
    /usr/lib
    /usr/lib64

Kernel modules, which can be added to the kernel during runtime, are stored in `/lib/modules`. All files in these directories should not be group-writable or world-writable. If any file in these directories is found to be group-writable or world-writable, correct its permission with the following command:

    # chmod go-w FILE

Rationale:

Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Restrictive permissions are necessary to protect the integrity of the system.

Severity: medium

Identifiers: GEN001300

References: DCSL-1, 1499

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    find /lib /usr/lib -follow -perm -20 -o -perm -2 2>/dev/null | xargs chmod go-w

#### Verify Extended ACLs on Shared Library Files [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN001310

References: ECLP-1, 1499

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl -RLb --remove-all /usr/lib/* /lib/*

#### Verify that System Executables Have Restrictive Permissions [ref]rule

System executables are stored in the following directories by default:

    /bin
    /sbin
    /usr/bin
    /usr/libexec
    /usr/local/bin
    /usr/local/sbin
    /usr/sbin

All files in these directories should not be group-writable or world-writable. If any file FILE in these directories is found to be group-writable or world-writable, correct its permission with the following command:

    # chmod go-w FILE

Rationale:

System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted.

Severity: medium

Identifiers: GEN001200

References: ECLP-1, 1499

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    find /etc /bin /usr/bin /usr/lbin /usr/usb /sbin /usr/sbin -follow -perm -20 -o -perm -2 2>/dev/null | xargs chmod go-w

#### Verify Extended ACLs on Shared Binary Files [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN001210

References: ECLP-1, 1499

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl -RLb /etc /bin /usr/bin /usr/lbin /usr/usb /sbin /usr/sbin 2>/dev/null

#### Verify that System Executables Have Root User Ownership [ref]rule

System executables are stored in the following directories by default:

    /bin
    /sbin
    /usr/bin
    /usr/libexec
    /usr/local/bin
    /usr/local/sbin
    /usr/sbin

All files in these directories should be owned by the `root` user. If any file FILE in these directories is found to be owned by a user other than root, correct its ownership with the following command:

    # chown root FILE

Rationale:

System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted.

Severity: medium

Identifiers: GEN001220

References: ECLP-1, 1499

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    find /bin/ \
    /usr/bin/ \
    /usr/local/bin/ \
    /sbin/ \
    /usr/sbin/ \
    /usr/local/sbin/ \
    /usr/libexec \
    \! -user root -execdir chown root {} \;

#### Verify that System Executables Have Root Group Ownership [ref]rule

System executables are stored in the following directories by default:

    /bin
    /sbin
    /usr/bin
    /usr/libexec
    /usr/local/bin
    /usr/local/sbin
    /usr/sbin

All files in these directories should be owned by the `root` user. If any file FILE in these directories is found to be owned by a user other than root, correct its ownership with the following command:

    # chown root FILE

Rationale:

System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted.

Severity: medium

Identifiers: GEN001240

References: ECLP-1, 1499

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    find /etc /bin /usr/bin /usr/lbin /usr/usb /sbin /usr/sbin -follow -gid +499 2>/dev/null | xargs chown :root

#### Verify User Who Owns aliases File [ref]rule

To properly set the owner of `/etc/aliases`, run the command:

    $ sudo chown root /etc/aliases

Rationale:

Severity: high

Identifiers: GEN004400

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/postfix/aliases /etc/postfix/aliases.db /etc/aliases /etc/aliases.db 2>/dev/null

#### Verify Group Who Owns aliases File [ref]rule

To properly set the group owner of `/etc/aliases`, run the command:

    $ sudo chgrp root /etc/aliases

Rationale:

Severity: medium

Identifiers: GEN004410

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/postfix/aliases /etc/postfix/aliases.db /etc/aliases /etc/aliases.db 2>/dev/null

#### Verify Permissions on aliases File [ref]rule

To properly set the permissions of `/etc/aliases`, run the command:

    $ sudo chmod 0644 /etc/aliases

Rationale:

Severity: medium

Identifiers: GEN004420

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 644 /etc/postfix/aliases /etc/postfix/aliases.db /etc/aliases /etc/aliases.db 2>/dev/null

#### Verify Extended ACLs on Aliases [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN004430

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/aliases /etc/aliases.db /etc/postfix/aliases /etc/postfix/aliases.db 2>/dev/null

#### Verify User Who Owns aliases File [ref]rule

To properly set the owner of `/etc/aliases`, run the command:

    $ sudo chown root /etc/aliases

Rationale:

Severity: medium

Identifiers: GEN004360

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep "/" /etc/aliases /etc/aliases.db | grep -v "#" | grep ^/ | sed 's/.*[\s|\t]\//\//' | xargs chown root

#### Verify Group Who Owns aliases File [ref]rule

To properly set the group owner of `/etc/aliases`, run the command:

    $ sudo chgrp root /etc/aliases

Rationale:

Severity: medium

Identifiers: GEN004370

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep "/" /etc/aliases /etc/aliases.db | grep -v "#" | grep ^/ | sed 's/.*[\s|\t]\//\//' | xargs chown :root

#### Verify Permissions on aliases File [ref]rule

To properly set the permissions of `/etc/aliases`, run the command:

    $ sudo chmod 0755 /etc/aliases

Rationale:

Severity: medium

Identifiers: GEN004380

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep "/" /etc/aliases /etc/aliases.db | grep -v "#" | grep ^/ | sed 's/.*[\s|\t]\//\//' | xargs chmod 755

#### Verify Extended ACLs on Aliases Files [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN004390

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep / /etc/aliases | grep -v "#" | sed s/^[^\/]*// | xargs setfacl --remove-all

#### Verify User Who Owns Audio Device Files [ref]rule

To properly set the owner of `/dev/audio`, run the command:

    $ sudo chown root /dev/audio

Rationale:

Severity: medium

Identifiers: GEN002340

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /dev/audio* /dev/snd/*

#### Verify Group Who Owns Audio Device Files [ref]rule

To properly set the group owner of `/dev/audio`, run the command:

    $ sudo chgrp root /dev/audio

Rationale:

Severity: medium

Identifiers: GEN002360

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /dev/audio* /dev/snd/*
    if [[ "`uname -r`" = "2.6.9"* ]]; then
    	sed -i 's/\(^audio\*:[a-z]*:\)[a-z]*:/\1sys:/' /etc/udev/permissions.d/50-udev.permissions
    elif [[ "`uname -r`" = "2.6.18"* ]]; then
    	sed -i '/^<console>  [0-9]* <sound>/s/<sound>.*/<sound>      0600 root.root/' /etc/security/console.perms.d/50-default.perms
    fi

#### Verify Permissions on Audio Device Files [ref]rule

To properly set the permissions of `/dev/audio`, run the command:

    $ sudo chmod 0660 /dev/audio

Rationale:

Severity: medium

Identifiers: GEN002320

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 660 /dev/audio* /dev/snd/*
    sed -i '/[audio|snd]/s/MODE="[0-9]*"/MODE="660"/' /etc/udev/rules.d/50-udev.rules

#### Verify Extended ACLs on Audio Device Files [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN002330

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /dev/audio* /dev/snd/* 2>/dev/null

#### Verify User Who Owns Audit Log Files [ref]rule

To properly set the owner of `/var/log/audit/audit.log`, run the command:

    $ sudo chown root /var/log/audit/audit.log

Rationale:

Severity: medium

Identifiers: GEN002680

References: ECTP-1, 162

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/auditd.conf ]; then
    	grep ^log_file /etc/audit/auditd.conf | awk '{ print $3 }' | xargs chown root
    if [ -e /etc/auditd.conf ]; then
    	grep ^log_file /etc/auditd.conf | awk '{ print $3 }' | xargs chown root
    fi

#### Verify Group Who Owns Audit Log Files [ref]rule

To properly set the group owner of `/var/log/audit/audit.log`, run the command:

    $ sudo chgrp root /var/log/audit/audit.log

Rationale:

Severity: medium

Identifiers: GEN002690

References: ECLP-1, ECTP-1, 162, 163

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/auditd.conf ]; then
    	grep ^log_file /etc/audit/auditd.conf | awk '{ print $3 }' | xargs chown :root
    if [ -e /etc/auditd.conf ]; then
    	grep ^log_file /etc/auditd.conf | awk '{ print $3 }' | xargs chown :root
    fi

#### Verify Permissions on Audit Log Files [ref]rule

System Audit Log Directory Must Have Mode 0755 or Less Permissive and System Audit Logs Must Have Mode 0640 or Less Permissive. Change the mode of the audit log directory with the following command:

    # chmod 0755 /var/log/audit/

Change the mode of the audit log files with the following command:

    # chmod 0640 audit_file

Rationale:

If users can write to audit logs, audit trails can be modified or destroyed.

Severity: medium

Identifiers: GEN002700

References: ECTP-1, 163

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/auditd.conf ]; then
    	grep ^log_file /etc/audit/auditd.conf | awk '{ print $3 }' | xargs chmod 640
    elif [ -e /etc/auditd.conf ]; then
    	grep ^log_file /etc/auditd.conf | awk '{ print $3 }' | xargs chmod 640
    fi

#### Verify Extended ACLs on Audit Log Files [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN002710

References: ECTP-1, 163

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/auditd.conf ]; then
    	grep "^log_file" /etc/audit/auditd.conf | sed s/^[^\/]*// | xargs setfacl --remove-all
    elif [ -e /etc/auditd.conf ]; then
    	grep "^log_file" /etc/auditd.conf | sed s/^[^\/]*// | xargs setfacl --remove-all
    fi

#### Verify User Who Owns Audit Tool Files [ref]rule

To properly set the owner of `/sbin/au*`, run the command:

    $ sudo chown root /sbin/au*

Rationale:

Severity: low

Identifiers: GEN002715

References: ECLP-1, 1493

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /sbin/auditctl /sbin/auditd /sbin/ausearch /sbin/aureport /sbin/autrace /sbin/audispd

#### Verify Group Who Owns Audit Tool Files [ref]rule

To properly set the group owner of `/sbin/au*`, run the command:

    $ sudo chgrp root /sbin/au*

Rationale:

Severity: low

Identifiers: GEN002716

References: ECLP-1, 1493

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /sbin/auditctl /sbin/auditd /sbin/ausearch /sbin/aureport /sbin/autrace /sbin/audispd

#### Verify Permissions on Audit Tool Files [ref]rule

To properly set the permissions of `/sbin/au*`, run the command:

    $ sudo chmod 0750 /sbin/au*

Rationale:

Severity: low

Identifiers: GEN002717

References: ECLP-1, 1493

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 750 /sbin/auditctl /sbin/auditd /sbin/ausearch /sbin/aureport /sbin/autrace /sbin/audispd

#### Verify Extended ACLs on Audit Tool Files [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: low

Identifiers: GEN002718

References: ECLP-1, 1493

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /sbin/auditctl /sbin/auditd /sbin/ausearch /sbin/aureport /sbin/autrace /sbin/audispd

#### Verify User Who Owns Traceroute [ref]rule

To properly set the owner of `/bin/traceroute`, run the command:

    $ sudo chown root /bin/traceroute

Rationale:

Severity: medium

Identifiers: GEN003960

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /bin/traceroute

#### Verify Group Who Owns Traceroute [ref]rule

To properly set the group owner of `/bin/traceroute`, run the command:

    $ sudo chgrp root /bin/traceroute

Rationale:

Severity: medium

Identifiers: GEN003980

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /bin/traceroute

#### Verify Permissions on Traceroute [ref]rule

To properly set the permissions of `/bin/traceroute`, run the command:

    $ sudo chmod 0700 /bin/traceroute

Rationale:

Severity: medium

Identifiers: GEN004000

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 700 /bin/traceroute

#### Verify Extended ACLs on Traceroute [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN004010

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /bin/traceroute

#### Verify User Who Owns Core Dump Directory [ref]rule

To properly set the owner of `/var/crash`, run the command:

    $ sudo chown root /var/crash

Rationale:

Severity: low

Identifiers: GEN003520

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep path.*/ /etc/kdump.conf | awk '{ print $2 }' | chown root

#### Verify Group Who Owns Core Dump Directory [ref]rule

To properly set the group owner of `/var/crash`, run the command:

    $ sudo chgrp root /var/crash

Rationale:

Severity: low

Identifiers: GEN003521

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep path.*/ /etc/kdump.conf | awk '{ print $2 }' | xargs chown :root

#### Verify Permissions on Core Dump Directory [ref]rule

To properly set the permissions of `/var/crash`, run the command:

    $ sudo chmod 0700 /var/crash

Rationale:

Severity: low

Identifiers: GEN003522

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep path.*/ /etc/kdump.conf | awk '{ print $2 }' | xargs chmod 700

#### Verify Extended ACLs on Core Dump Directory [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: low

Identifiers: GEN003523

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep path /etc/kdump.conf | grep -v "#" | awk '{ print $2 }' | xargs setfacl --remove-all

#### Verify Permissions on Cron Log Files [ref]rule

To properly set the permissions of `/var/log/cron`, run the command:

    $ sudo chmod 0600 /var/log/cron

Rationale:

Severity: medium

Identifiers: GEN003180

References: ECLP-1, ECTP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep ^cron /etc/syslog.conf | awk '{ print $2 }' | xargs chmod 0600

#### Verify Extended ACLs on Cron Log Files [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN003190

References: ECLP-1, ECTP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep cron /etc/syslog.conf | grep -v "#" | awk '{ print $2 }' | xargs setfacl --remove-all

#### Verify User Who Owns Crontab Directories [ref]rule

To properly set the owner of `/var/spool/cron`, run the command:

    $ sudo chown root /var/spool/cron

Rationale:

Severity: medium

Identifiers: GEN003120

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /var/spool/cron 2>/dev/null

#### Verify Group Who Owns Crontab Directories [ref]rule

To properly set the group owner of `/var/spool/cron`, run the command:

    $ sudo chgrp root /var/spool/cron

Rationale:

Severity: medium

Identifiers: GEN003140

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /var/spool/cron 2>/dev/null

#### Verify Permissions on Crontab Directories [ref]rule

To properly set the permissions of `/var/spool/cron`, run the command:

    $ sudo chmod 0755 /var/spool/cron

Rationale:

Severity: medium

Identifiers: GEN003100

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 755 /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /var/spool/cron 2>/dev/null

#### Verify Extended ACLs on Crontab Directories [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN003110

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/cron.d /etc/crontab /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /var/spool/cron 2>/dev/null

#### Verify User Who Owns Crontab Files [ref]rule

To properly set the owner of `/etc/cron*`, run the command:

    $ sudo chown root /etc/cron*

Rationale:

Severity: medium

Identifiers: GEN003040

References: DCSL-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/crontab /etc/cron.d/* /var/spool/cron/* 2>/dev/null

#### Verify Group Who Owns Crontab Files [ref]rule

To properly set the group owner of `/etc/cron*`, run the command:

    $ sudo chgrp root /etc/cron*

Rationale:

Severity: medium

Identifiers: GEN003050

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/crontab /etc/cron.d/* /var/spool/cron/* 2>/dev/null

#### Verify Permissions on Crontab Files [ref]rule

To properly set the permissions of `/etc/cron*`, run the command:

    $ sudo chmod 0600 /etc/cron*

Rationale:

Severity: medium

Identifiers: GEN003080

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 600 /etc/crontab /etc/cron.d/* /var/spool/cron/* 2>/dev/null

#### Verify Extended ACLs on Crontab Files [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN003090

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    find /etc/cron.d /etc/crontab /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /var/spool/cron  -type f 2>/dev/null | xargs setfacl --remove-all

#### Verify Permissions on Cron Files [ref]rule

To properly set the permissions of `/etc/cron*`, run the command:

    $ sudo chmod 0700 /etc/cron*

Rationale:

Severity: medium

Identifiers: GEN003080-2

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0700 /etc/cron.daily/* /etc/cron.hourly/* /etc/cron.monthly/* /etc/cron.weekly/* 2>/dev/null

#### Verify User Who Owns at.allow [ref]rule

To properly set the owner of `/etc/at.allow`, run the command:

    $ sudo chown root /etc/at.allow

Rationale:

Severity: medium

Identifiers: GEN003460

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/at.allow

#### Verify Group Who Owns at.allow [ref]rule

To properly set the group owner of `/etc/at.allow`, run the command:

    $ sudo chgrp root /etc/at.allow

Rationale:

Severity: medium

Identifiers: GEN003470

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/at.allow

#### Verify Permissions on at.allow [ref]rule

To properly set the permissions of `/etc/at.allow`, run the command:

    $ sudo chmod 0600 /etc/at.allow

Rationale:

Severity: medium

Identifiers: GEN003340

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0600 /etc/at.allow

#### Verify Extended ACLs on at.allow [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN003245

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/at.allow

#### Verify User Who Owns at.deny [ref]rule

To properly set the owner of `/etc/at.deny`, run the command:

    $ sudo chown root /etc/at.deny

Rationale:

Severity: medium

Identifiers: GEN003480

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/at.deny

#### Verify Group Who Owns at.deny [ref]rule

To properly set the group owner of `/etc/at.deny`, run the command:

    $ sudo chgrp root /etc/at.deny

Rationale:

Severity: medium

Identifiers: GEN003490

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/at.deny

#### Verify Permissions on at.deny [ref]rule

To properly set the permissions of `/etc/at.deny`, run the command:

    $ sudo chmod 0600 /etc/at.deny

Rationale:

Severity: medium

Identifiers: GEN003252

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0600 /etc/at.deny

#### Verify Extended ACLs on at.deny [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN003255

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/at.deny

#### Verify User Who Owns cron.allow [ref]rule

To properly set the owner of `/etc/cron.allow`, run the command:

    $ sudo chown root /etc/cron.allow

Rationale:

Severity: medium

Identifiers: GEN003240

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/cron.allow

#### Verify Group Who Owns cron.allow [ref]rule

To properly set the group owner of `/etc/cron.allow`, run the command:

    $ sudo chgrp root /etc/cron.allow

Rationale:

Severity: medium

Identifiers: GEN003250

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/cron.allow

#### Verify Permissions on cron.allow [ref]rule

To properly set the permissions of `/etc/cron.allow`, run the command:

    $ sudo chmod 0600 /etc/cron.allow

Rationale:

Severity: medium

Identifiers: GEN002980

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0600 /etc/cron.allow

#### Verify Extended ACLs on cron.allow [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN002990

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/cron.allow

#### Verify User Who Owns cron.deny [ref]rule

To properly set the owner of `/etc/cron.deny`, run the command:

    $ sudo chown root /etc/cron.deny

Rationale:

Severity: medium

Identifiers: GEN003260

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/cron.deny

#### Verify Group Who Owns cron.deny [ref]rule

To properly set the group owner of `/etc/cron.deny`, run the command:

    $ sudo chgrp root /etc/cron.deny

Rationale:

Severity: medium

Identifiers: GEN003270

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/cron.deny

#### Verify Permissions on cron.deny [ref]rule

To properly set the permissions of `/etc/cron.deny`, run the command:

    $ sudo chmod 0600 /etc/cron.deny

Rationale:

Severity: medium

Identifiers: GEN003200

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0600 /etc/cron.deny

#### Verify Extended ACLs on cron.deny [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN003210

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/cron.deny

#### Verify User Who Owns printers.conf [ref]rule

To properly set the owner of `/etc/cups/printers.conf`, run the command:

    $ sudo chown root /etc/cups/printers.conf

Rationale:

Severity: medium

Identifiers: GEN003920

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/cups/printers.conf

#### Verify Group Who Owns printers.conf [ref]rule

To properly set the group owner of `/etc/cups/printers.conf`, run the command:

    $ sudo chgrp root /etc/cups/printers.conf

Rationale:

Severity: medium

Identifiers: GEN003930

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/cups/printers.conf

#### Verify Permissions on printers.conf [ref]rule

To properly set the permissions of `/etc/cups/printers.conf`, run the command:

    $ sudo chmod 0644 /etc/cups/printers.conf

Rationale:

Severity: medium

Identifiers: GEN003940

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0644 /etc/cups/printers.conf

#### Verify Extended ACLs on printers.conf [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN003950

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/cups/printers.conf

#### Verify User Who Owns Exports [ref]rule

To properly set the owner of `/etc/exports`, run the command:

    $ sudo chown root /etc/exports

Rationale:

Severity: medium

Identifiers: GEN005740

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/exports

#### Verify Group Who Owns Exports [ref]rule

To properly set the group owner of `/etc/exports`, run the command:

    $ sudo chgrp root /etc/exports

Rationale:

Severity: medium

Identifiers: GEN005750

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/exports

#### Verify Permissions on Exports [ref]rule

To properly set the permissions of `/etc/exports`, run the command:

    $ sudo chmod 0644 /etc/exports

Rationale:

Severity: low

Identifiers: GEN005760

References: ECCD-1, ECCD-2, ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0644 /etc/exports

#### Verify Extended ACLs on Exports [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: low

Identifiers: GEN005770

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/exports

#### Verify User Who Owns Hosts [ref]rule

To properly set the owner of `/etc/hosts`, run the command:

    $ sudo chown root /etc/hosts

Rationale:

Severity: medium

Identifiers: GEN001366

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/hosts

#### Verify Group Who Owns Hosts [ref]rule

To properly set the group owner of `/etc/hosts`, run the command:

    $ sudo chgrp root /etc/hosts

Rationale:

Severity: medium

Identifiers: GEN001367

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/hosts

#### Verify Permissions on Hosts [ref]rule

To properly set the permissions of `/etc/hosts`, run the command:

    $ sudo chmod 0644 /etc/hosts

Rationale:

Severity: medium

Identifiers: GEN001368

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0644 /etc/hosts

#### Verify Extended ACLs on Hosts [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN001369

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/hosts

#### Verify User Who Owns ldap.conf [ref]rule

To properly set the owner of `/etc/ldap.conf`, run the command:

    $ sudo chown root /etc/ldap.conf

Rationale:

Severity: medium

Identifiers: GEN008080

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/ldap.conf

#### Verify Group Who Owns ldap.conf [ref]rule

To properly set the group owner of `/etc/ldap.conf`, run the command:

    $ sudo chgrp root /etc/ldap.conf

Rationale:

Severity: medium

Identifiers: GEN008100

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/ldap.conf

#### Verify Permissions on ldap.conf [ref]rule

To properly set the permissions of `/etc/ldap.conf`, run the command:

    $ sudo chmod 0644 /etc/ldap.conf

Rationale:

Severity: medium

Identifiers: GEN008060

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0644 /etc/ldap.conf

#### Verify Extended ACLs on ldap.conf [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN008120

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/ldap.conf

#### Verify Permissions on infeed.conf [ref]rule

To properly set the permissions of `/etc/news/infeed.conf`, run the command:

    $ sudo chmod 0600 /etc/news/infeed.conf

Rationale:

Severity: medium

Identifiers: GEN006280

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0600 /etc/news/infeed.conf

#### Verify Extended ACLs on infeed.conf [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN006290

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/news/infeed.conf

#### Verify Permissions on incoming.conf [ref]rule

To properly set the permissions of `/etc/news/incoming.conf`, run the command:

    $ sudo chmod 0600 /etc/news/incoming.conf

Rationale:

Severity: medium

Identifiers: GEN006260

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0600 /etc/news/incoming.conf

#### Verify Extended ACLs on incoming.conf [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN006270

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/news/incoming.conf

#### Verify Extended ACLs on nnrp.access [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN006310

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/news/nnrp.access

#### Verify Permissions on passwd.nntp [ref]rule

To properly set the permissions of `/etc/news/passwd.nntp`, run the command:

    $ sudo chmod 0600 /etc/news/passwd.nntp

Rationale:

Severity: medium

Identifiers: GEN006320

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0600 /etc/news/passwd.nntp

#### Verify Extended ACLs on passwd.nntp [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN006330

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/news/passwd.nntp

#### Verify User Who Owns nsswitch.conf [ref]rule

To properly set the owner of `/etc/nsswitch.conf`, run the command:

    $ sudo chown root /etc/nsswitch.conf

Rationale:

Severity: medium

Identifiers: GEN001371

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/nsswitch.conf

#### Verify Group Who Owns nsswitch.conf [ref]rule

To properly set the group owner of `/etc/nsswitch.conf`, run the command:

    $ sudo chgrp root /etc/nsswitch.conf

Rationale:

Severity: medium

Identifiers: GEN001372

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/nsswitch.conf

#### Verify Permissions on nsswitch.conf [ref]rule

To properly set the permissions of `/etc/nsswitch.conf`, run the command:

    $ sudo chmod 0644 /etc/nsswitch.conf

Rationale:

Severity: medium

Identifiers: GEN001373

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0644 /etc/nsswitch.conf

#### Verify Extended ACLs on nsswitch.conf [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN001374

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/nsswitch.conf

#### Verify User Who Owns ntp.conf [ref]rule

To properly set the owner of `/etc/ntp.conf`, run the command:

    $ sudo chown root /etc/ntp.conf

Rationale:

Severity: medium

Identifiers: GEN000250

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/ntp.conf

#### Verify Group Who Owns ntp.conf [ref]rule

To properly set the group owner of `/etc/ntp.conf`, run the command:

    $ sudo chgrp root /etc/ntp.conf

Rationale:

Severity: medium

Identifiers: GEN000251

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/ntp.conf

#### Verify Permissions on ntp.conf [ref]rule

To properly set the permissions of `/etc/ntp.conf`, run the command:

    $ sudo chmod 0644 /etc/ntp.conf

Rationale:

Severity: medium

Identifiers: GEN000252

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0640 /etc/ntp.conf

#### Verify Extended ACLs on ntp.conf [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN000253

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/ntp.conf

#### Verify User Who Owns resolv.conf [ref]rule

To properly set the owner of `/etc/resolv.conf`, run the command:

    $ sudo chown root /etc/resolv.conf

Rationale:

Severity: medium

Identifiers: GEN001362

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/resolv.conf

#### Verify Group Who Owns resolv.conf [ref]rule

To properly set the group owner of `/etc/resolv.conf`, run the command:

    $ sudo chgrp root /etc/resolv.conf

Rationale:

Severity: medium

Identifiers: GEN001363

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/resolv.conf

#### Verify Permissions on resolv.conf [ref]rule

To properly set the permissions of `/etc/resolv.conf`, run the command:

    $ sudo chmod 0644 /etc/resolv.conf

Rationale:

Severity: medium

Identifiers: GEN001364

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0644 /etc/resolv.conf

#### Verify Extended ACLs on resolv.conf [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN001365

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/resolv.conf

#### Verify User Who Owns smb.conf [ref]rule

To properly set the owner of `/etc/samba/smb.conf`, run the command:

    $ sudo chown root /etc/samba/smb.conf

Rationale:

Severity: medium

Identifiers: GEN006100

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/samba/smb.conf

#### Verify Group Who Owns smb.conf [ref]rule

To properly set the group owner of `/etc/samba/smb.conf`, run the command:

    $ sudo chgrp root /etc/samba/smb.conf

Rationale:

Severity: medium

Identifiers: GEN006120

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/samba/smb.conf

#### Verify Permissions on smb.conf [ref]rule

To properly set the permissions of `/etc/samba/smb.conf`, run the command:

    $ sudo chmod 0644 /etc/samba/smb.conf

Rationale:

Severity: medium

Identifiers: GEN006140

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0644 /etc/samba/smb.conf

#### Verify Extended ACLs on smb.conf [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN006150

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/samba/smb.conf

#### Verify User Who Owns Samba Password Files [ref]rule

To properly set the owner of `/etc/samba/passdb.tdb`, run the command:

    $ sudo chown root /etc/samba/passdb.tdb

Rationale:

Severity: medium

Identifiers: GEN006160

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/samba/passdb.tdb /etc/samba/secrets.tdb

#### Verify Group Who Owns Samba Password Files [ref]rule

To properly set the group owner of `/etc/samba/passdb.tdb`, run the command:

    $ sudo chgrp root /etc/samba/passdb.tdb

Rationale:

Severity: medium

Identifiers: GEN006180

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/samba/passdb.tdb /etc/samba/secrets.tdb

#### Verify Permissions on Samba Password Files [ref]rule

To properly set the permissions of `/etc/samba/passdb.tdb`, run the command:

    $ sudo chmod 0600 /etc/samba/passdb.tdb

Rationale:

Severity: medium

Identifiers: GEN006200

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0600 /etc/samba/passdb.tdb /etc/samba/secrets.tdb

#### Verify Extended ACLs on Samba Password Files [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN006210

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/samba/passdb.tdb /etc/samba/secrets.tdb

#### Verify User Who Owns securetty [ref]rule

To properly set the owner of `/etc/securetty`, run the command:

    $ sudo chown root /etc/securetty

Rationale:

Severity: medium

Identifiers: GEN000000-LNX00640

References: ECLP-1, 225, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/securetty

#### Verify Group Who Owns securetty [ref]rule

To properly set the group owner of `/etc/securetty`, run the command:

    $ sudo chgrp root /etc/securetty

Rationale:

Severity: medium

Identifiers: GEN000000-LNX00620

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/securetty

#### Verify Permissions on securetty [ref]rule

To properly set the permissions of `/etc/securetty`, run the command:

    $ sudo chmod 0600 /etc/securetty

Rationale:

Severity: medium

Identifiers: GEN000000-LNX00660

References: ECLP-1, 225, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0600 /etc/securetty

#### Verify User Who Owns access.conf [ref]rule

To properly set the owner of `/etc/access.conf`, run the command:

    $ sudo chown root /etc/access.conf

Rationale:

Severity: medium

Identifiers: GEN000000-LNX00400

References: ECLP-1, 225, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/security/access.conf

#### Verify Group Who Owns access.conf [ref]rule

To properly set the group owner of `/etc/access.conf`, run the command:

    $ sudo chgrp root /etc/access.conf

Rationale:

Severity: medium

Identifiers: GEN000000-LNX00420

References: ECLP-1, 225, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/security/access.conf

#### Verify Permissions on access.conf [ref]rule

To properly set the permissions of `/etc/access.conf`, run the command:

    $ sudo chmod 0640 /etc/access.conf

Rationale:

Severity: medium

Identifiers: GEN000000-LNX00440

References: ECLP-1, 225, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0640 /etc/security/access.conf

#### Verify Extended ACLs on access.conf [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN000000-LNX00450

References: ECLP-1, 225, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/security/access.conf

#### Verify User Who Owns services [ref]rule

To properly set the owner of `/etc/services`, run the command:

    $ sudo chown root /etc/services

Rationale:

Severity: medium

Identifiers: GEN003760

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/services

#### Verify Group Who Owns services [ref]rule

To properly set the group owner of `/etc/services`, run the command:

    $ sudo chgrp root /etc/services

Rationale:

Severity: medium

Identifiers: GEN003770

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/services

#### Verify Permissions on services [ref]rule

To properly set the permissions of `/etc/services`, run the command:

    $ sudo chmod 0640 /etc/services

Rationale:

Severity: medium

Identifiers: GEN003780

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0644 /etc/services

#### Verify Extended ACLs on services [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN003790

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/services

#### Verify User Who Owns Skeleton Files [ref]rule

To properly set the owner of `/etc/skel/*`, run the command:

    $ sudo chown root /etc/skel/*

Rationale:

Severity: medium

Identifiers: GEN001820

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/skel/*

#### Verify Group Who Owns Skeleton Files [ref]rule

To properly set the group owner of `/etc/skel/*`, run the command:

    $ sudo chgrp root /etc/skel/*

Rationale:

Severity: medium

Identifiers: GEN001830

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/skel/*

#### Verify Permissions on Skeleton Files [ref]rule

To properly set the permissions of `/etc/skel/*`, run the command:

    $ sudo chmod 0640 /etc/skel/*

Rationale:

Severity: medium

Identifiers: GEN001800

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0644 /etc/skel/*

#### Verify Extended ACLs on Skeleton Files [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN001810

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    find /etc/skel 2>/dev/null | xargs setfacl --remove-all

#### Verify User Who Owns sysctl.conf [ref]rule

To properly set the owner of `/etc/sysctl.conf`, run the command:

    $ sudo chown root /etc/sysctl.conf

Rationale:

Severity: medium

Identifiers: GEN000000-LNX00480

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/sysctl.conf

#### Verify Group Who Owns sysctl.conf [ref]rule

To properly set the group owner of `/etc/sysctl.conf`, run the command:

    $ sudo chgrp root /etc/sysctl.conf

Rationale:

Severity: medium

Identifiers: GEN000000-LNX00500

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/sysctl.conf

#### Verify Permissions on sysctl.conf [ref]rule

To properly set the permissions of `/etc/sysctl.conf`, run the command:

    $ sudo chmod 0600 /etc/sysctl.conf

Rationale:

Severity: medium

Identifiers: GEN000000-LNX00520

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0600 /etc/sysctl.conf

#### Verify Extended ACLs on sysctl.conf [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN000000-LNX00530

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/sysctl.conf

#### Verify User Who Owns syslog.conf [ref]rule

To properly set the owner of `/etc/syslog.conf`, run the command:

    $ sudo chown root /etc/syslog.conf

Rationale:

Severity: medium

Identifiers: GEN005400

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/syslog.conf

#### Verify Group Who Owns syslog.conf [ref]rule

To properly set the group owner of `/etc/syslog.conf`, run the command:

    $ sudo chgrp root /etc/syslog.conf

Rationale:

Severity: medium

Identifiers: GEN005420

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/syslog.conf

#### Verify Permissions on syslog.conf [ref]rule

To properly set the permissions of `/etc/syslog.conf`, run the command:

    $ sudo chmod 0640 /etc/syslog.conf

Rationale:

Severity: medium

Identifiers: GEN005390

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0640 /etc/syslog.conf

#### Verify Extended ACLs on syslog.conf [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN005395

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/syslog.conf

#### Verify User Who Owns xinetd.conf [ref]rule

To properly set the owner of `/etc/xinetd.conf`, run the command:

    $ sudo chown root /etc/xinetd.conf

Rationale:

Severity: medium

Identifiers: GEN003720

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/xinetd.conf

#### Verify Group Who Owns xinetd.conf [ref]rule

To properly set the group owner of `/etc/xinetd.conf`, run the command:

    $ sudo chgrp root /etc/xinetd.conf

Rationale:

Severity: medium

Identifiers: GEN003730

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/xinetd.conf

#### Verify Permissions on xinetd.conf [ref]rule

To properly set the permissions of `/etc/xinetd.conf`, run the command:

    $ sudo chmod 0640 /etc/xinetd.conf

Rationale:

Severity: medium

Identifiers: GEN003740

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0640 /etc/xinetd.conf /etc/xinetd.d/*

#### Verify Extended ACLs on xinetd.conf [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN003745

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/xinetd.conf

#### Verify Permissions on xinet.d Directory [ref]rule

To properly set the permissions of `/etc/xinet.d/`, run the command:

    $ sudo chmod 0640 /etc/xinet.d/

Rationale:

Severity: medium

Identifiers: GEN003750

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0755 /etc/xinet.d/*

#### Verify Extended ACLs on xinet.d Directory [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN003755

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    find /etc/xinetd.d -type f 2>/dev/null | xargs setfacl --remove-all

#### Verify User Who Owns Exports Directories [ref]rule

To properly set the owner of `/etc/exports`, run the command:

    $ sudo chown root /etc/exports

Rationale:

Severity: medium

Identifiers: GEN005800

References: ECSC-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    cat /etc/exports | awk '{ print $1 }' | xargs chown root

#### Verify Group Who Owns Exports Directories [ref]rule

To properly set the group owner of `/etc/exports`, run the command:

    $ sudo chgrp root /etc/exports

Rationale:

Severity: medium

Identifiers: GEN005810

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    cat /etc/exports | awk '{ print $1 }' | xargs chown :root

#### Verify User Who Owns ftpusers [ref]rule

To properly set the owner of `/etc/ftpusers`, run the command:

    $ sudo chown root /etc/ftpusers

Rationale:

Severity: medium

Identifiers: GEN004920

References: ECLP-1, 225

#### Verify Group Who Owns ftpusers [ref]rule

To properly set the group owner of `/etc/ftpusers`, run the command:

    $ sudo chgrp root /etc/ftpusers

Rationale:

Severity: medium

Identifiers: GEN004930

References: ECLP-1, 225

#### Verify Permissions on ftpusers [ref]rule

To properly set the permissions of `/etc/ftpusers`, run the command:

    $ sudo chmod 0640 /etc/ftpusers

Rationale:

Severity: medium

Identifiers: GEN004940

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0640 /etc/ftpusers /etc/vsftpd.ftpusers /etc/vsftpd/ftpusers 2>/dev/null

#### Verify Extended ACLs on ftpusers [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN004950

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/ftpusers /etc/vsftpd.ftpusers /etc/vsftpd/ftpusers

#### Verify User Who Owns Global Initialization Files [ref]rule

To properly set the owner of `/etc/profile`, run the command:

    $ sudo chown root /etc/profile

Rationale:

Severity: medium

Identifiers: GEN001740

References: ECLP-1, 225

#### Verify Group Who Owns Global Initialization Files [ref]rule

To properly set the group owner of `/etc/profile`, run the command:

    $ sudo chgrp root /etc/profile

Rationale:

Severity: medium

Identifiers: GEN001760

References: ECLP-1, 225

#### Verify Permissions on Global Initialization Files [ref]rule

To properly set the permissions of `/etc/profile`, run the command:

    $ sudo chmod 0644 /etc/profile

Rationale:

Severity: medium

Identifiers: GEN001720

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod -R 0644 /etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d 2>/dev/null

#### Verify Extended ACLs on Global Initialization Files [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN001730

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d/*

#### Verify Messaging is Disabled in Global Initialization Files [ref]rule

No global messaging should be enabled.

Rationale:

Severity: low

Identifiers: GEN001780

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    echo mesg n | tee -a /etc/profile &>/dev/null

#### Verify User Who Owns Home Directories [ref]rule

To properly set the owner of `/home/*`, run the command:

    $ sudo chown root /home/*

Rationale:

Severity: medium

Identifiers: GEN001500

References: ECLP-1, 225

#### Verify Group Who Owns Home Directories [ref]rule

To properly set the group owner of `/home/*`, run the command:

    $ sudo chgrp root /home/*

Rationale:

Severity: medium

Identifiers: GEN001520

References: ECLP-1, 225

#### Ensure that User Home Directories are not Group-Writable or World-Readable [ref]rule

For each human 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

Warning: This action may involve modifying user home directories. Notify your user community, and solicit input if appropriate, before making this type of change.
Rationale:

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 sub-directories or elsewhere in the filesystem if they are needed. Typically, user home directories should not be world-readable, as it would disclose file names to other users. If a subset of users need read access to one another's home directories, this can be provided using groups or ACLs.

Severity: low

Identifiers: GEN001480

References: ECLP-1, 225

#### Verify Extended ACLs on Home Directories [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: low

Identifiers: GEN001490

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    cut -d: -f6 /etc/passwd | sort -u | xargs setfacl --remove-all 2>/dev/null

#### Verify User Who Owns Home Files [ref]rule

To properly set the owner of `/home/*/*`, run the command:

    $ sudo chown root /home/*/*

Rationale:

Severity: low

Identifiers: GEN001540

References: ECCD-1, ECCD-2, 225

#### Verify Group Who Owns Home Files [ref]rule

To properly set the group owner of `/home/*/*`, run the command:

    $ sudo chgrp root /home/*/*

Rationale:

Severity: medium

Identifiers: GEN001550

References: ECLP-1, 225

#### Verify Permissions on Home Files [ref]rule

To properly set the permissions of `/home/*/*`, run the command:

    $ sudo chmod 0750 /home/*/*

Rationale:

Severity: low

Identifiers: GEN001560

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    find /root /home/* -perm -1 -o -perm -2 -o -perm -4 -o -perm -20 2>/dev/null | xargs -I entry chmod o-rwx,g-w "entry"

#### Verify Extended ACLs on Home Files [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN001570

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    find /home -type f 2>/dev/null | xargs setfacl --remove-all

#### Verify User Who Owns LDAP CA Certificates [ref]rule

To properly set the owner of `tls_cacert`, run the command:

    $ sudo chown root tls_cacert

Rationale:

Severity: medium

Identifiers: GEN008140

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep -i '^tls_cacert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chown -R root

#### Verify Group Who Owns LDAP CA Certificates [ref]rule

To properly set the group owner of `tls_cacert`, run the command:

    $ sudo chgrp root tls_cacert

Rationale:

Severity: medium

Identifiers: GEN008160

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep -i '^tls_cacert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chown -R :root

#### Verify Permissions on LDAP CA Certificates [ref]rule

To properly set the permissions of `tls_cacert`, run the command:

    $ sudo chmod 0640 tls_cacert

Rationale:

Severity: medium

Identifiers: GEN008180

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    KEY_PATH="`grep -i '^tls_cacert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }'`"
    if [ -d "${KEY_PATH}" ]; then
    	chmod 755 "${KEY_PATH}"
    	chmod 644 "${KEY_PATH}"/*
    elif [ -e "${KEY_PATH}" ]; then
    	chmod 644 "${KEY_PATH}"
    fi

#### Verify Extended ACLs on LDAP CA Certificates [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN008200

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep -i '^tls_cacert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs setfacl --remove-all

#### Verify User Who Owns LDAP Certificates [ref]rule

To properly set the owner of `tls_cert`, run the command:

    $ sudo chown root tls_cert

Rationale:

Severity: medium

Identifiers: GEN008220

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep -i '^tls_cert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chown -R root

#### Verify Group Who Owns LDAP Certificates [ref]rule

To properly set the group owner of `tls_cert`, run the command:

    $ sudo chgrp root tls_cert

Rationale:

Severity: medium

Identifiers: GEN008240

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep -i '^tls_cert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chown -R :root

#### Verify Permissions on LDAP Certificates [ref]rule

To properly set the permissions of `tls_cert`, run the command:

    $ sudo chmod 0640 tls_cert

Rationale:

Severity: medium

Identifiers: GEN008260

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep -i '^tls_cert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chmod -R 644

#### Verify Extended ACLs on LDAP Certificates [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN008280

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep -i '^tls_cert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs setfacl --remove-all

#### Verify User Who Owns LDAP Keys [ref]rule

To properly set the owner of `tls_key`, run the command:

    $ sudo chown root tls_key

Rationale:

Severity: medium

Identifiers: GEN008300

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep -i '^tls_key' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chown -R root

#### Verify Group Who Owns LDAP Keys [ref]rule

To properly set the group owner of `tls_key`, run the command:

    $ sudo chgrp root tls_key

Rationale:

Severity: medium

Identifiers: GEN008320

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep -i '^tls_key' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chown -R :root

#### Verify Permissions on LDAP Keys [ref]rule

To properly set the permissions of `tls_key`, run the command:

    $ sudo chmod 0600 tls_key

Rationale:

Severity: medium

Identifiers: GEN008340

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep -i '^tls_key' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chmod -R 600

#### Verify Extended ACLs on LDAP Keys [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN008360

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep -i '^tls_key' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs setfacl --remove-all

#### Verify User Who Owns Local Initialization Files [ref]rule

To properly set the owner of `~/.bashrc`, run the command:

    $ sudo chown root ~/.bashrc

Rationale:

Severity: medium

Identifiers: GEN001860

References: ECLP-1, 225

#### Verify Group Who Owns Local Initialization Files [ref]rule

To properly set the group owner of `~/.bashrc`, run the command:

    $ sudo chgrp root ~/.bashrc

Rationale:

Severity: medium

Identifiers: GEN001870

References: ECLP-1, 225

#### Verify Permissions on Local Initialization Files [ref]rule

To properly set the permissions of `~/.bashrc`, run the command:

    $ sudo chmod 0740 ~/.bashrc

Rationale:

Severity: medium

Identifiers: GEN001880

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    find /root /home -maxdepth 2 -type f \( -perm -o+r -o -perm -o+w  -o -perm -o+x -o -perm -g+w -o -perm -g+x \) -a \( -name \.bashrc -o -name \.bash_login -o -name \.bash_logout -o -name \.bash_profile -o -name \.cshrc -o -name \.kshrc -o -name \.login -o -name \.logout -o -name \.profile -o -name \.env -o -name \.dtprofile -o -name \.dispatch -o -name \.emacs -o -name \.exrc \) 2>/dev/null | xargs chmod o-rwx,g-wx

#### Verify Extended ACLs on Local Initialization Files [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN001890

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    cut -d: -f6 /etc/passwd | sort -u | xargs -n1 -IDIR find DIR -maxdepth 1 -name .bashrc -o -name .bash_login -o -name .bash_logout -o -name .bash_profile -o -name .cshrc -o -name .kshrc -o -name .login -o -name .logout -o -name .profile -o -name .env -o -name .dtprofile -o -name .dispatch -o -name .emacs -o -name .exrc 2>/dev/null | xargs setfacl --remove-all

#### Verify Permissions on Man Pages [ref]rule

To properly set the permissions of `/usr/share/man`, run the command:

    $ sudo chmod 0644 /usr/share/man

Rationale:

Severity: low

Identifiers: GEN001280

References: ECCD-1, ECCD-2, 225

#### Verify Extended ACLs on Man Pages [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: low

Identifiers: GEN001290

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl -RLb /usr/share/man/* /usr/share/info/* /usr/share/infopage/*

#### Verify Permissions on .Mib Files [ref]rule

To properly set the permissions of `*.mib`, run the command:

    $ sudo chmod 0640 *.mib

Rationale:

Severity: medium

Identifiers: GEN005340

References: ECLP-1, 225

#### Verify Extended ACLs on .Mib Files [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN005350

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    find / -name *.mib 2>/dev/null | xargs setfacl --remove-all

#### Verify Permissions on root Directory [ref]rule

To properly set the permissions of `/root`, run the command:

    $ sudo chmod 0700 /root

Rationale:

Severity: medium

Identifiers: GEN000920

References: ECCD-1, ECCD-2, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep ^root: /etc/passwd | awk -F: ' { print $6 }' | xargs -I entry chmod g-rwx,o-rwx "entry"

#### Verify Extended ACLs on root Directory [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN000930

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl -RLb /root/*

#### Verify User Who Owns Run Control Scripts [ref]rule

To properly set the owner of `/etc/rc*`, run the command:

    $ sudo chown root /etc/rc*

Rationale:

Severity: medium

Identifiers: GEN001660

References: ECLP-1, 225

#### Verify Group Who Owns Run Control Scripts [ref]rule

To properly set the group owner of `/etc/rc*`, run the command:

    $ sudo chgrp root /etc/rc*

Rationale:

Severity: medium

Identifiers: GEN001680

References: ECLP-1, 225

#### Verify Permissions on Run Control Scripts [ref]rule

To properly set the permissions of `/etc/rc*`, run the command:

    $ sudo chmod 0755 /etc/rc*

Rationale:

Severity: medium

Identifiers: GEN001580

References: ECLP-1, 225

#### Verify Extended ACLs on Run Control Scripts [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN001590

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    find /etc/rc* /etc/init.d -type f 2>/dev/null | xargs setfacl --remove-all

#### Verify User Who Owns Shell Files [ref]rule

To properly set the owner of `/etc/shells`, run the command:

    $ sudo chown root /etc/shells

Rationale:

Severity: medium

Identifiers: GEN002200

References: ECLP-1, 225

#### Verify Group Who Owns Shell Files [ref]rule

To properly set the group owner of `/etc/shells`, run the command:

    $ sudo chgrp root /etc/shells

Rationale:

Severity: medium

Identifiers: GEN002210

References: ECLP-1, 225

#### Verify Permissions on Shell Files [ref]rule

To properly set the permissions of `/etc/shells`, run the command:

    $ sudo chmod 0755 /etc/shells

Rationale:

Severity: high

Identifiers: GEN002220

References: ECLP-1, 225

#### Verify Extended ACLs on Shell Files [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN002230

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    cat /etc/shells | xargs setfacl --remove-all

#### Verify User Who Owns SMTP Logs [ref]rule

To properly set the owner of `/var/log/mail.log`, run the command:

    $ sudo chown root /var/log/mail.log

Rationale:

Severity: medium

Identifiers: GEN004480

References: ECLP-1, 225

#### Verify Permissions on SMTP Logs [ref]rule

To properly set the permissions of `/var/log/mail.log`, run the command:

    $ sudo chmod 0644 /var/log/mail.log

Rationale:

Severity: medium

Identifiers: GEN004500

References: ECLP-1, 225

#### Verify Extended ACLs on SMTP Logs [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN004510

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    egrep "(\*.crit|mail\.[^n][^/]*)" /etc/syslog.conf | sed 's/^[^/]*//' | xargs setfacl --remove-all

#### Verify User Who Owns snmpd.conf [ref]rule

To properly set the owner of `snmpd.conf`, run the command:

    $ sudo chown root snmpd.conf

Rationale:

Severity: medium

Identifiers: GEN005360

References: ECLP-1, 225

#### Verify Group Who Owns snmpd.conf [ref]rule

To properly set the group owner of `snmpd.conf`, run the command:

    $ sudo chgrp root snmpd.conf

Rationale:

Severity: medium

Identifiers: GEN005365

References: ECLP-1, 225

#### Verify Permissions on snmpd.conf [ref]rule

To properly set the permissions of `snmpd.conf`, run the command:

    $ sudo chmod 0644 snmpd.conf

Rationale:

Severity: medium

Identifiers: GEN005320

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    find / -name snmpd.conf 2>/dev/null | xargs chmod ugo-x,go-wr

#### Verify Extended ACLs on snmpd.conf [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN005375

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    find / -name snmpd.conf 2>/dev/null | xargs setfacl --remove-all

#### Verify Permissions on /etc/ssh/*key [ref]rule

To properly set the permissions of `/etc/ssh/*key`, run the command:

    $ sudo chmod 0600 /etc/ssh/*key

Rationale:

Severity: medium

Identifiers: GEN005523

References: ECLP-1, 225

#### Verify Permissions on /etc/ssh/*key.pub [ref]rule

To properly set the permissions of `/etc/ssh/*key.pub`, run the command:

    $ sudo chmod 0644 /etc/ssh/*key.pub

Rationale:

Severity: medium

Identifiers: GEN005522

References: ECLP-1, 225

#### Verify Permissions on TFTP Binary [ref]rule

To properly set the permissions of `/etc/xinetd.d/tftp`, run the command:

    $ sudo chmod 0755 /etc/xinetd.d/tftp

Rationale:

Severity: high

Identifiers: GEN005100

References: ECPA-1, 225

#### Verify Permissions on /usr/bin/ldd [ref]rule

To properly set the permissions of `/usr/bin/ldd`, run the command:

    $ sudo chmod 0000 /usr/bin/ldd

Rationale:

Severity: medium

Identifiers: GEN007960

References: ECSC-1, 305

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod a-x /usr/bin/ldd

#### Verify Permissions on sbin Directory [ref]rule

To properly set the permissions of `/usr/sbin/`, run the command:

    $ sudo chmod 0755 /usr/sbin/

Rationale:

Severity: medium

Identifiers: GEN001180

References: ECLP-1, 225

#### Verify Extended ACLs on sbin Directory [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN001190

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl -RLb /usr/sbin/*

#### Verify Permissions on System Logs [ref]rule

To properly set the permissions of `/var/log/*`, run the command:

    $ sudo chmod 0640 /var/log/*

Rationale:

Severity: medium

Identifiers: GEN001260

References: ECTP-1, 1314

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    find /var/log -follow -type f ! -name wtmp 2>/dev/null | xargs chmod o-rwx,g-wx,u-x

    # The following corrects the permission mask set for /var/log/rpmpkgs.
    if [ -e /etc/cron.daily/rpm ]; then
    	sed -i '/rpmpkgs/s/0644/0640/' /etc/cron.daily/rpm
    fi

#### Verify Extended ACLs on System Logs [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN001270

References: ECLP-1, ECTP-1, 1314

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl -RLb /var/log/*

#### Verify User Who Owns At Directory [ref]rule

To properly set the owner of `/var/spool/at/`, run the command:

    $ sudo chown root /var/spool/at/

Rationale:

Severity: medium

Identifiers: GEN003420

References: ECLP-1, 225

#### Verify Group Who Owns At Directory [ref]rule

To properly set the group owner of `/var/spool/at/`, run the command:

    $ sudo chgrp root /var/spool/at/

Rationale:

Severity: medium

Identifiers: GEN003430

References: ECLP-1, 225

#### Verify Permissions on At Directory [ref]rule

To properly set the permissions of `/var/spool/at/`, run the command:

    $ sudo chmod 0755 /var/spool/at/

Rationale:

Severity: medium

Identifiers: GEN003400

References: ECLP-1, 225

#### Verify Extended ACLs on At Directory [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN003410

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /var/spool/at

#### Verify User Who Owns YP Files [ref]rule

To properly set the owner of `/var/yp/*`, run the command:

    $ sudo chown root /var/yp/*

Rationale:

Severity: medium

Identifiers: GEN001320

References: ECLP-1, 225

#### Verify Group Who Owns YP Files [ref]rule

To properly set the group owner of `/var/yp/*`, run the command:

    $ sudo chgrp root /var/yp/*

Rationale:

Severity: medium

Identifiers: GEN001340

References: ECLP-1, 225

#### Verify Permissions on YP Files [ref]rule

To properly set the permissions of `/var/yp/*`, run the command:

    $ sudo chmod 0755 /var/yp/*

Rationale:

Severity: medium

Identifiers: GEN001360

References: ECLP-1, 225

#### Verify Extended ACLs on YP Files [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN001361

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl -RLb /var/yp/*

#### Verify Permissions on Xauthority Files [ref]rule

To properly set the permissions of `.Xauthority`, run the command:

    $ sudo chmod 0600 .Xauthority

Rationale:

Severity: medium

Identifiers: GEN005180

References: ECLP-1, 225

#### Verify Extended ACLs on Xauthority Files [ref]rule

No extended ACLs should be applied.

Rationale:

Severity: medium

Identifiers: GEN005190

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    cut -d: -f6 /etc/passwd | sort -u | xargs -n1 -IDIR find DIR -maxdepth 1 -name .Xauthority -o -name .xauth 2>/dev/null | xargs setfacl --remove-all

#### Verify that All World-Writable Directories Have Sticky Bits Set [ref]rule

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.
To set the sticky bit on a world-writable directory DIR, run the following command:

    # chmod +t DIR

Rationale:

Failing to set the sticky bit on public directories allows unauthorized users to delete files in the directory structure.
The only authorized public directories are those temporary directories supplied with the system, or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system, by users for temporary file storage (such as `/tmp`), and for directories requiring global read/write access.

Severity: low

Identifiers: GEN002500

References: ECCD-1, ECCD-2, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    find / /home /var /var/log /var/log/audit -xdev -perm -2 ! -perm -1000 -type d 2>/dev/null | xargs chmod o-w

#### Ensure No World-Writable Files Exist [ref]rule

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.

Rationale:

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.

Severity: medium

Identifiers: GEN002480

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    find / /var /home -xdev -follow -type f -perm -002 2>/dev/null | xargs chmod o-w

#### Ensure All Files Are Owned by a User [ref]rule

If any files are not owned by a user, then the cause of their lack of ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate user.

Rationale:

Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. 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 they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed.

Severity: low

Identifiers: GEN001160

References: ECCD-1, ECCD-2, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    find / /home /var /var/log /var/log/audit -xdev -nouser 2>/dev/null | xargs chown root

#### Ensure All Files Are Owned by a Group [ref]rule

If any files are not owned by a group, then the cause of their lack of group-ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate group.

Rationale:

Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. 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 they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed.

Severity: low

Identifiers: GEN001170

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    find / /home /var /var/log /var/log/audit -xdev -nogroup 2>/dev/null | xargs chown :root

#### Ensure All World-Writable Directories Are Owned by a System Account [ref]rule

All directories in local partitions which are world-writable should be owned by root or another system account. If any world-writable directories are not owned by a system account, this should be investigated. Following this, the files should be deleted or assigned to an appropriate group.

Rationale:

Allowing a user account to own a world-writable 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.

Severity: low

Identifiers: GEN002520

References: ECLP-1, 225

### Restrict Programs from Dangerous Execution Patterns [ref]group

The recommendations in this section are designed to ensure that the system's features to protect against potentially dangerous program execution are activated. These protections are applied at the system initialization or kernel level, and defend against certain types of badly-configured or compromised programs.

contains 3 rules

### Disable Core Dumps [ref]group

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 legitimately need to access these files. The core dump files may also contain sensitive information, or unnecessarily occupy large amounts of disk space.
Once a hard limit is set in `/etc/security/limits.conf`, a user cannot increase that limit within his or her 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.
The core dumps of setuid programs are further protected. The `sysctl` variable `fs.suid_dumpable` controls whether the kernel allows core dumps from these programs at all. The default value of 0 is recommended.

contains 1 rule

#### Disable Core Dumps for All Users [ref]rule

To disable core dumps for all users, add the following line to `/etc/security/limits.conf`:

    *     hard   core    0

Rationale:

A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers trying to debug problems.

Severity: low

Identifiers: GEN003500

References: ECCD-1, ECCD-2, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    echo "*     hard   core    0" >> /etc/security/limits.conf

### Enable ExecShield [ref]group

ExecShield describes kernel features that provide protection against exploitation of memory corruption errors such as 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. These protections are enabled by default and controlled through `sysctl` variables `kernel.exec-shield` and `kernel.randomize_va_space`.

contains 2 rules

#### Enable ExecShield and Randomized Layout of Virtual Address Space [ref]rule

To set the runtime status of the `kernel.exec-shield` kernel parameter, run the following command:

    $ sudo sysctl -w kernel.exec-shield=1

If this is not the system's default value, add the following line to `/etc/sysctl.conf`:

    kernel.exec-shield = 1

To set the runtime status of the `kernel.randomize_va_space` kernel parameter, run the following command:

    $ sudo sysctl -w kernel.randomize_va_space=1

If this is not the system's default value, add the following line to `/etc/sysctl.conf`:

    kernel.randomize_va_space = 1

Rationale:

ExecShield uses the segmentation feature on all x86 systems to prevent execution in memory higher than a certain address. It writes an address as a limit in the code segment descriptor, to control where code can be executed, on a per-process basis. When the kernel places a process's memory regions such as the stack and heap higher than this address, the hardware prevents execution in that address range. Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code they have introduced into a process's address space during an attempt at exploitation. Additionally, ASLR makes it more difficult for an attacker to know the location of existing code in order to re-purpose it using return oriented programming (ROP) techniques.

Severity: medium

Identifiers: GEN003540

References: ECCD-1, ECCD-2, ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [[ "`uname -r`" != "2.6.9"* ]]; then
    	/sbin/sysctl -q -n -w kernel.randomize_va_space=1
    	if grep --silent ^kernel.randomize_va_space /etc/sysctl.conf ; then
    		sed -i 's/^kernel.randomize_va_space.*/kernel.randomize_va_space = 1/g' /etc/sysctl.conf
    	else
    		echo "" >> /etc/sysctl.conf
    		echo "# Set kernel.randomize_va_space to 1 per security requirements" >> /etc/sysctl.conf
    		echo "kernel.randomize_va_space = 1" >> /etc/sysctl.conf
    	fi
    fi

    /sbin/sysctl -q -n -w kernel.exec-shield=1
    if grep --silent ^kernel.exec-shield /etc/sysctl.conf ; then
    	sed -i 's/^kernel.exec-shield.*/kernel.exec-shield = 1/g' /etc/sysctl.conf
    else
    	echo "" >> /etc/sysctl.conf
    	echo "# Set kernel.exec-shield to 1 per security requirements" >> /etc/sysctl.conf
    	echo "kernel.exec-shield = 1" >> /etc/sysctl.conf
    fi

#### Enable ExecShield [ref]rule

To set the runtime status of the `kernel.exec-shield` kernel parameter, run the following command:

    $ sudo sysctl -w kernel.exec-shield=1

If this is not the system's default value, add the following line to `/etc/sysctl.conf`:

    kernel.exec-shield = 1

Rationale:

ExecShield uses the segmentation feature on all x86 systems to prevent execution in memory higher than a certain address. It writes an address as a limit in the code segment descriptor, to control where code can be executed, on a per-process basis. When the kernel places a process's memory regions such as the stack and heap higher than this address, the hardware prevents execution in that address range.

Severity: low

Identifiers: GEN008420

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    /sbin/sysctl -q -n -w kernel.exec-shield=1
    if grep --silent ^kernel.exec-shield /etc/sysctl.conf ; then
    	sed -i 's/^kernel.exec-shield.*/kernel.exec-shield = 1/g' /etc/sysctl.conf
    else
    	echo "" >> /etc/sysctl.conf
    	echo "# Set kernel.exec-shield to 1 per security requirements" >> /etc/sysctl.conf
    	echo "kernel.exec-shield = 1" >> /etc/sysctl.conf
    fi

### SELinux [ref]group

SELinux is a feature of the Linux kernel which can be used to guard against misconfigured or compromised programs. SELinux enforces the idea that programs should be limited in what files they can access and what actions they can take.
The default SELinux policy, as configured on Red Hat Enterprise Linux 6, has been sufficiently developed and debugged that it should be usable on almost any Red Hat machine with minimal configuration and a small amount of system administrator training. This policy prevents system services - including most of the common network-visible services such as mail servers, FTP servers, and DNS servers - from accessing files which those services have no valid reason to access. This action alone prevents a huge amount of possible damage from network attacks against services, from trojaned software, and so forth.
This guide recommends that SELinux be enabled using the default (targeted) policy on every Red Hat system, unless that system has requirements which make a stronger policy appropriate.

contains 1 rule

### Enable SELinux [ref]group

Edit the file `/etc/selinux/config`. Add or correct the following lines:

    SELINUX=enforcing
    SELINUXTYPE=targeted

Edit the file `/etc/grub.conf`. Ensure that the following arguments DO NOT appear on any kernel command line in the file:

    selinux=0
    enforcing=0

The directive `SELINUX=enforcing` enables SELinux at boot time. If SELinux is suspected of involvement with boot-time problems (unlikely), it is possible to boot into the warning-only mode `SELINUX=permissive` for debugging purposes. Make certain to change the mode back to enforcing after debugging, set the filesystems to be relabeled for consistency using the command `touch /.autorelabel`, and reboot.
However, the Red Hat Enterprise Linux 6 default SELinux configuration should be sufficiently reasonable that most systems will boot without serious problems. Some applications that require deep or unusual system privileges, such as virtual machine software, may not be compatible with SELinux in its default configuration. However, this should be uncommon, and SELinux's application support continues to improve. In other cases, SELinux may reveal unusual or insecure program behavior by design.
The directive `SELINUXTYPE=targeted` configures SELinux to use the default targeted policy.
The SELinux boot mode specified in `/etc/selinux/config` can be overridden by command-line arguments passed to the kernel. It is necessary to check `grub.conf` to ensure that this has not been done and to protect the boot process.

contains 1 rule

#### Ensure SELinux State is Enforcing and Policy is Targeted [ref]rule

The SELinux state should be set to `enforcing` and the SELinux policy should be set to `targeted` at system boot time. In the file `/etc/selinux/config`, add or correct the following lines to configure the system to boot into enforcing mode with the targeted policy:

    SELINUX=enforcing

    SELINUXTYPE=targeted

Rationale:

Setting the SELinux state to `enforcing` ensures SELinux is able to confine potentially compromised processes to the security policy, which is designed to prevent them from causing damage to the system or further elevating their privileges. Setting the SELinux policy to `targeted` or a more specialized policy ensures the system will confine processes that are likely to be targeted for exploitation, such as network or system services.

Severity: low

Identifiers: GEN000000-LNX00800

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    var_selinux_policy_name="targeted"

    if [ "`grep -c ^SELINUX= /etc/sysconfig/selinux`" = "0" ]; then
    	echo SELINUX=enforcing >> /etc/sysconfig/selinux
    else
    	sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/sysconfig/selinux
    fi

    if [ "`grep -c ^SELINUX= /etc/selinux/config`" = "0" ]; then
    	echo SELINUX=enforcing >> /etc/selinux/config
    else
    	sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config
    fi

    if [ "`grep -c ^SELINUXTYPE= /etc/sysconfig/selinux`" = "0" ]; then
    	echo SELINUXTYPE=${var_selinux_policy_name} >> /etc/sysconfig/selinux
    else
    	sed -i "s/^SELINUXTYPE=.*/SELINUXTYPE=${var_selinux_policy_name}/" /etc/sysconfig/selinux
    fi

    if [ "`grep -c ^SELINUXTYPE= /etc/selinux/config`" = "0" ]; then
    	echo SELINUXTYPE=${var_selinux_policy_name} >> /etc/selinux/config
    else
    	sed -i "s/^SELINUXTYPE=.*/SELINUXTYPE=${var_selinux_policy_name}/" /etc/selinux/config
    fi

### Account and Access Control [ref]group

In traditional Unix security, if an attacker gains shell access to a certain login account, they can perform any action or access any file to which that account has access. Therefore, making it more difficult for unauthorized people to gain shell access to accounts, particularly to privileged accounts, is a necessary part of securing a system. This section introduces mechanisms for restricting access to accounts under Red Hat Enterprise Linux 5.

contains 50 rules

### Special Privileged Accounts Exist [ref]group

The system must not have special privilege accounts, such as `shutdown`, `reboot`, `halt`, `ftp`, `games`, `gopher`, and `news`.

contains 5 rules

#### Special Privileged Accounts [ref]rule

Remove any special privilege accounts, such as `shutdown`, `reboot`, and `halt`, from the /etc/passwd and /etc/shadow files using the `userdel` or `system-config-users` commands.

Rationale:

If special privilege accounts are compromised, the accounts could provide privileges to execute malicious commands on a system.

Severity: high

Identifiers: GEN000000-LNX00320

References: IAAC-1, 225, 764

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    /usr/bin/id shutdown &>/dev/null && /usr/sbin/userdel shutdown
    /usr/bin/id halt &>/dev/null && /usr/sbin/userdel halt
    /usr/bin/id reboot &>/dev/null && /usr/sbin/userdel reboot

#### Ftp Account [ref]rule

Remove the `ftp` account from the /etc/passwd and /etc/shadow files using the `userdel` or `system-config-users` commands.

Rationale:

Accounts that provide no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system.

Severity: medium

Identifiers: GEN000290-4

References: IAAC-1, 12

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    /usr/bin/id ftp &>/dev/null && /usr/sbin/userdel ftp

#### Games Account [ref]rule

Remove the `games` account from the /etc/passwd and /etc/shadow files using the `userdel` or `system-config-users` commands.

Rationale:

Accounts that provide no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system.

Severity: medium

Identifiers: GEN000290-1

References: IAAC-1, 12

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    /usr/bin/id games &>/dev/null && /usr/sbin/userdel games

#### Gopher Account [ref]rule

Remove the `gopher` account from the /etc/passwd and /etc/shadow files using the `userdel` or `system-config-users` commands.

Rationale:

Accounts that provide no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system.

Severity: medium

Identifiers: GEN000290-3

References: IAAC-1, 12

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    /usr/bin/id gopher &>/dev/null && /usr/sbin/userdel gopher

#### News Account [ref]rule

Remove the `news` account from the /etc/passwd and /etc/shadow files using the `userdel` or `system-config-users` commands.

Rationale:

Accounts that provide no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system.

Severity: medium

Identifiers: GEN000290-2

References: IAAC-1, 12

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    /usr/bin/id news &>/dev/null && /usr/sbin/userdel news

### Protect Accounts by Restricting Password-Based Login [ref]group

Conventionally, Unix shell accounts are accessed by providing a username and password to a login program, which tests these values for correctness using the `/etc/passwd` and `/etc/shadow` files. Password-based login is vulnerable to guessing of weak passwords, and to sniffing and man-in-the-middle attacks against passwords entered over a network or at an insecure console. Therefore, mechanisms for accessing accounts by entering usernames and passwords should be restricted to those which are operationally necessary.

contains 12 rules

### Restrict Root Logins [ref]group

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 then 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 also 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. Other sections of this document include guidance describing how to prevent root from logging in via SSH.

contains 4 rules

#### Restrict Virtual Console Root Logins [ref]rule

To restrict root logins through the (deprecated) virtual console devices, ensure lines of this form do not appear in `/etc/securetty`:

    vc/1
    vc/2
    vc/3
    vc/4

Rationale:

Preventing direct root login to virtual console devices helps ensure accountability for actions taken on the system using the root account.

Severity: medium

Identifiers: GEN000980

References: ECPA-1, ECSD-2, 770

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    echo tty1 > /etc/securetty

#### Restrict Web Browser Use for Administrative Accounts [ref]rule

Enforce policy requiring administrative accounts use web browsers only for local service administration.

Rationale:

If a browser vulnerability is exploited while running with administrative privileges, the entire system could be compromised. Specific exceptions for local service administration should be documented in site-defined policy.

Severity: low

Identifiers: GEN004220

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    rm -rf `grep ^root: /etc/passwd | awk -F: '{ print $6 }'`/.mozilla

#### Verify Only Root Has UID 0 [ref]rule

If any account other than root has a UID of 0, this misconfiguration should be investigated and the accounts other than root should be removed or have their UID changed.

Rationale:

An account has root authority if it has a UID of 0. Multiple accounts with a UID of 0 afford more opportunity for potential intruders to guess a password for a privileged account. Proper configuration of sudo is recommended to afford multiple system administrators access to root privileges in an accountable manner.

Severity: medium

Identifiers: GEN000880

References: ECLP-1, IAIA-1, IAIA-2, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    for UID0_USER in `cat /etc/passwd | cut -d: -f1,3 | grep :0$ | grep -v ^root: | cut -d: -f1`; do
    	userdel -rf ${UID0_USER}
    done

#### Switching To Root Account Must Require Wheel Membership [ref]rule

Ensure that only members of the wheel group are allowed to switch to the root account.

Rationale:

Configuring a supplemental group for users permitted to switch to the root user prevents unauthorized users from accessing the root account, even with knowledge of the root credentials.

Severity: low

Identifiers: GEN000850

References: ECLP-1, 9

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ "$(grep -c '#.*auth.*required.*pam_wheel.so' /etc/pam.d/su)" != "0" ]; then
    	sed -i '/auth.*required.*pam_wheel.so/s/#//g' /etc/pam.d/su
    else
    	sed -i '/auth.*include/iauth\t\trequired\tpam_wheel.so use_uid' /etc/pam.d/su
    fi

### Verify Proper Storage and Existence of Password Hashes [ref]group

By default, password hashes for local accounts are stored in the second field (colon-separated) in `/etc/shadow`. This file should be readable only by processes running with root credentials, preventing users from casually accessing others' password hashes and attempting to crack them. However, it remains possible to misconfigure the system and store password hashes in world-readable files such as `/etc/passwd`, or to even store passwords themselves in plaintext on the system. Using system-provided tools for password change/creation should allow administrators to avoid such misconfiguration.

contains 4 rules

#### Prevent Log In to Accounts With Empty Password [ref]rule

If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. Remove any instances of the `nullok` option in `/etc/pam.d/system-auth` to prevent logins with empty passwords.

Rationale:

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

Severity: high

Identifiers: GEN000560

References: IAIA-1, IAIA-2, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    sed --follow-symlinks -i 's/\<nullok\>//g' /etc/pam.d/system-auth

#### Verify All Account Password Hashes are Shadowed [ref]rule

If any password hashes are stored in `/etc/passwd` (in the second field, instead of an `x`), the cause of this misconfiguration should be investigated. The account should have its password reset and the hash should be properly stored, or the account should be deleted entirely.

Rationale:

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.

Severity: medium

Identifiers: GEN001470

References: ECLP-1, 201

#### All GIDs referenced in /etc/passwd must be defined in /etc/group [ref]rule

Add a group to the system for each GID referenced without a corresponding group.

Rationale:

Inconsistency in GIDs between `/etc/passwd` and `/etc/group` could lead to a user having unintended rights.

Severity: low

Identifiers: GEN000380

References: ECSC-1, 366

#### Verify No netrc Files Exist [ref]rule

The `.netrc` files contain login information used to auto-login into FTP servers and reside in the user's home directory. These files may contain unencrypted passwords to remote FTP servers making them susceptible to access by unauthorized users and should not be used. Any `.netrc` files should be removed.

Rationale:

Unencrypted passwords for remote FTP servers may be stored in `.netrc` files. DoD policy requires passwords be encrypted in storage and not used in access scripts.

Severity: medium

Identifiers: GEN002000

References: ECCD-1, ECCD-2, IAIA-1, IAIA-2, 196

### Set Password Expiration Parameters [ref]group

The file `/etc/login.defs` controls several password-related settings. Programs such as `passwd`, `su`, and `login` consult `/etc/login.defs` to determine behavior with regard to password aging, expiration warnings, and length. See the man page `login.defs(5)` for more information.
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.
For example, for each existing human user USER, expiration parameters could be adjusted to a 180 day maximum password age, 7 day minimum password age, and 7 day warning period with the following command:

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

contains 2 rules

#### Set Password Minimum Age [ref]rule

To specify password minimum age for new accounts, edit the file `/etc/login.defs` and add or correct the following line, replacing DAYS appropriately:

    PASS_MIN_DAYS DAYS

A value of 1 day is considered for sufficient for many environments. The DoD requirement is 1. Rationale:

Setting the minimum password age protects against users cycling back to a favorite password after satisfying the password reuse requirement.

Severity: medium

Identifiers: GEN000540

References: ECSC-1, 198

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    var_accounts_minimum_age_login_defs="1"

    grep -q ^PASS_MIN_DAYS /etc/login.defs && \
      sed -i "s/PASS_MIN_DAYS.*/PASS_MIN_DAYS     $var_accounts_minimum_age_login_defs/g" /etc/login.defs
    if ! [ $? -eq 0 ]; then
        echo "PASS_MIN_DAYS      $var_accounts_minimum_age_login_defs" >> /etc/login.defs
    fi

    USERACCT=$(egrep -v "^\+|^#" /etc/passwd | cut -d":" -f1)
    for SYS_USER in ${USERACCT}; do
    	if [ $(grep -c ${SYS_USER} /etc/shadow) != 0 ]; then
    		passwd -n $var_accounts_minimum_age_login_defs ${SYS_USER} &>/dev/null
    	fi
    done

#### Set Password Maximum Age [ref]rule

To specify password maximum age for new accounts, edit the file `/etc/login.defs` and add or correct the following line, replacing DAYS appropriately:

    PASS_MAX_DAYS DAYS

A value of 180 days is sufficient for many environments. The DoD requirement is 60. Rationale:

Setting the password maximum age ensures users are required to periodically change their passwords. This could possibly decrease the utility of a stolen password. Requiring shorter password lifetimes increases the risk of users writing down the password in a convenient location subject to physical compromise.

Severity: medium

Identifiers: GEN000700

References: IAIA-1, IAIA-2, 180

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    var_accounts_maximum_age_login_defs="60"

    grep -q ^PASS_MAX_DAYS /etc/login.defs && \
      sed -i "s/PASS_MAX_DAYS.*/PASS_MAX_DAYS     $var_accounts_maximum_age_login_defs/g" /etc/login.defs
    if ! [ $? -eq 0 ]; then
        echo "PASS_MAX_DAYS      $var_accounts_maximum_age_login_defs" >> /etc/login.defs
    fi

    USERACCT=$(egrep -v "^\+|^#" /etc/passwd | cut -d":" -f1)
    for SYS_USER in ${USERACCT}; do
    	if [ $(grep -c ${SYS_USER} /etc/shadow) != 0 ]; then
    		passwd -x $var_accounts_maximum_age_login_defs ${SYS_USER} &>/dev/null
    	fi
    done

### Set Account Expiration Parameters [ref]group

Accounts can be configured to be automatically disabled after a certain time period, meaning that they will require administrator interaction to become usable again. Expiration of accounts after inactivity can be set for all accounts by default and also on a per-account basis, such as for accounts that are known to be temporary. To configure automatic expiration of an account following the expiration of its password (that is, after the password has expired and not been changed), run the following command, substituting `NUM_DAYS` and `USER` appropriately:

    # chage -I NUM_DAYS USER

Accounts, such as temporary accounts, can also be configured to expire on an explicitly-set date with the `-E` option. The file `/etc/default/useradd` controls default settings for all newly-created accounts created with the system's normal command line utilities.

contains 2 rules

#### Set Account Expiration Following Inactivity [ref]rule

To specify the number of days after a password expires (which signifies inactivity) until an account is permanently disabled, add or correct the following lines in `/etc/default/useradd`, substituting `NUM_DAYS` appropriately:

    INACTIVE=NUM_DAYS

A value of 35 is recommended. If a password is currently on the verge of expiration, then 35 days remain until the account is automatically disabled. However, if the password will not expire for another 60 days, then 95 days could elapse until the account would be automatically disabled. See the `useradd` man page for more information. Determining the inactivity timeout must be done with careful consideration of the length of a "normal" period of inactivity for users in the particular environment. Setting the timeout too low incurs support costs and also has the potential to impact availability of the system to legitimate users. Rationale:

Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials.

Severity: low

Identifiers: GEN006660

References: AC-2(3), 17

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    var_account_disable_post_pw_expiration="35"

    if [ $(cat /etc/default/useradd | grep -c "^INACTIVE=") != 0 ]; then
    	sed -i "s/^INACTIVE=.*/INACTIVE=${var_account_disable_post_pw_expiration}/" /etc/default/useradd
    else
    	echo INACTIVE=${var_account_disable_post_pw_expiration} >>/etc/default/useradd
    fi

#### Ensure All Accounts on the System Have Unique Names [ref]rule

Change usernames, or delete accounts, so each has a unique name.

Rationale:

Unique usernames allow for accountability on the system.

Severity: low

Identifiers: GEN000300

References: IAIA-1, IAIA-2, 764

### Protect Accounts by Configuring PAM [ref]group

PAM, or Pluggable Authentication Modules, is a system which implements modular authentication for Linux programs. PAM provides a flexible and configurable architecture for authentication, and it should be configured to minimize exposure to unnecessary risk. This section contains guidance on how to accomplish that.
PAM is implemented as a set of shared objects which are loaded and invoked whenever an application wishes to authenticate a user. Typically, the application must be running as root in order to take advantage of PAM, because PAM's modules often need to be able to access sensitive stores of account information, such as /etc/shadow. Traditional privileged network listeners (e.g. sshd) or SUID programs (e.g. sudo) already meet this requirement. An SUID root application, userhelper, is provided so that programs which are not SUID or privileged themselves can still take advantage of PAM.
PAM looks in the directory `/etc/pam.d` for application-specific configuration information. For instance, if the program login attempts to authenticate a user, then PAM's libraries follow the instructions in the file `/etc/pam.d/login` to determine what actions should be taken.
One very important file in `/etc/pam.d` is `/etc/pam.d/system-auth`. This file, which is included by many other PAM configuration files, defines 'default' system authentication measures. Modifying this file is a good way to make far-reaching authentication changes, for instance when implementing a centralized authentication service.

Warning: Be careful when making changes to PAM's configuration files. The syntax for these files is complex, and modifications can have unexpected consequences. The default configurations shipped with applications should be sufficient for most users.
Warning: Running `authconfig` or `system-config-authentication` will re-write the PAM configuration files, destroying any manually made changes and replacing them with a series of system defaults. One reference to the configuration file syntax can be found at http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-configuration-file.html.

contains 13 rules

### Set Password Quality Requirements [ref]group

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 man page `pam_cracklib(8)` provides information on the capabilities and configuration of each.

contains 9 rules

### Set Password Quality Requirements, if using pam_cracklib [ref]group

The `pam_cracklib` PAM module can be configured to meet requirements for a variety of policies.
For example, to configure `pam_cracklib` to require at least one uppercase character, lowercase character, digit, and other (special) character, locate the following line in `/etc/pam.d/system-auth`:

    password requisite pam_cracklib.so try_first_pass retry=3

and then alter it to read:

    password required pam_cracklib.so try_first_pass retry=3 maxrepeat=3 minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 difok=4

If no such line exists, add one as the first line of the password section in `/etc/pam.d/system-auth`. The arguments can be modified to ensure compliance with your organization's security policy. Discussion of each parameter follows.
Warning: Note that the password quality requirements are not enforced for the root account for some reason.

contains 9 rules

#### Include Cracklib Password Module [ref]rule

To ensure the cracklib password module is being enforced and its configuration is not being overwritten by authconfig, the cracklib module must be defined in /etc/pam.d/system-auth. Additionally, the /etc/pam.d/passwd file must ensure the `password include` statement points to system-auth and not system-auth-ac.

Rationale:

An easily guessable password provides an open door to any external or internal malicious intruder. Many computer compromises occur as the result of account name and password guessing. This is generally done by someone with an automated script that uses repeated logon attempts until the correct account and password pair is guessed. Utilities, such as cracklib, can be used to validate passwords are not dictionary words and meet other criteria during password changes.

Severity: low

Identifiers: GEN000790

References: IAIA-1, IAIA-2, 189

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    authconfig --updateall
    if [ -e /etc/pam.d/system-auth-ac ]; then
    	sed -i '/password.*include.*system-auth-ac/ipassword    required     pam_cracklib.so' /etc/pam.d/system-auth
    else
    	sed -i '/password.*unix.so/ipassword    required     pam_cracklib.so' /etc/pam.d/system-auth
    fi

#### Set Password Minimum Length [ref]rule

To specify password length requirements for new accounts, edit the file `/etc/login.defs` and add or correct the following lines:

    PASS_MIN_LEN 14

The DoD requirement is `14`. The FISMA requirement is `12`. If a program consults `/etc/login.defs` and also another PAM module (such as `pam_cracklib`) during a password change operation, then the most restrictive must be satisfied. See PAM section for more information about enforcing password quality requirements. Rationale:

Requiring a minimum password length makes password cracking attacks more difficult by ensuring a larger search space. However, any security benefit from an onerous requirement must be carefully weighed against usability problems, support costs, or counterproductive behavior that may result.

Severity: medium

Identifiers: GEN000585

References: IAIA-1, IAIA-2, 205

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    var_password_pam_cracklib_minlen="14"

    if [ $(grep -c "minlen=" /etc/pam.d/system-auth) != 0 ]; then
    	sed -i "s/minlen=[0-9]*/minlen=$var_password_pam_cracklib_minlen/" /etc/pam.d/system-auth
    else
    	sed -i "/password.*pam_cracklib.so/s/$/ minlen=$var_password_pam_cracklib_minlen/" /etc/pam.d/system-auth
    fi
    if [ -e /etc/pam.d/system-auth-ac ]; then
    	if [ $(grep -c "minlen=" /etc/pam.d/system-auth-ac) != 0 ]; then
    		sed -i "s/minlen=[0-9]*/minlen=$var_password_pam_cracklib_minlen/" /etc/pam.d/system-auth-ac
    	else
    		sed -i "/password.*pam_cracklib.so/s/$/ minlen=$var_password_pam_cracklib_minlen/" /etc/pam.d/system-auth-ac
    	fi
    fi

#### Set Password to Maximum of Three Consecutive Repeating Characters [ref]rule

The pam_cracklib module's `maxrepeat` parameter controls requirements for consecutive repeating characters. When set to a positive number, it will reject passwords which contain more than that number of consecutive characters. Add `maxrepeat=3` after pam_cracklib.so to prevent a run of four or more identical characters.

Rationale:

Passwords with excessive repeating characters may be more vulnerable to password-guessing attacks.

Severity: low

Identifiers: GEN000680

References: IAIA-1, IAIA-2, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    var_password_pam_cracklib_maxrepeat="3"

    if [ $(grep -c "maxrepeat=" /etc/pam.d/system-auth) != 0 ]; then
    	sed -i "s/maxrepeat=[0-9]*/maxrepeat=$var_password_pam_cracklib_maxrepeat/" /etc/pam.d/system-auth
    else
    	sed -i "/password.*pam_cracklib.so/s/$/ maxrepeat=$var_password_pam_cracklib_maxrepeat/" /etc/pam.d/system-auth
    fi
    if [ -e /etc/pam.d/system-auth-ac ]; then
    	if [ $(grep -c "maxrepeat=" /etc/pam.d/system-auth-ac) != 0 ]; then
    		sed -i "s/maxrepeat=[0-9]*/maxrepeat=$var_password_pam_cracklib_maxrepeat/" /etc/pam.d/system-auth-ac
    	else
    		sed -i "/password.*pam_cracklib.so/s/$/ maxrepeat=$var_password_pam_cracklib_maxrepeat/" /etc/pam.d/system-auth-ac
    	fi
    fi

#### Set Password Strength Minimum Digit Characters [ref]rule

The pam_cracklib module's `dcredit` parameter controls requirements for usage of digits in a password. When set to a negative number, any password will be required to contain that many digits. When set to a positive number, pam_cracklib will grant +1 additional length credit for each digit. Add `dcredit=-1` after pam_cracklib.so to require use of a digit in passwords.

Rationale:

Requiring digits makes password guessing attacks more difficult by ensuring a larger search space.

Severity: low

Identifiers: GEN000620

References: IAIA-1, IAIA-2, 194

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    var_password_pam_cracklib_dcredit="-1"

    if [ $(grep -c "dcredit=" /etc/pam.d/system-auth) != 0 ]; then
    	sed -i "s/dcredit=[0-9]*/dcredit=$var_password_pam_cracklib_dcredit/" /etc/pam.d/system-auth
    else
    	sed -i "/password.*pam_cracklib.so/s/$/ dcredit=$var_password_pam_cracklib_dcredit/" /etc/pam.d/system-auth
    fi
    if [ -e /etc/pam.d/system-auth-ac ]; then
    	if [ $(grep -c "dcredit=" /etc/pam.d/system-auth-ac) != 0 ]; then
    		sed -i "s/dcredit=[0-9]*/dcredit=$var_password_pam_cracklib_dcredit/" /etc/pam.d/system-auth-ac
    	else
    		sed -i "/password.*pam_cracklib.so/s/$/ dcredit=$var_password_pam_cracklib_dcredit/" /etc/pam.d/system-auth-ac
    	fi
    fi

#### Set Password Strength Minimum Uppercase Characters [ref]rule

The pam_cracklib module's `ucredit=` parameter controls requirements for usage of uppercase letters in a password. When set to a negative number, any password will be required to contain that many uppercase characters. When set to a positive number, pam_cracklib will grant +1 additional length credit for each uppercase character. Add `ucredit=-1` after pam_cracklib.so to require use of an upper case character in passwords.

Rationale:

Requiring a minimum number of uppercase characters makes password guessing attacks more difficult by ensuring a larger search space.

Severity: low

Identifiers: GEN000600

References: IAIA-1, IAIA-2, 192

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    var_password_pam_cracklib_ucredit="-1"

    if [ $(grep -c "ucredit=" /etc/pam.d/system-auth) != 0 ]; then
    	sed -i "s/ucredit=[0-9]*/ucredit=$var_password_pam_cracklib_ucredit/" /etc/pam.d/system-auth
    else
    	sed -i "/password.*pam_cracklib.so/s/$/ ucredit=$var_password_pam_cracklib_ucredit/" /etc/pam.d/system-auth
    fi
    if [ -e /etc/pam.d/system-auth-ac ]; then
    	if [ $(grep -c "ucredit=" /etc/pam.d/system-auth-ac) != 0 ]; then
    		sed -i "s/ucredit=[0-9]*/ucredit=$var_password_pam_cracklib_ucredit/" /etc/pam.d/system-auth-ac
    	else
    		sed -i "/password.*pam_cracklib.so/s/$/ ucredit=$var_password_pam_cracklib_ucredit/" /etc/pam.d/system-auth-ac
    	fi
    fi

#### Set Password Strength Minimum Special Characters [ref]rule

The pam_cracklib module's `ocredit=` parameter controls requirements for usage of special (or ``other'') characters in a password. When set to a negative number, any password will be required to contain that many special characters. When set to a positive number, pam_cracklib will grant +1 additional length credit for each special character. Add `ocredit=-1` after pam_cracklib.so to require use of a special character in passwords.

Rationale:

Requiring a minimum number of special characters makes password guessing attacks more difficult by ensuring a larger search space.

Severity: low

Identifiers: GEN000640

References: IAIA-1, IAIA-2, 1619

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    var_password_pam_cracklib_ocredit="-1"

    if [ $(grep -c "ocredit=" /etc/pam.d/system-auth) != 0 ]; then
    	sed -i "s/ocredit=[0-9]*/ucredit=$var_password_pam_cracklib_ocredit/" /etc/pam.d/system-auth
    else
    	sed -i "/password.*pam_cracklib.so/s/$/ ocredit=$var_password_pam_cracklib_ocredit/" /etc/pam.d/system-auth
    fi
    if [ -e /etc/pam.d/system-auth-ac ]; then
    	if [ $(grep -c "ocredit=" /etc/pam.d/system-auth-ac) != 0 ]; then
    		sed -i "s/ocredit=[0-9]*/ucredit=$var_password_pam_cracklib_ocredit/" /etc/pam.d/system-auth-ac
    	else
    		sed -i "/password.*pam_cracklib.so/s/$/ ocredit=$var_password_pam_cracklib_ocredit/" /etc/pam.d/system-auth-ac
    	fi
    fi

#### Set Password Strength Minimum Lowercase Characters [ref]rule

The pam_cracklib module's `lcredit=` parameter controls requirements for usage of lowercase letters in a password. When set to a negative number, any password will be required to contain that many lowercase characters. When set to a positive number, pam_cracklib will grant +1 additional length credit for each lowercase character. Add `lcredit=-1` after pam_cracklib.so to require use of a lowercase character in passwords.

Rationale:

Requiring a minimum number of lowercase characters makes password guessing attacks more difficult by ensuring a larger search space.

Severity: low

Identifiers: GEN000610

References: IAIA-1, IAIA-2, 193

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    var_password_pam_cracklib_lcredit="-1"

    if [ $(grep -c "lcredit=" /etc/pam.d/system-auth) != 0 ]; then
    	sed -i "s/lcredit=[0-9]*/lcredit=$var_password_pam_cracklib_lcredit/" /etc/pam.d/system-auth
    else
    	sed -i "/password.*pam_cracklib.so/s/$/ lcredit=$var_password_pam_cracklib_lcredit/" /etc/pam.d/system-auth
    fi
    if [ -e /etc/pam.d/system-auth-ac ]; then
    	if [ $(grep -c "lcredit=" /etc/pam.d/system-auth-ac) != 0 ]; then
    		sed -i "s/lcredit=[0-9]*/lcredit=$var_password_pam_cracklib_lcredit/" /etc/pam.d/system-auth-ac
    	else
    		sed -i "/password.*pam_cracklib.so/s/$/ lcredit=$var_password_pam_cracklib_lcredit/" /etc/pam.d/system-auth-ac
    	fi
    fi

#### Set Password Strength Minimum Different Characters [ref]rule

The pam_cracklib module's `difok` parameter controls requirements for usage of different characters during a password change. Add `difok=NUM` after pam_cracklib.so to require differing characters when changing passwords, substituting NUM appropriately. The DoD requirement is `4`.

Rationale:

Requiring a minimum number of different characters during password changes ensures that newly changed passwords should not resemble previously compromised ones. Note that passwords which are changed on compromised systems will still be compromised, however.

Severity: low

Identifiers: GEN000750

References: IAIA-1, IAIA-2, 195

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    var_password_pam_cracklib_difok="4"

    if [ $(grep -c "difok=" /etc/pam.d/system-auth) != 0 ]; then
    	sed -i "s/difok=[0-9]*/difok=$var_password_pam_cracklib_difok/" /etc/pam.d/system-auth
    else
    	sed -i "/password.*pam_cracklib.so/s/$/ difok=$var_password_pam_cracklib_difok/" /etc/pam.d/system-auth
    fi
    if [ -e /etc/pam.d/system-auth-ac ]; then
    	if [ $(grep -c "difok=" /etc/pam.d/system-auth-ac) != 0 ]; then
    		sed -i "s/difok=[0-9]*/difok=$var_password_pam_cracklib_difok/" /etc/pam.d/system-auth-ac
    	else
    		sed -i "/password.*pam_cracklib.so/s/$/ difok=$var_password_pam_cracklib_difok/" /etc/pam.d/system-auth-ac
    	fi
    fi

#### Limit Password Reuse [ref]rule

Do not allow users to reuse recent passwords. This can be accomplished by using the `remember` option for the `pam_unix` PAM module. In the file `/etc/pam.d/system-auth`, append `remember=24` to the line which refers to the `pam_unix.so` module, as shown:

    password sufficient pam_unix.so existing_options remember=24

The DoD and FISMA requirement is 24 passwords.Rationale:

Preventing re-use of previous passwords helps ensure that a compromised password is not re-used by a user.

Severity: medium

Identifiers: GEN000800

References: IAIA-1, IAIA-2, 200

### Set Authentication Failure Actions [ref]group

The system should be configured to handle authentication failures so that password cracking attempts are mitigated.

Warning: Locking out user accounts presents the risk of a denial-of-service attack. The lockout policy must weigh whether the risk of such a denial-of-service attack outweighs the benefits of thwarting password guessing attacks.

contains 2 rules

#### Set Deny For Failed Password Attempts [ref]rule

To configure the system to lock out accounts after a number of incorrect login attempts using `pam_faillock.so`:
Add the following lines immediately below the `pam_unix.so` statement in `AUTH` section of `/etc/pam.d/system-auth`:

    auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 fail_interval=900

    auth required pam_faillock.so authsucc deny=3 unlock_time=604800 fail_interval=900

Rationale:

Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks.

Severity: medium

Identifiers: GEN000460

References: ECLO-1, ECLO-2, 44

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    var_accounts_password_pam_tally_deny="3"

    if [ $(grep auth.*required.*pam_tally2 /etc/pam.d/system-auth | grep -c "deny=") != 0 ]; then
    	sed -i "/account.*required.*pam_tally/s/deny=[0-9]*/deny=${var_accounts_password_pam_tally_deny}/" /etc/pam.d/system-auth
    elif [ $(grep -c "auth.*required.*pam_tally2" /etc/pam.d/system-auth) = 0 ]; then
    	if [ $(grep -c "pam_tally.so" /etc/pam.d/system-auth) != 0 ]; then
    		sed -i "s/pam_tally.so/pam_tally2.so/g" /etc/pam.d/system-auth
    	elif [ $(grep -c "auth.*include.*system-auth-ac" /etc/pam.d/system-auth) != 0 ]; then
    		sed -i 's/\(auth\s*include\s*system-auth-ac\)/auth        required     pam_tally2.so\n\1/' /etc/pam.d/system-auth
    	elif [ $(grep -c "auth.*pam_unix.so" /etc/pam.d/system-auth) != 0 ]; then
    		sed -i 's/\(auth.*pam_unix.so\)/auth        required     pam_tally2.so\n\1/' /etc/pam.d/system-auth
    	elif [ $(grep -c "auth.*pam_deny.so" /etc/pam.d/system-auth) != 0 ]; then
    		sed -i 's/\(auth.*pam_deny.so\)/auth        required     pam_tally2.so\n\1/' /etc/pam.d/system-auth
    	else
    		sed -i ':a;N;$!ba;s/\([\n]*[#]*[\s]*account\)/\nauth        required     pam_tally2.so\n\1/' /etc/pam.d/system-auth
    	fi
    	sed -i "/auth.*pam_tally/s/$/ deny=${var_accounts_password_pam_tally_deny}/" /etc/pam.d/system-auth
    else
    	sed -i "/auth.*pam_tally/s/$/ deny=${var_accounts_password_pam_tally_deny}/" /etc/pam.d/system-auth
    fi
    if [ ! -e /var/log/tallylog ]; then
    	>/var/log/tallylog
    fi
    chmod 640 /var/log/tallylog
    chown root:root /var/log/tallylog

#### Set Delay Between Failed Password Attempts [ref]rule

Check the value of the FAIL_DELAY variable and the ability to use it.

Rationale:

Enforcing a delay between successive failed login attempts increases protection against automated password guessing attacks.

Severity: medium

Identifiers: GEN000480

References: ECLO-1, ECLO-2, 43

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ $(grep -c ^FAIL_DELAY /etc/login.defs) != 0 ]; then
    	sed -i 's/^FAIL_DELAY.*[0-9]*/FAIL_DELAY 4/' /etc/login.defs
    else
    	echo "FAIL_DELAY 4" | tee -a /etc/login.defs &>/dev/null
    fi

    if [ $(grep -c pam_faildelay.so /etc/pam.d/system-auth) != 0 ]; then
    	if [ $(grep -c pam_faildelay.so.*delay\= /etc/pam.d/system-auth) != 0 ]; then
    		sed -i '/pam_faildelay.so/s/\(delay=\)[0-9]*/\14000000/' /etc/pam.d/system-auth
    	else
    		sed -i '/pam_faildelay.so/s/$/ delay=4000000/' /etc/pam.d/system-auth
    	fi
    else
    	sed -i '/auth.*include.*system-auth-ac/iauth        optional     pam_faildelay.so delay=4000000' /etc/pam.d/system-auth
    fi

### Set Password Hashing Algorithm [ref]group

The system's default algorithm for storing password hashes in `/etc/shadow` is SHA-512. This can be configured in several locations.

contains 1 rule

#### Set Password Hashing Algorithm in /etc/pam.d/system-auth [ref]rule

In `/etc/pam.d/system-auth`, the `password` section of the file controls which PAM modules execute during a password change. Set the `pam_unix.so` module in the `password` section to include the argument `sha512`, as shown below:

    password    sufficient    pam_unix.so sha512 other arguments...

This will help ensure when local users change their passwords, hashes for the new passwords will be generated using the SHA-512 algorithm. This is the default. Rationale:

Using a stronger hashing algorithm makes password cracking attacks more difficult.

Severity: medium

Identifiers: GEN000590

References: DCNR-1, IAIA-1, IAIA-2, 803

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    if [ $(grep "password.*pam_unix.so" /etc/pam.d/system-auth | egrep -c '(descrypt|bigcrypt|md5|sha256)') != 0 ]; then
    	sed -i '/password.*pam_unix.so/s/\(descrypt\|bigcrypt\|md5\|sha256\)/sha512/' /etc/pam.d/system-auth
    else
    	sed -i '/password.*pam_unix.so/s/$/ sha512/' /etc/pam.d/system-auth
    fi
    if [ -e /etc/pam.d/system-auth-ac ]; then
    	if [ $(grep "password.*pam_unix.so" /etc/pam.d/system-auth-ac | egrep -c '(descrypt|bigcrypt|md5|sha256)') != 0 ]; then
    		sed -i '/password.*pam_unix.so/s/\(descrypt\|bigcrypt\|md5\|sha256\)/sha512/' /etc/pam.d/system-auth-ac
    	else
    		sed -i '/password.*pam_unix.so/s/$/ sha512/' /etc/pam.d/system-auth-ac
    	fi
    fi

#### Configure Global Account Settings [ref]rule

The `/etc/pam.d/system-auth` file must not be a symbolic link to `/etc/pam.d/system-auth-ac`. The `/etc/pam.d/system-auth` file must instead link to an alternate file, such as `/etc/pam.d/system-auth-local`, which incorporates `include` statements for system-auth-ac. Specifically, the following `include` statements should be present:

    auth include system-auth-ac

    account include system-auth-ac

    password include system-auth-ac

    session include system-auth-ac

Rationale:

Pam global requirements are generally defined in the /etc/pam.d/system-auth or /etc/pam.d/system-auth-ac file. In order for the requirements to be applied the file containing them must be included directly or indirectly in each program's definition file in /etc/pam.d.

Severity: low

Identifiers: GEN000600-2

References: ECSC-1, 192

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    cat > /etc/pam.d/system-auth-local <<'STOP_HERE'
    auth        include      system-auth-ac
    account     include      system-auth-ac
    password    include      system-auth-ac
    session     include      system-auth-ac
    STOP_HERE
    ln -sf /etc/pam.d/system-auth-local /etc/pam.d/system-auth

### Secure Session Configuration Files for Login Accounts [ref]group

When a user logs into a Unix account, the system configures the user's session by reading a number of files. Many of these files are located in the user's home directory, and may have weak permissions as a result of user error or misconfiguration. If an attacker can modify or even read certain types of account configuration information, they can often gain full access to the affected user's account. Therefore, it is important to test and correct configuration file permissions for interactive accounts, particularly those of privileged users such as root or system administrators.

contains 5 rules

### Ensure that No Dangerous Directories Exist in Root's Path [ref]group

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.
Certain path elements could be considered dangerous, as they could lead to root executing unknown or untrusted programs, which could contain malicious code. Since root may sometimes work 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.

contains 3 rules

#### Ensure that Root's PATH Variable Only Includes Absolute Paths [ref]rule

Ensure that none of the directories in root's executable path is equal to a single `.` character, or that it contains any instances that lead to relative path traversal, such as `..` or beginning a path without the slash (`/`) 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. Rationale:

Including these entries increases the risk that root could execute code from an untrusted location.

Severity: low

Identifiers: GEN000940

References: ECCD-1, ECCD-2, ECSC-1, 366

#### Ensure that Root's LD_LIBRARY_PATH Variable Only Includes Absolute Paths [ref]rule

Ensure that none of the directories in root's library path is equal to a single `.` character, or that it contains any instances that lead to relative path traversal, such as `..` or beginning a path without the slash (`/`) character. Also ensure that there are no "empty" elements in the path, such as in these examples:

    LD_LIBRARY_PATH=:/lib
    LD_LIBRARY_PATH=/lib:
    LD_LIBRARY_PATH=/lib::/usr/lib

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

Including these entries increases the risk that root could execute code from an untrusted location.

Severity: low

Identifiers: GEN000945

References: ECSC-1, 366

#### Ensure that Root's Path Does Not Include World or Group-Writable Directories [ref]rule

For each element in root's path, run:

    # ls -ld DIR

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

Such entries increase the risk that root could execute code provided by unprivileged users, and potentially malicious code.

Severity: low

Identifiers: GEN000960

References: ECCD-1, ECCD-2, 366

### Ensure that Users Have Sensible Umask Values [ref]group

The umask setting controls the default permissions for the creation of new files. 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 by 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 groups of which the user is a member.

contains 1 rule

#### Ensure the Default Umask is Set Correctly [ref]rule

To ensure the default umask for users is set properly, add or correct the `umask` setting in `/etc/bashrc` to read as follows:

    umask 077

Rationale:

The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users.

Severity: low

Identifiers: GEN002560

References: ECCD-1, ECCD-2, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    var_accounts_user_umask="077"

    egrep -li ^[[:blank:]]*umask `find /etc /root /home/* -maxdepth 1 -type f 2>/dev/null` | while read FILE; do
    	sed -i "s/\([uU][mM][aA][sS][kK]\s*[=]*\s*\)[0-9]*/\1${var_accounts_user_umask}/" "${FILE}"
    done

#### Limit the Number of Concurrent Login Sessions Allowed Per User [ref]rule

Limiting the number of allowed users and sessions per user can limit risks related to Denial of Service attacks. This addresses concurrent sessions for a single account and does not address concurrent sessions by a single user via multiple accounts. The DoD requirement is 10. To set the number of concurrent sessions per user add the following line in `/etc/security/limits.conf`:

    * hard maxlogins 10

Rationale:

Limiting simultaneous user logins can insulate the system from denial of service problems caused by excessive logins. Automated login processes operating improperly or maliciously may result in an exceptional number of simultaneous login sessions.

Severity: low

Identifiers: GEN000450

References: ECSC-1, 54

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    max_concurrent_login_sessions_value="10"

    if [ $(grep -v "#" /etc/security/limits.conf | grep -c "maxlogins") = "0" ]; then
    	echo "* hard maxlogins ${max_concurrent_login_sessions_value}" >>/etc/security/limits.conf
    else
    	sed -i 's/.*maxlogins.*/* hard maxlogins ${max_concurrent_login_sessions_value}/' /etc/security/limits.conf
    fi

### Protect Physical Console Access [ref]group

It is impossible to fully protect a system from an attacker with physical access, so securing the space in which the system is located should be considered a necessary step. However, there are some steps which, if taken, make it more difficult for an attacker to quickly or undetectably modify a system from its console.

contains 12 rules

### Set Boot Loader Password [ref]group

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. The default Red Hat Enterprise Linux boot loader for x86 systems is called GRUB. 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, protect the boot loader configuration with a password and ensure its configuration file's permissions are set properly.

contains 7 rules

#### Verify /boot/grub/grub.conf Exists [ref]rule

The file `/boot/grub/grub.conf` should exist.

Rationale:

GRUB is a versatile boot loader used by several platforms that can provide authentication for access to the system or boot loader.

Severity: high

Identifiers: GEN008660

References: ECAR-1, ECAR-2, ECAR-3, 366

#### Verify /etc/grub.conf User Ownership [ref]rule

The file `/etc/grub.conf` should be owned by the `root` user to prevent destruction or modification of the file. To properly set the owner of `/etc/grub.conf`, run the command:

    $ sudo chown root /etc/grub.conf

Rationale:

Only root should be able to modify important boot parameters.

Severity: medium

Identifiers: GEN008760

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown root /etc/grub.conf /boot/grub/grub.conf

#### Verify /etc/grub.conf Group Ownership [ref]rule

The file `/etc/grub.conf` should be group-owned by the `root` group to prevent destruction or modification of the file. To properly set the group owner of `/etc/grub.conf`, run the command:

    $ sudo chgrp root /etc/grub.conf

Rationale:

The `root` group is a highly-privileged group. Furthermore, the group-owner of this file should not have any access privileges anyway.

Severity: medium

Identifiers: GEN008780

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chown :root /etc/grub.conf

#### Verify /boot/grub/grub.conf Permissions [ref]rule

File permissions for `/boot/grub/grub.conf` should be set to 600, which is the default. To properly set the permissions of `/boot/grub/grub.conf`, run the command:

    $ sudo chmod 600 /boot/grub/grub.conf

Rationale:

Proper permissions ensure that only the root user can modify important boot parameters.

Severity: medium

Identifiers: GEN008720

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    chmod 0600 /etc/grub.conf /boot/grub/grub.conf

#### Verify /boot/grub/grub.conf Extended ACLs [ref]rule

The system's boot loader configuration file(s) must not have extended ACLs.

Rationale:

Proper permissions ensure that only the root user can modify important boot parameters.

Severity: medium

Identifiers: GEN008740

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    setfacl --remove-all /etc/grub.conf /boot/grub/grub.conf

#### Set Boot Loader Password [ref]rule

The grub boot loader should have password protection enabled to protect boot-time settings. To do so, select a password and then generate a hash from it by running the following command:

    # /sbin/grub-md5-crypt

When prompted to enter a password, insert the following line into `/etc/grub.conf` immediately after the header comments. (Use the output from `grub-md5-crypt` as the value of password-hash):

    password --md5 password-hash

NOTE: To meet FISMA Moderate, the bootloader password MUST differ from the root password. Rationale:

Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode.

Severity: high

Identifiers: GEN008700

References: IAIA-1, IAIA-2, 213

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /tmp/GRUB.TMP ]; then
    	/sbin/grub-md5-crypt < /tmp/GRUB.TMP &> /tmp/GRUB.TMP.out
    	md5crypt=`tail -n1 /tmp/GRUB.TMP.out`
    	if [ -f /boot/grub/grub.conf ] && [ ! -h /boot/grub/grub.conf ]; then
    		if [ "$(grep -c '^password' /boot/grub/grub.conf)" = "0" ]; then
    			sed -i "/timeout/apassword --md5 ${md5crypt}" /boot/grub/grub.conf
    		else
    			sed -i "s/^password .*/password --md5 ${md5crypt}/" /boot/grub/grub.conf
    		fi
    	fi
    	if [ -f /etc/grub.conf ] && [ ! -h /etc/grub.conf ]; then
    		if [ "$(grep -c '^password' /etc/grub.conf)" = "0" ]; then
    			sed -i "/timeout/apassword --md5 ${md5crypt}" /etc/grub.conf
    		else
    			sed -i "s/^password .*/password --md5 ${md5crypt}/" /etc/grub.conf
    		fi
    	fi
    	rm -f /tmp/GRUB.TMP /tmp/GRUB.TMP.out
    fi

#### Set Boot Loader Password Hash [ref]rule

The grub boot loader password should be protected by being hashed with an approved hash algorithm, such as md5. To do so, select a password and then generate a hash from it by running the following command:

    # /sbin/grub-md5-crypt

When prompted to enter a password, insert the following line into `/etc/grub.conf` immediately after the header comments. (Use the output from `grub-md5-crypt` as the value of password-hash):

    password --md5 password-hash

NOTE: To meet FISMA Moderate, the bootloader password MUST differ from the root password. Rationale:

Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode.

Severity: medium

Identifiers: GEN008710

References: IAIA-1, IAIA-2, 213

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /tmp/GRUB.TMP ]; then
    	/sbin/grub-md5-crypt < /tmp/GRUB.TMP &> /tmp/GRUB.TMP.out
    	md5crypt=`tail -n1 /tmp/GRUB.TMP.out`
    	if [ -f /boot/grub/grub.conf ] && [ ! -h /boot/grub/grub.conf ]; then
    		if [ "$(grep -c '^password' /boot/grub/grub.conf)" = "0" ]; then
    			sed -i "/timeout/apassword --md5 ${md5crypt}" /boot/grub/grub.conf
    		else
    			sed -i "s/^password .*/password --md5 ${md5crypt}/" /boot/grub/grub.conf
    		fi
    	fi
    	if [ -f /etc/grub.conf ] && [ ! -h /etc/grub.conf ]; then
    		if [ "$(grep -c '^password' /etc/grub.conf)" = "0" ]; then
    			sed -i "/timeout/apassword --md5 ${md5crypt}" /etc/grub.conf
    		else
    			sed -i "s/^password .*/password --md5 ${md5crypt}/" /etc/grub.conf
    		fi
    	fi
    	rm -f /tmp/GRUB.TMP /tmp/GRUB.TMP.out
    fi

### Configure Screen Locking [ref]group

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, and policies can be implemented to reinforce this.
Automatic screen locking is only meant as a safeguard for those cases where a user forgot to lock the screen.

contains 3 rules

### Configure GUI Screen Locking [ref]group

In the default GNOME desktop, the screen can be locked by choosing Lock Screen from the System menu.
The `gconftool-2` program can be used to enforce mandatory screen locking settings for the default GNOME environment. The following sections detail commands to enforce idle activation of the screen saver, screen locking, a blank-screen screensaver, and an idle activation time.
Because users should be trained to lock the screen when they step away from the computer, the automatic locking feature is only meant as a backup. The Lock Screen icon from the System menu can also be dragged to the taskbar in order to facilitate even more convenient screen-locking.
The root account cannot be screen-locked, but this should have no practical effect as the root account should never be used to log into an X Windows environment, and should only be used to for direct login via console in emergency circumstances.
For more information about configuring GNOME screensaver, see http://live.gnome.org/GnomeScreensaver. For more information about enforcing preferences in the GNOME environment using the GConf configuration system, see http://projects.gnome.org/gconf and the man page `gconftool-2(1)`.

contains 3 rules

#### Set GNOME Login Inactivity Timeout [ref]rule

Run the following command to set the idle time-out value for inactivity in the GNOME desktop to 15 minutes:

    # gconftool-2 \
      --direct \
      --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
      --type int \
      --set /apps/gnome-screensaver/idle_delay 15

Rationale:

Setting the idle delay controls when the screensaver will start, and can be combined with screen locking to prevent access from passersby.

Severity: medium

Identifiers: GEN000500-2

References: PESL-1, 57

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type int --set /apps/gnome-screensaver/idle_delay 15 &>/dev/null

#### GNOME Desktop Screensaver Mandatory Use [ref]rule

Run the following command to activate the screensaver in the GNOME desktop after a period of inactivity:

    # gconftool-2 --direct \
      --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
      --type bool \
      --set /apps/gnome-screensaver/idle_activation_enabled true

Rationale:

Enabling idle activation of the screen saver ensures the screensaver will be activated after the idle delay. Applications requiring continuous, real-time screen display (such as network management products) require the login session does not have administrator rights and the display station is located in a controlled-access area.

Severity: medium

Identifiers: GEN000500

References: PESL-1, 57

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set /apps/gnome-screensaver/idle_activation_enabled true &>/dev/null

#### Enable Screen Lock Activation After Idle Period [ref]rule

Run the following command to activate locking of the screensaver in the GNOME desktop when it is activated:

    # gconftool-2 --direct \
      --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
      --type bool \
      --set /apps/gnome-screensaver/lock_enabled true

Rationale:

Enabling the activation of the screen lock after an idle period ensures password entry will be required in order to access the system, preventing access by passersby.

Severity: medium

Identifiers: GEN000500-3

References: PESL-1, 57

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set /apps/gnome-screensaver/lock_enabled true &>/dev/null

#### Require Authentication for Single User Mode [ref]rule

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.
To require entry of the root password even if the system is started in single-user mode, add or correct the following line in the file `/etc/inittab`:

    ~:S:wait:/sbin/sulogin

Rationale:

This prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password.

Severity: medium

Identifiers: GEN000020

References: IAIA-1, IAIA-2, 213

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep -q :S: /etc/inittab && \
      sed -i "s/.*:S:.*/~:S:wait:\/sbin\/sulogin/g" /etc/inittab
    if ! [ $? -eq 0 ]; then
        echo "~:S:wait:/sbin/sulogin" >> /etc/inittab
    fi

#### Disable Ctrl-Alt-Del Reboot Activation [ref]rule

By default, the system includes the following line in `/etc/init/control-alt-delete.conf` to reboot the system when the Ctrl-Alt-Del key sequence is pressed:

    exec /sbin/shutdown -r now "Control-Alt-Delete pressed"

To configure the system to log a message instead of rebooting the system, alter that line to read as follows:

    exec /usr/bin/logger -p security.info "Control-Alt-Delete pressed"

Rationale:

A locally logged-in user who presses Ctrl-Alt-Del, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. In the GNOME graphical environment, risk of unintentional reboot from the Ctrl-Alt-Del sequence is reduced because the user will be prompted before any action is taken.

Severity: high

Identifiers: GEN000000-LNX00580

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    sed -i 's/^.*:ctrlaltdel:.*\(shutdown\|reboot\).*/ca:nil:ctrlaltdel:\/usr\/bin\/logger -p security.info "Ctrl-Alt-Del was pressed"/' /etc/inittab

### Warning Banners for System Accesses [ref]group

Each system should expose as little information about itself as possible.
System banners, which are typically displayed just before a login prompt, give out information about the service or the host's operating system. This might include the distribution name and the system kernel version, and the particular version of a network service. This information can assist intruders in gaining access to the system as it can reveal whether the system is running vulnerable software. Most network services can be configured to limit what information is displayed.
Many organizations implement security policies that require a system banner provide notice of the system's ownership, provide warning to unauthorized users, and remind authorized users of their consent to monitoring.

contains 3 rules

### Implement a GUI Warning Banner [ref]group

In the default graphical environment, users logging directly into the system are greeted with a login screen provided by the GNOME Display Manager (GDM). The warning banner should be displayed in this graphical environment for these users. The following sections describe how to configure the GDM login banner.

contains 1 rule

#### Enable GUI Warning Banner With Proper Text [ref]rule

To enable displaying a login warning banner in the GNOME Display Manager's login screen, run the following command:

    sudo -u gdm gconftool-2 \
      --type bool \
      --set /apps/gdm/simple-greeter/banner_message_enable true

To set the text shown by the GNOME Display Manager in the login screen, run the following command:

    sudo -u gdm gconftool-2 \
      --type string \
      --set /apps/gdm/simple-greeter/banner_message_text \
      "Text of the warning banner here"

When entering a warning banner that spans several lines, remember to begin and end the string with `"`. This command writes directly to the file `/var/lib/gdm/.gconf/apps/gdm/simple-greeter/%gconf.xml`, and this file can later be edited directly if necessary. Rationale:

An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers.

Severity: medium

Identifiers: GEN000402

References: ECWM-1, 48

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    gui_login_banner_text="You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U.S.[\s\n]+Government[\s\n]+\(USG\)[\s\n]+Information[\s\n]+System[\s\n]+\(IS\)[\s\n]+that[\s\n]+is[\s\n]+provided[\s\n]+for[\s\n]+USG-authorized[\s\n]+use[\s\n]+only.[\s\n]*By[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+\(which[\s\n]+includes[\s\n]+any[\s\n]+device[\s\n]+attached[\s\n]+to[\s\n]+this[\s\n]+IS\),[\s\n]+you[\s\n]+consent[\s\n]+to[\s\n]+the[\s\n]+following[\s\n]+conditions\:[\s\n]*-[\s\n]*The[\s\n]+USG[\s\n]+routinely[\s\n]+intercepts[\s\n]+and[\s\n]+monitors[\s\n]+communications[\s\n]+on[\s\n]+this[\s\n]+IS[\s\n]+for[\s\n]+purposes[\s\n]+including,[\s\n]+but[\s\n]+not[\s\n]+limited[\s\n]+to,[\s\n]+penetration[\s\n]+testing,[\s\n]+COMSEC[\s\n]+monitoring,[\s\n]+network[\s\n]+operations[\s\n]+and[\s\n]+defense,[\s\n]+personnel[\s\n]+misconduct[\s\n]+\(PM\),[\s\n]+law[\s\n]+enforcement[\s\n]+\(LE\),[\s\n]+and[\s\n]+counterintelligence[\s\n]+\(CI\)[\s\n]+investigations.[\s\n]*-[\s\n]*At[\s\n]+any[\s\n]+time,[\s\n]+the[\s\n]+USG[\s\n]+may[\s\n]+inspect[\s\n]+and[\s\n]+seize[\s\n]+data[\s\n]+stored[\s\n]+on[\s\n]+this[\s\n]+IS.[\s\n]*-[\s\n]*Communications[\s\n]+using,[\s\n]+or[\s\n]+data[\s\n]+stored[\s\n]+on,[\s\n]+this[\s\n]+IS[\s\n]+are[\s\n]+not[\s\n]+private,[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+routine[\s\n]+monitoring,[\s\n]+interception,[\s\n]+and[\s\n]+search,[\s\n]+and[\s\n]+may[\s\n]+be[\s\n]+disclosed[\s\n]+or[\s\n]+used[\s\n]+for[\s\n]+any[\s\n]+USG-authorized[\s\n]+purpose.[\s\n]*-[\s\n]*This[\s\n]+IS[\s\n]+includes[\s\n]+security[\s\n]+measures[\s\n]+\(e.g.,[\s\n]+authentication[\s\n]+and[\s\n]+access[\s\n]+controls\)[\s\n]+to[\s\n]+protect[\s\n]+USG[\s\n]+interests[\s\n]+--[\s\n]+not[\s\n]+for[\s\n]+your[\s\n]+personal[\s\n]+benefit[\s\n]+or[\s\n]+privacy.[\s\n]*-[\s\n]*Notwithstanding[\s\n]+the[\s\n]+above,[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+does[\s\n]+not[\s\n]+constitute[\s\n]+consent[\s\n]+to[\s\n]+PM,[\s\n]+LE[\s\n]+or[\s\n]+CI[\s\n]+investigative[\s\n]+searching[\s\n]+or[\s\n]+monitoring[\s\n]+of[\s\n]+the[\s\n]+content[\s\n]+of[\s\n]+privileged[\s\n]+communications,[\s\n]+or[\s\n]+work[\s\n]+product,[\s\n]+related[\s\n]+to[\s\n]+personal[\s\n]+representation[\s\n]+or[\s\n]+services[\s\n]+by[\s\n]+attorneys,[\s\n]+psychotherapists,[\s\n]+or[\s\n]+clergy,[\s\n]+and[\s\n]+their[\s\n]+assistants.[\s\n]+Such[\s\n]+communications[\s\n]+and[\s\n]+work[\s\n]+product[\s\n]+are[\s\n]+private[\s\n]+and[\s\n]+confidential.[\s\n]+See[\s\n]+User[\s\n]+Agreement[\s\n]+for[\s\n]+details."

    gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set /apps/gdm/simple-greeter/banner_message_enable true &>/dev/null
    gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type string --set /apps/gdm/simple-greeter/banner_message_text "$(echo $gui_login_banner_text | sed -e 's/\[\\s\\n\][+|*]/ /g' -e 's/\&amp;/\&/g' -e 's/\\//g' -e 's/ - /\n- /g')" &>/dev/null

#### Modify the System Login Banner [ref]rule

To configure the system login banner:
Edit `/etc/issue`. Replace the default text with a message compliant with the local site policy or a legal disclaimer. The DoD required text is either:
`You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.`
OR:
`I've read & consent to terms in IS user agreem't.`

Rationale:

An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers.

Severity: medium

Identifiers: GEN000400

References: ECWM-1, 48

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    system_login_banner_text="You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U.S.[\s\n]+Government[\s\n]+\(USG\)[\s\n]+Information[\s\n]+System[\s\n]+\(IS\)[\s\n]+that[\s\n]+is[\s\n]+provided[\s\n]+for[\s\n]+USG-authorized[\s\n]+use[\s\n]+only.[\s\n]*By[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+\(which[\s\n]+includes[\s\n]+any[\s\n]+device[\s\n]+attached[\s\n]+to[\s\n]+this[\s\n]+IS\),[\s\n]+you[\s\n]+consent[\s\n]+to[\s\n]+the[\s\n]+following[\s\n]+conditions\:[\s\n]*-[\s\n]*The[\s\n]+USG[\s\n]+routinely[\s\n]+intercepts[\s\n]+and[\s\n]+monitors[\s\n]+communications[\s\n]+on[\s\n]+this[\s\n]+IS[\s\n]+for[\s\n]+purposes[\s\n]+including,[\s\n]+but[\s\n]+not[\s\n]+limited[\s\n]+to,[\s\n]+penetration[\s\n]+testing,[\s\n]+COMSEC[\s\n]+monitoring,[\s\n]+network[\s\n]+operations[\s\n]+and[\s\n]+defense,[\s\n]+personnel[\s\n]+misconduct[\s\n]+\(PM\),[\s\n]+law[\s\n]+enforcement[\s\n]+\(LE\),[\s\n]+and[\s\n]+counterintelligence[\s\n]+\(CI\)[\s\n]+investigations.[\s\n]*-[\s\n]*At[\s\n]+any[\s\n]+time,[\s\n]+the[\s\n]+USG[\s\n]+may[\s\n]+inspect[\s\n]+and[\s\n]+seize[\s\n]+data[\s\n]+stored[\s\n]+on[\s\n]+this[\s\n]+IS.[\s\n]*-[\s\n]*Communications[\s\n]+using,[\s\n]+or[\s\n]+data[\s\n]+stored[\s\n]+on,[\s\n]+this[\s\n]+IS[\s\n]+are[\s\n]+not[\s\n]+private,[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+routine[\s\n]+monitoring,[\s\n]+interception,[\s\n]+and[\s\n]+search,[\s\n]+and[\s\n]+may[\s\n]+be[\s\n]+disclosed[\s\n]+or[\s\n]+used[\s\n]+for[\s\n]+any[\s\n]+USG-authorized[\s\n]+purpose.[\s\n]*-[\s\n]*This[\s\n]+IS[\s\n]+includes[\s\n]+security[\s\n]+measures[\s\n]+\(e.g.,[\s\n]+authentication[\s\n]+and[\s\n]+access[\s\n]+controls\)[\s\n]+to[\s\n]+protect[\s\n]+USG[\s\n]+interests[\s\n]+--[\s\n]+not[\s\n]+for[\s\n]+your[\s\n]+personal[\s\n]+benefit[\s\n]+or[\s\n]+privacy.[\s\n]*-[\s\n]*Notwithstanding[\s\n]+the[\s\n]+above,[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+does[\s\n]+not[\s\n]+constitute[\s\n]+consent[\s\n]+to[\s\n]+PM,[\s\n]+LE[\s\n]+or[\s\n]+CI[\s\n]+investigative[\s\n]+searching[\s\n]+or[\s\n]+monitoring[\s\n]+of[\s\n]+the[\s\n]+content[\s\n]+of[\s\n]+privileged[\s\n]+communications,[\s\n]+or[\s\n]+work[\s\n]+product,[\s\n]+related[\s\n]+to[\s\n]+personal[\s\n]+representation[\s\n]+or[\s\n]+services[\s\n]+by[\s\n]+attorneys,[\s\n]+psychotherapists,[\s\n]+or[\s\n]+clergy,[\s\n]+and[\s\n]+their[\s\n]+assistants.[\s\n]+Such[\s\n]+communications[\s\n]+and[\s\n]+work[\s\n]+product[\s\n]+are[\s\n]+private[\s\n]+and[\s\n]+confidential.[\s\n]+See[\s\n]+User[\s\n]+Agreement[\s\n]+for[\s\n]+details."

    echo $system_login_banner_text | sed -e 's/\[\\s\\n\][+|*]/ /g' -e 's/\&amp;/\&/g' -e 's/\\//g' -e 's/ - /\n- /g' >/etc/issue

#### Create Warning Banners for All FTP Users [ref]rule

Edit the vsftpd configuration file, which resides at `/etc/vsftpd/vsftpd.conf` by default. Add or correct the following configuration options:

    banner_file=/etc/issue

Rationale:

This setting will cause the system greeting banner to be used for FTP connections as well.

Severity: medium

Identifiers: GEN000410

References: ECWM-1, 48

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    ftp_login_banner_text="You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U.S.[\s\n]+Government[\s\n]+\(USG\)[\s\n]+Information[\s\n]+System[\s\n]+\(IS\)[\s\n]+that[\s\n]+is[\s\n]+provided[\s\n]+for[\s\n]+USG-authorized[\s\n]+use[\s\n]+only.[\s\n]*By[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+\(which[\s\n]+includes[\s\n]+any[\s\n]+device[\s\n]+attached[\s\n]+to[\s\n]+this[\s\n]+IS\),[\s\n]+you[\s\n]+consent[\s\n]+to[\s\n]+the[\s\n]+following[\s\n]+conditions\:[\s\n]*-[\s\n]*The[\s\n]+USG[\s\n]+routinely[\s\n]+intercepts[\s\n]+and[\s\n]+monitors[\s\n]+communications[\s\n]+on[\s\n]+this[\s\n]+IS[\s\n]+for[\s\n]+purposes[\s\n]+including,[\s\n]+but[\s\n]+not[\s\n]+limited[\s\n]+to,[\s\n]+penetration[\s\n]+testing,[\s\n]+COMSEC[\s\n]+monitoring,[\s\n]+network[\s\n]+operations[\s\n]+and[\s\n]+defense,[\s\n]+personnel[\s\n]+misconduct[\s\n]+\(PM\),[\s\n]+law[\s\n]+enforcement[\s\n]+\(LE\),[\s\n]+and[\s\n]+counterintelligence[\s\n]+\(CI\)[\s\n]+investigations.[\s\n]*-[\s\n]*At[\s\n]+any[\s\n]+time,[\s\n]+the[\s\n]+USG[\s\n]+may[\s\n]+inspect[\s\n]+and[\s\n]+seize[\s\n]+data[\s\n]+stored[\s\n]+on[\s\n]+this[\s\n]+IS.[\s\n]*-[\s\n]*Communications[\s\n]+using,[\s\n]+or[\s\n]+data[\s\n]+stored[\s\n]+on,[\s\n]+this[\s\n]+IS[\s\n]+are[\s\n]+not[\s\n]+private,[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+routine[\s\n]+monitoring,[\s\n]+interception,[\s\n]+and[\s\n]+search,[\s\n]+and[\s\n]+may[\s\n]+be[\s\n]+disclosed[\s\n]+or[\s\n]+used[\s\n]+for[\s\n]+any[\s\n]+USG-authorized[\s\n]+purpose.[\s\n]*-[\s\n]*This[\s\n]+IS[\s\n]+includes[\s\n]+security[\s\n]+measures[\s\n]+\(e.g.,[\s\n]+authentication[\s\n]+and[\s\n]+access[\s\n]+controls\)[\s\n]+to[\s\n]+protect[\s\n]+USG[\s\n]+interests[\s\n]+--[\s\n]+not[\s\n]+for[\s\n]+your[\s\n]+personal[\s\n]+benefit[\s\n]+or[\s\n]+privacy.[\s\n]*-[\s\n]*Notwithstanding[\s\n]+the[\s\n]+above,[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+does[\s\n]+not[\s\n]+constitute[\s\n]+consent[\s\n]+to[\s\n]+PM,[\s\n]+LE[\s\n]+or[\s\n]+CI[\s\n]+investigative[\s\n]+searching[\s\n]+or[\s\n]+monitoring[\s\n]+of[\s\n]+the[\s\n]+content[\s\n]+of[\s\n]+privileged[\s\n]+communications,[\s\n]+or[\s\n]+work[\s\n]+product,[\s\n]+related[\s\n]+to[\s\n]+personal[\s\n]+representation[\s\n]+or[\s\n]+services[\s\n]+by[\s\n]+attorneys,[\s\n]+psychotherapists,[\s\n]+or[\s\n]+clergy,[\s\n]+and[\s\n]+their[\s\n]+assistants.[\s\n]+Such[\s\n]+communications[\s\n]+and[\s\n]+work[\s\n]+product[\s\n]+are[\s\n]+private[\s\n]+and[\s\n]+confidential.[\s\n]+See[\s\n]+User[\s\n]+Agreement[\s\n]+for[\s\n]+details."

    if [ -e /etc/xinetd.d/gssftp ]; then
    	if [ "`egrep -c '^(\s|\t)banner' /etc/xinetd.d/gssftp`" = "0" ]; then
    		sed -i "/^}$/i\\\tbanner\t\t= /etc/issue" /etc/xinetd.d/gssftp
    	else
    		GSSFTP_BANNER_FILE="`egrep '^(\s|\t)banner' /etc/xinetd.d/gssftp | awk '{ print $3 }'`"
    		echo $ftp_login_banner_text | sed -e 's/\[\\s\\n\][+|*]/ /g' -e 's/\&amp;/\&/g' -e 's/\\//g' -e 's/ - /\n- /g' >"${GSSFTP_BANNER_FILE}"
    	fi
    fi

    if [ -e /etc/vsftpd/vsftpd.conf ]; then
    	if [ "`egrep -c '^banner_file' /etc/vsftpd/vsftpd.conf`" = "0" ]; then
    		echo "banner_file=/etc/issue" >> /etc/vsftpd/vsftpd.conf
    	else
    		VSFTPD_BANNER_FILE="`egrep '^banner_file' /etc/vsftpd/vsftpd.conf | awk -F= '{ print $2 }'`"
    		echo $ftp_login_banner_text | sed -e 's/\[\\s\\n\][+|*]/ /g' -e 's/\&amp;/\&/g' -e 's/\\//g' -e 's/ - /\n- /g' >"${VSFTPD_BANNER_FILE}"
    	fi
    fi

### Network Configuration and Firewalls [ref]group

Most machines must be connected to a network of some sort, and this brings with it the substantial risk of network attack. This section discusses the security impact of decisions about networking which must be made when configuring a system.
This section also discusses firewalls, network access controls, and other network security frameworks, which allow system-level rules to be written that can limit an attackers' ability to connect to your system. These rules can specify that network traffic should be allowed or denied from certain IP addresses, hosts, and networks. The rules can also specify which of the system's network services are available to particular hosts or networks.

contains 29 rules

### Kernel Parameters Which Affect Networking [ref]group

The `sysctl` utility is used to set parameters which affect the operation of the Linux kernel. Kernel parameters which affect networking and have security implications are described here.

contains 8 rules

### Network Parameters for Hosts Only [ref]group

If the system is not going to be used as a router, then setting certain kernel parameters ensure that the host will not perform routing of network traffic.

contains 2 rules

#### Disable Kernel Parameter for Sending ICMP Redirects for All Interfaces [ref]rule

To set the runtime status of the `net.ipv4.conf.all.send_redirects` kernel parameter, run the following command:

    $ sudo sysctl -w net.ipv4.conf.all.send_redirects=0

If this is not the system's default value, add the following line to `/etc/sysctl.conf`:

    net.ipv4.conf.all.send_redirects = 0

Rationale:

Sending ICMP redirects permits the system to instruct other systems to update their routing information. The ability to send ICMP redirects is only appropriate for systems acting as routers.

Severity: medium

Identifiers: GEN003610

References: ECSC-1, 1551

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    /sbin/sysctl -q -n -w net.ipv4.conf.all.send_redirects=0
    /sbin/sysctl -q -n -w net.ipv4.conf.default.send_redirects=0

    if grep --silent ^net.ipv4.conf.all.send_redirects /etc/sysctl.conf ; then
    	sed -i 's/^net.ipv4.conf.all.send_redirects.*/net.ipv4.conf.all.send_redirects = 0/g' /etc/sysctl.conf
    else
    	echo "" >> /etc/sysctl.conf
    	echo "# Set net.ipv4.conf.all.send_redirects to 0 per security requirements" >> /etc/sysctl.conf
    	echo "net.ipv4.conf.all.send_redirects = 0" >> /etc/sysctl.conf
    fi

    if grep --silent ^net.ipv4.conf.default.send_redirects /etc/sysctl.conf ; then
    	sed -i 's/^net.ipv4.conf.default.send_redirects.*/net.ipv4.conf.default.send_redirects = 0/g' /etc/sysctl.conf
    else
    	echo "" >> /etc/sysctl.conf
    	echo "# Set net.ipv4.conf.default.send_redirects to 0 per security requirements" >> /etc/sysctl.conf
    	echo "net.ipv4.conf.default.send_redirects = 0" >> /etc/sysctl.conf
    fi

#### Disable Kernel Parameter for IP Forwarding [ref]rule

To set the runtime status of the `net.ipv4.ip_forward` kernel parameter, run the following command:

    $ sudo sysctl -w net.ipv4.ip_forward=0

If this is not the system's default value, add the following line to `/etc/sysctl.conf`:

    net.ipv4.ip_forward = 0

Rationale:

IP forwarding permits the kernel to forward packets from one network interface to another. The ability to forward packets between two networks is only appropriate for systems acting as routers.

Severity: medium

Identifiers: GEN005600

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | medium
Reboot: | true
Strategy: | disable

    #
    # Set runtime for net.ipv4.ip_forward
    #
    /sbin/sysctl -q -n -w net.ipv4.ip_forward=0

    #
    # If net.ipv4.ip_forward present in /etc/sysctl.conf, change value to "0"
    #	else, add "net.ipv4.ip_forward = 0" to /etc/sysctl.conf
    #
    if grep --silent ^net.ipv4.ip_forward /etc/sysctl.conf ; then
    	sed -i 's/^net.ipv4.ip_forward.*/net.ipv4.ip_forward = 0/g' /etc/sysctl.conf
    else
    	echo -e "\n# Set net.ipv4.ip_forward to 0 per security requirements" >> /etc/sysctl.conf
    	echo "net.ipv4.ip_forward = 0" >> /etc/sysctl.conf
    fi

### Network Related Kernel Runtime Parameters for Hosts and Routers [ref]group

Certain kernel parameters should be set for systems which are acting as either hosts or routers to improve the system's ability defend against certain types of IPv4 protocol attacks.

contains 6 rules

#### Disable Kernel Parameter for Accepting Source-Routed Packets for All Interfaces [ref]rule

To set the runtime status of the `net.ipv4.conf.all.accept_source_route` kernel parameter, run the following command:

    $ sudo sysctl -w net.ipv4.conf.all.accept_source_route=0

If this is not the system's default value, add the following line to `/etc/sysctl.conf`:

    net.ipv4.conf.all.accept_source_route = 0

Rationale:

Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required.

Severity: medium

Identifiers: GEN003607

References: ECSC-1, 1551

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    /sbin/sysctl -q -n -w net.ipv4.conf.all.accept_source_route=0
    /sbin/sysctl -q -n -w net.ipv4.conf.default.accept_source_route=0

    if grep --silent ^net.ipv4.conf.all.accept_source_route /etc/sysctl.conf ; then
    	sed -i 's/^net.ipv4.conf.all.accept_source_route.*/net.ipv4.conf.all.accept_source_route = 0/g' /etc/sysctl.conf
    else
    	echo "" >> /etc/sysctl.conf
    	echo "# Set net.ipv4.conf.all.accept_source_route to 0 per security requirements" >> /etc/sysctl.conf
    	echo "net.ipv4.conf.all.accept_source_route = 0" >> /etc/sysctl.conf
    fi

    if grep --silent ^net.ipv4.conf.default.accept_source_route /etc/sysctl.conf ; then
    	sed -i 's/^net.ipv4.conf.default.accept_source_route.*/net.ipv4.conf.default.accept_source_route = 0/g' /etc/sysctl.conf
    else
    	echo "" >> /etc/sysctl.conf
    	echo "# Set net.ipv4.conf.default.accept_source_route to 0 per security requirements" >> /etc/sysctl.conf
    	echo "net.ipv4.conf.default.accept_source_route = 0" >> /etc/sysctl.conf
    fi

#### Disable Kernel Parameter for Accepting ICMP Redirects for All Interfaces [ref]rule

To set the runtime status of the `net.ipv4.conf.all.accept_redirects` kernel parameter, run the following command:

    $ sudo sysctl -w net.ipv4.conf.all.accept_redirects=0

If this is not the system's default value, add the following line to `/etc/sysctl.conf`:

    net.ipv4.conf.all.accept_redirects = 0

Rationale:

Accepting ICMP redirects has few legitimate uses. It should be disabled unless it is absolutely required.

Severity: medium

Identifiers: GEN003609

References: ECSC-1, 1503, 1551

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    /sbin/sysctl -q -n -w net.ipv4.conf.all.accept_redirects=0
    /sbin/sysctl -q -n -w net.ipv4.conf.default.accept_redirects=0

    if grep --silent ^net.ipv4.conf.all.accept_redirects /etc/sysctl.conf ; then
    	sed -i 's/^net.ipv4.conf.all.accept_redirects.*/net.ipv4.conf.all.accept_redirects = 0/g' /etc/sysctl.conf
    else
    	echo "" >> /etc/sysctl.conf
    	echo "# Set net.ipv4.conf.all.accept_redirects to 0 per security requirements" >> /etc/sysctl.conf
    	echo "net.ipv4.conf.all.accept_redirects = 0" >> /etc/sysctl.conf
    fi

    if grep --silent ^net.ipv4.conf.default.accept_redirects /etc/sysctl.conf ; then
    	sed -i 's/^net.ipv4.conf.default.accept_redirects.*/net.ipv4.conf.default.accept_redirects = 0/g' /etc/sysctl.conf
    else
    	echo "" >> /etc/sysctl.conf
    	echo "# Set net.ipv4.conf.default.accept_redirects to 0 per security requirements" >> /etc/sysctl.conf
    	echo "net.ipv4.conf.default.accept_redirects = 0" >> /etc/sysctl.conf
    fi

#### Enable Kernel Parameter to Log Martian Packets [ref]rule

To set the runtime status of the `net.ipv4.conf.all.log_martians` kernel parameter, run the following command:

    $ sudo sysctl -w net.ipv4.conf.all.log_martians=1

If this is not the system's default value, add the following line to `/etc/sysctl.conf`:

    net.ipv4.conf.all.log_martians = 1

Rationale:

The presence of "martian" packets (which have impossible addresses) as well as spoofed packets, source-routed packets, and redirects could be a sign of nefarious network activity. Logging these packets enables this activity to be detected.

Severity: low

Identifiers: GEN003611

References: ECAT-1, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    /sbin/sysctl -q -n -w net.ipv4.conf.all.log_martians=1
    /sbin/sysctl -q -n -w net.ipv4.conf.default.log_martians=1

    if grep --silent ^net.ipv4.conf.all.log_martians /etc/sysctl.conf ; then
    	sed -i 's/^net.ipv4.conf.all.log_martians.*/net.ipv4.conf.all.log_martians = 1/g' /etc/sysctl.conf
    else
    	echo "" >> /etc/sysctl.conf
    	echo "# Set net.ipv4.conf.all.log_martians to 1 per security requirements" >> /etc/sysctl.conf
    	echo "net.ipv4.conf.all.log_martians = 1" >> /etc/sysctl.conf
    fi

    if grep --silent ^net.ipv4.conf.default.log_martians /etc/sysctl.conf ; then
    	sed -i 's/^net.ipv4.conf.default.log_martians.*/net.ipv4.conf.default.log_martians = 1/g' /etc/sysctl.conf
    else
    	echo "" >> /etc/sysctl.conf
    	echo "# Set net.ipv4.conf.default.log_martians to 1 per security requirements" >> /etc/sysctl.conf
    	echo "net.ipv4.conf.default.log_martians = 1" >> /etc/sysctl.conf
    fi

#### Enable Kernel Parameter to Ignore ICMP Broadcast Echo Requests [ref]rule

To set the runtime status of the `net.ipv4.icmp_echo_ignore_broadcasts` kernel parameter, run the following command:

    $ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1

If this is not the system's default value, add the following line to `/etc/sysctl.conf`:

    net.ipv4.icmp_echo_ignore_broadcasts = 1

Rationale:

Ignoring ICMP echo requests (pings) sent to broadcast or multicast addresses makes the system slightly more difficult to enumerate on the network.

Severity: low

Identifiers: GEN003603

References: ECSC-1, 1551

Remediation Shell script: (show)

Complexity: | low
Disruption: | medium
Reboot: | true
Strategy: | disable

    #
    # Set runtime for net.ipv4.icmp_echo_ignore_broadcasts
    #
    /sbin/sysctl -q -n -w net.ipv4.icmp_echo_ignore_broadcasts=1

    #
    # If net.ipv4.icmp_echo_ignore_broadcasts present in /etc/sysctl.conf, change value to "1"
    #	else, add "net.ipv4.icmp_echo_ignore_broadcasts = 1" to /etc/sysctl.conf
    #
    if grep --silent ^net.ipv4.icmp_echo_ignore_broadcasts /etc/sysctl.conf ; then
    	sed -i 's/^net.ipv4.icmp_echo_ignore_broadcasts.*/net.ipv4.icmp_echo_ignore_broadcasts = 1/g' /etc/sysctl.conf
    else
    	echo -e "\n# Set net.ipv4.icmp_echo_ignore_broadcasts to 1 per security requirements" >> /etc/sysctl.conf
    	echo "net.ipv4.icmp_echo_ignore_broadcasts = 1" >> /etc/sysctl.conf
    fi

#### Enable Kernel Parameter to Use TCP Syncookies [ref]rule

To set the runtime status of the `net.ipv4.tcp_syncookies` kernel parameter, run the following command:

    $ sudo sysctl -w net.ipv4.tcp_syncookies=1

If this is not the system's default value, add the following line to `/etc/sysctl.conf`:

    net.ipv4.tcp_syncookies = 1

Rationale:

A TCP SYN flood attack can cause a denial of service by filling a system's TCP connection table with connections in the SYN_RCVD state. Syncookies can be used to track a connection when a subsequent ACK is received, verifying the initiator is attempting a valid connection and is not a flood source. This feature is activated when a flood condition is detected, and enables the system to continue servicing valid connection requests.

Severity: medium

Identifiers: GEN003612

References: ECSC-1, 1092

Remediation Shell script: (show)

Complexity: | low
Disruption: | medium
Reboot: | true
Strategy: | disable

    #
    # Set runtime for net.ipv4.tcp_syncookies
    #
    /sbin/sysctl -q -n -w net.ipv4.tcp_syncookies=1

    #
    # If net.ipv4.tcp_syncookies present in /etc/sysctl.conf, change value to "1"
    #	else, add "net.ipv4.tcp_syncookies = 1" to /etc/sysctl.conf
    #
    if grep --silent ^net.ipv4.tcp_syncookies /etc/sysctl.conf ; then
    	sed -i 's/^net.ipv4.tcp_syncookies.*/net.ipv4.tcp_syncookies = 1/g' /etc/sysctl.conf
    else
    	echo -e "\n# Set net.ipv4.tcp_syncookies to 1 per security requirements" >> /etc/sysctl.conf
    	echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
    fi

#### TCP backlog queue sizes must be set appropriately [ref]rule

To set the runtime status of the `net.ipv4.max_syn_backlog` kernel parameter, run the following command:

    $ sudo sysctl -w net.ipv4.max_syn_backlog=1280

If this is not the system's default value, add the following line to `/etc/sysctl.conf`:

    net.ipv4.max_syn_backlog = 1280

Rationale:

To provide some mitigation to TCP Denial of Service attacks, the TCP backlog queue sizes must be set to at least 1280 or in accordance with product-specific guidelines.

Severity: medium

Identifiers: GEN003601

References: ECSC-1, http://iase.disa.mil/stigs/cci/Pages/index.aspx

Remediation Shell script: (show)

Complexity: | low
Disruption: | medium
Reboot: | true
Strategy: | disable

    #
    # Set runtime for net.ipv4.tcp_max_syn_backlog
    #
    /sbin/sysctl -q -n -w net.ipv4.tcp_max_syn_backlog=1280

    #
    # If net.ipv4.tcp_max_syn_backlog present in /etc/sysctl.conf, change value to "1280"
    #	else, add "net.ipv4.tcp_max_syn_backlog = 1280" to /etc/sysctl.conf
    #
    if grep --silent ^net.ipv4.tcp_max_syn_backlog /etc/sysctl.conf ; then
    	sed -i 's/^net.ipv4.tcp_max_syn_backlog.*/net.ipv4.tcp_max_syn_backlog = 1280/g' /etc/sysctl.conf
    else
    	echo -e "\n# Set net.ipv4.tcp_max_syn_backlog to 1280 per security requirements" >> /etc/sysctl.conf
    	echo "net.ipv4.tcp_max_syn_backlog = 1280" >> /etc/sysctl.conf
    fi

### Wireless Networking [ref]group

Wireless networking, such as 802.11 (WiFi) and Bluetooth, can present a security risk to sensitive or classified systems and networks. Wireless networking hardware is much more likely to be included in laptop or portable systems than desktops or servers.
Removal of hardware provides the greatest assurance that the wireless capability remains disabled. Acquisition policies often include provisions to prevent the purchase of equipment that will be used in sensitive spaces and includes wireless capabilities. If it is impractical to remove the wireless hardware, and policy permits the device to enter sensitive spaces as long as wireless is disabled, efforts should instead focus on disabling wireless capability via software.

contains 1 rule

### Disable Wireless Through Software Configuration [ref]group

If it is impossible to remove the wireless hardware from the device in question, disable as much of it as possible through software. The following methods can disable software support for wireless networking, but note that these methods do not prevent malicious software or careless users from re-activating the devices.

contains 1 rule

#### Disable Bluetooth Kernel Modules [ref]rule

The kernel's module loading system can be configured to prevent loading of the Bluetooth module. Add the following to the appropriate `/etc/modprobe.d` configuration file to prevent the loading of the Bluetooth module:

    install net-pf-31 /bin/true
    install bluetooth /bin/true

Rationale:

If Bluetooth functionality must be disabled, preventing the kernel from loading the kernel module provides an additional safeguard against its activation.

Severity: medium

Identifiers: GEN007660

References: ECSC-1, 1551

Remediation Shell script: (show)

Complexity: | low
Disruption: | medium
Reboot: | true
Strategy: | disable

    if [ -d /etc/modprobe.d/ ]; then
    	echo "install bluetooth /bin/true" >> /etc/modprobe.d/disabled_modules.conf
    else
    	echo "install bluetooth /bin/true" >> /etc/modprobe.conf
    fi

### IPv6 [ref]group

The system includes support for Internet Protocol version 6. A major and often-mentioned improvement over IPv4 is its enormous increase in the number of available addresses. Another important feature is its support for automatic configuration of many network settings.

contains 5 rules

### Disable Support for IPv6 Unless Needed [ref]group

Despite configuration that suggests support for IPv6 has been disabled, link-local IPv6 address auto-configuration occurs even when only an IPv4 address is assigned. The only way to effectively prevent execution of the IPv6 networking stack is to instruct the system not to activate the IPv6 kernel module.

contains 2 rules

#### Disable IPv6 Networking Support Automatic Loading [ref]rule

To prevent the IPv6 kernel module (`ipv6`) from loading the IPv6 networking stack, add the following line to `/etc/modprobe.d/disabled.conf` (or another file in `/etc/modprobe.d`):

    options ipv6 disable=1

This permits the IPv6 module to be loaded (and thus satisfy other modules that depend on it), while disabling support for the IPv6 protocol. Rationale:

Any unnecessary network stacks - including IPv6 - should be disabled, to reduce the vulnerability to exploitation.

Severity: medium

Identifiers: GEN007720

References: ECSC-1, 1551

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -d /etc/modprobe.d/ ]; then
    	echo "install ipv6 /bin/true" >> /etc/modprobe.d/disabled_modules.conf
    else
    	echo "install ipv6 /bin/true" >> /etc/modprobe.conf
    fi
    chkconfig ip6tables off

#### Disable Interface Usage of IPv6 [ref]rule

To disable interface usage of IPv6, add or correct the following lines in `/etc/sysconfig/network`:

    NETWORKING_IPV6=no

Severity: low

Identifiers: GEN007700

References: ECSC-1, 1551

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ $(grep -c "^NETWORKING_IPV6" /etc/sysconfig/network) = 0 ]; then
    	echo "NETWORKING_IPV6=no" | tee -a /etc/sysconfig/network &>/dev/null
    else
    	sed -i 's/NETWORKING_IPV6.*/NETWORKING_IPV6=no/' /etc/sysconfig/network
    fi
    chkconfig ip6tables off

### Configure IPv6 Settings if Necessary [ref]group

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 preferable to accepting it from the network in an unauthenticated fashion.

contains 3 rules

### Disable Automatic Configuration [ref]group

Disable the system's acceptance of router advertisements and redirects by adding or correcting the following line in `/etc/sysconfig/network` (note that this does not disable sending router solicitations):

    IPV6_AUTOCONF=no

contains 2 rules

#### Disable Accepting IPv6 Redirects [ref]rule

To set the runtime status of the `net.ipv6.conf.all.accept_redirects` kernel parameter, run the following command:

    $ sudo sysctl -w net.ipv6.conf.all.accept_redirects=0

If this is not the system's default value, add the following line to `/etc/sysctl.conf`:

    net.ipv6.conf.all.accept_redirects = 0

Rationale:

An illicit ICMP redirect message could result in a man-in-the-middle attack.

Severity: medium

Identifiers: GEN007860

References: ECSC-1, 1551

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    #
    # Set runtime for net.ipv6.conf.all.accept_redirects
    #
    if [ -e /proc/sys/net/ipv6/ ]; then
    	/sbin/sysctl -q -n -w net.ipv6.conf.all.accept_redirects=0
    fi

    #
    # If net.ipv6.conf.all.accept_redirects present in /etc/sysctl.conf, change value to "0"
    #	else, add "net.ipv6.conf.all.accept_redirects = 0" to /etc/sysctl.conf
    #
    if grep --silent ^net.ipv6.conf.all.accept_redirects /etc/sysctl.conf ; then
    	sed -i 's/^net.ipv6.conf.all.accept_redirects.*/net.ipv6.conf.all.accept_redirects = 0/g' /etc/sysctl.conf
    else
    	echo "" >> /etc/sysctl.conf
    	echo "# Set net.ipv6.conf.all.accept_redirects to 0 per security requirements" >> /etc/sysctl.conf
    	echo "net.ipv6.conf.all.accept_redirects = 0" >> /etc/sysctl.conf
    fi

#### Disable Accepting IPv6 Forwarding [ref]rule

To set the runtime status of the `net.ipv6.conf.all.forwarding` kernel parameter, run the following command:

    $ sudo sysctl -w net.ipv6.conf.all.forwarding=0

If this is not the system's default value, add the following line to `/etc/sysctl.conf`:

    net.ipv6.conf.all.forwarding = 0

To set the runtime status of the `net.ipv6.conf.default.forwarding` kernel parameter, run the following command:

    $ sudo sysctl -w net.ipv6.conf.default.forwarding=0

If this is not the system's default value, add the following line to `/etc/sysctl.conf`:

    net.ipv6.conf.default.forwarding = 0

Rationale:

Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv6 forwarding is enabled and the system is functioning as a router.

Severity: medium

Identifiers: GEN007920

References: ECSC-1, 1551

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    #
    # Set runtime for net.ipv6.conf.all.forwarding
    #
    if [ -e /proc/sys/net/ipv6/ ]; then
    	/sbin/sysctl -q -n -w net.ipv6.conf.all.forwarding=0
    fi

    #
    # If net.ipv6.conf.all.forwarding present in /etc/sysctl.conf, change value to "0"
    #	else, add "net.ipv6.conf.all.forwarding = 0" to /etc/sysctl.conf
    #
    if grep --silent ^net.ipv6.conf.all.forwarding /etc/sysctl.conf ; then
    	sed -i 's/^net.ipv6.conf.all.forwarding.*/net.ipv6.conf.all.forwarding = 0/g' /etc/sysctl.conf
    else
    	echo "" >> /etc/sysctl.conf
    	echo "# Set net.ipv6.conf.all.forwarding to 0 per security requirements" >> /etc/sysctl.conf
    	echo "net.ipv6.conf.all.forwarding = 0" >> /etc/sysctl.conf
    fi

    #
    # Set runtime for net.ipv6.conf.default.forwarding
    #
    if [ -e /proc/sys/net/ipv6/ ]; then
    	/sbin/sysctl -q -n -w net.ipv6.conf.default.forwarding=0
    fi
    #
    # If net.ipv6.conf.default.forwarding present in /etc/sysctl.conf, change value to "0"
    #	else, add "net.ipv6.conf.default.forwarding = 0" to /etc/sysctl.conf
    #
    if grep --silent ^net.ipv6.conf.default.forwarding /etc/sysctl.conf ; then
    	sed -i 's/^net.ipv6.conf.default.forwarding.*/net.ipv6.conf.default.forwarding = 0/g' /etc/sysctl.conf
    else
    	echo "" >> /etc/sysctl.conf
    	echo "# Set net.ipv6.conf.default.forwarding to 0 per security requirements" >> /etc/sysctl.conf
    	echo "net.ipv6.conf.default.forwarding = 0" >> /etc/sysctl.conf
    fi

#### Manually Assign IPv6 Router Address [ref]rule

Edit the file `/etc/sysconfig/network-scripts/ifcfg-interface`, and add or correct the following line (substituting your gateway IP as appropriate):

    IPV6_DEFAULTGW=2001:0DB8::0001

Router addresses should be manually set and not accepted via any auto-configuration or router advertisement.

Severity: low

Identifiers: GEN005570

References: ECSC-1, 366

### iptables and ip6tables [ref]group

A host-based firewall called Netfilter is included as part of the Linux kernel distributed with the system. It is activated by default. This firewall is controlled by the program iptables, and the entire capability is frequently referred to by this name. An analogous program called ip6tables handles filtering for IPv6.
Unlike TCP Wrappers, which depends on the network server program to support and respect the rules written, Netfilter filtering occurs at the kernel level, before a program can even process the data from the network packet. As such, any program on the system is affected by the rules written.
This section provides basic information about strengthening the iptables and ip6tables configurations included with the system. For more complete information that may allow the construction of a sophisticated ruleset tailored to your environment, please consult the references at the end of this section.

contains 5 rules

### Inspect and Activate Default Rules [ref]group

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

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 essentially the same.

contains 1 rule

#### Verify iptables Enabled [ref]rule

The `iptables` service can be enabled with the following command:

    $ sudo chkconfig --level 2345 iptables on

Rationale:

The `iptables` service provides the system's host-based firewalling capability for IPv4 and ICMP.

Severity: medium

Identifiers: GEN008520

References: ECSC-1, 1118

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    #
    # Enable iptables for all run levels
    #
    /sbin/chkconfig --level 0123456 iptables on

    #
    # Start iptables if not currently running
    #
    /sbin/service iptables start 1>/dev/null

### Strengthen the Default Ruleset [ref]group

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

Warning: The program `system-config-securitylevel` allows additional services to penetrate the default firewall rules and automatically adjusts `/etc/sysconfig/iptables`. This program is only useful if the default ruleset meets your security requirements. Otherwise, this program should not be used to make changes to the firewall configuration because it re-writes the saved configuration file.

contains 4 rules

#### Reject Incoming Timestamp Requests and Replies [ref]rule

To reject incoming timestamp requests and replies, add or correct the following line in `/etc/sysconfig/iptables`:

    -I INPUT -p icmp -m icmp --icmp-type timestamp-request -j DROP

    -I INPUT -p icmp -m icmp --icmp-type timestamp-reply -j DROP

Rationale:

The processing of (ICMP) timestamp requests increases the attack surface of the system.

Severity: low

Identifiers: GEN003602

References: ECSC-1, 1551

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ "$(egrep -c '(--icmp-type 14|timestamp-reply) -j DROP')" = "0" ]; then
    	/sbin/iptables -I INPUT -p ICMP --icmp-type timestamp-reply -j DROP
    fi
    if [ "$(egrep -c '(--icmp-type 13|timestamp-request) -j DROP')" = "0" ]; then
    	/sbin/iptables -I INPUT -p ICMP --icmp-type timestamp-request -j DROP
    fi
    /sbin/iptables-save > /etc/sysconfig/iptables
    if [ "$(grep -c 'icmp-type 13' /etc/sysconfig/iptables)" != "0" ]; then
    	sed -i 's/icmp-type 13/icmp-type timestamp-request/' /etc/sysconfig/iptables
    fi
    if [ "$(grep -c 'icmp-type 14' /etc/sysconfig/iptables)" != "0" ]; then
    	sed -i 's/icmp-type 14/icmp-type timestamp-reply/' /etc/sysconfig/iptables
    fi

#### Add Reject Rule for INPUT Chain. [ref]rule

To set the default policy to DROP (instead of ACCEPT) for the built-in INPUT chain which processes incoming packets, add or correct the following line in `/etc/sysconfig/iptables`:

    :INPUT DROP [0:0]

Rationale:

In `iptables` the default policy is applied only after all the applicable rules in the table are examined for a match. Setting the default policy to `DROP` implements proper design for a firewall, i.e. any packets which are not explicitly permitted should not be accepted.

Severity: medium

Identifiers: GEN008540

References: ECSC-1, 1109

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    /sbin/iptables -A INPUT -j REJECT --reject-with icmp-host-prohibited
    /sbin/iptables-save > /etc/sysconfig/iptables

#### Ignore ICMPv6 Echo Requests On a Broadcast Address. [ref]rule

To configure the system to ignore ICMPv6 echo requests on a broadcast address, add or correct the following line in `/etc/sysconfig/ip6tables`:

    -A INPUT -p icmpv6 -d ff02::1 --icmpv6-type 128 -j DROP

Rationale:

Responding to broadcast ICMP echo requests facilitates network mapping and provides a vector for amplification attacks.

Severity: medium

Identifiers: GEN007950

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ ! -e /etc/sysconfig/ip6tables ] || [ "$(grep -c ^ /etc/sysconfig/ip6tables)" -lt "5" ]; then
    	echo -e "*filter\n:INPUT DROP [0:0]\n:FORWARD DROP [0:0]\n:OUTPUT ACCEPT [0:0]\nCOMMIT" | tee /etc/sysconfig/ip6tables &>/dev/null
    	echo "-A INPUT -p icmpv6 -d ff02::1 --icmpv6-type 128 -j DROP" | tee -a /etc/sysconfig/ip6tables &>/dev/null
    else
    	echo "-A INPUT -p icmpv6 -d ff02::1 --icmpv6-type 128 -j DROP" | tee -a /etc/sysconfig/ip6tables &>/dev/null
    fi

#### TCP Wrappers Must Be Configured To Grant/Deny Access To Hosts. [ref]rule

To configure the system to grant/deny access to hosts, ensure the following file exists: `/etc/hosts.allow`: In addition, make sure the following file is present and includes the following line: `/etc/hosts.deny`:

    ALL: ALL

Rationale:

If the system's access control program is not configured with appropriate rules for allowing and denying access to system network resources, services may be accessible to unauthorized hosts.

Severity: medium

Identifiers: GEN006620

References: ECCD-1, ECCD-2, ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ ! -e /etc/hosts.allow ]; then
    	>/etc/hosts.allow
    	chmod 644 /etc/hosts.allow
    	chown root:root /etc/hosts.allow
    fi
    if [ ! -e /etc/hosts.deny ]; then
    	>/etc/hosts.deny
    	chmod 644 /etc/hosts.deny
    	chown root:root /etc/hosts.deny
    fi
    if [ ! -e /var/log/host.access ]; then
    	>/var/log/host.access
    	chmod 640 /var/log/host.access
    	chown root:root /var/log/host.access
    fi
    if [ $(grep -c "ALL: ALL" /etc/hosts.deny) = 0 ]; then
    	echo 'ALL: ALL: spawn /bin/echo Access denied on $(/bin/date) from %a for access to %d \(pid %p\)>>/var/log/host.access' | tee -a /etc/hosts.deny &>/dev/null
    fi

### IP Tunnelling Support [ref]group

Support for creating IP encapsulated tunnels between a system and remote endpoints, to also include tunnelling ipv6 over ipv4, is available in Red Hat.

contains 3 rules

#### Remove IP Tunnels [ref]rule

To remove IP tunnels, perform the following command for each IP tunnel:

    # ip tun del tunnel

Severity: low

Identifiers: GEN007820

References: ECSC-1, 1551

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    ip tunnel list | cut -d: -f1 | while read TUNNEL_INTERFACE; do ip tunnel del $TUNNEL_INTERFACE 2>/dev/null; done

#### Remove 6to4 IP Tunnels [ref]rule

To remove 6to4 IP tunnels, perform the following command for each IP tunnel:

    # ip tun del tunnel

Severity: low

Identifiers: GEN007780

References: ECSC-1, 1551

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    ip tunnel list | cut -d: -f1 | while read TUNNEL_INTERFACE; do ip tunnel del $TUNNEL_INTERFACE 2>/dev/null; done

#### Disable Teredo Services [ref]rule

To disable teredo services, perform the following command:

    # ps ax | grep -i miredo | grep -v grep | awk ' { print $1 }' | xargs kill

Severity: low

Identifiers: GEN007800

References: ECSC-1, 1551

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    ps ax | grep -i miredo | grep -v grep | awk ' { print $1 }' | xargs kill

### Uncommon Network Protocols [ref]group

The system includes support for several network protocols which are not commonly used. Although security vulnerabilities in kernel networking code are not frequently discovered, the consequences can be dramatic. Ensuring uncommon network protocols are disabled reduces the system's risk to attacks targeted at its implementation of those protocols.

Warning: Although these protocols are not commonly used, avoid disruption in your network environment by ensuring they are not needed prior to disabling them.

contains 7 rules

#### Disable DCCP Support [ref]rule

The Datagram Congestion Control Protocol (DCCP) is a relatively new transport layer protocol, designed to support streaming media and telephony. To configure the system to prevent the `dccp` kernel module from being loaded, add the following line to a file in the directory `/etc/modprobe.d`:

    install dccp /bin/true

Rationale:

Disabling DCCP protects the system against exploitation of any flaws in its implementation.

Severity: medium

Identifiers: GEN007080

References: ECSC-1, 382

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -d /etc/modprobe.d/ ]; then
    	echo "install dccp /bin/true" >> /etc/modprobe.d/disabled_modules.conf
    	echo "install dccp_ipv4 /bin/true" >> /etc/modprobe.d/disabled_modules.conf
    	echo "install dccp_ipv6 /bin/true" >> /etc/modprobe.d/disabled_modules.conf
    else
    	echo "install dccp /bin/true" >> /etc/modprobe.conf
    	echo "install dccp_ipv4 /bin/true" >> /etc/modprobe.conf
    	echo "install dccp_ipv6 /bin/true" >> /etc/modprobe.conf
    fi

#### Disable SCTP Support [ref]rule

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. To configure the system to prevent the `sctp` kernel module from being loaded, add the following line to a file in the directory `/etc/modprobe.d`:

    install sctp /bin/true

Rationale:

Disabling SCTP protects the system against exploitation of any flaws in its implementation.

Severity: medium

Identifiers: GEN007020

References: ECSC-1, 382

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -d /etc/modprobe.d/ ]; then
    	echo "install sctp /bin/true" >> /etc/modprobe.d/disabled_modules.conf
    else
    	echo "install sctp /bin/true" >> /etc/modprobe.conf
    fi

#### Disable RDS Support [ref]rule

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. To configure the system to prevent the `rds` kernel module from being loaded, add the following line to a file in the directory `/etc/modprobe.d`:

    install rds /bin/true

Rationale:

Disabling RDS protects the system against exploitation of any flaws in its implementation.

Severity: low

Identifiers: GEN007480

References: ECSC-1, 382

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -d /etc/modprobe.d/ ]; then
    	echo "install rds /bin/true" >> /etc/modprobe.d/disabled_modules.conf
    else
    	echo "install rds /bin/true" >> /etc/modprobe.conf
    fi

#### Disable TIPC Support [ref]rule

The Transparent Inter-Process Communication (TIPC) protocol is designed to provide communications between nodes in a cluster. To configure the system to prevent the `tipc` kernel module from being loaded, add the following line to a file in the directory `/etc/modprobe.d`:

    install tipc /bin/true

Rationale:

Disabling TIPC protects the system against exploitation of any flaws in its implementation.

Severity: medium

Identifiers: GEN007540

References: ECSC-1, 382

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -d /etc/modprobe.d/ ]; then
    	echo "install tipc /bin/true" >> /etc/modprobe.d/disabled_modules.conf
    else
    	echo "install tipc /bin/true" >> /etc/modprobe.conf
    fi

#### Disable AppleTalk Support [ref]rule

The AppleTalk suite of protocols is no longer in common use. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the system to dynamically load a protocol handler by opening a socket using the protocol. To configure the system to prevent the `appletalk` kernel module from being loaded, add the following line to a file in the directory `/etc/modprobe.d`:

    install appletalk /bin/true

Rationale:

Disabling AppleTalk protects the system against exploitation of any flaws in its implementation.

Severity: medium

Identifiers: GEN007260

References: ECSC-1, 382

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -d /etc/modprobe.d/ ]; then
    	echo "install appletalk /bin/true" >> /etc/modprobe.d/disabled_modules.conf
    else
    	echo "install appletalk /bin/true" >> /etc/modprobe.conf
    fi

#### Disable Network Bridging Support [ref]rule

Some systems have the ability to bridge or switch frames (link-layer forwarding) between multiple interfaces. This can be useful in a variety of situations but, if enabled when not needed, has the potential to bypass network partitioning and security. To configure the system to prevent the `bridge` kernel module from being loaded, add the following line to a file in the directory `/etc/modprobe.d`:

    install bridge /bin/true

Rationale:

Disabling network bridging protects the system against exploitation of any flaws in its implementation.

Severity: medium

Identifiers: GEN003619

References: ECSC-1, 1551

Remediation Shell script: (show)

Complexity: | low
Disruption: | medium
Reboot: | true
Strategy: | disable

    if [ -d /etc/modprobe.d/ ]; then
    	echo "install bridge /bin/true" >> /etc/modprobe.d/disabled_modules.conf
    else
    	echo "install bridge /bin/true" >> /etc/modprobe.conf
    fi

#### Disable IEEE1394 (Firewire) Support [ref]rule

Firewire is a common computer peripheral interface. Firewire devices may include storage devices with the potential to install malicious software on a system or exfiltrate data. To configure the system to prevent the `ieee1394` kernel module from being loaded, add the following line to a file in the directory `/etc/modprobe.d`:

    install ieee1394 /bin/true

Rationale:

Disabling IEEE1394 (Firewire) protects the system against exploitation of any flaws in its implementation.

Severity: low

Identifiers: GEN008500

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | medium
Reboot: | true
Strategy: | disable

    if [ -d /etc/modprobe.d/ ]; then
    	echo "install ieee1394 /bin/true" >> /etc/modprobe.d/disabled_modules.conf
    else
    	echo "install ieee1394 /bin/true" >> /etc/modprobe.conf
    fi

### Configure Syslog [ref]group

The syslog service has been the default Unix logging mechanism for many years. It has a number of downsides, including inconsistent log format, lack of authentication for received messages, and lack of authentication, encryption, or reliable transport for messages sent over a network. However, due to its long history, syslog is a de facto standard which is supported by almost all Unix applications.

contains 3 rules

### Syslog Logs Sent To Remote Host [ref]group

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.
However, it is recommended that logs be stored on the local host in addition to being sent to the loghost, especially if `syslog` has been configured to use the UDP protocol to send messages over a network. UDP does not guarantee reliable delivery, and moderately busy sites will lose log messages occasionally, especially in periods of high traffic which may be the result of an attack. In addition, remote `syslog` messages are not authenticated in any way by default, so it is easy for an attacker to introduce spurious messages to the central log server. Also, some problems cause loss of network connectivity, which will prevent the sending of messages to the central server. For all of these reasons, it is better to store log messages both centrally and on each host, so that they can be correlated if necessary.

contains 1 rule

#### Ensure Logs Sent To Remote Host [ref]rule

To configure syslog to send logs to a remote log server, open `/etc/syslog.conf` and read and understand the last section of the file, which describes the multiple directives necessary to activate remote logging. Along with these other directives, the system can be configured to forward its logs to a particular log server by adding or correcting one of the following lines, substituting `loghost.example.com` appropriately. The choice of protocol depends on the environment of the system; although TCP and RELP provide more reliable message delivery, they may not be supported in all environments.
To use UDP for log message delivery:

    *.* @loghost.example.com

To use TCP for log message delivery:

    *.* @@loghost.example.com

To use RELP for log message delivery:

    *.* :omrelp:loghost.example.com

Rationale:

A log server (loghost) receives syslog messages from one or more systems. This data can be used as an additional log source in the event a system is compromised and its local logs are suspect. Forwarding log messages to a remote loghost also provides system administrators with a centralized place to view the status of multiple hosts within the enterprise.

Severity: low

Identifiers: GEN005460

References: ECSC-1, 366

### Configure syslogd to Accept Remote Messages If Acting as a Log Server [ref]group

By default, `syslog` does not listen over the network for log messages. If needed, modules can be enabled to allow the syslog daemon to receive messages from other systems and for the system thus to act as a log server. If the machine is not a log server, then lines concerning these modules should remain commented out.

contains 1 rule

#### Ensure syslog Does Not Accept Remote Messages Unless Acting As Log Server [ref]rule

The `syslog` daemon should not accept remote messages unless the system acts as a log server. To ensure that it is not listening on the network, ensure the following lines are not found in `/etc/syslog.conf`:

    $ModLoad imtcp.so
    $InputTCPServerRun port
    $ModLoad imudp.so
    $InputUDPServerRun port
    $ModLoad imrelp.so
    $InputRELPServerRun port

Rationale:

Any process which receives messages from the network incurs some risk of receiving malicious messages. This risk can be eliminated for syslog by configuring it not to listen on the network.

Severity: low

Identifiers: GEN005480

References: ECSC-1, 366

### Ensure All Logs are Rotated by logrotate [ref]group

Edit the file `/etc/logrotate.d/syslog`. Find the first line, which should look like this (wrapped for clarity):

    /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/syslog.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.

contains 1 rule

#### Ensure Logrotate Runs Periodically [ref]rule

The `logrotate` utility allows for the automatic rotation of log files. The frequency of rotation is specified in `/etc/logrotate.conf`, which triggers a cron task. To configure logrotate to run daily, add or correct the following line in `/etc/logrotate.conf`:

    # rotate log files frequency
    daily

Rationale:

Log files that are not properly rotated run the risk of growing so large that they fill up the /var/log partition. Valuable logging information could be lost if the /var/log partition becomes full.

Severity: low

Identifiers: GEN002860

References: ECSC-1, 366

### System Accounting with auditd [ref]group

The audit service provides substantial capabilities for recording system activities. By default, the service audits about SELinux AVC denials and certain types of security-relevant events such as system logins, account modifications, and authentication events performed by programs such as sudo. Under its default configuration, `auditd` has modest disk space requirements, and should not noticeably impact system performance.
Government networks often have substantial auditing requirements and `auditd` can be configured to meet these requirements. Examining some example audit records demonstrates how the Linux audit system satisfies common requirements. The following example from Fedora Documentation available at `http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages.html` shows the substantial amount of information captured in a two typical "raw" audit messages, followed by a breakdown of the most important fields. In this example the message is SELinux-related and reports an AVC denial (and the associated system call) that occurred when the Apache HTTP Server attempted to access the `/var/www/html/file1` file (labeled with the `samba_share_t` type):

    type=AVC msg=audit(1226874073.147:96): avc:  denied  { getattr } for pid=2465 comm="httpd"
    path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0
    tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

    type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13
    a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48
    gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd"
    exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

- `msg=audit(1226874073.147:96)`
  - The number in parentheses is the unformatted time stamp (Epoch time) for the event, which can be converted to standard time by using the `date` command.
- `{ getattr }`
  - The item in braces indicates the permission that was denied. `getattr` indicates the source process was trying to read the target file's status information. This occurs before reading files. This action is denied due to the file being accessed having the wrong label. Commonly seen permissions include `getattr`, `read`, and `write`.
- `comm="httpd"`
  - The executable that launched the process. The full path of the executable is found in the `exe=` section of the system call (`SYSCALL`) message, which in this case, is `exe="/usr/sbin/httpd"`.
- `path="/var/www/html/file1"`
  - The path to the object (target) the process attempted to access.
- `scontext="unconfined_u:system_r:httpd_t:s0"`
  - The SELinux context of the process that attempted the denied action. In this case, it is the SELinux context of the Apache HTTP Server, which is running in the `httpd_t` domain.
- `tcontext="unconfined_u:object_r:samba_share_t:s0"`
  - The SELinux context of the object (target) the process attempted to access. In this case, it is the SELinux context of `file1`. Note: the `samba_share_t` type is not accessible to processes running in the `httpd_t` domain.
- From the system call (`SYSCALL`) message, two items are of interest:
  - `success=no`: indicates whether the denial (AVC) was enforced or not. `success=no` indicates the system call was not successful (SELinux denied access). `success=yes` indicates the system call was successful - this can be seen for permissive domains or unconfined domains, such as `initrc_t` and `kernel_t`.
  - `exe="/usr/sbin/httpd"`: the full path to the executable that launched the process, which in this case, is `exe="/usr/sbin/httpd"`.

contains 40 rules

### Configure auditd Data Retention [ref]group

The audit system writes data to `/var/log/audit/audit.log`. By default, `auditd` rotates 5 logs by size (6MB), retaining a maximum of 30MB 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. This also minimizes the risk of the audit daemon temporarily disabling the system if it cannot write audit log (which it can be configured to do). For a busy system or a system which is thoroughly auditing system activity, the default settings for data retention may 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 awhile 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, 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. If your system is configured to halt when logging cannot be performed, make sure this can never happen under normal circumstances! Ensure that `/var/log/audit` is on its own partition, and that this partition is larger than the maximum amount of data `auditd` will retain normally.

References: AU-11, 138

contains 3 rules

#### Configure auditd space_left Action on Low Disk Space [ref]rule

The `auditd` service can be configured to take an action when disk space starts to run low. Edit the file `/etc/audit/auditd.conf`. Modify the following line, substituting ACTION appropriately:

    space_left_action = ACTION

Possible values for ACTION are described in the `auditd.conf` man page. These include:

- `ignore`
- `syslog`
- `email`
- `exec`
- `suspend`
- `single`
- `halt`

Set this to `email` (instead of the default, which is `suspend`) as it is more likely to get prompt attention. Acceptable values also include `suspend`, `single`, and `halt`. Rationale:

Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption.

Severity: medium

Identifiers: GEN002730

References: ECSC-1, 143

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/auditd.conf ]; then
    	AUDITD_CONF_FILE="/etc/audit/auditd.conf"
    elif [ -e /etc/auditd.conf ]; then
    	AUDITD_CONF_FILE="/etc/auditd.conf"
    else
    	exit
    fi

    if [ "$(grep -v "#" ${AUDITD_CONF_FILE} | grep -c space_left_action)" != "0" ]; then
    	sed -i 's/space_left_action.*/space_left_action = syslog/' ${AUDITD_CONF_FILE}
    else
    	echo "space_left_action = syslog">>${AUDITD_CONF_FILE}
    fi

#### Configure auditd disk_error_action and disk_full_action on Storage Failures [ref]rule

The `auditd` service can be configured to take an action when the disk errors or becomes full. Edit the file `/etc/audit/auditd.conf`. Add or modify the following lines, substituting ACTION appropriately:

    disk_error_action = ACTION

    disk_full_action = ACTION

Set this value to `single` to cause the system to switch to single user mode for corrective action. Acceptable values also include `syslog`, `exec`, and `halt`. For certain systems, the need for availability outweighs the need to log all actions, and a different setting should be determined. Details regarding all possible values for ACTION are described in the `auditd.conf` man page. Rationale:

Administrators should be made aware of an inability to write to disk.

Severity: low

Identifiers: GEN002719

References: ECAT-1, 139

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    var_auditd_disk_error_action="syslog"

    if [ -e /etc/audit/auditd.conf ]; then
    	AUDITD_CONF_FILE="/etc/audit/auditd.conf"
    elif [ -e /etc/auditd.conf ]; then
    	AUDITD_CONF_FILE="/etc/auditd.conf"
    else
    	exit
    fi

    grep -q ^disk_error_action ${AUDITD_CONF_FILE} && \
      sed -i "s/disk_error_action.*/disk_error_action = $var_auditd_disk_error_action/g" ${AUDITD_CONF_FILE}
    if ! [ $? -eq 0 ]; then
        echo "disk_error_action = $var_auditd_disk_error_action" >> ${AUDITD_CONF_FILE}
    fi
    grep -q ^disk_full_action ${AUDITD_CONF_FILE} && \
      sed -i "s/disk_full_action.*/disk_full_action = $var_auditd_disk_error_action/g" ${AUDITD_CONF_FILE}
    if ! [ $? -eq 0 ]; then
        echo "disk_full_action = $var_auditd_disk_error_action" >> ${AUDITD_CONF_FILE}
    fi

#### Configure auditd to use audispd's syslog plugin [ref]rule

To configure the `auditd` service to use the `syslog` plug-in of the `audispd` audit event multiplexor, set the `active` line in `/etc/audisp/plugins.d/syslog.conf` to `yes`. Restart the `auditd` service:

    # service auditd restart

Rationale:

The auditd service does not include the ability to send audit records to a centralized server for management directly. It does, however, include a plug-in for audit event multiplexor (audispd) to pass audit records to the local syslog server

Severity: low

Identifiers: GEN002870

References: ECTB-1, 136

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    grep -q ^active /etc/audisp/plugins.d/syslog.conf && \
      sed -i "s/active.*/active = yes/g" /etc/audisp/plugins.d/syslog.conf
    if ! [ $? -eq 0 ]; then
        echo "active = yes" >> /etc/audisp/plugins.d/syslog.conf
    fi

### Configure auditd Rules for Comprehensive Auditing [ref]group

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 exists to facilitate community discussion of the auditing system.
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 at startup are controlled by 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 during runtime. See documentation in `/usr/share/doc/audit-VERSION` and in the related man pages for more details.
If copying any example audit rulesets from `/usr/share/doc/audit-VERSION`, be sure to 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, the new rules can be activated as follows:

    # service auditd restart

contains 35 rules

### Records Events that Modify Date and Time Information [ref]group

Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time. All changes to the system time should be audited.

contains 4 rules

#### Record attempts to alter time through adjtimex [ref]rule

On a 32-bit system, add the following to `/etc/audit/audit.rules`:

    # audit_time_rules
    -a exit,always -F arch=b32 -S adjtimex -k audit_time_rules

On a 64-bit system, add the following to `/etc/audit/audit.rules`:

    # audit_time_rules
    -a exit,always -F arch=b64 -S adjtimex -k audit_time_rules

The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls:

    -a exit,always -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules

Rationale:

Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.

Severity: low

Identifiers: GEN002760-3

References: ECAR-1, ECAR-2, ECAR-3, 347, ECAR-1, ECAR-2, ECAR-3, 347

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k audit_time_rules"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S adjtimex '`" = "0" ]; then
    	if [ "`uname -p`" != "x86_64" ]; then
    		echo "-a exit,always -F arch=b32 -S adjtimex ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b64 -S adjtimex ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record attempts to alter time through settimeofday [ref]rule

On a 32-bit system, add the following to `/etc/audit/audit.rules`:

    # audit_time_rules
    -a exit,always -F arch=b32 -S settimeofday -k audit_time_rules

On a 64-bit system, add the following to `/etc/audit/audit.rules`:

    # audit_time_rules
    -a exit,always -F arch=b64 -S settimeofday -k audit_time_rules

The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls:

    -a exit,always -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules

Rationale:

Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.

Severity: low

Identifiers: GEN002760-4

References: ECAR-1, ECAR-2, ECAR-3, 347, ECAR-1, ECAR-2, ECAR-3, 347

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k audit_time_rules"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S settimeofday '`" = "0" ]; then
    	if [ "`uname -p`" != "x86_64" ]; then
    		echo "-a exit,always -F arch=b32 -S settimeofday ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b64 -S settimeofday ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record Attempts to Alter Time Through stime [ref]rule

Add the following line to `/etc/audit/audit.rules` for both 32-bit and 64-bit systems:

    # audit_time_rules
    -a always,exit -F arch=b32 -S stime -k audit_time_rules

Since the 64-bit version of the "stime" system call is not defined in the audit lookup table, the corresponding "-F arch=b64" form of this rule is not expected to be defined on 64-bit systems (the aforementioned "-F arch=b32" stime rule form itself is sufficient for both 32-bit and 64-bit systems). The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls:

    -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules

Rationale:

Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.

Severity: low

Identifiers: GEN002760-5

References: ECAR-1, ECAR-2, ECAR-3, 347, ECAR-1, ECAR-2, ECAR-3, 347

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k audit_time_rules"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S stime '`" = "0" ]; then
    	if [ "`uname -p`" != "x86_64" ]; then
    		echo "-a exit,always -F arch=b32 -S stime ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    		# stime is not supported on 64-bit.
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record Attempts to Alter Time Through clock_settime [ref]rule

On a 32-bit system, add the following to `/etc/audit/audit.rules`:

    # time-change
    -a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change

On a 64-bit system, add the following to `/etc/audit/audit.rules`:

    # time-change
    -a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change

The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls:

    -a exit,always -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules

Rationale:

Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.

Severity: low

Identifiers: GEN002760-6

References: ECAR-1, ECAR-2, ECAR-3, 347, ECAR-1, ECAR-2, ECAR-3, 347

### Record Events that Modify the System's Discretionary Access Controls [ref]group

At a minimum the audit system should collect file permission changes for all users and root. Note that the "-F arch=b32" lines should be present even on a 64 bit system. These commands identify system calls for auditing. Even if the system is 64 bit it can still execute 32 bit system calls. Additionally, these rules can be configured in a number of ways while still achieving the desired effect. An example of this is that the "-S" calls could be split up and placed on separate lines, however, this is less efficient. Add the following to `/etc/audit/audit.rules`:

    -a exit,always -F arch=b32 -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod
        -a exit,always -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod
        -a exit,always -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

If your system is 64 bit then these lines should be duplicated and the arch=b32 replaced with arch=b64 as follows:

    -a exit,always -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod
        -a exit,always -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod
        -a exit,always -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

contains 13 rules

#### Record Events that Modify the System's Discretionary Access Controls - chmod [ref]rule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to `/etc/audit/audit.rules`:

    -a exit,always -F arch=b32 -S chmod -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

    -a exit,always -F arch=b64 -S chmod  -F auid>=500 -F auid!=4294967295 -k perm_mod

Warning: Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Severity: low

Identifiers: GEN002820

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k perm_mod"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S chmod '`" = "0" ]; then
    	if [ "`uname -p`" = "x86_64" ]; then
    		echo "-a exit,always -F arch=b64 -S chmod ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b32 -S chmod ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record Events that Modify the System's Discretionary Access Controls - chown [ref]rule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to `/etc/audit/audit.rules`:

    -a exit,always -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

    -a exit,always -F arch=b64 -S chown -F auid>=500 -F auid!=4294967295 -k perm_mod

Warning: Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Severity: low

Identifiers: GEN002820-4

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k perm_mod"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S chown '`" = "0" ]; then
    	if [ "`uname -p`" = "x86_64" ]; then
    		echo "-a exit,always -F arch=b64 -S chown ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b32 -S chown ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S chown32 '`" = "0" ]; then
    	if [ "`uname -p`" = "x86_64" ]; then
    		echo "-a exit,always -F arch=b64 -S chown32 ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b32 -S chown32 ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record Events that Modify the System's Discretionary Access Controls - fchmod [ref]rule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to `/etc/audit/audit.rules`:

    -a exit,always -F arch=b32 -S fchmod -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

    -a exit,always -F arch=b64 -S fchmod -F auid>=500 -F auid!=4294967295 -k perm_mod

Warning: Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Severity: low

Identifiers: GEN002820-2

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k perm_mod"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fchmod '`" = "0" ]; then
    	if [ "`uname -p`" = "x86_64" ]; then
    		echo "-a exit,always -F arch=b64 -S fchmod ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b32 -S fchmod ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record Events that Modify the System's Discretionary Access Controls - fchmodat [ref]rule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to `/etc/audit/audit.rules`:

    -a exit,always -F arch=b32 -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

    -a exit,always -F arch=b64 -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod

Warning: Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Severity: low

Identifiers: GEN002820-3

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k perm_mod"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fchmodat '`" = "0" ]; then
    	if [ "`uname -p`" = "x86_64" ]; then
    		echo "-a exit,always -F arch=b64 -S fchmodat ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b32 -S fchmodat ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record Events that Modify the System's Discretionary Access Controls - fchown [ref]rule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to `/etc/audit/audit.rules`:

    -a exit,always -F arch=b32 -S fchown -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

    -a exit,always -F arch=b64 -S fchown -F auid>=500 -F auid!=4294967295 -k perm_mod

Warning: Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Severity: low

Identifiers: GEN002820-5

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k perm_mod"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fchown '`" = "0" ]; then
    	if [ "`uname -p`" = "x86_64" ]; then
    		echo "-a exit,always -F arch=b64 -S fchown ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b32 -S fchown ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fchown32 '`" = "0" ]; then
    	if [ "`uname -p`" = "x86_64" ]; then
    		echo "-a exit,always -F arch=b64 -S fchown32 ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b32 -S fchown32 ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record Events that Modify the System's Discretionary Access Controls - fchownat [ref]rule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to `/etc/audit/audit.rules`:

    -a exit,always -F arch=b32 -S fchownat -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

    -a exit,always -F arch=b64 -S fchownat -F auid>=500 -F auid!=4294967295 -k perm_mod

Warning: Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Severity: low

Identifiers: GEN002820-6

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k perm_mod"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fchownat '`" = "0" ]; then
    	if [ "`uname -p`" = "x86_64" ]; then
    		echo "-a exit,always -F arch=b64 -S fchownat ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b32 -S fchownat ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record Events that Modify the System's Discretionary Access Controls - fremovexattr [ref]rule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to `/etc/audit/audit.rules`:

    -a exit,always -F arch=b32 -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

    -a exit,always -F arch=b64 -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

Warning: Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Severity: low

Identifiers: GEN002820-13

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k perm_mod"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fremovexattr '`" = "0" ]; then
    	if [ "`uname -p`" = "x86_64" ]; then
    		echo "-a exit,always -F arch=b64 -S fremovexattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b32 -S fremovexattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record Events that Modify the System's Discretionary Access Controls - fsetxattr [ref]rule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to `/etc/audit/audit.rules`:

    -a exit,always -F arch=b32 -S fsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

    -a exit,always -F arch=b64 -S fsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod

Warning: Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Severity: low

Identifiers: GEN002820-10

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k perm_mod"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fsetxattr '`" = "0" ]; then
    	if [ "`uname -p`" = "x86_64" ]; then
    		echo "-a exit,always -F arch=b64 -S fsetxattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b32 -S fsetxattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record Events that Modify the System's Discretionary Access Controls - lchown [ref]rule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to `/etc/audit/audit.rules`:

    -a exit,always -F arch=b32 -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

    -a exit,always -F arch=b64 -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod

Warning: Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Severity: low

Identifiers: GEN002820-7

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k perm_mod"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S lchown '`" = "0" ]; then
    	if [ "`uname -p`" = "x86_64" ]; then
    		echo "-a exit,always -F arch=b64 -S lchown ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b32 -S lchown ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S lchown32 '`" = "0" ]; then
    	if [ "`uname -p`" = "x86_64" ]; then
    		echo "-a exit,always -F arch=b64 -S lchown32 ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b32 -S lchown32 ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record Events that Modify the System's Discretionary Access Controls - lremovexattr [ref]rule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to `/etc/audit/audit.rules`:

    -a exit,always -F arch=b32 -S lremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

    -a exit,always -F arch=b64 -S lremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

Warning: Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Severity: low

Identifiers: GEN002820-12

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k perm_mod"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S lremovexattr '`" = "0" ]; then
    	if [ "`uname -p`" = "x86_64" ]; then
    		echo "-a exit,always -F arch=b64 -S lremovexattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b32 -S lremovexattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record Events that Modify the System's Discretionary Access Controls - lsetxattr [ref]rule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to `/etc/audit/audit.rules`:

    -a exit,always -F arch=b32 -S lsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

    -a exit,always -F arch=b64 -S lsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod

Warning: Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Severity: low

Identifiers: GEN002820-9

References: ECAR-1, ECAR-2, ECAR-3, http://iase.disa.mil/stigs/cci/Pages/index.aspx

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k perm_mod"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S lsetxattr '`" = "0" ]; then
    	if [ "`uname -p`" = "x86_64" ]; then
    		echo "-a exit,always -F arch=b64 -S lsetxattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b32 -S lsetxattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record Events that Modify the System's Discretionary Access Controls - removexattr [ref]rule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to `/etc/audit/audit.rules`:

    -a exit,always -F arch=b32 -S removexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

    -a exit,always -F arch=b64 -S removexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

Warning: Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Severity: low

Identifiers: GEN002820-11

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k perm_mod"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S removexattr '`" = "0" ]; then
    	if [ "`uname -p`" = "x86_64" ]; then
    		echo "-a exit,always -F arch=b64 -S removexattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b32 -S removexattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record Events that Modify the System's Discretionary Access Controls - setxattr [ref]rule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to `/etc/audit/audit.rules`:

    -a exit,always -F arch=b32 -S setxattr -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

    -a exit,always -F arch=b64 -S setxattr -F auid>=500 -F auid!=4294967295 -k perm_mod

Warning: Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Severity: low

Identifiers: GEN002820-8

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k perm_mod"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S setxattr '`" = "0" ]; then
    	if [ "`uname -p`" = "x86_64" ]; then
    		echo "-a exit,always -F arch=b64 -S setxattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b32 -S setxattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record Events that Create User/Group Information [ref]rule

Add the following to `/etc/audit/audit.rules`, in order to capture events that create accounts:

    # audit_account_creation
    -w /usr/sbin/groupadd -p x -k audit_account_changes
    -w /usr/sbin/useradd -p x -k audit_account_changes
    -w /etc/group -p a -k audit_account_changes
    -w /etc/passwd -p a -k audit_account_changes
    -w /etc/gshadow -p a -k audit_account_changes
    -w /etc/shadow -p a -k audit_account_changes

Rationale:

In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy.

Severity: low

Identifiers: GEN002750

References: ECAT-1, 18

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    else
    	exit
    fi

    for FILE in /usr/sbin/useradd /usr/sbin/groupadd; do
    	if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then
    		echo "-w ${FILE} -p x -k audit_account_creation" >>${AUDIT_RULES_FILE}
    	elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [wa]*x"`" = "0" ]; then
    		SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')"
    		if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then
    			sed -i "s/\(-w ${SED_FILE}\)/\1 -p x/" ${AUDIT_RULES_FILE}
    		else
    			sed -i "s/\(-w ${SED_FILE} -p \)/\1x/" ${AUDIT_RULES_FILE}
    		fi
    	fi
    done
    for FILE in /etc/group /etc/passwd /etc/gshadow /etc/shadow; do
    	if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then
    		echo "-w ${FILE} -p a -k audit_account_creation" >>${AUDIT_RULES_FILE}
    	elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [wx]*a"`" = "0" ]; then
    		SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')"
    		if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then
    			sed -i "s/\(-w ${SED_FILE}\)/\1 -p a/" ${AUDIT_RULES_FILE}
    		else
    			sed -i "s/\(-w ${SED_FILE} -p \)/\1a/" ${AUDIT_RULES_FILE}
    		fi
    	fi
    done
    service auditd restart 1>/dev/null

#### Record Events that Disable User Accounts [ref]rule

Add the following to `/etc/audit/audit.rules`, in order to capture events that disable accounts:

    # audit_account_disabling
    -w /usr/bin/passwd -p x -k audit_account_disabling

Rationale:

In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy.

Severity: low

Identifiers: GEN002752

References: ECAT-1, 1404

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w /usr/bin/passwd"`" = "0" ]; then
    	echo "-w /usr/bin/passwd -p x -k audit_account_changes" >>${AUDIT_RULES_FILE}
    elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w /usr/bin/passwd -p [wa]*x"`" = "0" ]; then
    	if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w /usr/bin/passwd -p "`" = "0" ]; then
    		sed -i "s/\(-w \/usr\/bin\/passwd\)/\1 -p x/" ${AUDIT_RULES_FILE}
    	else
    		sed -i "s/\(-w \/usr\/bin\/passwd -p \)/\1x/" ${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record Events that Modify User/Group Information [ref]rule

Add the following to `/etc/audit/audit.rules`, in order to capture events that modify account changes:

    # audit_account_changes
    -w /usr/sbin/groupmod -p x -k audit_account_changes
    -w /usr/sbin/usermod -p x -k audit_account_changes
    -w /etc/group -p w -k audit_account_changes
    -w /etc/passwd -p w -k audit_account_changes
    -w /etc/gshadow -p w -k audit_account_changes
    -w /etc/shadow -p w -k audit_account_changes

Rationale:

In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy.

Severity: low

Identifiers: GEN002751

References: ECAT-1, 1403

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    else
    	exit
    fi

    for FILE in /usr/sbin/usermod /usr/sbin/groupmod; do
    	if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then
    		echo "-w ${FILE} -p x -k audit_account_changes" >>${AUDIT_RULES_FILE}
    	elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [wa]*x"`" = "0" ]; then
    		SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')"
    		if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then
    			sed -i "s/\(-w ${SED_FILE}\)/\1 -p x/" ${AUDIT_RULES_FILE}
    		else
    			sed -i "s/\(-w ${SED_FILE} -p \)/\1x/" ${AUDIT_RULES_FILE}
    		fi
    	fi
    done
    for FILE in /etc/group /etc/passwd /etc/gshadow /etc/shadow; do
    	if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then
    		echo "-w ${FILE} -p w -k audit_account_changes" >>${AUDIT_RULES_FILE}
    	elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [xa]*w"`" = "0" ]; then
    		SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')"
    		if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then
    			sed -i "s/\(-w ${SED_FILE}\)/\1 -p w/" ${AUDIT_RULES_FILE}
    		else
    			sed -i "s/\(-w ${SED_FILE} -p \)/\1w/" ${AUDIT_RULES_FILE}
    		fi
    	fi
    done
    service auditd restart 1>/dev/null

#### Record Events that Terminate Users/Groups [ref]rule

Add the following to `/etc/audit/audit.rules`, in order to capture events that terminate accounts:

    # audit_account_termination
    -w /usr/sbin/groupdel -p x -k audit_account_termination
    -w /usr/sbin/userdel -p x -k audit_account_termination

Rationale:

In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy.

Severity: low

Identifiers: GEN002753

References: ECAT-1, 1405

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    else
    	exit
    fi

    for FILE in /usr/sbin/userdel /usr/sbin/groupdel; do
    	if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then
    		echo "-w ${FILE} -p x -k audit_account_changes" >>${AUDIT_RULES_FILE}
    	elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [wa]*x"`" = "0" ]; then
    		SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')"
    		if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then
    			sed -i "s/\(-w ${SED_FILE}\)/\1 -p x/" ${AUDIT_RULES_FILE}
    		else
    			sed -i "s/\(-w ${SED_FILE} -p \)/\1x/" ${AUDIT_RULES_FILE}
    		fi
    	fi
    done
    service auditd restart 1>/dev/null

#### Record Events that Modify the System's Host Name [ref]rule

Add the following to `/etc/audit/audit.rules`, setting ARCH to either b32 or b64 as appropriate for your system:

    # audit_network_sethostname
    -a exit,always -F arch=ARCH -S sethostname -k audit_network_modifications

Rationale:

The network environment should not be modified by anything other than administrator action. Any change to network parameters should be audited.

Severity: low

Identifiers: GEN002760-7

References: ECAR-1, ECAR-2, ECAR-3, 347

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k set_hostname"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`uname -p`" != "x86_64" ]; then
    	echo "-a exit,always -F arch=b32 -S sethostname ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    else
    	echo "-a exit,always -F arch=b64 -S sethostname ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    fi
    service auditd restart 1>/dev/null

#### Record Events that Modify the System's Domain Name [ref]rule

Add the following to `/etc/audit/audit.rules`, setting ARCH to either b32 or b64 as appropriate for your system:

    # audit_network_setdomainname
    -a exit,always -F arch=ARCH -S setdomainname -k audit_network_modifications

Rationale:

The network environment should not be modified by anything other than administrator action. Any change to network parameters should be audited.

Severity: low

Identifiers: GEN002760-8

References: ECAR-1, ECAR-2, ECAR-3, 347

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k set_domainname"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`uname -p`" != "x86_64" ]; then
    	echo "-a exit,always -F arch=b32 -S setdomainname ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    else
    	echo "-a exit,always -F arch=b64 -S setdomainname ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    fi
    service auditd restart 1>/dev/null

#### Record Events that Modify the System's Scheduler Parameters [ref]rule

Add the following to `/etc/audit/audit.rules`, setting ARCH to either b32 or b64 as appropriate for your system:

    # audit_network_sethostname
    -a exit,always -F arch=ARCH -S sched_setparam -k scheduler

Rationale:

The scheduler parameters should not be modified by anything other than administrator action. Any change to network parameters should be audited.

Severity: low

Identifiers: GEN002760-9

References: ECAR-1, ECAR-2, ECAR-3, 347

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k set_scheduler_parameters"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    # check for realtime capabilities
    if [ `lsmod | grep -ic jiffies` = 0 ]; then
    	if [ "`uname -p`" != "x86_64" ]; then
    		echo "-a exit,always -F arch=b32 -S sched_setparam ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b64 -S sched_setparam ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record Events that Modify the System's Scheduler Priorities [ref]rule

Add the following to `/etc/audit/audit.rules`, setting ARCH to either b32 or b64 as appropriate for your system:

    # audit_network_sethostname
    -a exit,always -F arch=ARCH -S sched_setscheduler -k scheduler

Rationale:

The scheduler priorities should not be modified by anything other than administrator action. Any change to network parameters should be audited.

Severity: low

Identifiers: GEN002760-10

References: ECAR-1, ECAR-2, ECAR-3, 347

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k set_scheduler_setting"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    # check for realtime capabilities
    if [ `lsmod | grep -ic jiffies` = 0 ]; then
    	if [ "`uname -p`" != "x86_64" ]; then
    		echo "-a exit,always -F arch=b32 -S sched_setscheduler ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b64 -S sched_setscheduler ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Record Attempts to Alter Logon and Logout Events [ref]rule

The audit system already collects login info for all users and root. To watch for attempted manual edits of files involved in storing logon events, add the following to `/etc/audit/audit.rules`:

    -w /var/log/faillog -p wa -k logins
    -w /var/log/lastlog -p wa -k logins

Rationale:

Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion.

Severity: low

Identifiers: GEN002800

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    else
    	exit
    fi
    for FILE in /var/log/faillog /var/log/lastlog; do
    	if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then
    		echo "-w ${FILE} -p wa -k audit_login_events" >>${AUDIT_RULES_FILE}
    	elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [x]*\(wa\|aw\)"`" = "0" ]; then
    		SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')"
    		if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then
    			sed -i "s/\(-w ${SED_FILE}\)/\1 -p wa/" ${AUDIT_RULES_FILE}
    		else
    			if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [xa]*w"`" = "0" ]; then
    				sed -i "s/\(-w ${SED_FILE} -p \)/\1w/" ${AUDIT_RULES_FILE}
    			fi
    			if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [xw]*a"`" = "0" ]; then
    				sed -i "s/\(-w ${SED_FILE} -p \)/\1a/" ${AUDIT_RULES_FILE}
    			fi
    		fi
    	fi
    done
    service auditd restart 1>/dev/null

#### Record Attempts to Alter Audit Rules [ref]rule

To watch for attempted manual edits of audit rules, add the following to `/etc/audit/audit.rules`:

    -w /etc/audit/audit.rules -p w -k audit_rules

Rationale:

Manual editing of audit rules may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion.

Severity: low

Identifiers: GEN002760-2

References: ECAR-1, ECAR-2, ECAR-3, 347

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${AUDIT_RULES_FILE}"`" = "0" ]; then
    	echo "-w ${AUDIT_RULES_FILE} -p wa -k audit_rules_changes" >>${AUDIT_RULES_FILE}
    elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${AUDIT_RULES_FILE} -p [x]*\(wa\|aw\)"`" = "0" ]; then
    	if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${AUDIT_RULES_FILE} -p "`" = "0" ]; then
    		sed -i "s/\(-w ${AUDIT_RULES_FILE}\)/\1 -p wa/" ${AUDIT_RULES_FILE}
    	else
    		if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${AUDIT_RULES_FILE} -p [xa]*w"`" = "0" ]; then
    			sed -i "s/\(-w ${AUDIT_RULES_FILE} -p \)/\1w/" ${AUDIT_RULES_FILE}
    		fi
    		if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${AUDIT_RULES_FILE} -p [xw]*a"`" = "0" ]; then
    			sed -i "s/\(-w ${AUDIT_RULES_FILE} -p \)/\1a/" ${AUDIT_RULES_FILE}
    		fi
    	fi
    fi
    service auditd restart 1>/dev/null

#### Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) Via creat [ref]rule

At a minimum the audit system should collect unauthorized file accesses for all users and root. Add the following to `/etc/audit/audit.rules`, setting ARCH to either b32 or b64 as appropriate for your system with either:

    -a exit,always -F arch=ARCH -S creat -F success=0 -k access

or

    -a exit,always -F arch=ARCH -S creat -F exit=-EPERM -k access
    -a exit,always -F arch=ARCH -S creat -F exit=-EACCES -k access

Rationale:

Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise.

Severity: low

Identifiers: GEN002720

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	if [ "`grep " -S creat " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EACCES'`" = "0" ]; then
    		if [ "`uname -p`" != "x86_64" ]; then
    			echo "-a exit,always -F arch=b32 -S creat -F exit=-EACCES -k access" >>/etc/audit/audit.rules
    		else
    			echo "-a exit,always -F arch=b64 -S creat -F exit=-EACCES -k access" >>/etc/audit/audit.rules
    		fi
    	fi
    	if [ "`grep " -S creat " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EPERM'`" = "0" ]; then
    		if [ "`uname -p`" != "x86_64" ]; then
    			echo "-a exit,always -F arch=b32 -S creat -F exit=-EPERM -k access" >>/etc/audit/audit.rules
    		else
    			echo "-a exit,always -F arch=b64 -S creat -F exit=-EPERM -k access" >>/etc/audit/audit.rules
    		fi
    	fi
    elif [ -e /etc/audit.rules ]; then
    	if [ "`grep " -S creat " /etc/audit.rules | grep -v '#' | grep -c '\success=0'`" = "0" ]; then
    		if [ "`uname -p`" != "x86_64" ]; then
    			echo "-a exit,always -F arch=b32 -S creat -F success=0" >>/etc/audit.rules
    		else
    			echo "-a exit,always -F arch=b64 -S creat -F success=0" >>/etc/audit.rules
    		fi
    	fi
    else
    	exit
    fi
    service auditd restart 1>/dev/null

#### Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) Via ftruncate [ref]rule

At a minimum the audit system should collect unauthorized file accesses for all users and root. Add the following to `/etc/audit/audit.rules`, setting ARCH to either b32 or b64 as appropriate for your system with either:

    -a exit,always -F arch=ARCH -S ftruncate -F success=0 -k access

or

    -a exit,always -F arch=ARCH -S ftruncate -F exit=-EPERM -k access
    -a exit,always -F arch=ARCH -S ftruncate -F exit=-EACCES -k access

Rationale:

Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise.

Severity: low

Identifiers: GEN002720-5

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	if [ "`grep " -S ftruncate " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EACCES'`" = "0" ]; then
    		if [ "`uname -p`" != "x86_64" ]; then
    			echo "-a exit,always -F arch=b32 -S ftruncate -F exit=-EACCES -k access" >>/etc/audit/audit.rules
    		else
    			echo "-a exit,always -F arch=b64 -S ftruncate -F exit=-EACCES -k access" >>/etc/audit/audit.rules
    		fi
    	fi
    	if [ "`grep " -S ftruncate " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EPERM'`" = "0" ]; then
    		if [ "`uname -p`" != "x86_64" ]; then
    			echo "-a exit,always -F arch=b32 -S ftruncate -F exit=-EPERM -k access" >>/etc/audit/audit.rules
    		else
    			echo "-a exit,always -F arch=b64 -S ftruncate -F exit=-EPERM -k access" >>/etc/audit/audit.rules
    		fi
    	fi
    elif [ -e /etc/audit.rules ]; then
    	if [ "`grep " -S ftruncate " /etc/audit.rules | grep -v '#' | grep -c '\success=0'`" = "0" ]; then
    		if [ "`uname -p`" != "x86_64" ]; then
    			echo "-a exit,always -F arch=b32 -S ftruncate -F success=0" >>/etc/audit.rules
    		else
    			echo "-a exit,always -F arch=b64 -S ftruncate -F success=0" >>/etc/audit.rules
    		fi
    	fi
    else
    	exit
    fi
    service auditd restart 1>/dev/null

#### Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) Via open [ref]rule

At a minimum the audit system should collect unauthorized file accesses for all users and root. Add the following to `/etc/audit/audit.rules`, setting ARCH to either b32 or b64 as appropriate for your system with either:

    -a exit,always -F arch=ARCH -S open -F success=0 -k access

or

    -a exit,always -F arch=ARCH -S open -F exit=-EPERM -k access
    -a exit,always -F arch=ARCH -S open -F exit=-EACCES -k access

Rationale:

Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise.

Severity: low

Identifiers: GEN002720-2

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	if [ "`grep " -S open " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EACCES'`" = "0" ]; then
    		if [ "`uname -p`" != "x86_64" ]; then
    			echo "-a exit,always -F arch=b32 -S open -F exit=-EACCES -k access" >>/etc/audit/audit.rules
    		else
    			echo "-a exit,always -F arch=b64 -S open -F exit=-EACCES -k access" >>/etc/audit/audit.rules
    		fi
    	fi
    	if [ "`grep " -S open " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EPERM'`" = "0" ]; then
    		if [ "`uname -p`" != "x86_64" ]; then
    			echo "-a exit,always -F arch=b32 -S open -F exit=-EPERM -k access" >>/etc/audit/audit.rules
    		else
    			echo "-a exit,always -F arch=b64 -S open -F exit=-EPERM -k access" >>/etc/audit/audit.rules
    		fi
    	fi
    elif [ -e /etc/audit.rules ]; then
    	if [ "`grep " -S open " /etc/audit.rules | grep -v '#' | grep -c '\success=0'`" = "0" ]; then
    		if [ "`uname -p`" != "x86_64" ]; then
    			echo "-a exit,always -F arch=b32 -S open -F success=0" >>/etc/audit.rules
    		else
    			echo "-a exit,always -F arch=b64 -S open -F success=0" >>/etc/audit.rules
    		fi
    	fi
    else
    	exit
    fi
    service auditd restart 1>/dev/null

#### Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) Via openat [ref]rule

At a minimum the audit system should collect unauthorized file accesses for all users and root. Add the following to `/etc/audit/audit.rules`, setting ARCH to either b32 or b64 as appropriate for your system with either:

    -a exit,always -F arch=ARCH -S openat -F success=0 -k access

or

    -a exit,always -F arch=ARCH -S openat -F exit=-EPERM -k access
    -a exit,always -F arch=ARCH -S openat -F exit=-EACCES -k access

Rationale:

Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise.

Severity: low

Identifiers: GEN002720-3

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	if [ "`grep " -S openat " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EACCES'`" = "0" ]; then
    		if [ "`uname -p`" != "x86_64" ]; then
    			echo "-a exit,always -F arch=b32 -S openat -F exit=-EACCES -k access" >>/etc/audit/audit.rules
    		else
    			echo "-a exit,always -F arch=b64 -S openat -F exit=-EACCES -k access" >>/etc/audit/audit.rules
    		fi
    	fi
    	if [ "`grep " -S openat " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EPERM'`" = "0" ]; then
    		if [ "`uname -p`" != "x86_64" ]; then
    			echo "-a exit,always -F arch=b32 -S openat -F exit=-EPERM -k access" >>/etc/audit/audit.rules
    		else
    			echo "-a exit,always -F arch=b64 -S openat -F exit=-EPERM -k access" >>/etc/audit/audit.rules
    		fi
    	fi
    elif [ -e /etc/audit.rules ]; then
    	if [ "`grep " -S openat " /etc/audit.rules | grep -v '#' | grep -c '\success=0'`" = "0" ]; then
    		if [ "`uname -p`" != "x86_64" ]; then
    			echo "-a exit,always -F arch=b32 -S openat -F success=0" >>/etc/audit.rules
    		else
    			echo "-a exit,always -F arch=b64 -S openat -F success=0" >>/etc/audit.rules
    		fi
    	fi
    else
    	exit
    fi
    service auditd restart 1>/dev/null

#### Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) Via truncate [ref]rule

At a minimum the audit system should collect unauthorized file accesses for all users and root. Add the following to `/etc/audit/audit.rules`, setting ARCH to either b32 or b64 as appropriate for your system with either:

    -a exit,always -F arch=ARCH -S truncate -F success=0 -k access

or

    -a exit,always -F arch=ARCH -S truncate -F exit=-EPERM -k access
    -a exit,always -F arch=ARCH -S truncate -F exit=-EACCES -k access

Rationale:

Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise.

Severity: low

Identifiers: GEN002720-4

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	if [ "`grep " -S truncate " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EACCES'`" = "0" ]; then
    		if [ "`uname -p`" != "x86_64" ]; then
    			echo "-a exit,always -F arch=b32 -S truncate -F exit=-EACCES -k access" >>/etc/audit/audit.rules
    		else
    			echo "-a exit,always -F arch=b64 -S truncate -F exit=-EACCES -k access" >>/etc/audit/audit.rules
    		fi
    	fi
    	if [ "`grep " -S truncate " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EPERM'`" = "0" ]; then
    		if [ "`uname -p`" != "x86_64" ]; then
    			echo "-a exit,always -F arch=b32 -S truncate -F exit=-EPERM -k access" >>/etc/audit/audit.rules
    		else
    			echo "-a exit,always -F arch=b64 -S truncate -F exit=-EPERM -k access" >>/etc/audit/audit.rules
    		fi
    	fi
    elif [ -e /etc/audit.rules ]; then
    	if [ "`grep " -S truncate " /etc/audit.rules | grep -v '#' | grep -c '\success=0'`" = "0" ]; then
    		if [ "`uname -p`" != "x86_64" ]; then
    			echo "-a exit,always -F arch=b32 -S truncate -F success=0" >>/etc/audit.rules
    		else
    			echo "-a exit,always -F arch=b64 -S truncate -F success=0" >>/etc/audit.rules
    		fi
    	fi
    else
    	exit
    fi
    service auditd restart 1>/dev/null

#### Ensure auditd Collects File Deletion Events by User [ref]rule

At a minimum the audit system should collect file deletion events for all users and root. Add the following to `/etc/audit/audit.rules`, setting ARCH to either b32 or b64 as appropriate for your system:

    -a exit,always -F arch=ARCH -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295 -k delete

Rationale:

Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence.

Severity: low

Identifiers: GEN002740

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k delete"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S unlink '`" = "0" ]; then
    	if [ "`uname -p`" != "x86_64" ]; then
    		echo "-a exit,always -F arch=b32 -S unlink ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b64 -S unlink ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Ensure auditd Collects Directory Deletion Events by User [ref]rule

At a minimum the audit system should collect directory deletion events for all users and root. Add the following to `/etc/audit/audit.rules`, setting ARCH to either b32 or b64 as appropriate for your system:

    -a exit,always -F arch=ARCH -S rmdir -k delete

Rationale:

Auditing directory deletions will create an audit trail for directories that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log directories to conceal their presence.

Severity: low

Identifiers: GEN002740-2

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k delete"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S rmdir '`" = "0" ]; then
    	if [ "`uname -p`" != "x86_64" ]; then
    		echo "-a exit,always -F arch=b32 -S rmdir ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b64 -S rmdir ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    service auditd restart 1>/dev/null

#### Ensure auditd Collects Information on Kernel Module Loading and Unloading [ref]rule

Add the following to `/etc/audit/audit.rules` in order to capture kernel module loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system:

    -w /sbin/insmod -p x -k modules
    -w /sbin/rmmod -p x -k modules
    -w /sbin/modprobe -p x -k modules
    -a exit,always -F arch=ARCH -S init_module -S delete_module -k modules

Rationale:

The addition/removal of kernel modules can be used to alter the behavior of the kernel and potentially introduce malicious code into kernel space. It is important to have an audit trail of modules that have been introduced into the kernel.

Severity: low

Identifiers: GEN002825-2

References: ECAR-1, ECAR-2, ECAR-3, 126

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/audit/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit/audit.rules"
    	AUDIT_TAG="-k modules"
    elif [ -e /etc/audit.rules ]; then
    	AUDIT_RULES_FILE="/etc/audit.rules"
    	AUDIT_TAG=""
    else
    	exit
    fi

    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S init_module '`" = "0" ]; then
    	if [ "`uname -p`" != "x86_64" ]; then
    		echo "-a exit,always -F arch=b32 -S init_module ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b64 -S init_module ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi
    if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S delete_module '`" = "0" ]; then
    	if [ "`uname -p`" != "x86_64" ]; then
    		echo "-a exit,always -F arch=b32 -S delete_module ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	else
    		echo "-a exit,always -F arch=b64 -S delete_module ${AUDIT_TAG}" >>${AUDIT_RULES_FILE}
    	fi
    fi

    for FILE in /sbin/insmod /sbin/rmmod /sbin/modprobe; do
    	if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then
    		echo "-w ${FILE} -p x -k modules" >>${AUDIT_RULES_FILE}
    	elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [wa]*x"`" = "0" ]; then
    		SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')"
    		if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then
    			sed -i "s/\(-w ${SED_FILE}\)/\1 -p x/" ${AUDIT_RULES_FILE}
    		else
    			sed -i "s/\(-w ${SED_FILE} -p \)/\1x/" ${AUDIT_RULES_FILE}
    		fi
    	fi
    done
    service auditd restart 1>/dev/null

#### Enable auditd Service [ref]rule

The `auditd` service is an essential userspace component of the Linux Auditing System, as it is responsible for writing audit records to disk. The `auditd` service can be enabled with the following command:

    $ sudo chkconfig --level 2345 auditd on

Rationale:

Ensuring the `auditd` service is active ensures audit records generated by the kernel can be written to disk, or that appropriate actions will be taken if other obstacles exist.

Severity: medium

Identifiers: GEN002660

References: ECAR-1, ECAR-2, ECAR-3, 169

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    #
    # Enable auditd for all run levels
    #
    /sbin/chkconfig --level 0123456 auditd on

    #
    # Start auditd if not currently running
    #
    /sbin/service auditd start 1>/dev/null

#### Enable Auditing for Processes Which Start Prior to the Audit Daemon [ref]rule

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

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

Rationale:

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 it is set for every process during boot.

Severity: low

Identifiers: GEN000000-LNX00720

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ $(grep -v '#' /boot/grub/grub.conf | grep kernel | grep -c audit=) = 0 ]; then
    	sed -i '/^[ |\t]*kernel/s/$/ audit=1/' /boot/grub/grub.conf
    else
    	sed -i '/^[ |\t]*kernel/s/audit=./audit=1/' /boot/grub/grub.conf
    fi

### Services [ref]group

The best protection against vulnerable software is running less software. This section describes how to review the software which Red Hat Enterprise Linux 5 installs on a system and disable software which is not needed. It then enumerates the software packages installed on a default Red Hat Enterprise Linux 5 system and provides guidance about which ones can be safely disabled.
Red Hat Enterprise Linux 5 provides a convenient minimal install option that essentially installs the bare necessities for a functional system. When building Red Hat Enterprise Linux 5 systems, it is highly recommended to select the minimal packages and then build up the system from there.

contains 86 rules

### Obsolete Services [ref]group

This section discusses a number of network-visible services which have historically caused problems for system security, and for which disabling or severely limiting the service has been the best available guidance for some time. As a result of this, many of these services are not installed as part of Red Hat Enterprise Linux 6 by default.
Organizations which are running these services should switch to more secure equivalents as soon as possible. If it remains absolutely necessary to run one of these services for legacy reasons, care should be taken to restrict the service as much as possible, for instance by configuring host firewall software such as `iptables` to restrict access to the vulnerable service to only those remote hosts which have a known need to use it.

contains 11 rules

### Xinetd [ref]group

The `xinetd` service acts as a dedicated listener for some network services (mostly, obsolete ones) and can be used to provide access controls and perform some logging. It has been largely obsoleted by other features, and it is not installed by default. The older Inetd service is not even available as part of Red Hat Enterprise Linux 6.

contains 1 rule

#### Disable xinetd Service [ref]rule

The `xinetd` service can be disabled with the following command:

    $ sudo chkconfig xinetd off

Rationale:

The xinetd service provides a dedicated listener service for some programs, which is no longer necessary for commonly-used network services. Disabling it ensures that these uncommon services are not running, and also prevents attacks against xinetd itself.

Severity: medium

Identifiers: GEN003700

References: ECSC-1, 305

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    #
    # Disable xinetd for all run levels
    #
    /sbin/chkconfig --level 0123456 xinetd off

    #
    # Stop xinetd if currently running
    #
    /sbin/service xinetd stop 1>/dev/null

### Telnet [ref]group

The telnet protocol does not provide confidentiality or integrity for information transmitted on the network. This includes authentication information such as passwords. Organizations which use telnet should be actively working to migrate to a more secure protocol.

contains 1 rule

#### Disable telnet Service [ref]rule

The `telnet` service can be disabled with the following command:

    $ sudo chkconfig telnet off

Rationale:

The telnet protocol uses unencrypted network communication, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network. The telnet protocol is also subject to man-in-the-middle attacks.

Severity: high

Identifiers: GEN003850

References: DCPP-1, 197

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    #
    # Disable telnetd for all run levels
    #
    /sbin/chkconfig --level 0123456 telnetd off

    #
    # Stop telnetd if currently running
    #
    /sbin/service telnetd stop 1>/dev/null

### Rlogin, Rsh, and Rexec [ref]group

The Berkeley r-commands are legacy services which allow cleartext remote access and have an insecure trust model.

contains 6 rules

#### Uninstall rsh-server Package [ref]rule

The `rsh-server` package can be uninstalled with the following command:

    # yum erase rsh-server

Rationale:

The `rsh-server` package provides several obsolete and insecure network services. Removing it decreases the risk of those services' accidental (or intentional) activation.

Severity: medium

Identifiers: GEN003845

References: ECSC-1, 305

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    yum -y remove rsh-server --disablerepo=* 1>/dev/null

Remediation Puppet snippet: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    include remove_rsh-server

    class remove_rsh-server {
      package { 'rsh-server':
        ensure => 'purged',
      }
    }

Remediation Anaconda snippet: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    package -remove=rsh-server

#### Disable rexec Service [ref]rule

The `rexec` service, which is available with the `rsh-server` package and runs as a service through xinetd, should be disabled. The `rexec` service can be disabled with the following command:

    $ sudo chkconfig rexec off

Rationale:

The rexec service uses unencrypted network communications, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network.

Severity: high

Identifiers: GEN003840

References: EBRP-1, ECSC-1, 1435

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    #
    # Disable rexec for all run levels
    #
    /sbin/chkconfig --level 0123456 rexec off

    #
    # Stop rexec if currently running
    #
    /sbin/service rexec stop 1>/dev/null

#### Disable rsh Service [ref]rule

The `rsh` service, which is available with the `rsh-server` package and runs as a service through xinetd, should be disabled. The `rsh` service can be disabled with the following command:

    $ sudo chkconfig rsh off

Rationale:

The rsh service uses unencrypted network communications, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network.

Severity: high

Identifiers: GEN003820

References: EBRU-1, 68

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    #
    # Disable rsh for all run levels
    #
    /sbin/chkconfig --level 0123456 rsh off

    #
    # Stop rsh if currently running
    #
    /sbin/service rsh stop 1>/dev/null

#### Disable rlogin Service [ref]rule

The `rlogin` service, which is available with the `rsh-server` package and runs as a service through xinetd, should be disabled. The `rlogin` service can be disabled with the following command:

    $ sudo chkconfig rlogin off

Rationale:

The rlogin service uses unencrypted network communications, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network.

Severity: medium

Identifiers: GEN003830

References: DCPP-1, 68

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    #
    # Disable rlogin for all run levels
    #
    /sbin/chkconfig --level 0123456 rlogin off

    #
    # Stop rlogin if currently running
    #
    /sbin/service rlogin stop 1>/dev/null

#### Remove Rsh Trust Files [ref]rule

The files `/etc/hosts.equiv` and `~/.rhosts` (in each user's home directory) list remote hosts and users that are trusted by the local system when using the rshd daemon. To remove these files, run the following command to delete them from any location:

    # rm /etc/hosts.equiv

    $ rm ~/.rhosts

Rationale:

Trust files are convenient, but when used in conjunction with the R-services, they can allow unauthenticated access to a system.

Severity: high

Identifiers: GEN002040

References: ECCD-1, ECCD-2, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    find -type f -name .rhosts -exec rm -f '{}' \;
    rm /etc/hosts.equiv

#### Remove rhosts_auth Entries [ref]rule

All pam files located within /etc/pam.d/ must not include rhosts_auth. To remove these entries, run the following command:

    # sed -i '/.*rhosts_auth.*/d' /etc/pam.d/*

Rationale:

.rhosts files are used to specify a list of hosts permitted remote access to a particular account without authenticating. The use of such a mechanism defeats strong identification and authentication requirements.

Severity: medium

Identifiers: GEN002100

References: ECCD-1, ECCD-2, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    sed -i '/.*rhosts_auth.*/d' /etc/pam.d/*

### NIS [ref]group

The Network Information Service (NIS), also known as 'Yellow Pages' (YP), and its successor NIS+ have been made obsolete by Kerberos, LDAP, and other modern centralized authentication services. NIS should not be used because it suffers from security problems inherent in its design, such as inadequate protection of important authentication information.

contains 1 rule

#### Disable ypbind Service [ref]rule

The `ypbind` service, which allows the system to act as a client in a NIS or NIS+ domain, should be disabled. The `ypbind` service can be disabled with the following command:

    $ sudo chkconfig ypbind off

Rationale:

Disabling the `ypbind` service ensures the system is not acting as a client in a NIS or NIS+ domain.

Severity: medium

Identifiers: GEN006400

References: ECSC-1, 1435

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    #
    # Disable ypbind for all run levels
    #
    /sbin/chkconfig --level 0123456 ypbind off

    #
    # Stop ypbind if currently running
    #
    /sbin/service ypbind stop 1>/dev/null

### TFTP Server [ref]group

TFTP is a lightweight version of the FTP protocol which has traditionally been used to configure networking equipment. However, TFTP provides little security, and modern versions of networking operating systems frequently support configuration via SSH or other more secure protocols. A TFTP server should be run only if no more secure method of supporting existing equipment can be found.

contains 2 rules

#### Disable tftp Service [ref]rule

The `tftp` service should be disabled. The `tftp` service can be disabled with the following command:

    $ sudo chkconfig tftp off

Rationale:

Disabling the `tftp` service ensures the system is not acting as a TFTP server, which does not provide encryption or authentication.

Severity: high

Identifiers: GEN005140

References: DCSW-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | medium
Reboot: | true
Strategy: | disable

    #
    # Disable tftp for all run levels
    #
    /sbin/chkconfig --level 0123456 tftp off

    #
    # Stop tftp if currently running
    #
    /sbin/service tftp stop 1>/dev/null

#### Ensure tftp Daemon Uses Secure Mode [ref]rule

If running the `tftp` service is necessary, it should be configured to change its root directory at startup. To do so, ensure `/etc/xinetd.d/tftp` includes `-s` as a command line argument, as shown in the following example (which is also the default):

    server_args = -s /var/lib/tftpboot

Rationale:

Using the `-s` option causes the TFTP service to only serve files from the given directory. Serving files from an intentionally-specified directory reduces the risk of sharing files which should remain private.

Severity: high

Identifiers: GEN005080

References: ECSC-1, 366

### Base Services [ref]group

This section addresses the base services that are installed on a Red Hat Enterprise Linux 6 default installation which are not covered in other sections. Some of these services listen on the network and should be treated with particular discretion. Other services are local system utilities that may or may not be extraneous. In general, system services should be disabled if not required.

contains 2 rules

#### Disable KDump Kernel Crash Analyzer (kdump) [ref]rule

The `kdump` service provides a kernel crash dump analyzer. It uses the `kexec` system call to boot a secondary kernel ("capture" kernel) following a system crash, which can load information from the crashed kernel for analysis. The `kdump` service can be disabled with the following command:

    $ sudo chkconfig kdump off

Rationale:

Unless the system is used for kernel development or testing, there is little need to run the kdump service.

Severity: low

Identifiers: GEN003510

References: ECSC-1, 366

#### Disable Automatic Updates [ref]rule

The `yum-updatesd` service can be disabled with the following command:

    $ sudo chkconfig yum-updatesd off

Rationale:

System package management tools can obtain a list of updates and patches from a package repository and make this information available to the SA for review and action. Using a package repository outside of the organization's control presents a risk of malicious packages being introduced.

Severity: low

Identifiers: GEN008820

References: ECSC-1, 1233

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    #
    # Disable yum-updatesd for all run levels
    #
    /sbin/chkconfig --level 0123456 yum-updatesd off

    #
    # Stop yum-updatesd if currently running
    #
    /sbin/service yum-updatesd stop 1>/dev/null

### Cron and At Daemons [ref]group

The cron and at services are used to allow commands to be executed at a later time. The cron service is required by almost all systems to perform necessary maintenance tasks, while at may or may not be required on a given system. Both daemons should be configured defensively.

contains 5 rules

### Restrict cron to Authorized Users if Necessary [ref]group

The `/etc/cron.allow` file contain lists of users who are allowed to use cron to delay execution of processes. If this file exists and if the corresponding file `/etc/cron.deny` does not exist, then only users listed in the relevant allow files can run the crontab commands to submit jobs to be run at scheduled intervals. On many systems, only the system administrator needs the ability to schedule jobs. Note that even if a given user is not listed in `cron.allow`, cron jobs can still be run as that user.
To restrict cron to only authorized users:

- Remove the cron.deny file:

      # rm /etc/cron.deny

- Edit `/etc/cron.allow`, adding one line for each user allowed to use the crontab command to create cron jobs.

contains 2 rules

#### Cron Must Control Access [ref]rule

The cron service must control access to the execution of cron jobs. This is accomplished defining the users allowed/denied in the cron.allow and cron.deny files. To confirm if these files exist, run the following commands:

    # ls -1l /etc/cron.allow
    # ls -1l /etc/cron.deny

The cron facility allows users to execute recurring jobs on a regular and unattended basis. The cron.allow file designates accounts allowed to enter and execute jobs using the cron facility. If neither cron.allow nor cron.deny exists, then any account may use the cron facility. This may open the facility up for abuse by system intruders and malicious users.

Severity: low

Identifiers: GEN002960

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ ! -e [/etc/cron.allow ]; then
    	> /etc/cron.allow
    	chown root:root /etc/cron.allow
    	chmod 0600 /etc/cron.allow
    fi
    if [ ! -e [/etc/cron.deny ]; then
    	SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done)
    	for USER in `echo $SYS_USER`; do
    		if [ $(grep -c "^${USER}$" /etc/cron.deny) = 0 ]; then
    			echo ${USER} | tee -a /etc/cron.deny &>/dev/null
    		fi
    	done
    	chown root:root /etc/cron.deny
    	chmod 0600 /etc/cron.deny
    fi

#### Cron Must Deny System Accounts [ref]rule

The cron service must deny system accounts (except for root) access to the execution of cron jobs. This includes all accounts with a UID less than 500, except for 0. This is accomplished by listing all system users within the cron.deny file and ensuring that they are not listed in the cron.allow file. To confirm these conditions are met, run the following commands:

    # cat /etc/passwd | awk -F: '{ print $1"|"$3 }' | grep -v "^root|" | while read ENTRY; do
    if [ $(echo $ENTRY | cut -d"|" -f2) -lt 500 ];then
    if [ $(grep -c "$(echo $ENTRY | cut -d"|" -f1)" /etc/cron.deny) = 0 ] ||
    [ $(grep -c "$(echo $ENTRY | cut -d"|" -f1)" /etc/cron.allow) != 0 ]; then
    echo $ENTRY | cut -d"|" -f1; fi; fi; done

If any users are listed from the above command, then the listed user(s) does not meet the above requirements. To centralize the management of privileged account crontabs, of the default system accounts, only root may have a crontab.

Severity: low

Identifiers: GEN003060

References: ECPA-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done)
    for USER in `echo $SYS_USER`; do
    	if [ $(grep -c "^${USER}$" /etc/cron.deny) = 0 ]; then
    		echo ${USER} | tee -a /etc/cron.deny &>/dev/null
    	fi
    done

### Restrict at to Authorized Users if Necessary [ref]group

The `/etc/at.allow` file contain lists of users who are allowed to use at to delay execution of processes. If this file exists and if the corresponding file `/etc/at.deny` does not exist, then only users listed in the relevant allow files can run the at commands to submit jobs to be run at scheduled intervals. On many systems, only the system administrator needs the ability to schedule jobs. Note that even if a given user is not listed in `cron.allow`, cron jobs can still be run as that user. The `cron.allow` file controls only administrative access to the crontab command for scheduling and modifying cron jobs.
To restrict at to only authorized users:

- Remove the `at.deny` file:

      # rm /etc/at.deny

- Edit `/etc/at.allow`, adding one line for each user allowed to use the at command to create at jobs.

contains 3 rules

#### At Must Control Access [ref]rule

The at service must control access to the execution of at jobs. This is accomplished defining the users allowed/denied in the at.allow and at.deny files. To confirm if these files exist, run the following commands:

    # ls -1l /etc/at.allow
    # ls -1l /etc/at.deny

The at facility allows users to execute recurring jobs on a regular and unattended basis. The at.allow file designates accounts allowed to enter and execute jobs using the at facility. If neither at.allow nor at.deny exists, then any account may use the at facility. This may open the facility up for abuse by system intruders and malicious users.

Severity: low

Identifiers: GEN003280

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ ! -e [/etc/at.allow ]; then
    	> /etc/at.allow
    	chown root:root /etc/at.allow
    	chmod 0600 /etc/at.allow
    fi
    if [ ! -e [/etc/at.deny ]; then
    	SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done)
    	for USER in `echo $SYS_USER`; do
    		if [ $(grep -c "^${USER}$" /etc/at.deny) = 0 ]; then
    			echo ${USER} | tee -a /etc/at.deny &>/dev/null
    		fi
    	done
    	chown root:root /etc/at.deny
    	chmod 0600 /etc/at.deny
    fi

#### At Must Deny System Accounts [ref]rule

The at service must deny system accounts (except for root) access to the execution of at jobs. This includes all accounts with a UID less than 500, except for 0. This is accomplished by listing all system users within the at.deny file and ensuring that they are not listed in the at.allow file. To confirm these conditions are met, run the following commands:

    # cat /etc/passwd | awk -F: '{ print $1"|"$3 }' | grep -v "^root|" | while read ENTRY; do
    if [ $(echo $ENTRY | cut -d"|" -f2) -lt 500 ];then
    if [ $(grep -c "$(echo $ENTRY | cut -d"|" -f1)" /etc/at.deny) = 0 ] ||
    [ $(grep -c "$(echo $ENTRY | cut -d"|" -f1)" /etc/at.allow) != 0 ]; then
    echo $ENTRY | cut -d"|" -f1; fi; fi; done

If any users are listed from the above command, then the listed user(s) does not meet the above requirements. To centralize the management of privileged account at jobs, of the default system accounts, only root may have the ability to schedule at jobs.

Severity: low

Identifiers: GEN003320

References: ECPA-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done)
    for USER in `echo $SYS_USER`; do
    	if [ $(grep -c "^${USER}$" /etc/at.deny) = 0 ]; then
    		echo ${USER} | tee -a /etc/at.deny &>/dev/null
    	fi
    done

#### At.deny Must Either Not Exist Or Not Be Empty [ref]rule

On some systems, if there is no at.allow file and there is an empty at.deny file, then the system assumes everyone has permission to use the "at" facility. This could create an insecure setting in the case of malicious users or system intruders. To confirm these conditions are met, run the following command:

    # ls -1l /etc/at.deny

If the above command returns with details about /etc/at.deny, then it exists. If it exists, then run the following command:

    # cat /etc/at.deny

If no entries are returned, then configure the at.deny file with the default system accounts, excluding root.

Severity: low

Identifiers: GEN003300

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done)
    for USER in `echo $SYS_USER`; do
    	if [ $(grep -c "^${USER}$" /etc/at.deny) = 0 ]; then
    		echo ${USER} | tee -a /etc/at.deny &>/dev/null
    	fi
    done
    sed -i '/^$/d' /etc/at.deny

### SSH Server [ref]group

The SSH protocol is recommended for remote login and remote file transfer. SSH provides confidentiality and integrity for data exchanged between two systems, as well as server authentication, through the use of public key cryptography. The implementation included with the system is called OpenSSH, and more detailed documentation is available from its website, http://www.openssh.org. Its server program is called `sshd` and provided by the RPM package `openssh-server`.

contains 21 rules

### Configure OpenSSH Server if Necessary [ref]group

If the system needs to act as an SSH server, then certain changes should be made to the OpenSSH daemon configuration file `/etc/ssh/sshd_config`. The following recommendations can be applied to this file. See the `sshd_config(5)` man page for more detailed information.

contains 16 rules

### Strengthen Firewall Configuration if Possible [ref]group

If the SSH server is expected to only receive connections from the local network, then strengthen the default firewall rule for the SSH service to only accept connections from the appropriate network segment(s).
Determine an appropriate network block, `netwk`, and network mask, `mask`, representing the machines on your network which will be allowed to access this SSH server.
Edit the files `etc/sysconfig/iptables` and `/etc/sysconfig/ip6tables` (if IPv6 is in use). In each file, locate the line:

    -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

and replace it with:

    -A INPUT -s netwk/mask -m state --state NEW -p tcp --dport 22 -j ACCEPT

contains 2 rules

#### Assign Designated IP [ref]rule

The SSH daemon must only listen on management network addresses unless authorized for uses other than management. By default, all addresses are allowed. The default setting in `/etc/ssh/sshd_config` must be modified to include the specific IP address that the SSH server should be managed from, for example:

    ListenAddress 10.10.2.1

Rationale:

The SSH daemon should only listen on network addresses designated for management traffic. If the system has multiple network interfaces and SSH listens on addresses not designated for management traffic, the SSH service could be subject to unauthorized access. If SSH is used for purposes other than management, such as providing an SFTP service, the list of approved listening addresses may be documented.

Severity: medium

Identifiers: GEN005504

References: ECSC-1, 69

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    MANAGEMENT_IP=$(/sbin/ifconfig | grep inet | grep -v 127.0.0.1 | cut -d: -f2 | awk '{ print $1}' | head -1)
    if [ $(cat /etc/ssh/sshd_config | grep -ic "^ListenAddress") = "0" ]; then
    	echo "ListenAddress ${MANAGEMENT_IP}" | tee -a /etc/ssh/sshd_config &>/dev/null
    else
    	sed -i "s/^ListenAddress.*/ListenAddress ${MANAGEMENT_IP}/" /etc/ssh/sshd_config
    fi
    service sshd restart 1>/dev/null

#### Enable SSH IP Filtering [ref]rule

IP filtering should be enabled for SSH in either /etc/hosts.allow or /etc/hosts.deny. By default, no IP filtering is configured. IP filtering for SSH can be verified by ensuring that a line similar to the following appears:

    sshd:10.10.:spawn /bin/echo SSHD accessed on $(/bin/date) from %h>>/var/log/host.access

Rationale:

The SSH daemon must be configured for IP filtering to provide a layered defence against connection attempts from unauthorized addresses.

Severity: medium

Identifiers: GEN005540

References: ECSC-1, ECWM-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    MANAGEMENT_IP=$(/sbin/ifconfig | grep inet | grep -v 127.0.0.1 | cut -d: -f2 | awk '{ print $1}' | head -1 | cut -d. -f1-2)
    sed -i '/sshd/d' /etc/hosts.allow
    echo "sshd: ${MANAGEMENT_IP}.: spawn /bin/echo SSHD accessed on \$(/bin/date) from %h>>/var/log/host.access" | tee -a /etc/hosts.allow &>/dev/null

#### Allow Only SSH Protocol 2 [ref]rule

Only SSH protocol version 2 connections should be permitted. The default setting in `/etc/ssh/sshd_config` is correct, and can be verified by ensuring that the following line appears:

    Protocol 2

Rationale:

SSH protocol version 1 suffers from design flaws that result in security vulnerabilities and should not be used.

Severity: high

Identifiers: GEN005500

References: DCPP-1, ECSC-1, 1436

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ $(cat /etc/ssh/sshd_config | grep -c "^Protocol") != "0" ]; then
    	sed -i 's/^Protocol.*/Protocol 2/' /etc/ssh/sshd_config
    else
    	echo "Protocol 2">>/etc/ssh/sshd_config
    fi
    service sshd restart 1>/dev/null

#### Disable SSH Root Login [ref]rule

The root user should never be allowed to login to a system directly over a network. To disable root login via SSH, add or correct the following line in `/etc/ssh/sshd_config`:

    PermitRootLogin no

Rationale:

Permitting direct root login reduces auditable information about who ran privileged commands on the system and also allows direct attack attempts on root's password.

Severity: medium

Identifiers: GEN001120

References: ECPA-1, 770

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    grep -q ^PermitRootLogin /etc/ssh/sshd_config && \
      sed -i "s/PermitRootLogin.*/PermitRootLogin no/g" /etc/ssh/sshd_config
    if ! [ $? -eq 0 ]; then
        echo "PermitRootLogin no" >> /etc/ssh/sshd_config
    fi
    service sshd restart 1>/dev/null

#### Enable SSH Warning Banner [ref]rule

To enable the warning banner and ensure it is consistent across the system, add or correct the following line in `/etc/ssh/sshd_config`:

    Banner /etc/issue

Another section contains information on how to create an appropriate system-wide warning banner. Rationale:

The warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. Alternatively, systems whose ownership should not be obvious should ensure usage of a banner that does not provide easy attribution.

Severity: medium

Identifiers: GEN005550

References: ECWM-1, 48

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep -q ^Banner /etc/ssh/sshd_config && \
      sed -i "s/Banner.*/Banner \/etc\/issue/g" /etc/ssh/sshd_config
    if ! [ $? -eq 0 ]; then
        echo "Banner /etc/issue" >> /etc/ssh/sshd_config
    fi
    service sshd restart 1>/dev/null

#### Use Only Approved Ciphers [ref]rule

Limit the ciphers to those algorithms which are FIPS-approved. The following line in `/etc/ssh/sshd_config` demonstrates use of FIPS-approved ciphers:

    Ciphers aes128-ctr,aes192-ctr,aes256-ctr

The man page `sshd_config(5)` contains a list of supported ciphers. Rationale:

Approved algorithms should impart some level of confidence in their implementation. These are also required for compliance.

Severity: medium

Identifiers: GEN005505

References: DCNR-1, 68

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep -q ^Ciphers /etc/ssh/sshd_config && \
      sed -i "s/Ciphers.*/Ciphers aes128-ctr,aes192-ctr,aes256-ctr/g" /etc/ssh/sshd_config
    if ! [ $? -eq 0 ]; then
        echo "Ciphers aes128-ctr,aes192-ctr,aes256-ctr" >> /etc/ssh/sshd_config
    fi
    service sshd restart 1>/dev/null

#### Do Not Use CBC Mode [ref]rule

The Cipher-Block Chaining (CBC) mode of encryption as implemented in the SSHv2 protocol is vulnerable to chosen plain text attacks. Counter (CTR) mode is preferred over CBC mode. The following line in `/etc/ssh/sshd_config` demonstrates use of FIPS-approved ciphers:

    Ciphers aes128-ctr,aes192-ctr,aes256-ctr

The man page `sshd_config(5)` contains a list of supported ciphers. Rationale:

Approved algorithms should impart some level of confidence in their implementation. These are also required for compliance.

Severity: medium

Identifiers: GEN005506

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep -q ^Ciphers /etc/ssh/sshd_config && \
      sed -i "s/Ciphers.*/Ciphers aes128-ctr,aes192-ctr,aes256-ctr/g" /etc/ssh/sshd_config
    if ! [ $? -eq 0 ]; then
        echo "Ciphers aes128-ctr,aes192-ctr,aes256-ctr" >> /etc/ssh/sshd_config
    fi
    /sbin/service sshd restart 1>/dev/null

#### Use Only Approved Macs [ref]rule

Limit the MACs to those hash algorithms which are FIPS-approved. The following line in `/etc/ssh/sshd_config` demonstrates use of FIPS-approved MACs:

    Macs hmac-sha1

The man page `sshd_config(5)` contains a list of supported macs. Rationale:

DoD information systems are required to use FIPS 140-2 approved cryptographic hash functions.

Severity: medium

Identifiers: GEN005507

References: DCNR-1, 1453

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | disable

    if [ $(cat /etc/ssh/sshd_config | grep -c "^MACs") = "0" ]; then
    	echo "MACs hmac-sha1" | tee -a /etc/ssh/sshd_config &>/dev/null
    else
    	sed -i 's/^MACs.*/MACs hmac-sha1/' /etc/ssh/sshd_config
    fi
    service sshd restart 1>/dev/null

#### Disable GSSAPIAuthentication [ref]rule

GSSAPIAuthentication should not be permitted. The default setting in `/etc/ssh/sshd_config` is correct, and can be verified by ensuring that the following line appears:

    GSSAPIAuthentication no

Rationale:

GSSAPI authentication is used to provide additional authentication mechanisms to applications. Allowing GSSAPI authentication through SSH exposes the system’s GSSAPI to remote hosts, increasing the attack surface of the system. GSSAPI authentication must be disabled unless needed.

Severity: low

Identifiers: GEN005524

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ $(cat /etc/ssh/sshd_config | grep -c "^GSSAPIAuthentication") = "0" ]; then
    	echo "GSSAPIAuthentication no" | tee -a /etc/ssh/sshd_config &>/dev/null
    else
    	sed -i 's/^GSSAPIAuthentication.*/GSSAPIAuthentication no/' /etc/ssh/sshd_config
    fi
    service sshd restart 1>/dev/null

#### Display Login Details [ref]rule

A user should be presented with details on the last attempted access to their account, upon logging in. The default setting in `/etc/ssh/sshd_config` is correct, and can be verified by ensuring that the following line appears:

    PrintLastLog yes

Rationale:

Providing users with feedback on when account accesses last occurred facilitates user recognition and reporting of unauthorized account use.

Severity: low

Identifiers: GEN000452

References: ECSC-1, 52

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ "$(grep -c '^session.*required.*pam_lastlog.so$' /etc/pam.d/sshd)" = "0" ]; then
    	echo -e "session    required\tpam_lastlog.so" | tee -a /etc/pam.d/sshd &>/dev/null
    elif [ "$(grep pam_lastlog /etc/pam.d/sshd | grep -c silent)" != "0" ]; then
    	sed -i '/pam_lastlog/s/silent//' /etc/pam.d/sshd
    fi
    if [ $(cat /etc/ssh/sshd_config | grep -ic "^PrintLastLog") = "0" ]; then
    	echo "PrintLastLog yes" | tee -a /etc/ssh/sshd_config &>/dev/null
    else
    	sed -i 's/^PrintLastLog.*/PrintLastLog yes/' /etc/ssh/sshd_config
    fi
    service sshd restart 1>/dev/null

#### Restrict Users/Groups [ref]rule

Login access to the SSH server should be restricted to a list of allowed users or groups. The default setting in `/etc/ssh/sshd_config` is to allow all users and groups access to login. The user/group restriction can be verified by ensuring that the following line appears:

    AllowedUsers

or

    AllowedGroups

Rationale:

Restricting SSH logins to a limited group of users, such as system administrators, prevents password-guessing and other SSH attacks from reaching system accounts and other accounts not authorized for SSH access.

Severity: medium

Identifiers: GEN005521

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    echo "AllowGroups wheel" | tee -a /etc/ssh/sshd_config &>/dev/null
    service sshd restart 1>/dev/null

#### Disable KerberosAuthentication [ref]rule

KerberosAuthentication should not be permitted. The default setting in `/etc/ssh/sshd_config` is correct, and can be verified by ensuring that the following line appears:

    KerberosAuthentication no

Rationale:

Kerberos authentication for SSH is often implemented using GSSAPI. If Kerberos is enabled through SSH, the SSH daemon provides a means of access to the system's Kerberos implementation. Vulnerabilities in the system's Kerberos implementation may then be subject to exploitation. To reduce the attack surface of the system, the Kerberos authentication mechanism within SSH must be disabled for systems not using this capability.

Severity: low

Identifiers: GEN005526

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ $(cat /etc/ssh/sshd_config | grep -ic "^KerberosAuthentication") = "0" ]; then
    	echo "KerberosAuthentication no" | tee -a /etc/ssh/sshd_config &>/dev/null
    else
    	sed -i 's/^KerberosAuthentication.*/KerberosAuthentication no/' /etc/ssh/sshd_config
    fi
    service sshd restart 1>/dev/null

#### Enable StrictModes [ref]rule

StrictModes must be enabled. The default setting in `/etc/ssh/sshd_config` is not correct, and can be verified by ensuring that the following line appears:

    StrictModes yes

Rationale:

If other users have access to modify user-specific SSH configuration files, they may be able to log into the system as another user.

Severity: medium

Identifiers: GEN005536

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ $(cat /etc/ssh/sshd_config | grep -c "^StrictModes") = "0" ]; then
    	echo "StrictModes yes" | tee -a /etc/ssh/sshd_config &>/dev/null
    else
    	sed -i 's/^StrictModes.*/StrictModes yes/' /etc/ssh/sshd_config
    fi
    service sshd restart 1>/dev/null

#### Enable Privilege Separation [ref]rule

UsePrivilegeSeparation must be enabled. The default setting in `/etc/ssh/sshd_config` is not correct, and can be verified by ensuring that the following line appears:

    UsePrivilegeSeparation yes

Rationale:

SSH daemon privilege separation causes the SSH process to drop root privileges when not needed, which would decrease the impact of software vulnerabilities in the unprivileged section.

Severity: medium

Identifiers: GEN005537

References: ECLP-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ $(cat /etc/ssh/sshd_config | grep -ic "^UsePrivilegeSeparation") = "0" ]; then
    	echo "UsePrivilegeSeparation yes" | tee -a /etc/ssh/sshd_config &>/dev/null
    else
    	sed -i 's/^UsePrivilegeSeparation.*/UsePrivilegeSeparation yes/' /etc/ssh/sshd_config
    fi
    service sshd restart 1>/dev/null

#### Disable RhostsRSAAuthentication [ref]rule

RhostsRSAAuthentication should not be permitted. The default setting in `/etc/ssh/sshd_config` is correct, and can be verified by ensuring that the following line appears:

    RhostsRSAAuthentication no

Rationale:

If SSH permits rhosts RSA authentication, a user may be able to log in based on the keys of the host originating the request and not any user-specific authentication.

Severity: medium

Identifiers: GEN005538

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ $(cat /etc/ssh/sshd_config | grep -ic "^RhostsRSAAuthentication") = "0" ]; then
    	echo "RhostsRSAAuthentication no" | tee -a /etc/ssh/sshd_config &>/dev/null
    else
    	sed -i 's/^RhostsRSAAuthentication.*/RhostsRSAAuthentication no/' /etc/ssh/sshd_config
    fi
    service sshd restart 1>/dev/null

#### Disable Or Delay Compression [ref]rule

Compression should not be permitted prior to authentication. The default setting in `/etc/ssh/sshd_config` is not correct, and can be verified by ensuring that either of the following lines appear:

    Compression no

or

    Compression delayed

Rationale:

If compression is allowed in an SSH connection prior to authentication, vulnerabilities in the compression software could result in compromise of the system from an unauthenticated connection, potentially with root privileges.

Severity: medium

Identifiers: GEN005539

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ $(cat /etc/ssh/sshd_config | grep -ic "^Compression") = "0" ]; then
    	echo "Compression delayed" | tee -a /etc/ssh/sshd_config &>/dev/null
    else
    	sed -i 's/^Compression.*/Compression delayed/' /etc/ssh/sshd_config
    fi
    service sshd restart 1>/dev/null

### Configure OpenSSH Client if Necessary [ref]group

If the system needs to utilize the SSH client, then certain changes should be made to the OpenSSH client configuration file `/etc/ssh/ssh_config`. The following recommendations can be applied to this file. See the `ssh_config(5)` man page for more detailed information.

contains 5 rules

#### Allow Only SSH Protocol 2 [ref]rule

Only SSH protocol version 2 connections should be permitted. The default setting in `/etc/ssh/ssh_config` is correct, and can be verified by ensuring that the following line appears:

    Protocol 2

Rationale:

SSH protocol version 1 suffers from design flaws that result in security vulnerabilities and should not be used.

Severity: medium

Identifiers: GEN005501

References: DCPP-1, 1436

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ $(cat /etc/ssh/ssh_config | grep -c "^Protocol") != "0" ]; then
    	sed -i 's/^Protocol.*/Protocol 2/' /etc/ssh/ssh_config
    else
    	echo "Protocol 2">>/etc/ssh/ssh_config
    fi

#### Use Only Approved Ciphers [ref]rule

Limit the ciphers to those algorithms which are FIPS-approved. The following line in `/etc/ssh/ssh_config` demonstrates use of FIPS-approved ciphers:

    Ciphers aes128-ctr,aes192-ctr,aes256-ctr

The man page `ssh_config(5)` contains a list of supported ciphers. Rationale:

Approved algorithms should impart some level of confidence in their implementation. These are also required for compliance.

Severity: medium

Identifiers: GEN005510

References: DCNR-1, 68

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep -q ^Ciphers /etc/ssh/ssh_config && \
      sed -i "s/Ciphers.*/Ciphers aes128-ctr,aes192-ctr,aes256-ctr/g" /etc/ssh/ssh_config
    if ! [ $? -eq 0 ]; then
        echo "Ciphers aes128-ctr,aes192-ctr,aes256-ctr" >> /etc/ssh/ssh_config
    fi

#### Do Not Use CBC Mode [ref]rule

The Cipher-Block Chaining (CBC) mode of encryption as implemented in the SSHv2 protocol is vulnerable to chosen plain text attacks. Counter (CTR) mode is preferred over CBC mode. The following line in `/etc/ssh/ssh_config` demonstrates use of FIPS-approved ciphers:

    Ciphers aes128-ctr,aes192-ctr,aes256-ctr

The man page `ssh_config(5)` contains a list of supported ciphers. Rationale:

Approved algorithms should impart some level of confidence in their implementation. These are also required for compliance.

Severity: medium

Identifiers: GEN005511

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    grep -q ^Ciphers /etc/ssh/ssh_config && \
      sed -i "s/Ciphers.*/Ciphers aes128-ctr,aes192-ctr,aes256-ctr/g" /etc/ssh/ssh_config
    if ! [ $? -eq 0 ]; then
        echo "Ciphers aes128-ctr,aes192-ctr,aes256-ctr" >> /etc/ssh/ssh_config
    fi

#### Use Only Approved Macs [ref]rule

Limit the MACs to those hash algorithms which are FIPS-approved. The following line in `/etc/ssh/ssh_config` demonstrates use of FIPS-approved MACs:

    Macs hmac-sha1

The man page `ssh_config(5)` contains a list of supported macs. Rationale:

DoD information systems are required to use FIPS 140-2 approved cryptographic hash functions.

Severity: medium

Identifiers: GEN005512

References: DCNR-1, 1453

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ $(cat /etc/ssh/ssh_config | grep -c "^MACs") = "0" ]; then
    	echo "MACs hmac-sha1" | tee -a /etc/ssh/ssh_config &>/dev/null
    else
    	sed -i 's/^MACs.*/MACs hmac-sha1/' /etc/ssh/ssh_config
    fi

#### Disable GSSAPIAuthentication [ref]rule

GSSAPIAuthentication should not be permitted. The default setting in `/etc/ssh/ssh_config` is correct, and can be verified by ensuring that the following line appears:

    GSSAPIAuthentication no

Rationale:

GSSAPI authentication is used to provide additional authentication mechanisms to applications. Allowing GSSAPI authentication through SSH exposes the system’s GSSAPI to remote hosts, increasing the attack surface of the system. GSSAPI authentication must be disabled unless needed.

Severity: low

Identifiers: GEN005525

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ $(cat /etc/ssh/ssh_config | grep -c "^GSSAPIAuthentication") = "0" ]; then
    	echo "GSSAPIAuthentication no" | tee -a /etc/ssh/ssh_config &>/dev/null
    else
    	sed -i 's/^GSSAPIAuthentication.*/GSSAPIAuthentication no/' /etc/ssh/ssh_config
    fi

### X Window System [ref]group

The X Window System implementation included with the system is called X.org.

contains 1 rule

### Disable X Windows [ref]group

Unless there is a mission-critical reason for the system to run a graphical user interface, ensure X is not set to start automatically at boot and remove the X Windows software packages. There is usually no reason to run X Windows on a dedicated server machine, as it increases the system's attack surface and consumes system resources. Administrators of server systems should instead login via SSH or on the text console.

contains 1 rule

#### Disable X Windows Startup By Setting Runlevel [ref]rule

Setting the system's runlevel to 3 will prevent automatic startup of the X server. To do so, ensure the following line in `/etc/inittab` features a `3` as shown:

    id:3:initdefault:

Rationale:

Unnecessary services should be disabled to decrease the attack surface of the system.

Severity: low

Identifiers: GEN005260

References: ECSC-1, 1436

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    sed -i 's/.*:initdefault:.*/id:3:initdefault:/' /etc/inittab

### DHCP [ref]group

The Dynamic Host Configuration Protocol (DHCP) allows systems to request and obtain an IP address and other configuration parameters from a server.
This guide recommends configuring networking on clients by manually editing the appropriate files under `/etc/sysconfig`. Use of DHCP can make client systems vulnerable to compromise by rogue DHCP servers, and should be avoided unless necessary. If using DHCP is necessary, however, there are best practices that should be followed to minimize security risk.

contains 2 rules

### Disable DHCP Client [ref]group

DHCP is the default network configuration method provided by the system installer, and common on many networks. Nevertheless, manual management of IP addresses for systems implies a greater degree of management and accountability for network activity.

contains 1 rule

#### Disable DHCP Client [ref]rule

For each interface on the system (e.g. eth0), edit `/etc/sysconfig/network-scripts/ifcfg-interface` and make the following changes:

- Correct the BOOTPROTO line to read:

      BOOTPROTO=static

- Add or correct the following lines, substituting the appropriate values based on your site's addressing scheme:

      NETMASK=255.255.255.0
      IPADDR=192.168.1.2
      GATEWAY=192.168.1.1

Rationale:

DHCP relies on trusting the local network. If the local network is not trusted, then it should not be used. However, the automatic configuration provided by DHCP is commonly used and the alternative, manual configuration, presents an unacceptable burden in many circumstances.

Severity: low

Identifiers: GEN007840

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    sed -i 's/^BOOTPROTO=.*/BOOTPROTO="static"/' /etc/sysconfig/network-scripts/ifcfg-*

### Configure DHCP Client if Necessary [ref]group

If DHCP must be used, then certain configuration changes can minimize the amount of information it receives and applies from the network, and thus the amount of incorrect information a rogue DHCP server could successfully distribute. For more information on configuring dhclient, see the `dhclient(8)` and `dhclient.conf(5)` man pages.

contains 1 rule

#### Do Not Use Dynamic DNS [ref]rule

To prevent the DHCP client from transmitting system information, edit `/etc/dhclient.conf`, and add or correct the following global option:

    do-forward-updates false;

Rationale:

Dynamic DNS updates transmit unencrypted information about a system including its name and address and should not be used unless needed.

Severity: low

Identifiers: GEN007850

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/dhclient.conf ]; then
    	if [ $(grep -c "do-forward-updates false;" /etc/dhclient.conf) = 0 ]; then
    		echo "do-forward-updates false;" | tee -a /etc/dhclient.conf &>/dev/null
    	fi
    else
    	echo "do-forward-updates false;" | tee /etc/dhclient.conf &>/dev/null
    fi

### Network Time Protocol [ref]group

The Network Time Protocol is used to manage the system clock over a network. Computer clocks are not very accurate, so time will drift unpredictably on unmanaged systems. Central time protocols can be used both to ensure that time is consistent among a network of machines, and that their time is consistent with the outside world.
If every system on a network reliably reports the same time, then it is much easier to correlate log messages in case of an attack. In addition, a number of cryptographic protocols (such as Kerberos) use timestamps to prevent certain types of attacks. If your network does not have synchronized time, these protocols may be unreliable or even unusable.
Depending on the specifics of the network, global time accuracy may be just as important as local synchronization, or not very important at all. If your network is connected to the Internet, using a public timeserver (or one provided by your enterprise) provides globally accurate timestamps which may be essential in investigating or responding to an attack which originated outside of your network.
A typical network setup involves a small number of internal systems operating as NTP servers, and the remainder obtaining time information from those internal servers.
More information on how to configure the NTP server software, including configuration of cryptographic authentication for time data, is available at http://www.ntp.org.

contains 3 rules

#### Enable the NTP Daemon [ref]rule

The `ntpd` service can be enabled with the following command:

    $ sudo chkconfig --level 2345 ntpd on

Rationale:

Enabling the `ntpd` service ensures that the `ntpd` service will be running and that the system will synchronize its time to any servers specified. This is important whether the system is configured to be a client (and synchronize only its own clock) or it is also acting as an NTP server to other systems. Synchronizing time is essential for authentication services such as Kerberos, but it is also important for maintaining accurate logs and auditing possible security breaches.
The NTP daemon offers all of the functionality of `ntpdate`, which is now deprecated. Additional information on this is available at http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate

Severity: medium

Identifiers: GEN000241

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    #
    # Enable ntpd for all run levels
    #
    /sbin/chkconfig --level 0123456 ntpd on

    #
    # Start ntpd if not currently running
    #
    /sbin/service ntpd start 1>/dev/null

#### Specify a Remote NTP Server [ref]rule

To specify a remote NTP server for time synchronization, edit the file `/etc/ntp.conf`. Add or correct the following lines, substituting the IP or hostname of a remote NTP server for ntpserver:

    server ntpserver

This instructs the NTP software to contact that remote server to obtain time data. Rationale:

Synchronizing with an NTP server makes it possible to collate system logs from multiple sources or correlate computer events with real time events.

Severity: medium

Identifiers: GEN000240

References: ECSC-1, 1492

#### Specify Additional Remote NTP Servers [ref]rule

Additional NTP servers can be specified for time synchronization in the file `/etc/ntp.conf`. To do so, add additional lines of the following form, substituting the IP address or hostname of a remote NTP server for ntpserver:

    server ntpserver

Rationale:

Specifying additional NTP servers increases the availability of accurate time data, in the event that one of the specified servers becomes unavailable. This is typical for a system acting as an NTP server for other systems.

Severity: low

Identifiers: GEN000242

References: ECSC-1, 160

### Mail Server Software [ref]group

Mail servers are used to send and receive email over the network. Mail is a very common service, and Mail Transfer Agents (MTAs) are obvious targets of network attack. Ensure that machines are not running MTAs unnecessarily, and configure needed MTAs as defensively as possible.
Very few systems at any site should be configured to directly receive email over the network. Users should instead use mail client programs to retrieve email from a central server that supports protocols such as IMAP or POP3. However, it is normal for most systems to be independently capable of sending email, for instance so that cron jobs can report output to an administrator. Most MTAs, including Postfix, support a submission-only mode in which mail can be sent from the local system to a central site MTA (or directly delivered to a local account), but the system still cannot receive mail directly over a network.
The `alternatives` program in Red Hat Enterprise Linux permits selection of other mail server software (such as Sendmail), but Postfix is the default and is preferred. Postfix was coded with security in mind and can also be more effectively contained by SELinux as its modular design has resulted in separate processes performing specific actions. More information is available on its website, http://www.postfix.org.

contains 12 rules

### Mail Server Logging [ref]group

It is important to ensure adequate logging of mail server connections so as to support detecting any unauthorized activity.

contains 2 rules

#### Enable Mail Server Logging [ref]rule

To ensure logging is enabled, perform the following command:

    grep "mail\." /etc/syslog.conf

The output received should indicate either `mail.crit` or `mail.*`. Rationale:

If informational and more severe SMTP service messages are not logged, malicious activity on the system may go unnoticed.

Severity: medium

Identifiers: GEN004460

References: ECAR-1, ECAR-2, ECAR-3, ECSC-1, 126

#### Configure Mail Server Logging Level [ref]rule

If sendmail is installed, perform the following checks: Edit the file `/etc/mail/sendmail.cf` and confirm that the following line appears:

    O LogLevel=9

If postfix is installed, this check is not applicable. Rationale:

If Sendmail is not configured to log at level 9, system logs may not contain the information necessary for tracking unauthorized use of the sendmail service.

Severity: low

Identifiers: GEN004440

References: ECAR-1, ECAR-2, ECAR-3, 366

### Mail Server Features [ref]group

Mail servers are used to send and receive email over the network. Mail is a very common service, and Mail Transfer Agents (MTAs) are obvious targets of network attack. Ensure that machines are not running MTAs unnecessarily, and configure needed MTAs as defensively as possible.
Very few systems at any site should be configured to directly receive email over the network. Users should instead use mail client programs to retrieve email from a central server that supports protocols such as IMAP or POP3. However, it is normal for most systems to be independently capable of sending email, for instance so that cron jobs can report output to an administrator. Most MTAs, including Postfix, support a submission-only mode in which mail can be sent from the local system to a central site MTA (or directly delivered to a local account), but the system still cannot receive mail directly over a network.
The `alternatives` program in Red Hat Enterprise Linux permits selection of other mail server software (such as Sendmail), but Postfix is the default and is preferred. Postfix was coded with security in mind and can also be more effectively contained by SELinux as its modular design has resulted in separate processes performing specific actions. More information is available on its website, http://www.postfix.org.

contains 9 rules

#### Disable Debug Command [ref]rule

From a terminal, type the following commands:

    # telnet localhost 25

    # debug

If debug is disabled, one of the following errors should be returned:

    500 error code of "command unrecognised"

    550 error code of "access denied"

Rationale:

Debug mode is a feature present in older versions of sendmail which, if not disabled, may allow an attacker to gain access to a system through the sendmail service.

Severity: high

Identifiers: GEN004620

References: ECSC-1, 366

#### Disable Decode Command [ref]rule

Edit the file(s) `/etc/aliases` and `/usr/lib/aliases`, if either exist, to ensure that the `decode:` and `uudecode:` entries do NOT include the file path to uudecode, such as the following:

    decode: |/usr/bin/uudecode

    uudecode: |/usr/bin/uuencode -d

Rationale:

A common configuration for older Mail Transfer Agents (MTAs) is to include an alias for the decode user. All mail sent to this user is sent to the uudecode program, which automatically converts and stores files. By sending mail to the decode or the uudecode aliases present on some systems, a remote attacker may be able to create or overwrite files on the remote host. This could possibly be used to gain remote access.

Severity: high

Identifiers: GEN004640

References: ECSC-1, 1230

#### Disable EXPN Command [ref]rule

If sendmail is installed, perform the following checks: Edit the file `/etc/mail/sendmail.cf` to ensure that the following `PrivacyOptions` line appears and includes `noexpn`:

    O PrivacyOptions=authwarnings,novrfy,noexpn,restrictqrun

If postfix is installed, this check is not applicable. Rationale:

The SMTP EXPN function allows an attacker to determine if an account exists on a system, providing significant assistance to a brute force attack on user accounts. EXPN may also provide additional information concerning users on the system, such as the full names of account owners.

Severity: low

Identifiers: GEN004660

References: ECSC-1, 366

#### Disable Help Command [ref]rule

If sendmail is installed, perform the following checks: Edit the file `/etc/mail/helpfile` to ensure that the file is empty. If postfix is installed, this check is not applicable.

Rationale:

The HELP command should be disabled to mask version information. The version of the SMTP service software could be used by attackers to target vulnerabilities present in specific software versions.

Severity: medium

Identifiers: GEN004540

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    >/etc/mail/helpfile

#### Disable VRFY Command [ref]rule

If sendmail is installed, perform the following checks: Edit the file `/etc/mail/sendmail.cf` to ensure that the following `PrivacyOptions` line appears and includes `novrfy`:

    O PrivacyOptions=authwarnings,novrfy,noexpn,restrictqrun

If postfix is installed, this check is not applicable. Rationale:

The VRFY command allows an attacker to determine if an account exists on a system, providing significant assistance to a brute force attack on user accounts. VRFY may provide additional information about users on the system, such as the full names of account owners.

Severity: low

Identifiers: GEN004680

References: ECSC-1, 366

#### Disable WIZ Command [ref]rule

From a terminal, type the following commands:

    # telnet localhost 25

    # wiz

If wiz is disabled, the following error should be returned:

    500 error code of "command unrecognised"

Rationale:

Very old installations of the Sendmail mailing system contained a feature whereby a remote user connecting to the SMTP port can enter the WIZ command and be given an interactive shell with root privileges.

Severity: low

Identifiers: GEN004700

References: ECSC-1, 366

#### Don't Display Version [ref]rule

If sendmail is installed, perform the following checks: Edit the file `/etc/mail/sendmail.cf` to ensure that the following `SmtpGreetingMessage` line does not appear as:

    O SmtpGreetingMessage=$j Sendmail $v/$Z; $b

If the above line appears, it should be changed to:

    O SmtpGreetingMessage= Mail Server Ready ; $b

If postfix is installed, perform the following checks: Edit the file `/etc/postfix/main.cf` to ensure that the following `smtpd_banner` line does not appear with `$mail_version`. If so, remove the `$mail_version` entry or comment out the entire line to use the default value. Rationale:

The version of the SMTP service can be used by attackers to plan an attack based on vulnerabilities present in the specific version.

Severity: low

Identifiers: GEN004560

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    SENDMAIL_CONFIG=$(rpm -ql sendmail | grep sendmail.cf)
    SENDMAIL_MAINCONF=$(rpm -ql sendmail | grep sendmail.mc)
    if [ "$(rpm -q sendmail-cf &>/dev/null; echo $?)" = "0" ]; then
    	if [ -e "${SENDMAIL_MAINCONF}" ]; then
    		if [ "$(grep -c "^define(\`confSMTP_LOGIN_MSG" "${SENDMAIL_MAINCONF}")" = "0" ]; then
    			sed -i "0,/^define/s/\(^define\)/define(\`confSMTP_LOGIN_MSG', \` Mail Server Ready ; $b')dnl\n\1/" "${SENDMAIL_MAINCONF}"
    		elif [ "$(grep -c "^define(\`confSMTP_LOGIN_MSG', \` Mail Server Ready ; \$b')dnl" "${SENDMAIL_MAINCONF}")" = "0" ]; then
    			sed -i "s/^define(\`confSMTP_LOGIN_MSG.*/define(\`confSMTP_LOGIN_MSG', \`Mail Server Ready ; \$b')dnl/" "${SENDMAIL_MAINCONF}"
    		fi
    		m4 "${SENDMAIL_MAINCONF}" > "${SENDMAIL_CONFIG}"
    	fi
    else
    	sed -i 's/O SmtpGreetingMessage=.*/O SmtpGreetingMessage= Mail Server Ready ; $b/' "${SENDMAIL_CONFIG}"
    fi
    service sendmail restart 1>/dev/null

#### Restrict Mail Forwarding [ref]rule

If sendmail is installed, perform the following checks: Edit the file `/etc/mail/sendmail.cf` to ensure that the following `ForwardPath` line appears without any file path specified:

    0 ForwardPath

Perform a search on the system for any `.forward` files by issuing the following command:

    # find / -name .forward

The above command should not return any results. If so, delete each file returned. Rationale:

The .forward file allows users to automatically forward mail to another system. Use of .forward files could allow the unauthorized forwarding of mail and could potentially create mail loops which could degrade system performance.

Severity: medium

Identifiers: GEN004580

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    SENDMAIL_CONFIG=$(rpm -ql sendmail | grep sendmail.cf)
    SENDMAIL_MAINCONF=$(rpm -ql sendmail | grep sendmail.mc)
    if [ "$(rpm -q sendmail-cf &>/dev/null; echo $?)" = "0" ]; then
    	if [ -e "${SENDMAIL_MAINCONF}" ]; then
    		if [ "$(grep -c 'confFORWARD_PATH' "${SENDMAIL_MAINCONF}")" = "0" ]; then
    			sed -i "0,/^define/s/\(^define\)/define(\`confFORWARD_PATH',\`')dnl\n\1/" "${SENDMAIL_MAINCONF}"
    		elif [ "$(grep -c "define(\`confFORWARD_PATH',\`')dnl" "${SENDMAIL_MAINCONF}")" = "0" ]; then
    			sed -i "s/define(\`confFORWARD.*/define(\`confFORWARD_PATH',\`')dnl/" "${SENDMAIL_MAINCONF}"
    		fi
    		m4 "${SENDMAIL_MAINCONF}" > "${SENDMAIL_CONFIG}"
    	fi
    else
    	sed -i 's/O ForwardPath.*/O ForwardPath/' "${SENDMAIL_CONFIG}"
    fi
    service sendmail restart 1>/dev/null
    for FILE in $(find /etc -name .forward -type f 2>/dev/null); do
    	rm -f ${FILE}
    done

#### Restrict Mail Relaying [ref]rule

If sendmail is installed, perform the following checks: Edit the file `/etc/mail/sendmail.cf` to ensure that only the following `DaemonPortOptions` line appears:

    O DaemonPortOptions=Port=smtp,Addr=127.0.0.1, Name=MTA

Edit the file `/etc/mail/sendmail.mc` to ensure that the following `promiscuous_relay` line does NOT appear:

    promiscuous_relay

If postfix is installed, perform the following checks: Edit the file `/etc/postfix/main.cf` to ensure that only the following `inet_interfaces` line appears:

    inet_interfaces = localhost

Edit the file `/etc/postfix/main.cf` to ensure that only the following `smtpd_client_restrictions` line appears:

    smtpd_client_restrictions = reject

Rationale:

If unrestricted mail relaying is permitted, unauthorized senders could use this host as a mail relay for the purpose of sending SPAM or other unauthorized activity.

Severity: medium

Identifiers: GEN004710

References: ECSC-1, 1305

#### Mail Server Software Updates [ref]rule

If sendmail is installed, perform the following command:

    # rpm -q sendmail

The version indicated should be equal to or greater than the following:

    8.13.8-8

If postfix is installed, perform the following command:

    # rpm -q postfix

The version indicated should be equal to or greater than the following:

    2.3.3-6

Rationale:

The SMTP service version on the system must be current to avoid exposing vulnerabilities present in unpatched versions.

Severity: high

Identifiers: GEN004600

References: VIVM-1, 1230

### LDAP [ref]group

LDAP is a popular directory service, that is, a standardized way of looking up information from a central database. Red Hat Enterprise Linux 5 includes software that enables a system to act as both an LDAP client and server.

contains 5 rules

### Configure OpenLDAP Clients [ref]group

This section provides information on which security settings are important to configure in OpenLDAP clients by manually editing the appropriate configuration files. Red Hat Enterprise Linux 5 provides an automated configuration tool called authconfig and a graphical wrapper for authconfig called `system-config-authentication`. However, these tools do not provide as much control over configuration as manual editing of configuration files. The authconfig tools do not allow you to specify locations of SSL certificate files, which is useful when trying to use SSL cleanly across several protocols. Installation and configuration of OpenLDAP on Red Hat Enterprise Linux 5 is available at https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/ch-ldap.html.

Warning: Before configuring any system to be an LDAP client, ensure that a working LDAP server is present on the network.

contains 5 rules

#### Configure LDAP Client to Use TLS For All Transactions [ref]rule

Configure LDAP to enforce TLS use. First, edit the file `/etc/ldap.conf`, and add or correct the following lines:

    ssl start_tls

Then review the LDAP server and ensure TLS has been configured. Rationale:

The ssl directive specifies whether to use ssl or not. If not specified it will default to no. It should be set to start_tls rather than doing LDAP over SSL.

Severity: medium

Identifiers: GEN007980

References: DCNR-1, 1453

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ "$(cat /etc/ldap.conf | grep -c '^ssl ')" = "0" ]; then
    	echo "ssl start_tls" | tee -a /etc/ldap.conf &>/dev/null
    else
    	sed -i 's/^ssl .*/ssl start_tls/' /etc/ldap.conf
    fi
    if [ "$(cat /etc/ldap.conf | grep -c '^tls_ciphers ')" = "0" ]; then
    	echo "tls_ciphers TLSv1" | tee -a /etc/ldap.conf &>/dev/null
    else
    	sed -i 's/^tls_ciphers .*/tls_ciphers TLSv1/' /etc/ldap.conf
    fi

#### Configure Certificate Directives for LDAP Use of TLS [ref]rule

Ensure a copy of a trusted CA certificate has been placed in the file `/etc/pki/tls/CA/cacert.pem`. Configure LDAP to enforce TLS use and to trust certificates signed by that CA. First, edit the file `/etc/ldap.conf`, and add or correct either of the following lines:

    tls_cert /etc/pki/tls/CA

or

    tls_cert /etc/pki/tls/CA/cacert.pem

Rationale:

LDAP can be used to provide user authentication and account information, which are vital to system security. Communication between an LDAP server and a host using LDAP requires authentication.

Severity: medium

Identifiers: GEN008000

References: DCNR-1, 185

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    sed -i 's/ ldap//g' /etc/nsswitch.conf

#### Configure Certificate Trust Validation [ref]rule

Ensure LDAP server connections have a valid trust path. Configure LDAP to enforce validation of LDAP server certificates for trust. First, edit the file `/etc/ldap.conf`, and add or correct the following line:

    tls_checkpeer yes

Rationale:

The NSS LDAP service provides user mappings which are a vital component of system security. Communication between an LDAP server and a host using LDAP for NSS require authentication.

Severity: medium

Identifiers: GEN008020

References: DCNR-1, 185

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ $(cat /etc/ldap.conf | grep -c "^tls_checkpeer") = "0" ]; then
    	echo "tls_checkpeer yes" | tee -a /etc/ldap.conf &>/dev/null
    else
    	sed -i 's/^tls_checkpeer.*/tls_checkpeer yes/' /etc/ldap.conf
    fi

#### Configure Certificate Revocation Validation [ref]rule

Ensure LDAP server connections have a valid certificate that is not revoked. Configure LDAP to enforce validation of LDAP server certificates for revocation. First, edit the file `/etc/ldap.conf`, and add or correct the following line:

    tls_crlcheck all

Rationale:

LDAP can be used to provide user authentication and account information, which are vital to system security. Communication between an LDAP server and a host using LDAP requires authentication.

Severity: medium

Identifiers: GEN008040

References: DCNR-1, 185

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ $(cat /etc/ldap.conf | grep -c "^tls_crlcheck") = "0" ]; then
    	echo "tls_crlcheck all" | tee -a /etc/ldap.conf &>/dev/null
    else
    	sed -i 's/^tls_crlcheck.*/tls_crlcheck all/' /etc/ldap.conf
    fi

#### LDAP Passwords Are Stored In Clear Text [ref]rule

Ensure the LDAP configuration does not include any passwords stored in clear text. Edit the file `/etc/ldap.conf`, and remove any lines that include the `bindpw` directive.

Rationale:

The authentication of automated LDAP connections between systems must not use passwords since more secure methods are available, such as PKI and Kerberos. Additionally, the storage of unencrypted passwords on the system is not permitted.

Severity: medium

Identifiers: GEN008050

References: IAIA-1, IAIA-2, 196

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    sed -i '/bindpw/d' /etc/ldap.conf

### NFS and RPC [ref]group

The Network File System is a popular distributed filesystem for the Unix environment, and is very widely deployed. This section discusses the circumstances under which it is possible to disable NFS and its dependencies, and then details steps which should be taken to secure NFS's configuration. This section is relevant to machines operating as NFS clients, as well as to those operating as NFS servers.

contains 7 rules

### Disable All NFS Services if Possible [ref]group

If there is not a reason for the system to operate as either an NFS client or an NFS server, follow all instructions in this section to disable subsystems required by NFS.

Warning: The steps in this section will prevent a machine from operating as either an NFS client or an NFS server. Only perform these steps on machines which do not need NFS at all.

contains 2 rules

### Remove Services Used Only by NFS [ref]group

If NFS is not needed, remove the NFS client daemons portmap and rpcbind.
All of these daemons run with elevated privileges, and many listen for network connections. If they are not needed, they should be disabled to improve system security posture.

contains 1 rule

#### Remove portmap and rpcbind Packages [ref]rule

The `portmap` and `rpcbind` packages can be uninstalled with the following command:

    # yum erase portmap rpcbind

Severity: low

Identifiers: GEN003815

References: ECSC-1, 305

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    yum -y remove portmap rpcbind --disablerepo=* 1>/dev/null

### Disable Services Used Only by NFS [ref]group

If NFS is not needed, disable the NFS client daemons nfslock, rpcgssd, and rpcidmapd.
All of these daemons run with elevated privileges, and many listen for network connections. If they are not needed, they should be disabled to improve system security posture.

contains 1 rule

#### Disable portmap and rpcbind Services [ref]rule

The rpcbind service increase the attack surface of the system and should only be used when needed. The rpcbind service are used by a variety of services using Remote Procedure Calls (RPCs). The `rpcbind` service can be disabled with the following command:

    $ sudo chkconfig rpcbind off

Severity: low

Identifiers: GEN003810

References: ECSC-1, 1436

### Configure All Machines which Use NFS [ref]group

The steps in this section are appropriate for all machines which run NFS, whether they operate as clients or as servers.

contains 5 rules

### Configure NFS Clients [ref]group

The steps in this section are appropriate for machines which operate as NFS clients.

contains 1 rule

#### Mount Remote Filesystems with nosuid [ref]rule

Add the `nosuid` option to the fourth column of `/etc/fstab` for the line which controls mounting of any NFS mounts.

Rationale:

NFS mounts should not present suid binaries to users. Only vendor-supplied suid executables should be installed to their default location on the local filesystem.

Severity: medium

Identifiers: GEN005900

References: ECPA-1, 225

### Configure NFS Servers [ref]group

The steps in this section are appropriate for machines which operate as NFS servers.

contains 4 rules

#### Specify UID and GID for Anonymous NFS Connections [ref]rule

To specify the UID and GID for remote root users, edit the `/etc/exports` file and add the following for each export:

    anonuid=-1
    anongid=-1

Rationale:

Specifying the anonymous UID and GID as -1 ensures that the remote root user is mapped to a local account which has no permissions on the system.

Severity: low

Identifiers: GEN005820

References: ECSC-1, IAIA-1, IAIA-2, 62

#### All Exports Must Define Allowed Targets [ref]rule

When configuring NFS exports, ensure that each export line in `/etc/exports` contains a list of hosts which are allowed to access that export. If no hosts are specified on an export line, then that export is available to any remote host which requests it. All lines of the exports file should specify the hosts (or subnets, if needed) which are allowed to access the exported directory, so that unknown or remote hosts will be denied.
Authorized hosts can be specified in several different formats:

- Name or alias that is recognized by the resolver
- Fully qualified domain name
- IP address
- IP subnets in the format `address/netmask` or `address/CIDR`

Rationale:

The NFS access option limits user access to the specified level. This assists in protecting exported file systems. If access is not restricted, unauthorized hosts may be able to access the system's NFS exports.

Severity: low

Identifiers: GEN005840

References: ECSC-1, 366

#### Use Root-Squashing on All Exports [ref]rule

If a filesystem is exported using root squashing, requests from root on the client are considered to be unprivileged (mapped to a user such as nobody). This provides some mild protection against remote abuse of an NFS server. Root squashing is enabled by default, and should not be disabled.
Ensure that no line in `/etc/exports` contains the option `no_root_squash`.

Rationale:

If the NFS server allows root access to local file systems from remote hosts, this access could be used to compromise the system.

Severity: low

Identifiers: GEN005880

References: EBRP-1, 225

#### Ensure Insecure File Locking is Not Allowed [ref]rule

By default the NFS server requires secure file-lock requests, which require credentials from the client in order to lock a file. Most NFS clients send credentials with file lock requests, however, there are a few clients that do not send credentials when requesting a file-lock, allowing the client to only be able to lock world-readable files. To get around this, the `insecure_locks` option can be used so these clients can access the desired export. This poses a security risk by potentially allowing the client access to data for which it does not have authorization. Remove any instances of the `insecure_locks` option from the file `/etc/exports`.

Rationale:

Allowing insecure file locking could allow for sensitive data to be viewed or edited by an unauthorized user.

Severity: high

Identifiers: GEN000000-LNX00560

References: IAIA-1, IAIA-2, 225, 764

### FTP Server [ref]group

FTP is a common method for allowing remote access to files. Like telnet, the FTP protocol is unencrypted, which means that passwords and other data transmitted during the session can be captured and that the session is vulnerable to hijacking. Therefore, running the FTP server software is not recommended.
However, there are some FTP server configurations which may be appropriate for some environments, particularly those which allow only read-only anonymous access as a means of downloading data available to the public.

contains 7 rules

#### Disable Unencrypted FTP Services [ref]rule

The `vsftpd` service can be disabled with the following command:

    $ sudo chkconfig vsftpd off

Rationale:

Running unencrypted FTP server software provides a network-based avenue of attack, and should be disabled if not needed. Furthermore, the FTP protocol is unencrypted and creates a risk of compromising sensitive information.

Severity: low

Identifiers: GEN004800

References: ECSC-1, 366

#### Enable Logging of All FTP Transactions [ref]rule

Add or correct the following configuration options within the `vsftpd` configuration file, located at `/etc/vsftpd/vsftpd.conf`:

    xferlog_enable=YES
    xferlog_std_format=NO
    log_ftp_protocol=YES

Warning: If verbose logging to `vsftpd.log` is done, sparse logging of downloads to `/var/log/xferlog` will not also occur. However, the information about what files were downloaded is included in the information logged to `vsftpd.log`
Rationale:

To trace malicious activity facilitated by the FTP service, it must be configured to ensure that all commands sent to the FTP server are logged using the verbose vsftpd log format. The default vsftpd log file is `/var/log/vsftpd.log`.

Severity: low

Identifiers: GEN004980

References: ECAR-1, ECAR-2, ECAR-3, 130

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ -e /etc/xinetd.d/gssftp ]; then
    	if [ "$(grep server_args /etc/xinetd.d/gssftp | grep -c " -l")" = "0" ]; then
    		sed -i "/server_args/s/$/ -l/" /etc/xinetd.d/gssftp
    	fi
    fi
    if [ -e /etc/vsftpd/vsftpd.conf ]; then
    	if [ "$(grep -ic "^xferlog_enable=yes" /etc/vsftpd/vsftpd.conf)" = "0" ]; then
    		sed -i "s/xferlog_enable.*/xferlog_enable=yes/" /etc/xinetd.d/gssftp
    	fi
    fi

#### FTP Umask Must Be 077. [ref]rule

All FTP users must have a default umask of 077.

Rationale:

The umask controls the default access mode assigned to newly created files. An umask of 077 limits new files to mode 700 or less permissive. Although umask is stored as a 4-digit number, the first digit representing special access modes is typically ignored or required to be zero (0).

Severity: low

Identifiers: GEN005040

References: ECCD-1, ECCD-2, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ "$(rpm -q krb5-workstation &>/dev/null; echo $?)" = "0" ]; then
    	if [ "$(grep server_args /etc/xinetd.d/gssftp | grep -v "#" | grep -c "\-u 077")" = "0" ]; then
    		sed -i '/server_args/s/$/ -u 077/' /etc/xinetd.d/gssftp
    	fi
    fi
    if [ "$(rpm -q vsftpd &>/dev/null; echo $?)" = "0" ]; then
    	if [ "$(grep -c local_umask /etc/vsftpd/vsftpd.conf)" = "0" ]; then
    		echo "local_umask=077" >> /etc/vsftpd/vsftpd.conf
    	else
    		sed -i '/local_umask/s/=.*/=077/' /etc/vsftpd/vsftpd.conf
    	fi
    	if [ "$(grep -c anon_umask /etc/vsftpd/vsftpd.conf)" = "0" ]; then
    		echo "anon_umask=077" >> /etc/vsftpd/vsftpd.conf
    	else
    		sed -i '/anon_umask/s/=.*/=077/' /etc/vsftpd/vsftpd.conf
    	fi
    fi

#### Ftpusers File Contains Users [ref]rule

The ftpusers file must contain account names not allowed to use FTP.

Rationale:

The ftpusers file contains a list of accounts not allowed to use FTP to transfer files. If the file does not contain the names of all accounts not authorized to use FTP, then unauthorized use of FTP may take place.

Severity: low

Identifiers: GEN004900

References: ECCD-1, ECCD-2, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done)
    if [ "$(rpm -q krb5-workstation &>/dev/null; echo $?)" = "0" ]; then
    	if [ ! -e /etc/ftpusers ]; then
    		>/etc/ftpusers
    		chmod 0640 /etc/ftpusers
    		chown root:root /etc/ftpusers
    	fi
    	for USER in `echo $SYS_USER`; do
    		if [ $(grep -c "^${USER}$" /etc/ftpusers) = 0 ]; then
    			echo ${USER} | tee -a /etc/ftpusers &>/dev/null
    		fi
    	done
    fi
    if [ "$(rpm -q vsftpd &>/dev/null; echo $?)" = "0" ]; then
    	if [ ! -e /etc/vsftpd/ftpusers ]; then
    		>/etc/vsftpd/ftpusers
    		chmod 0640 /etc/vsftpd/ftpusers
    		chown root:root /etc/vsftpd/ftpusers
    	fi
    	for USER in `echo $SYS_USER`; do
    		if [ $(grep -c "^${USER}$" /etc/vsftpd/ftpusers) = 0 ]; then
    			echo ${USER} | tee -a /etc/vsftpd/ftpusers &>/dev/null
    		fi
    	done
    fi

#### Ftpusers File Exists [ref]rule

The ftpusers file must exist.

Rationale:

The ftpusers file contains a list of accounts not allowed to use FTP to transfer files. If this file does not exist, then unauthorized accounts can utilize FTP.

Severity: low

Identifiers: GEN004880

References: ECCD-1, ECCD-2, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done)
    if [ "$(rpm -q krb5-workstation &>/dev/null; echo $?)" = "0" ]; then
    	if [ ! -e /etc/ftpusers ]; then
    		>/etc/ftpusers
    		chmod 0640 /etc/ftpusers
    		chown root:root /etc/ftpusers
    	fi
    	for USER in `echo $SYS_USER`; do
    		if [ $(grep -c "^${USER}$" /etc/ftpusers) = 0 ]; then
    			echo ${USER} | tee -a /etc/ftpusers &>/dev/null
    		fi
    	done
    fi
    if [ "$(rpm -q vsftpd &>/dev/null; echo $?)" = "0" ]; then
    	if [ ! -e /etc/vsftpd/ftpusers ]; then
    		>/etc/vsftpd/ftpusers
    		chmod 0640 /etc/vsftpd/ftpusers
    		chown root:root /etc/vsftpd/ftpusers
    	fi
    	for USER in `echo $SYS_USER`; do
    		if [ $(grep -c "^${USER}$" /etc/vsftpd/ftpusers) = 0 ]; then
    			echo ${USER} | tee -a /etc/vsftpd/ftpusers &>/dev/null
    		fi
    	done
    fi

#### FTP User Has Shell [ref]rule

Anonymous FTP accounts must not have a functional shell.

Rationale:

If an anonymous FTP account has been configured to use a functional shell, attackers could gain access to the shell if the account is compromised.

Severity: low

Identifiers: GEN005000

References: ECCD-1, ECCD-2, 225

#### TFTP User Has Shell [ref]rule

The TFTP daemon must be configured to vendor specifications, including a dedicated TFTP user account, a non-login shell such as /bin/false, and a home directory owned by the TFTP user.

Rationale:

If TFTP has a valid shell, it increases the likelihood someone could log on to the TFTP account and compromise the system.

Severity: low

Identifiers: GEN005120

References: ECSC-1, 225

### Samba(SMB) Microsoft Windows File Sharing Server [ref]group

When properly configured, the Samba service allows Linux machines to provide file and print sharing to Microsoft Windows machines. There are two software packages that provide Samba support. The first, `samba-client`, provides a series of command line tools that enable a client machine to access Samba shares. The second, simply labeled `samba`, provides the Samba service. It is this second package that allows a Linux machine to act as an Active Directory server, a domain controller, or as a domain member. Only the `samba-client` package is installed by default.

contains 6 rules

### Remove Samba if Possible [ref]group

The Samba server must not be installed unless it provides an operational need.

contains 1 rule

#### Remove samba and samba3x Packages [ref]rule

The `samba` and `samba3x` packages can be uninstalled with the following command:

    # yum erase samba samba3x

Severity: low

Identifiers: GEN006060

References: DCPD-1, ECSC-1, 1436

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    yum -y remove samba-common --disablerepo=* 1>/dev/null

### Configure Samba if Necessary [ref]group

All settings for the Samba daemon can be found in `/etc/samba/smb.conf`. Settings are divided between a `[global]` configuration section and a series of user created share definition sections meant to describe file or print shares on the system. By default, Samba will operate in user mode and allow client machines to access local home directories and printers. It is recommended that these settings be changed or that additional limitations be set in place.

contains 5 rules

#### Samba Web Administration Tool Must Be Restricted [ref]rule

The Samba Web Administration Tool (SWAT) must be restricted to the local host or require SSL.

Rationale:

SWAT is a tool used to configure Samba. It modifies Samba configuration, which can impact system security, and must be protected from unauthorized access. SWAT authentication may involve the root password, which must be protected by encryption when traversing the network. Restricting access to the local host allows for the use of SSH TCP forwarding, if configured, or administration by a web browser on the local system.

Severity: low

Identifiers: GEN006080

References: EBRP-1, ECCT-1, ECCT-2, 1436

#### Configure hosts Option [ref]rule

Samba increases the attack surface of the system and must be restricted to communicate only with systems requiring access.

Rationale:

Specifying the anonymous UID and GID as -1 ensures that the remote root user is mapped to a local account which has no permissions on the system.

Severity: low

Identifiers: GEN006220

References: ECSC-1, 225

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    sed -i 's/\(^\[global\]$\)/\1\n\n\thosts allow = 127./' /etc/samba/smb.conf

#### Configure security Option [ref]rule

Samba share authentication does not provide for individual user identification and must not be used.

Rationale:

Specifying the anonymous UID and GID as -1 ensures that the remote root user is mapped to a local account which has no permissions on the system.

Severity: low

Identifiers: GEN006225

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    sed -i '/^[#|;]/!s/\([ |\t]*security =\).*/\1 user/' /etc/samba/smb.conf

#### Configure encrypt passwords Option [ref]rule

Rationale:

Samba must be configured to use encrypted passwords.

Severity: low

Identifiers: GEN006230

References: IAIA-1, IAIA-2, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    if [ "$(grep -c '^[ |\t]*encrypt passwords' /etc/samba/smb.conf)" = "0" ]; then
    	sed -i 's/\(^\[global\]$\)/\1\n\n\tencrypt passwords = yes/' /etc/samba/smb.conf
    else
    	sed -i '/^[#|;]/!s/\(encrypt passwords =\).*/\1 yes/g' /etc/samba/smb.conf
    fi

#### Configure guest ok Option [ref]rule

Rationale:

Guest access to shares permits anonymous access and is not permitted.

Severity: low

Identifiers: GEN006235

References: ECSC-1, 366

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    sed -i '/^[#|;]/!s/\(guest ok =\).*/\1 no/g' /etc/samba/smb.conf

### SNMP Server [ref]group

The Simple Network Management Protocol allows administrators to monitor the state of network devices, including computers. Older versions of SNMP were well-known for weak security, such as plaintext transmission of the community string (used for authentication) and usage of easily-guessable choices for the community string.

contains 4 rules

### Configure SNMP Server [ref]group

If it is necessary to run the snmpd agent on the system, some best practices should be followed to minimize the security risk from the installation. The multiple security models implemented by SNMP cannot be fully covered here so only the following general configuration advice can be offered:

- use only SNMP version 3 security models and enable the use of authentication and encryption
- write access to the MIB (Management Information Base) should be allowed only if necessary
- all access to the MIB should be restricted following a principle of least privilege
- network access should be limited to the maximum extent possible including restricting to expected network addresses both in the configuration files and in the system firewall rules
- ensure SNMP agents send traps only to, and accept SNMP queries only from, authorized management stations
- ensure that permissions on the `snmpd.conf` configuration file (by default, in `/etc/snmp`) are 640 or more restrictive
- ensure that any MIB files' permissions are also 640 or more restrictive

contains 4 rules

#### Configure SNMP Service to Use Only SNMPv3 or Newer [ref]rule

Edit `/etc/snmp/snmpd.conf`, removing any references to `v1`, `v2c`, or `com2sec`. Upon doing that, restart the SNMP service:

    # service snmpd restart

Rationale:

Earlier versions of SNMP are considered insecure, as they potentially allow unauthorized access to detailed system management information.

Severity: medium

Identifiers: GEN005305

References: DCPP-1, 1435

Remediation Shell script: (show)

Complexity: | low
Disruption: | low
Reboot: | false
Strategy: | configure

    find / -xdev -name snmpd.conf 2>/dev/null | xargs sed -i '/.*\(v1\|v2c\|community\|com2sec\).*/s/^/#/'

#### Ensure Default Password Is Not Used [ref]rule

Edit `/etc/snmp/snmpd.conf`, remove default community strings `public`, `private`, `snmp-trap`, `password`. Upon doing that, restart the SNMP service:

    # service snmpd restart

Rationale:

Presence of the default SNMP password enables querying of different system aspects and could result in unauthorized knowledge of the system.

Severity: high

Identifiers: GEN005300

References: IAAC-1, 178

#### Ensure Approved Hash Is Used [ref]rule

Edit `/etc/snmp/snmpd.conf`, ensure every line beginning with `createUser` includes `SHA`, similar to the following:

    # createUser myuser SHA -l 0x0001020304050607080900010203040506070809 AES -l 0x00010203040506070809000102030405

Upon doing that, restart the SNMP service:

    # service snmpd restart

Rationale:

The SNMP service must use SHA-1 or a FIPS 140-2 approved successor for authentication and integrity.

Severity: medium

Identifiers: GEN005306

References: DCNR-1, 1453

#### Ensure Approved Encryption Is Used [ref]rule

Edit `/etc/snmp/snmpd.conf`, ensure every line beginning with `createUser` includes `AES`, similar to the following:

    # createUser myuser SHA -l 0x0001020304050607080900010203040506070809 AES -l 0x00010203040506070809000102030405

Upon doing that, restart the SNMP service:

    # service snmpd restart

Rationale:

The SNMP service must use AES or a FIPS 140-2 approved successor algorithm for protecting the privacy of communications.

Severity: medium

Identifiers: GEN005307

References: DCNR-1, 68

Red Hat and Red Hat Enterprise Linux are either registered trademarks or trademarks of Red Hat, Inc. in the United States and other countries. All other names are registered trademarks or trademarks of their respective companies.