Red Hat Enterprise Linux 6 Security Technical Implementation Guide

Checks: C-19327r376553_chk

Run the following command to determine if "/tmp" is on its own partition or logical volume: $ mount | grep "on /tmp " If "/tmp" has its own partition or volume group, a line will be returned. If no line is returned, this is a finding.

Fix: F-19325r376554_fix

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.

Generate Mitigation Statement:

Checks: C-19328r376556_chk

Run the following command to determine if "/var" is on its own partition or logical volume: $ mount | grep "on /var " If "/var" has its own partition or volume group, a line will be returned. If no line is returned, this is a finding.

Fix: F-19326r376557_fix

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.

Generate Mitigation Statement:

Checks: C-19329r376559_chk

Run the following command to determine if "/var/log" is on its own partition or logical volume: $ mount | grep "on /var/log " If "/var/log" has its own partition or volume group, a line will be returned. If no line is returned, this is a finding.

Fix: F-19327r376560_fix

System logs are stored in the "/var/log" directory. Ensure that it has its own partition or logical volume at installation time, or migrate it using LVM.

Generate Mitigation Statement:

Checks: C-19330r376562_chk

Run the following command to determine if "/var/log/audit" is on its own partition or logical volume: $ mount | grep "on /var/log/audit " If "/var/log/audit" has its own partition or volume group, a line will be returned. If no line is returned, this is a finding.

Fix: F-19328r376563_fix

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.

Generate Mitigation Statement:

Checks: C-19332r376568_chk

Run the following command to determine if "/home" is on its own partition or logical volume: $ mount | grep "on /home " If "/home" has its own partition or volume group, a line will be returned. If no line is returned, this is a finding.

Fix: F-19330r376569_fix

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.

Generate Mitigation Statement:

Checks: C-19334r376574_chk

If the system uses RHN or an RHN Satellite, this is not applicable. To check that the "rhnsd" service is disabled in system boot configuration, run the following command: # chkconfig "rhnsd" --list Output should indicate the "rhnsd" service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig "rhnsd" --list "rhnsd" 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify "rhnsd" is disabled through current runtime configuration: # service rhnsd status If the service is disabled the command will return the following output: rhnsd is stopped If the service is running, this is a finding.

Fix: F-19332r376575_fix

The Red Hat Network service automatically queries Red Hat Network servers to determine whether there are any actions that should be executed, such as package updates. This only occurs if the system was registered to an RHN server or satellite and managed as such. The "rhnsd" service can be disabled with the following commands: # chkconfig rhnsd off # service rhnsd stop

Generate Mitigation Statement:

Checks: C-19337r376583_chk

To determine whether "yum" has been configured to disable "gpgcheck" for any repos, inspect all files in "/etc/yum.repos.d" and ensure the following does not appear in any sections: gpgcheck=0 A value of "0" indicates that "gpgcheck" has been disabled for that repo. If GPG checking is disabled, this is a finding. If the "yum" system package management tool is not used to update the system, verify with the SA that installed packages are cryptographically signed.

Fix: F-19335r376584_fix

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

Generate Mitigation Statement:

Checks: C-19344r376604_chk

Check the file "/etc/selinux/config" and ensure the following line appears: SELINUXTYPE=targeted If it does not, this is a finding.

Fix: F-19342r376605_fix

The SELinux "targeted" policy is appropriate for general-purpose desktops and servers, as well as systems in many other roles. To configure the system to use this policy, add or correct the following line in "/etc/selinux/config": SELINUXTYPE=targeted Other policies, such as "mls", provide additional security labeling and greater confinement but are not compatible with many general-purpose use cases.

Generate Mitigation Statement:

Checks: C-19345r376607_chk

To check for unlabeled device files, run the following command: # ls -RZ /dev | grep unlabeled_t It should produce no output in a well-configured system. If there is output, this is a finding.

Fix: F-19343r376608_fix

Device files, which are used for communication with important system resources, should be labeled with proper SELinux types. If any device files carry the SELinux type "unlabeled_t", investigate the cause and correct the file's context.

Generate Mitigation Statement:

Checks: C-19347r376613_chk

To check for serial port entries which permit root login, run the following command: # grep '^ttyS[0-9]' /etc/securetty If any output is returned, then root login over serial ports is permitted. If root login over serial ports is permitted, this is a finding.

Fix: F-19345r376614_fix

To restrict root logins on serial ports, ensure lines of this form do not appear in "/etc/securetty": ttyS0 ttyS1 Note: Serial port entries are not limited to those listed above. Any lines starting with "ttyS" followed by numerals should be removed

Generate Mitigation Statement:

Checks: C-19371r376685_chk

To check the password warning age, run the command: $ grep PASS_WARN_AGE /etc/login.defs The DoD requirement is 7. If it is not set to the required value, this is a finding.

Fix: F-19369r376686_fix

To specify how many days prior to password expiration that a warning will be issued to users, edit the file "/etc/login.defs" and add or correct the following line, replacing [DAYS] appropriately: PASS_WARN_AGE [DAYS] The DoD requirement is 7.

Generate Mitigation Statement:

Checks: C-19373r462373_chk

To check how many digits are required in a password, run the following command: $ grep pam_cracklib /etc/pam.d/system-auth /etc/pam.d/password-auth Note: The "dcredit" parameter (as a negative number) will indicate how many digits are required. The DoD requires at least one digit in a password. This would appear as "dcredit=-1". If “dcredit” is not found or not set to the required value, this is a finding.

Fix: F-19371r462374_fix

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. Edit /etc/pam.d/system-auth and /etc/pam.d/password-auth adding "dcredit=-1" after pam_cracklib.so to require use of a digit in passwords.

Generate Mitigation Statement:

Checks: C-19374r462376_chk

To check how many uppercase characters are required in a password, run the following command: $ grep pam_cracklib /etc/pam.d/system-auth /etc/pam.d/password-auth Note: The "ucredit" parameter (as a negative number) will indicate how many uppercase characters are required. The DoD requires at least one uppercase character in a password. This would appear as "ucredit=-1". If “ucredit” is not found or not set to the required value, this is a finding.

Fix: F-19372r462377_fix

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. Edit /etc/pam.d/system-auth and /etc/pam.d/password-auth adding "ucredit=-1" after pam_cracklib.so to require use of an uppercase character in passwords.

Generate Mitigation Statement:

Checks: C-19375r462379_chk

To check how many special characters are required in a password, run the following command: $ grep pam_cracklib /etc/pam.d/system-auth /etc/pam.d/password-auth Note: The "ocredit" parameter (as a negative number) will indicate how many special characters are required. The DoD requires at least one special character in a password. This would appear as "ocredit=-1". If “ocredit” is not found or not set to the required value, this is a finding.

Fix: F-19373r462380_fix

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. Edit /etc/pam.d/system-auth and /etc/pam.d/password-auth adding "ocredit=-1" after pam_cracklib.so to require use of a special character in passwords.

Generate Mitigation Statement:

Checks: C-19376r462382_chk

To check how many lower-case characters are required in a password, run the following command: $ grep pam_cracklib /etc/pam.d/system-auth /etc/pam.d/password-auth Note: The "lcredit" parameter (as a negative number) will indicate how many lower-case characters are required. The DoD requires at least one lower-case character in a password. This would appear as "lcredit=-1". If “lcredit” is not found or not set to the required value, this is a finding.

Fix: F-19374r462383_fix

The pam_cracklib module's "lcredit=" parameter controls requirements for usage of lower-case letters in a password. When set to a negative number, any password will be required to contain that many lower-case characters. Edit /etc/pam.d/system-auth and /etc/pam.d/password-auth adding "lcredit=-1" after pam_cracklib.so to require use of a lower-case character in passwords.

Generate Mitigation Statement:

Checks: C-19377r462385_chk

To check how many characters must differ during a password change, run the following command: $ grep pam_cracklib /etc/pam.d/system-auth /etc/pam.d/password-auth Note: The "difok" parameter will indicate how many characters must differ. The DoD requires eight characters differ during a password change. This would appear as "difok=8". If “difok” is not found or is set to a value less than “8”, this is a finding.

Fix: F-19375r462386_fix

The pam_cracklib module's "difok" parameter controls requirements for usage of different characters during a password change. Edit /etc/pam.d/system-auth and /etc/pam.d/password-auth adding "difok=[NUM]" after pam_cracklib.so to require differing characters when changing passwords, substituting [NUM] appropriately. The DoD requirement is 8.

Generate Mitigation Statement:

Checks: C-19388r462507_chk

Verify the operating system terminates all network connections associated with a communications session at the end of the session or based on inactivity. Check the value of the system inactivity timeout with the following command: # grep -i tmout /etc/profile.d/* etc/profile.d/tmout.sh:TMOUT=900 /etc/profile.d/tmout.sh:readonly TMOUT /etc/profile.d/tmout.sh:export TMOUT If "TMOUT" is not set to "900" or less in a script located in the /etc/profile.d/ directory to enforce session termination after inactivity, this is a finding.

Fix: F-19386r462508_fix

Configure the operating system to terminate all network connections associated with a communications session at the end of the session or after a period of inactivity. Create a script to enforce the inactivity timeout (for example /etc/profile.d/tmout.sh) such as: #!/bin/bash TMOUT=900 readonly TMOUT export TMOUT

Generate Mitigation Statement:

Checks: C-19398r376766_chk

The status of the "net.ipv4.conf.all.log_martians" kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.all.log_martians net.ipv4.conf.all.log_martians = 1 $ grep net.ipv4.conf.all.log_martians /etc/sysctl.conf /etc/sysctl.d/* net.ipv4.conf.all.log_martians = 1 If "net.ipv4.conf.all.log_martians" is not configured in the /etc/sysctl.conf file or in the /etc/sysctl.d/ directory, is commented out or does not have a value of "1", this is a finding.

Fix: F-19396r376767_fix

To set the runtime status of the "net.ipv4.conf.all.log_martians" kernel parameter, run the following command: # sysctl -w net.ipv4.conf.all.log_martians=1 Set the system to the required kernel parameter by adding the following line to "/etc/sysctl.conf" or a config file in the /etc/sysctl.d/ directory (or modify the line to have the required value): net.ipv4.conf.all.log_martians = 1 Issue the following command to make the changes take effect: # sysctl --system

Generate Mitigation Statement:

Checks: C-19401r376775_chk

The status of the "net.ipv4.conf.default.accept_redirects" kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.default.accept_redirects net.ipv4.conf.default.accept_redirects = 0 $ grep net.ipv4.conf.default.accept_redirects /etc/sysctl.conf /etc/sysctl.d/* net.ipv4.conf.default.accept_redirects = 0 If "net.ipv4.conf.default.accept_redirects" is not configured in the /etc/sysctl.conf file or in the /etc/sysctl.d/ directory, is commented out or does not have a value of "0", this is a finding.

Fix: F-19399r376776_fix

To set the runtime status of the "net.ipv4.conf.default.accept_redirects" kernel parameter, run the following command: # sysctl -w net.ipv4.conf.default.accept_redirects=0 Set the system to the required kernel parameter by adding the following line to "/etc/sysctl.conf" or a config file in the /etc/sysctl.d/ directory (or modify the line to have the required value): net.ipv4.conf.default.accept_redirects = 0 Issue the following command to make the changes take effect: # sysctl --system

Generate Mitigation Statement:

Checks: C-19402r376778_chk

The status of the "net.ipv4.icmp_echo_ignore_broadcasts" kernel parameter can be queried by running the following command: $ sysctl net.ipv4.icmp_echo_ignore_broadcasts net.ipv4.icmp_echo_ignore_broadcasts = 1 $ grep net.ipv4.icmp_echo_ignore_broadcasts /etc/sysctl.conf /etc/sysctl.d/* net.ipv4.icmp_echo_ignore_broadcasts = 1 If "net.ipv4.icmp_echo_ignore_broadcasts" is not configured in the /etc/sysctl.conf file or in the /etc/sysctl.d/ directory, is commented out or does not have a value of "1", this is a finding.

Fix: F-19400r376779_fix

To set the runtime status of the "net.ipv4.icmp_echo_ignore_broadcasts" kernel parameter, run the following command: # sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1 Set the system to the required kernel parameter by adding the following line to "/etc/sysctl.conf" or a config file in the /etc/sysctl.d/ directory (or modify the line to have the required value): net.ipv4.icmp_echo_ignore_broadcasts = 1 Issue the following command to make the changes take effect: # sysctl --system

Generate Mitigation Statement:

Checks: C-19403r376781_chk

The status of the "net.ipv4.icmp_ignore_bogus_error_responses" kernel parameter can be queried by running the following command: $ sysctl net.ipv4.icmp_ignore_bogus_error_responses net.ipv4.icmp_ignore_bogus_error_responses = 1 $ grep net.ipv4.icmp_ignore_bogus_error_responses /etc/sysctl.conf /etc/sysctl.d/* net.ipv4.icmp_ignore_bogus_error_responses = 1 If "net.ipv4.icmp_ignore_bogus_error_responses" is not configured in the /etc/sysctl.conf file or in the /etc/sysctl.d/ directory, is commented out or does not have a value of "1", this is a finding.

Fix: F-19401r376782_fix

To set the runtime status of the "net.ipv4.icmp_ignore_bogus_error_responses" kernel parameter, run the following command: # sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1 Set the system to the required kernel parameter by adding the following line to "/etc/sysctl.conf" or a config file in the /etc/sysctl.d/ directory (or modify the line to have the required value): net.ipv4.icmp_ignore_bogus_error_responses = 1 Issue the following command to make the changes take effect: # sysctl --system

Generate Mitigation Statement:

Checks: C-19417r376823_chk

If the system is configured to prevent the loading of the "rds" kernel module, it will contain lines inside any file in "/etc/modprobe.d" or the deprecated "/etc/modprobe.conf". These lines instruct the module loading system to run another program (such as "/bin/true") upon a module "install" event. Run the following command to search for such lines in all files in "/etc/modprobe.d" and the deprecated "/etc/modprobe.conf": $ grep -r rds /etc/modprobe.conf /etc/modprobe.d If no line is returned, this is a finding.

Fix: F-19415r376824_fix

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

Generate Mitigation Statement:

Checks: C-19424r376844_chk

Run the following commands to determine the current status of the "logrotate" service: # grep logrotate /var/log/cron* If the logrotate service is not run on a daily basis by cron, this is a finding.

Fix: F-19422r376845_fix

The "logrotate" service should be installed or reinstalled if it is not installed and operating properly, by running the following command: # yum reinstall logrotate

Generate Mitigation Statement:

Checks: C-19432r376868_chk

To determine if the system is configured to audit calls to the "adjtimex" system call, run the following command: $ sudo grep -w "adjtimex" /etc/audit/audit.rules -a always,exit -F arch=b32 -S adjtimex -k audit_time_rules -a always,exit -F arch=b64 -S adjtimex -k audit_time_rules If the system is 64-bit and does not return a rule for both "b32" and "b64" architectures, this is a finding. If the system is not configured to audit the "adjtimex" syscall, this is a finding.

Fix: F-19430r376869_fix

Add the following to "/etc/audit/audit.rules": # audit_time_rules -a always,exit -F arch=b32 -S adjtimex -k audit_time_rules If the system is 64-bit, then also add the following: # audit_time_rules -a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k audit_time_rules

Generate Mitigation Statement:

Checks: C-19433r376871_chk

To determine if the system is configured to audit calls to the "settimeofday" system call, run the following command: $ sudo grep -w "settimeofday" /etc/audit/audit.rules -a always,exit -F arch=b32 -S settimeofday -k audit_time_rules -a always,exit -F arch=b64 -S settimeofday -k audit_time_rules If the system is 64-bit and does not return a rule for both "b32" and "b64" architectures, this is a finding. If the system is not configured to the "settimeofday" syscall, this is a finding.

Fix: F-19431r376872_fix

Add the following to "/etc/audit/audit.rules": # audit_time_rules -a always,exit -F arch=b32 -S settimeofday -k audit_time_rules If the system is 64-bit, then also add the following: # audit_time_rules -a always,exit -F arch=b64 -S settimeofday -k audit_time_rules

Generate Mitigation Statement:

Checks: C-19434r376874_chk

If the system is 64-bit only, this is not applicable. To determine if the system is configured to audit calls to the "stime" system call, run the following command: $ sudo grep -w "stime" /etc/audit/audit.rules -a always,exit -F arch=b32 -S stime -k audit_time_rules If the system is not configured to audit the "stime" syscall, this is a finding.

Fix: F-19432r376875_fix

Add the following to "/etc/audit/audit.rules": # audit_time_rules -a always,exit -F arch=b32 -S stime -k audit_time_rules

Generate Mitigation Statement:

Checks: C-19435r376877_chk

To determine if the system is configured to audit calls to the "clock_settime" system call, run the following command: $ sudo grep -w "clock_settime" /etc/audit/audit.rules -a always,exit -F arch=b32 -S clock_settime -k audit_time_rules -a always,exit -F arch=b64 -S clock_settime -k audit_time_rules If the system is 64-bit and does not return a rule for both "b32" and "b64" architectures, this is a finding. If the system is not configured to audit the "clock_settime" syscall, this is a finding.

Fix: F-19433r376878_fix

Add the following to "/etc/audit/audit.rules": # audit_time_rules -a always,exit -F arch=b32 -S clock_settime -k audit_time_rules If the system is 64-bit, then also add the following: # audit_time_rules -a always,exit -F arch=b64 -S clock_settime -k audit_time_rules

Generate Mitigation Statement:

Checks: C-19436r376880_chk

To determine if the system is configured to audit attempts to alter time via the /etc/localtime file, run the following command: $ sudo grep -w "/etc/localtime" /etc/audit/audit.rules If the system is configured to audit this activity, it will return a line. If the system is not configured to audit time changes, this is a finding.

Fix: F-19434r376881_fix

Add the following to "/etc/audit/audit.rules": -w /etc/localtime -p wa -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 and should always be used.

Generate Mitigation Statement:

Checks: C-19437r376883_chk

To determine if the system is configured to audit account changes, run the following command: $ sudo egrep -w '(/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow|/etc/security/opasswd)' /etc/audit/audit.rules If the system is configured to watch for account changes, lines should be returned for each file specified (and with "-p wa" for each). If the system is not configured to audit account changes, this is a finding.

Fix: F-19435r376884_fix

Add the following to "/etc/audit/audit.rules", in order to capture events that modify account changes: # audit_account_changes -w /etc/group -p wa -k audit_account_changes -w /etc/passwd -p wa -k audit_account_changes -w /etc/gshadow -p wa -k audit_account_changes -w /etc/shadow -p wa -k audit_account_changes -w /etc/security/opasswd -p wa -k audit_account_changes

Generate Mitigation Statement:

Checks: C-19438r376886_chk

To determine if the system is configured to audit account changes, run the following command: $sudo egrep -w '(/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow|/etc/security/opasswd)' /etc/audit/audit.rules If the system is configured to watch for account changes, lines should be returned for each file specified (and with "-p wa" for each). If the system is not configured to audit account changes, this is a finding.

Fix: F-19436r376887_fix

Add the following to "/etc/audit/audit.rules", in order to capture events that modify account changes: # audit_account_changes -w /etc/group -p wa -k audit_account_changes -w /etc/passwd -p wa -k audit_account_changes -w /etc/gshadow -p wa -k audit_account_changes -w /etc/shadow -p wa -k audit_account_changes -w /etc/security/opasswd -p wa -k audit_account_changes

Generate Mitigation Statement:

Checks: C-19439r376889_chk

To determine if the system is configured to audit account changes, run the following command: $sudo egrep -w '(/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow|/etc/security/opasswd)' /etc/audit/audit.rules If the system is configured to watch for account changes, lines should be returned for each file specified (and with "-p wa" for each). If the system is not configured to audit account changes, this is a finding.

Fix: F-19437r376890_fix

Add the following to "/etc/audit/audit.rules", in order to capture events that modify account changes: # audit_account_changes -w /etc/group -p wa -k audit_account_changes -w /etc/passwd -p wa -k audit_account_changes -w /etc/gshadow -p wa -k audit_account_changes -w /etc/shadow -p wa -k audit_account_changes -w /etc/security/opasswd -p wa -k audit_account_changes

Generate Mitigation Statement:

Checks: C-19440r376892_chk

To determine if the system is configured to audit account changes, run the following command: $sudo egrep -w '(/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow|/etc/security/opasswd)' /etc/audit/audit.rules If the system is configured to watch for account changes, lines should be returned for each file specified (and with "-p wa" for each). If the system is not configured to audit account changes, this is a finding.

Fix: F-19438r376893_fix

Add the following to "/etc/audit/audit.rules", in order to capture events that modify account changes: # audit_account_changes -w /etc/group -p wa -k audit_account_changes -w /etc/passwd -p wa -k audit_account_changes -w /etc/gshadow -p wa -k audit_account_changes -w /etc/shadow -p wa -k audit_account_changes -w /etc/security/opasswd -p wa -k audit_account_changes

Generate Mitigation Statement:

Checks: C-19441r376895_chk

If you are running x86_64 architecture, determine the values for sethostname: $ uname -m; ausyscall i386 sethostname; ausyscall x86_64 sethostname If the values returned are not identical verify that the system is configured to monitor network configuration changes for the i386 and x86_64 architectures: $ sudo egrep -w '(sethostname|setdomainname|/etc/issue|/etc/issue.net|/etc/hosts|/etc/sysconfig/network)' /etc/audit/audit.rules -a always,exit -F arch=b32 -S sethostname -S setdomainname -k audit_network_modifications -a always,exit -F arch=b64 -S sethostname -S setdomainname -k audit_network_modifications -w /etc/issue -p wa -k audit_network_modifications -w /etc/issue.net -p wa -k audit_network_modifications -w /etc/hosts -p wa -k audit_network_modifications -w /etc/sysconfig/network -p wa -k audit_network_modifications If the system is 64-bit and does not return a rule for both "b32" and "b64" architectures, this is a finding. If the system is not configured to audit changes of the network configuration, this is a finding.

Fix: F-19439r376896_fix

Add the following to "/etc/audit/audit.rules": # audit_network_modifications -a always,exit -F arch=b32 -S sethostname -S setdomainname -k audit_network_modifications -w /etc/issue -p wa -k audit_network_modifications -w /etc/issue.net -p wa -k audit_network_modifications -w /etc/hosts -p wa -k audit_network_modifications -w /etc/sysconfig/network -p wa -k audit_network_modifications If the system is 64-bit, then also add the following: -a always,exit -F arch=b64 -S sethostname -S setdomainname -k audit_network_modifications

Generate Mitigation Statement:

Checks: C-19442r376898_chk

To determine if the system is configured to audit changes to its SELinux configuration files, run the following command: $ sudo grep -w "/etc/selinux" /etc/audit/audit.rules If the system is configured to watch for changes to its SELinux configuration, a line should be returned (including "-p wa" indicating permissions that are watched). If the system is not configured to audit attempts to change the MAC policy, this is a finding.

Fix: F-19440r376899_fix

Add the following to "/etc/audit/audit.rules": -w /etc/selinux/ -p wa -k MAC-policy

Generate Mitigation Statement:

Checks: C-19443r376901_chk

To determine if the system is configured to audit calls to the "chmod" system call, run the following command: $ sudo grep -w "chmod" /etc/audit/audit.rules -a always,exit -F arch=b32 -S chmod -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S chmod -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S chmod -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S chmod -F auid=0 -k perm_mod If the system is 64-bit and does not return a rule for both "b32" and "b64" architectures, this is a finding. If the system is not configured to audit the "chmod" system call, this is a finding.

Fix: F-19441r376902_fix

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 always,exit -F arch=b32 -S chmod -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S chmod -F auid=0 -k perm_mod If the system is 64-bit, then also add the following: -a always,exit -F arch=b64 -S chmod -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S chmod -F auid=0 -k perm_mod

Generate Mitigation Statement:

Checks: C-19444r376904_chk

To determine if the system is configured to audit calls to the "chown" system call, run the following command: $ sudo grep -w "chown" /etc/audit/audit.rules -a always,exit -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S chown -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S chown -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S chown -F auid=0 -k perm_mod If the system is 64-bit and does not return a rule for both "b32" and "b64" architectures, this is a finding. If the system is not configured to audit the "chown" system call, this is a finding.

Fix: F-19442r376905_fix

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 always,exit -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S chown -F auid=0 -k perm_mod If the system is 64-bit, then also add the following: -a always,exit -F arch=b64 -S chown -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S chown -F auid=0 -k perm_mod

Generate Mitigation Statement:

Checks: C-19445r376907_chk

To determine if the system is configured to audit calls to the "fchmod" system call, run the following command: $ sudo grep -w "fchmod" /etc/audit/audit.rules -a always,exit -F arch=b32 -S fchmod -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S fchmod -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fchmod -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S fchmod -F auid=0 -k perm_mod If the system is 64-bit and does not return a rule for both "b32" and "b64" architectures, this is a finding. If the system is not configured to audit the "fchmod" system call, this is a finding.

Fix: F-19443r376908_fix

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 always,exit -F arch=b32 -S fchmod -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S fchmod -F auid=0 -k perm_mod If the system is 64-bit, then also add the following: -a always,exit -F arch=b64 -S fchmod -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S fchmod -F auid=0 -k perm_mod

Generate Mitigation Statement:

Checks: C-19446r376910_chk

To determine if the system is configured to audit calls to the "fchmodat" system call, run the following command: $ sudo grep -w "fchmodat" /etc/audit/audit.rules -a always,exit -F arch=b32 -S fchmodat -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S fchmodat -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fchmodat -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S fchmodat -F auid=0 -k perm_mod If the system is 64-bit and does not return a rule for both "b32" and "b64" architectures, this is a finding. If the system is not configured to audit the "fchmodat" system call, this is a finding.

Fix: F-19444r376911_fix

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 always,exit -F arch=b32 -S fchmodat -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S fchmodat -F auid=0 -k perm_mod If the system is 64-bit, then also add the following: -a always,exit -F arch=b64 -S fchmodat -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S fchmodat -F auid=0 -k perm_mod

Generate Mitigation Statement:

Checks: C-19447r376913_chk

To determine if the system is configured to audit calls to the "fchown" system call, run the following command: $ sudo grep -w "fchown" /etc/audit/audit.rules -a always,exit -F arch=b32 -S fchown -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S fchown -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fchown -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S fchown -F auid=0 -k perm_mod If the system is 64-bit and does not return a rule for both "b32" and "b64" architectures, this is a finding. If the system is not configured to audit the "fchown" system call, this is a finding.

Fix: F-19445r376914_fix

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 always,exit -F arch=b32 -S fchown -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S fchown -F auid=0 -k perm_mod If the system is 64-bit, then also add the following: -a always,exit -F arch=b64 -S fchown -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S fchown -F auid=0 -k perm_mod

Generate Mitigation Statement:

Checks: C-19448r376916_chk

To determine if the system is configured to audit calls to the "fchownat" system call, run the following command: $ sudo grep -w "fchownat" /etc/audit/audit.rules -a always,exit -F arch=b32 -S fchownat -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S fchownat -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fchownat -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S fchownat -F auid=0 -k perm_mod If the system is 64-bit and does not return a rule for both "b32" and "b64" architectures, this is a finding. If the system is not configured to audit the "fchownat" system call, this is a finding.

Fix: F-19446r376917_fix

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 always,exit -F arch=b32 -S fchownat -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S fchownat -F auid=0 -k perm_mod If the system is 64-bit, then also add the following: -a always,exit -F arch=b64 -S fchownat -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S fchownat -F auid=0 -k perm_mod

Generate Mitigation Statement:

Checks: C-19449r376919_chk

To determine if the system is configured to audit calls to the "fremovexattr" system call, run the following command: $ sudo grep -w "fremovexattr" /etc/audit/audit.rules -a always,exit -F arch=b32 -S fremovexattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S fremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid=0 -k perm_mod If the system is 64-bit and does not return a rule for both "b32" and "b64" architectures, this is a finding. If the system is not configured to audit the "fremovexattr" system call, this is a finding.

Fix: F-19447r376920_fix

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 always,exit -F arch=b32 -S fremovexattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S fremovexattr -F auid=0 -k perm_mod If the system is 64-bit, then also add the following: -a always,exit -F arch=b64 -S fremovexattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid=0 -k perm_mod

Generate Mitigation Statement:

Checks: C-19450r376922_chk

To determine if the system is configured to audit calls to the "fsetxattr" system call, run the following command: $ sudo grep -w "fsetxattr" /etc/audit/audit.rules -a always,exit -F arch=b32 -S fsetxattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S fsetxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid=0 -k perm_mod If the system is 64-bit and does not return a rule for both "b32" and "b64" architectures, this is a finding. If the system is not configured to audit the "fsetxattr" system call, this is a finding.

Fix: F-19448r376923_fix

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 always,exit -F arch=b32 -S fsetxattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S fsetxattr -F auid=0 -k perm_mod If the system is 64-bit, then also add the following: -a always,exit -F arch=b64 -S fsetxattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid=0 -k perm_mod

Generate Mitigation Statement:

Checks: C-19451r376925_chk

To determine if the system is configured to audit calls to the "lchown" system call, run the following command: $ sudo grep -w "lchown" /etc/audit/audit.rules -a always,exit -F arch=b32 -S lchown -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S lchown -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S lchown -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S lchown -F auid=0 -k perm_mod If the system is 64-bit and does not return a rule for both "b32" and "b64" architectures, this is a finding. If the system is not configured to audit the "lchown" system call, this is a finding.

Fix: F-19449r376926_fix

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 always,exit -F arch=b32 -S lchown -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S lchown -F auid=0 -k perm_mod If the system is 64-bit, then also add the following: -a always,exit -F arch=b64 -S lchown -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S lchown -F auid=0 -k perm_mod

Generate Mitigation Statement:

Checks: C-19452r376928_chk

To determine if the system is configured to audit calls to the "lremovexattr" system call, run the following command: $ sudo grep -w "lremovexattr" /etc/audit/audit.rules -a always,exit -F arch=b32 -S lremovexattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S lremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid=0 -k perm_mod If the system is 64-bit and does not return a rule for both "b32" and "b64" architectures, this is a finding. If the system is not configured to audit the "lremovexattr" system call, this is a finding.

Fix: F-19450r376929_fix

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 always,exit -F arch=b32 -S lremovexattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S lremovexattr -F auid=0 -k perm_mod If the system is 64-bit, then also add the following: -a always,exit -F arch=b64 -S lremovexattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid=0 -k perm_mod

Generate Mitigation Statement:

Checks: C-19453r376931_chk

To determine if the system is configured to audit calls to the "lsetxattr" system call, run the following command: $ sudo grep -w "lsetxattr" /etc/audit/audit.rules -a always,exit -F arch=b32 -S lsetxattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S lsetxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid=0 -k perm_mod If the system is 64-bit and does not return a rule for both "b32" and "b64" architectures, this is a finding. If the system is not configured to audit the "lsetxattr" system call, this is a finding.

Fix: F-19451r376932_fix

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 always,exit -F arch=b32 -S lsetxattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S lsetxattr -F auid=0 -k perm_mod If the system is 64-bit, then also add the following: -a always,exit -F arch=b64 -S lsetxattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid=0 -k perm_mod

Generate Mitigation Statement:

Checks: C-19454r376934_chk

To determine if the system is configured to audit calls to the "removexattr" system call, run the following command: $ sudo grep -w "removexattr" /etc/audit/audit.rules -a always,exit -F arch=b32 -S removexattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S removexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid=0 -k perm_mod If the system is 64-bit and does not return a rule for both "b32" and "b64" architectures, this is a finding. If the system is not configured to audit the "removexattr" system call, this is a finding.

Fix: F-19452r376935_fix

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 always,exit -F arch=b32 -S removexattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S removexattr -F auid=0 -k perm_mod If the system is 64-bit, then also add the following: -a always,exit -F arch=b64 -S removexattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid=0 -k perm_mod

Generate Mitigation Statement:

Checks: C-19455r376937_chk

To determine if the system is configured to audit calls to the "setxattr" system call, run the following command: $ sudo grep -w "setxattr" /etc/audit/audit.rules -a always,exit -F arch=b32 -S setxattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S setxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S setxattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S setxattr -F auid=0 -k perm_mod If the system is 64-bit and does not return a rule for both "b32" and "b64" architectures, this is a finding. If the system is not configured to audit the "setxattr" system call, this is a finding.

Fix: F-19453r376938_fix

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 always,exit -F arch=b32 -S setxattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b32 -S setxattr -F auid=0 -k perm_mod If the system is 64-bit, then also add the following: -a always,exit -F arch=b64 -S setxattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod -a always,exit -F arch=b64 -S setxattr -F auid=0 -k perm_mod

Generate Mitigation Statement:

Checks: C-19456r376940_chk

To verify that the audit system collects unauthorized file accesses, run the following commands: # grep EACCES /etc/audit/audit.rules -a always,exit -F arch=b32 -S creat -S open -S openat -S truncate \ -S ftruncate -F exit=-EACCES -F auid>=500 -F auid!=4294967295 -k access -a always,exit -F arch=b32 -S creat -S open -S openat -S truncate \ -S ftruncate -F exit=-EACCES -F auid=0 -k access -a always,exit -F arch=b64 -S creat -S open -S openat -S truncate \ -S ftruncate -F exit=-EACCES -F auid>=500 -F auid!=4294967295 -k access -a always,exit -F arch=b64 -S creat -S open -S openat -S truncate \ -S ftruncate -F exit=-EACCES -F auid=0 -k access # grep EPERM /etc/audit/audit.rules -a always,exit -F arch=b32 -S creat -S open -S openat -S truncate \ -S ftruncate -F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access -a always,exit -F arch=b32 -S creat -S open -S openat -S truncate \ -S ftruncate -F exit=-EPERM -F auid=0 -k access -a always,exit -F arch=b64 -S creat -S open -S openat -S truncate \ -S ftruncate -F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access -a always,exit -F arch=b64 -S creat -S open -S openat -S truncate \ -S ftruncate -F exit=-EPERM -F auid=0 -k access If the system is 64-bit and does not return rules for both "b32" and "b64" architectures, this is a finding. If either command lacks output, this is a finding.

Fix: F-19454r376941_fix

At a minimum, the audit system should collect unauthorized file accesses for all users and root. Add the following to "/etc/audit/audit.rules": -a always,exit -F arch=b32 -S creat -S open -S openat -S truncate \ -S ftruncate -F exit=-EACCES -F auid>=500 -F auid!=4294967295 -k access -a always,exit -F arch=b32 -S creat -S open -S openat -S truncate \ -S ftruncate -F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access -a always,exit -F arch=b32 -S creat -S open -S openat -S truncate \ -S ftruncate -F exit=-EACCES -F auid=0 -k access -a always,exit -F arch=b32 -S creat -S open -S openat -S truncate \ -S ftruncate -F exit=-EPERM -F auid=0 -k access If the system is 64-bit, then also add the following: -a always,exit -F arch=b64 -S creat -S open -S openat -S truncate \ -S ftruncate -F exit=-EACCES -F auid>=500 -F auid!=4294967295 -k access -a always,exit -F arch=b64 -S creat -S open -S openat -S truncate \ -S ftruncate -F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access -a always,exit -F arch=b64 -S creat -S open -S openat -S truncate \ -S ftruncate -F exit=-EACCES -F auid=0 -k access -a always,exit -F arch=b64 -S creat -S open -S openat -S truncate \ -S ftruncate -F exit=-EPERM -F auid=0 -k access

Generate Mitigation Statement:

Checks: C-19457r376943_chk

To verify that auditing of privileged command use is configured, run the following command once for each local partition [PART] to find relevant setuid / setgid programs: $ sudo find [PART] -xdev -type f -perm /6000 2>/dev/null Run the following command to verify entries in the audit rules for all programs found with the previous command: $ sudo grep path /etc/audit/audit.rules It should be the case that all relevant setuid / setgid programs have a line in the audit rules. If that is not the case, this is a finding.

Fix: F-19455r376944_fix

At a minimum, the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid / setgid programs, run the following command for each local partition [PART]: $ sudo find [PART] -xdev -type f -perm /6000 2>/dev/null Then, for each setuid / setgid program on the system, add a line of the following form to "/etc/audit/audit.rules", where [SETUID_PROG_PATH] is the full path to each setuid / setgid program in the list: -a always,exit -F path=[SETUID_PROG_PATH] -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged

Generate Mitigation Statement:

Checks: C-19458r376946_chk

To verify that auditing is configured for all media exportation events, run the following command: $ sudo grep -w "mount" /etc/audit/audit.rules -a always,exit -F arch=b32 -S mount -F auid>=500 -F auid!=4294967295 -k export -a always,exit -F arch=b32 -S mount -F auid=0 -k export -a always,exit -F arch=b64 -S mount -F auid>=500 -F auid!=4294967295 -k export -a always,exit -F arch=b64 -S mount -F auid=0 -k export If the system is 64-bit and does not return rules for both "b32" and "b64" architectures, this is a finding. If no line is returned, this is a finding.

Fix: F-19456r376947_fix

At a minimum, the audit system should collect media exportation events for all users and root. Add the following to "/etc/audit/audit.rules": -a always,exit -F arch=b32 -S mount -F auid>=500 -F auid!=4294967295 -k export -a always,exit -F arch=b32 -S mount -F auid=0 -k export If the system is 64-bit, then also add the following: -a always,exit -F arch=b64 -S mount -F auid>=500 -F auid!=4294967295 -k export -a always,exit -F arch=b64 -S mount -F auid=0 -k export

Generate Mitigation Statement:

Checks: C-19459r376949_chk

To determine if the system is configured to audit user deletions of files and programs, run the following command: $ sudo egrep -w 'rmdir|unlink|unlinkat|rename|renameat' /etc/audit/audit.rules -a always,exit -F arch=b32 -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295 -k delete -a always,exit -F arch=b32 -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid=0 -k delete -a always,exit -F arch=b64 -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295 -k delete -a always,exit -F arch=b64 -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid=0 -k delete If the system is 64-bit and does not return rules for both "b32" and "b64" architectures, this is a finding. If the system is not configured to audit "rmdir", this is a finding. If the system is not configured to audit "unlink", this is a finding. If the system is not configured to audit "unlinkat", this is a finding. If the system is not configured to audit "rename", this is a finding. If the system is not configured to audit "renameat", this is a finding. If no line is returned, this is a finding.

Fix: F-19457r376950_fix

At a minimum, the audit system should collect file deletion events for all users and root. Add the following to "/etc/audit/audit.rules": -a always,exit -F arch=b32 -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295 -k delete -a always,exit -F arch=b32 -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid=0 -k delete If the system is 64-bit, then also add the following: -a always,exit -F arch=b64 -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295 -k delete -a always,exit -F arch=b64 -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid=0 -k delete

Generate Mitigation Statement:

Checks: C-19460r376952_chk

To verify that auditing is configured for system administrator actions, run the following command: $ sudo grep -w "/etc/sudoers" /etc/audit/audit.rules If the system is configured to watch for changes to its sudoers configuration, a line should be returned (including "-p wa" indicating permissions that are watched). If there is no output, this is a finding.

Fix: F-19458r376953_fix

At a minimum, the audit system should collect administrator actions for all users and root. Add the following to "/etc/audit/audit.rules": -w /etc/sudoers -p wa -k actions

Generate Mitigation Statement:

Checks: C-19463r376961_chk

If network services are using the xinetd service, this is not applicable. Run the following command to determine if the "xinetd" package is installed: # rpm -q xinetd If the package is installed, this is a finding.

Fix: F-19461r376962_fix

The "xinetd" package can be uninstalled with the following command: # yum erase xinetd

Generate Mitigation Statement:

Checks: C-19477r603817_chk

Run the following command to see what the timeout interval is: # grep ClientAliveInterval /etc/ssh/sshd_config ClientAliveInterval 600 If "ClientAliveInterval" has a value greater than "600", this is a finding.

Fix: F-19475r603818_fix

SSH allows administrators to set an idle timeout interval. After this interval has passed, the idle user will be automatically logged out. To set an idle timeout interval, edit the following line in "/etc/ssh/sshd_config" as follows: ClientAliveInterval [interval] The timeout [interval] is given in seconds. To have a timeout of ten minutes, set [interval] to 600. If a shorter timeout has already been set for the login shell, that value will preempt any SSH setting made here. Keep in mind that some processes may stop SSH from correctly detecting that the user is idle.

Generate Mitigation Statement:

Checks: C-19478r377006_chk

To ensure the SSH idle timeout will occur when the "ClientAliveCountMax" is set, run the following command: # grep ClientAliveCountMax /etc/ssh/sshd_config If properly configured, output should be: ClientAliveCountMax 0 If it is not, this is a finding.

Fix: F-19476r377007_fix

To ensure the SSH idle timeout occurs precisely when the "ClientAliveCountMax" is set, edit "/etc/ssh/sshd_config" as follows: ClientAliveCountMax 0

Generate Mitigation Statement:

Checks: C-19484r377024_chk

To ensure users are not able to present environment daemons, run the following command: # grep PermitUserEnvironment /etc/ssh/sshd_config If properly configured, output should be: PermitUserEnvironment no If it is not, this is a finding.

Fix: F-19482r377025_fix

To ensure users are not able to present environment options to the SSH daemon, add or correct the following line in "/etc/ssh/sshd_config": PermitUserEnvironment no

Generate Mitigation Statement:

Checks: C-19487r377033_chk

To check that the "avahi-daemon" service is disabled in system boot configuration, run the following command: # chkconfig "avahi-daemon" --list Output should indicate the "avahi-daemon" service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig "avahi-daemon" --list "avahi-daemon" 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify "avahi-daemon" is disabled through current runtime configuration: # service avahi-daemon status If the service is disabled the command will return the following output: avahi-daemon is stopped If the service is running, this is a finding.

Fix: F-19485r377034_fix

The "avahi-daemon" service can be disabled with the following commands: # chkconfig avahi-daemon off # service avahi-daemon stop

Generate Mitigation Statement:

Checks: C-19491r377045_chk

To verify the "openldap-servers" package is not installed, run the following command: $ rpm -q openldap-servers The output should show the following. package openldap-servers is not installed If it does not, this is a finding.

Fix: F-19489r377046_fix

The "openldap-servers" package should be removed if not in use. # yum erase openldap-servers The openldap-servers RPM is not installed by default on RHEL6 machines. It is needed only by the OpenLDAP server, not by the clients which use LDAP for authentication. If the system is not intended for use as an LDAP Server it should be removed.

Generate Mitigation Statement:

Checks: C-19495r377057_chk

If the GConf2 package is not installed, this is not applicable. To ensure the screensaver is configured to be blank, run the following command: $ gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --get /apps/gnome-screensaver/mode If properly configured, the output should be "blank-only". If it is not, this is a finding.

Fix: F-19493r377058_fix

Run the following command to set the screensaver mode in the GNOME desktop to a blank screen: # gconftool-2 \ --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type string \ --set /apps/gnome-screensaver/mode blank-only

Generate Mitigation Statement:

Checks: C-19496r377060_chk

To check that the "abrtd" service is disabled in system boot configuration, run the following command: # chkconfig "abrtd" --list Output should indicate the "abrtd" service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig "abrtd" --list "abrtd" 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify "abrtd" is disabled through current runtime configuration: # service abrtd status If the service is disabled the command will return the following output: abrtd is stopped If the service is running, this is a finding.

Fix: F-19494r377061_fix

The Automatic Bug Reporting Tool ("abrtd") daemon collects and reports crash data when an application crash is detected. Using a variety of plugins, abrtd can email crash reports to system administrators, log crash reports to files, or forward crash reports to a centralized issue tracking system such as RHTSupport. The "abrtd" service can be disabled with the following commands: # chkconfig abrtd off # service abrtd stop

Generate Mitigation Statement:

Checks: C-19497r377063_chk

If the system requires the use of the "atd" service to support an organizational requirement, this is not applicable. To check that the "atd" service is disabled in system boot configuration, run the following command: # chkconfig "atd" --list Output should indicate the "atd" service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig "atd" --list "atd" 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify "atd" is disabled through current runtime configuration: # service atd status If the service is disabled the command will return the following output: atd is stopped If the service is running, this is a finding.

Fix: F-19495r377064_fix

The "at" and "batch" commands can be used to schedule tasks that are meant to be executed only once. This allows delayed execution in a manner similar to cron, except that it is not recurring. The daemon "atd" keeps track of tasks scheduled via "at" and "batch", and executes them at the specified time. The "atd" service can be disabled with the following commands: # chkconfig atd off # service atd stop

Generate Mitigation Statement:

Checks: C-19498r377066_chk

To check that the "ntpdate" service is disabled in system boot configuration, run the following command: # chkconfig "ntpdate" --list Output should indicate the "ntpdate" service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig "ntpdate" --list "ntpdate" 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify "ntpdate" is disabled through current runtime configuration: # service ntpdate status If the service is disabled the command will return the following output: ntpdate is stopped If the service is running, this is a finding.

Fix: F-19496r377067_fix

The ntpdate service sets the local hardware clock by polling NTP servers when the system boots. It synchronizes to the NTP servers listed in "/etc/ntp/step-tickers" or "/etc/ntp.conf" and then sets the local hardware clock to the newly synchronized system time. The "ntpdate" service can be disabled with the following commands: # chkconfig ntpdate off # service ntpdate stop

Generate Mitigation Statement:

Checks: C-19499r377069_chk

To check that the "oddjobd" service is disabled in system boot configuration, run the following command: # chkconfig "oddjobd" --list Output should indicate the "oddjobd" service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig "oddjobd" --list "oddjobd" 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify "oddjobd" is disabled through current runtime configuration: # service oddjobd status If the service is disabled the command will return the following output: oddjobd is stopped If the service is running, this is a finding.

Fix: F-19497r377070_fix

The "oddjobd" service exists to provide an interface and access control mechanism through which specified privileged tasks can run tasks for unprivileged client applications. Communication with "oddjobd" is through the system message bus. The "oddjobd" service can be disabled with the following commands: # chkconfig oddjobd off # service oddjobd stop

Generate Mitigation Statement:

Checks: C-19500r377072_chk

To check that the "qpidd" service is disabled in system boot configuration, run the following command: # chkconfig "qpidd" --list Output should indicate the "qpidd" service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig "qpidd" --list "qpidd" 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify "qpidd" is disabled through current runtime configuration: # service qpidd status If the service is disabled the command will return the following output: qpidd is stopped If the service is running, this is a finding.

Fix: F-19498r377073_fix

The "qpidd" service provides high speed, secure, guaranteed delivery services. It is an implementation of the Advanced Message Queuing Protocol. By default the qpidd service will bind to port 5672 and listen for connection attempts. The "qpidd" service can be disabled with the following commands: # chkconfig qpidd off # service qpidd stop

Generate Mitigation Statement:

Checks: C-19501r377075_chk

To check that the "rdisc" service is disabled in system boot configuration, run the following command: # chkconfig "rdisc" --list Output should indicate the "rdisc" service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig "rdisc" --list "rdisc" 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify "rdisc" is disabled through current runtime configuration: # service rdisc status If the service is disabled the command will return the following output: rdisc is stopped If the service is running, this is a finding.

Fix: F-19499r377076_fix

The "rdisc" service implements the client side of the ICMP Internet Router Discovery Protocol (IRDP), which allows discovery of routers on the local subnet. If a router is discovered then the local routing table is updated with a corresponding default route. By default this daemon is disabled. The "rdisc" service can be disabled with the following commands: # chkconfig rdisc off # service rdisc stop

Generate Mitigation Statement:

Checks: C-19504r377084_chk

Identify any removable media that is configured on the system: # cat /etc/fstab /dev/mapper/vg_rhel6-lv_root / ext4 defaults 1 1 UUID=0be9b205-f8e6-4bf4-b0ba-1f235fc55936 /boot ext4 defaults 1 2 UUID=5D49-30B2 /boot/efi vfat umask=0077,shortname=winnt 0 0 /dev/mapper/vg_rhel6-lv_home /home ext4 defaults 1 2 /dev/mapper/vg_rhel6-lv_tmp /tmp ext4 defaults 1 2 /dev/mapper/vg_rhel6-lv_var /var ext4 defaults 1 2 /dev/mapper/vg_rhel6-lv_swap swap swap defaults 0 0 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /dev/sdc1 /media/usb vfat defaults,rw,noexec 0 0 If any of the identified removable media devices do not have "noexec" defined, this is a finding.

Fix: F-19502r377085_fix

The "noexec" mount option prevents the direct execution of binaries on the mounted filesystem. Users should not be allowed to execute binaries that exist on partitions mounted from removable media (such as a USB key). The "noexec" option prevents code from being executed directly from the media itself, and may therefore provide a line of defense against certain types of worms or malicious code. Add the "noexec" option to the fourth column of "/etc/fstab" for the line which controls mounting of any removable media partitions.

Generate Mitigation Statement:

Checks: C-19505r377087_chk

To verify that Samba clients running smbclient must use packet signing, run the following command: # grep signing /etc/samba/smb.conf The output should show: client signing = mandatory If it is not, this is a finding.

Fix: F-19503r377088_fix

To require samba clients running "smbclient" to use packet signing, add the following to the "[global]" section of the Samba configuration file in "/etc/samba/smb.conf": client signing = mandatory Requiring samba clients such as "smbclient" to use packet signing ensures they can only communicate with servers that support packet signing.

Generate Mitigation Statement:

Checks: C-19506r377090_chk

If Samba is not in use, this is not applicable. To verify that Samba clients using mount.cifs must use packet signing, run the following command: # grep sec /etc/fstab /etc/mtab The output should show either "krb5i" or "ntlmv2i" in use. If it does not, this is a finding.

Fix: F-19504r377091_fix

Require packet signing of clients who mount Samba shares using the "mount.cifs" program (e.g., those who specify shares in "/etc/fstab"). To do so, ensure signing options (either "sec=krb5i" or "sec=ntlmv2i") are used. See the "mount.cifs(8)" man page for more information. A Samba client should only communicate with servers who can support SMB packet signing.

Generate Mitigation Statement:

Checks: C-19508r377096_chk

Determine if encryption must be used to protect data on the system. If encryption must be used and is not employed, this is a finding.

Fix: F-19506r377097_fix

Red Hat Enterprise Linux 6 natively supports partition encryption through the Linux Unified Key Setup-on-disk-format (LUKS) technology. The easiest way to encrypt a partition is during installation time. For manual installations, select the "Encrypt" checkbox during partition creation to encrypt the partition. When this option is selected the system will prompt for a passphrase to use in decrypting the partition. The passphrase will subsequently need to be entered manually every time the system boots. For automated/unattended installations, it is possible to use Kickstart by adding the "--encrypted" and "--passphrase=" options to the definition of each partition to be encrypted. For example, the following line would encrypt the root partition: part / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=[PASSPHRASE] Any [PASSPHRASE] is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the "--passphrase=" option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation. Detailed information on encrypting partitions using LUKS can be found on the Red Hat Documentation web site: https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html

Generate Mitigation Statement:

Checks: C-19509r377099_chk

Determine if encryption must be used to protect data on the system. If encryption must be used and is not employed, this is a finding.

Fix: F-19507r377100_fix

Red Hat Enterprise Linux 6 natively supports partition encryption through the Linux Unified Key Setup-on-disk-format (LUKS) technology. The easiest way to encrypt a partition is during installation time. For manual installations, select the "Encrypt" checkbox during partition creation to encrypt the partition. When this option is selected the system will prompt for a passphrase to use in decrypting the partition. The passphrase will subsequently need to be entered manually every time the system boots. For automated/unattended installations, it is possible to use Kickstart by adding the "--encrypted" and "--passphrase=" options to the definition of each partition to be encrypted. For example, the following line would encrypt the root partition: part / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=[PASSPHRASE] Any [PASSPHRASE] is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the "--passphrase=" option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation. Detailed information on encrypting partitions using LUKS can be found on the Red Hat Documentation web site: https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html

Generate Mitigation Statement:

Checks: C-19510r377102_chk