contains 19 rules |
System Settings
[ref]groupContains rules that check correct system settings. |
contains 19 rules |
Installing and Maintaining Software
[ref]groupThe following sections contain information on
security-relevant choices during the initial operating system
installation process and the setup of software
updates. |
contains 7 rules |
Disk Partitioning
[ref]groupTo 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 5 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.
|
Ensure /var Located On Separate Partition
[ref]ruleThe /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.
|
Ensure /var/log Located On Separate Partition
[ref]rule
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.
Rationale:
Placing /var/log in its own partition
enables better separation between log files
and other files in /var/ .
|
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.
|
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.
|
Sudo , which stands for "su 'do'", provides the ability to delegate authority
to certain users, groups of users, or system administrators. When configured for system
users and/or groups, Sudo can allow a user or group to execute privileged commands
that normally only root is allowed to execute.
For more information on Sudo and addition Sudo configuration options, see
https://www.sudo.ws
|
contains 2 rules |
Ensure Users Re-Authenticate for Privilege Escalation - sudo NOPASSWD
[ref]rule
The sudo NOPASSWD tag, when specified, allows a user to execute commands using
sudo without having to authenticate. This should be disabled by making sure that the
NOPASSWD tag does not exist in /etc/sudoers configuration file or
any sudo configuration snippets in /etc/sudoers.d/ .
Rationale:
Without re-authentication, users may access resources or perform tasks for which they
do not have authorization.
When operating systems provide the capability to escalate a functional capability, it
is critical that the user re-authenticate.
|
Ensure Users Re-Authenticate for Privilege Escalation - sudo !authenticate
[ref]rule
The sudo !authenticate option, when specified, allows a user to execute commands using
sudo without having to authenticate. This should be disabled by making sure that the
!authenticate option does not exist in /etc/sudoers configuration file or
any sudo configuration snippets in /etc/sudoers.d/ .
Rationale:
Without re-authentication, users may access resources or perform tasks for which they
do not have authorization.
When operating systems provide the capability to escalate a functional capability, it
is critical that the user re-authenticate.
|
File Permissions and Masks
[ref]groupTraditional 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 6 rules |
Verify Permissions on Important Files and
Directories
[ref]groupPermissions 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 4 rules |
Verify Permissions on Files with Local Account Information and Credentials
[ref]groupThe 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 4 rules |
Verify Permissions on shadow File
[ref]rule
To properly set the permissions of /etc/shadow , run the command:
$ sudo chmod 0000 /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. Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | configure |
---|
chmod 0000 /etc/shadow
Remediation Ansible snippet: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | configure |
---|
- name: Ensure permission 0000 on /etc/shadow
file:
path="{{item}}"
mode=0000
with_items:
- /etc/shadow
tags:
- file_permissions_etc_shadow
- medium_severity
- configure_strategy
- low_complexity
- low_disruption
- CCE-27100-7
- NIST-800-53-AC-6
- PCI-DSS-Req-8.7.c
- CJIS-5.5.2.2
|
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. Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | configure |
---|
chmod 0644 /etc/group
Remediation Ansible snippet: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | configure |
---|
- name: Find /etc/group file(s)
find:
paths: "{{ '/etc/group' | dirname }}"
patterns: "{{ '/etc/group' | basename }}"
register: files_found
tags:
- file_permissions_etc_group
- medium_severity
- configure_strategy
- low_complexity
- low_disruption
- CCE-26949-8
- NIST-800-53-AC-6
- PCI-DSS-Req-8.7.c
- CJIS-5.5.2.2
- name: Set permissions
file:
path: "{{ item.path }}"
mode: 0644
with_items:
- "{{ files_found.files }}"
tags:
- file_permissions_etc_group
- medium_severity
- configure_strategy
- low_complexity
- low_disruption
- CCE-26949-8
- NIST-800-53-AC-6
- PCI-DSS-Req-8.7.c
- CJIS-5.5.2.2
|
Verify Permissions on gshadow File
[ref]rule
To properly set the permissions of /etc/gshadow , run the command:
$ sudo chmod 0000 /etc/gshadow
Rationale:The /etc/gshadow file contains group password hashes. Protection of this file
is critical for system security. Identifiers:
CCE-27162-7 References:
AC-6, 6.1.5 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | configure |
---|
chmod 0000 /etc/gshadow
Remediation Ansible snippet: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | configure |
---|
- name: Find /etc/gshadow file(s)
find:
paths: "{{ '/etc/gshadow' | dirname }}"
patterns: "{{ '/etc/gshadow' | basename }}"
register: files_found
tags:
- file_permissions_etc_gshadow
- medium_severity
- configure_strategy
- low_complexity
- low_disruption
- CCE-27162-7
- NIST-800-53-AC-6
- name: Set permissions
file:
path: "{{ item.path }}"
mode: 0000
with_items:
- "{{ files_found.files }}"
tags:
- file_permissions_etc_gshadow
- medium_severity
- configure_strategy
- low_complexity
- low_disruption
- CCE-27162-7
- NIST-800-53-AC-6
|
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. Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | configure |
---|
chmod 0644 /etc/passwd
Remediation Ansible snippet: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | configure |
---|
- name: Find /etc/passwd file(s)
find:
paths: "{{ '/etc/passwd' | dirname }}"
patterns: "{{ '/etc/passwd' | basename }}"
register: files_found
tags:
- file_permissions_etc_passwd
- medium_severity
- configure_strategy
- low_complexity
- low_disruption
- CCE-26887-0
- NIST-800-53-AC-6
- PCI-DSS-Req-8.7.c
- CJIS-5.5.2.2
- name: Set permissions
file:
path: "{{ item.path }}"
mode: 0644
with_items:
- "{{ files_found.files }}"
tags:
- file_permissions_etc_passwd
- medium_severity
- configure_strategy
- low_complexity
- low_disruption
- CCE-26887-0
- NIST-800-53-AC-6
- PCI-DSS-Req-8.7.c
- CJIS-5.5.2.2
|
Restrict Programs from Dangerous Execution Patterns
[ref]groupThe 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 2 rules |
Disable Core Dumps
[ref]groupA 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 SUID programs
[ref]rule
To set the runtime status of the fs.suid_dumpable kernel parameter,
run the following command:
$ sudo sysctl -w fs.suid_dumpable=0
If this is not the system's default value, add the following line to /etc/sysctl.conf :
fs.suid_dumpable = 0
Rationale:The core dump of a setuid program is more likely to contain
sensitive data, as the program itself runs with greater privileges than the
user who initiated execution of the program. Disabling the ability for any
setuid program to write a core file decreases the risk of unauthorized access
of such data. Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
#
# Set runtime for fs.suid_dumpable
#
/sbin/sysctl -q -n -w fs.suid_dumpable=0
#
# If fs.suid_dumpable present in /etc/sysctl.conf, change value to "0"
# else, add "fs.suid_dumpable = 0" to /etc/sysctl.conf
#
# Function to replace configuration setting in config file or add the configuration setting if
# it does not exist.
#
# Expects four arguments:
#
# config_file: Configuration file that will be modified
# key: Configuration option to change
# value: Value of the configuration option to change
# cce: The CCE identifier or '@CCENUM@' if no CCE identifier exists
#
# Optional arugments:
#
# format: Optional argument to specify the format of how key/value should be
# modified/appended in the configuration file. The default is key = value.
#
# Example Call(s):
#
# With default format of 'key = value':
# replace_or_append '/etc/sysctl.conf' '^kernel.randomize_va_space' '2' '@CCENUM@'
#
# With custom key/value format:
# replace_or_append '/etc/sysconfig/selinux' '^SELINUX=' 'disabled' '@CCENUM@' '%s=%s'
#
# With a variable:
# replace_or_append '/etc/sysconfig/selinux' '^SELINUX=' $var_selinux_state '@CCENUM@' '%s=%s'
#
function replace_or_append {
local config_file=$1
local key=$2
local value=$3
local cce=$4
local format=$5
# Check sanity of the input
if [ $# -lt "3" ]
then
echo "Usage: replace_or_append 'config_file_location' 'key_to_search' 'new_value'"
echo
echo "If symlinks need to be taken into account, add yes/no to the last argument"
echo "to allow to 'follow_symlinks'."
echo "Aborting."
exit 1
fi
# Test if the config_file is a symbolic link. If so, use --follow-symlinks with sed.
# Otherwise, regular sed command will do.
if test -L $config_file; then
sed_command="sed -i --follow-symlinks"
else
sed_command="sed -i"
fi
# Test that the cce arg is not empty or does not equal @CCENUM@.
# If @CCENUM@ exists, it means that there is no CCE assigned.
if ! [ "x$cce" = x ] && [ "$cce" != '@CCENUM@' ]; then
cce="CCE-${cce}"
else
cce="CCE"
fi
# Strip any search characters in the key arg so that the key can be replaced without
# adding any search characters to the config file.
stripped_key=$(sed "s/[\^=\$,;+]*//g" <<< $key)
# If there is no print format specified in the last arg, use the default format.
if ! [ "x$format" = x ] ; then
printf -v formatted_output "$format" "$stripped_key" "$value"
else
formatted_output="$stripped_key = $value"
fi
# If the key exists, change it. Otherwise, add it to the config_file.
if `grep -qi "$key" $config_file` ; then
eval '$sed_command "s/$key.*/$formatted_output/g" $config_file'
else
# \n is precaution for case where file ends without trailing newline
echo -e "\n# Per $cce: Set $formatted_output in $config_file" >> $config_file
echo -e "$formatted_output" >> $config_file
fi
}
replace_or_append '/etc/sysctl.conf' '^fs.suid_dumpable' "0" 'CCE-26900-1'
Remediation Ansible snippet: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
- name: Ensure sysctl fs.suid_dumpable is set to 0
sysctl:
name: fs.suid_dumpable
value: 0
state: present
reload: yes
tags:
- sysctl_fs_suid_dumpable
- low_severity
- disable_strategy
- low_complexity
- medium_disruption
- CCE-26900-1
- NIST-800-53-SI-11
|
Enable ExecShield
[ref]groupExecShield 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
on 32-bit systems and controlled through sysctl variables
kernel.exec-shield and kernel.randomize_va_space . On the latest
64-bit systems, kernel.exec-shield cannot be enabled or disabled with
sysctl .
|
contains 1 rule |
Enable Randomized Layout of Virtual Address Space
[ref]rule
To set the runtime status of the kernel.randomize_va_space kernel parameter,
run the following command:
$ sudo sysctl -w kernel.randomize_va_space=2
If this is not the system's default value, add the following line to /etc/sysctl.conf :
kernel.randomize_va_space = 2
Rationale: 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.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
# Function to replace configuration setting in config file or add the configuration setting if
# it does not exist.
#
# Expects four arguments:
#
# config_file: Configuration file that will be modified
# key: Configuration option to change
# value: Value of the configuration option to change
# cce: The CCE identifier or '@CCENUM@' if no CCE identifier exists
#
# Optional arugments:
#
# format: Optional argument to specify the format of how key/value should be
# modified/appended in the configuration file. The default is key = value.
#
# Example Call(s):
#
# With default format of 'key = value':
# replace_or_append '/etc/sysctl.conf' '^kernel.randomize_va_space' '2' '@CCENUM@'
#
# With custom key/value format:
# replace_or_append '/etc/sysconfig/selinux' '^SELINUX=' 'disabled' '@CCENUM@' '%s=%s'
#
# With a variable:
# replace_or_append '/etc/sysconfig/selinux' '^SELINUX=' $var_selinux_state '@CCENUM@' '%s=%s'
#
function replace_or_append {
local config_file=$1
local key=$2
local value=$3
local cce=$4
local format=$5
# Check sanity of the input
if [ $# -lt "3" ]
then
echo "Usage: replace_or_append 'config_file_location' 'key_to_search' 'new_value'"
echo
echo "If symlinks need to be taken into account, add yes/no to the last argument"
echo "to allow to 'follow_symlinks'."
echo "Aborting."
exit 1
fi
# Test if the config_file is a symbolic link. If so, use --follow-symlinks with sed.
# Otherwise, regular sed command will do.
if test -L $config_file; then
sed_command="sed -i --follow-symlinks"
else
sed_command="sed -i"
fi
# Test that the cce arg is not empty or does not equal @CCENUM@.
# If @CCENUM@ exists, it means that there is no CCE assigned.
if ! [ "x$cce" = x ] && [ "$cce" != '@CCENUM@' ]; then
cce="CCE-${cce}"
else
cce="CCE"
fi
# Strip any search characters in the key arg so that the key can be replaced without
# adding any search characters to the config file.
stripped_key=$(sed "s/[\^=\$,;+]*//g" <<< $key)
# If there is no print format specified in the last arg, use the default format.
if ! [ "x$format" = x ] ; then
printf -v formatted_output "$format" "$stripped_key" "$value"
else
formatted_output="$stripped_key = $value"
fi
# If the key exists, change it. Otherwise, add it to the config_file.
if `grep -qi "$key" $config_file` ; then
eval '$sed_command "s/$key.*/$formatted_output/g" $config_file'
else
# \n is precaution for case where file ends without trailing newline
echo -e "\n# Per $cce: Set $formatted_output in $config_file" >> $config_file
echo -e "$formatted_output" >> $config_file
fi
}
replace_or_append '/etc/sysctl.conf' '^kernel.randomize_va_space' '2' 'CCE-27127-0'
Remediation Ansible snippet: (show)
Complexity: | low |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | disable |
---|
- name: Ensure sysctl kernel.randomize_va_space is set to 2
sysctl:
name: kernel.randomize_va_space
value: 2
state: present
reload: yes
tags:
- sysctl_kernel_randomize_va_space
- medium_severity
- disable_strategy
- low_complexity
- medium_disruption
- CCE-27127-0
- NIST-800-53-SC-30(2)
- NIST-800-171-3.1.7
- DISA-STIG-RHEL-07-040201
|
Configure Syslog
[ref]groupThe 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.
In Red Hat Enterprise Linux 7, rsyslog has replaced ksyslogd as the
syslog daemon of choice, and it includes some additional security features
such as reliable, connection-oriented (i.e. TCP) transmission of logs, the
option to log to database formats, and the encryption of log data en route to
a central logging server.
This section discusses how to configure rsyslog for
best effect, and how to use tools provided with the system to maintain and
monitor logs. |
contains 6 rules |
Ensure Proper Configuration of Log Files
[ref]group
The file /etc/rsyslog.conf controls where log message are written.
These are controlled by lines called rules, which consist of a
selector and an action.
These rules are often customized depending on the role of the system, the
requirements of the environment, and whatever may enable
the administrator to most effectively make use of log data.
The default rules in Red Hat Enterprise Linux 7 are:
*.info;mail.none;authpriv.none;cron.none /var/log/messages
authpriv.* /var/log/secure
mail.* -/var/log/maillog
cron.* /var/log/cron
*.emerg *
uucp,news.crit /var/log/spooler
local7.* /var/log/boot.log
See the man page rsyslog.conf(5) for more information.
Note that the rsyslog daemon can be configured to use a timestamp format that
some log processing programs may not understand. If this occurs,
edit the file /etc/rsyslog.conf and add or edit the following line:
$ ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
|
contains 3 rules |
Ensure Log Files Are Owned By Appropriate User
[ref]ruleThe owner of all log files written by
rsyslog should be root.
These log files are determined by the second part of each Rule line in
/etc/rsyslog.conf and typically all appear in /var/log .
For each log file LOGFILE referenced in /etc/rsyslog.conf ,
run the following command to inspect the file's owner:
$ ls -l LOGFILE
If the owner is not root , run the following command to
correct this:
$ sudo chown root LOGFILE
Rationale:The log files generated by rsyslog contain valuable information regarding system
configuration, user authentication, and other such information. Log files should be
protected from unauthorized access. |
Ensure Log Files Are Owned By Appropriate Group
[ref]ruleThe group-owner of all log files written by
rsyslog should be root.
These log files are determined by the second part of each Rule line in
/etc/rsyslog.conf and typically all appear in /var/log .
For each log file LOGFILE referenced in /etc/rsyslog.conf ,
run the following command to inspect the file's group owner:
$ ls -l LOGFILE
If the owner is not root , run the following command to
correct this:
$ sudo chgrp root LOGFILE
Rationale:The log files generated by rsyslog contain valuable information regarding system
configuration, user authentication, and other such information. Log files should be
protected from unauthorized access. |
Ensure System Log Files Have Correct Permissions
[ref]ruleThe file permissions for all log files written by
rsyslog should be set to 600, or more restrictive.
These log files are determined by the second part of each Rule line in
/etc/rsyslog.conf and typically all appear in /var/log .
For each log file LOGFILE referenced in /etc/rsyslog.conf ,
run the following command to inspect the file's permissions:
$ ls -l LOGFILE
If the permissions are not 600 or more restrictive,
run the following command to correct this:
$ sudo chmod 0600 LOGFILE
Rationale:Log files can contain valuable information regarding system
configuration. If the system log files are not protected unauthorized
users could change the logged data, eliminating their forensic value.
Remediation Shell script: (show)
# List of log file paths to be inspected for correct permissions
# * Primarily inspect log file paths listed in /etc/rsyslog.conf
RSYSLOG_ETC_CONFIG="/etc/rsyslog.conf"
# * And also the log file paths listed after rsyslog's $IncludeConfig directive
# (store the result into array for the case there's shell glob used as value of IncludeConfig)
RSYSLOG_INCLUDE_CONFIG=($(grep -e "\$IncludeConfig[[:space:]]\+[^[:space:];]\+" /etc/rsyslog.conf | cut -d ' ' -f 2))
# Declare an array to hold the final list of different log file paths
declare -a LOG_FILE_PATHS
# Browse each file selected above as containing paths of log files
# ('/etc/rsyslog.conf' and '/etc/rsyslog.d/*.conf' in the default configuration)
for LOG_FILE in "${RSYSLOG_ETC_CONFIG}" "${RSYSLOG_INCLUDE_CONFIG[@]}"
do
# From each of these files extract just particular log file path(s), thus:
# * Ignore lines starting with space (' '), comment ('#"), or variable syntax ('$') characters,
# * Ignore empty lines,
# * From the remaining valid rows select only fields constituting a log file path
# Text file column is understood to represent a log file path if and only if all of the following are met:
# * it contains at least one slash '/' character,
# * it doesn't contain space (' '), colon (':'), and semicolon (';') characters
# Search log file for path(s) only in case it exists!
if [[ -f "${LOG_FILE}" ]]
then
MATCHED_ITEMS=$(sed -e "/^[[:space:]|#|$]/d ; s/[^\/]*[[:space:]]*\([^:;[:space:]]*\)/\1/g ; /^$/d" "${LOG_FILE}")
# Since above sed command might return more than one item (delimited by newline), split the particular
# matches entries into new array specific for this log file
readarray -t ARRAY_FOR_LOG_FILE <<< "$MATCHED_ITEMS"
# Concatenate the two arrays - previous content of $LOG_FILE_PATHS array with
# items from newly created array for this log file
LOG_FILE_PATHS=("${LOG_FILE_PATHS[@]}" "${ARRAY_FOR_LOG_FILE[@]}")
# Delete the temporary array
unset ARRAY_FOR_LOG_FILE
fi
done
for PATH in "${LOG_FILE_PATHS[@]}"
do
# Sanity check - if particular $PATH is empty string, skip it from further processing
if [ -z "$PATH" ]
then
continue
fi
# In RHEL 7 we have systemd, so it doesn't make sense to patch/change /etc/rc.d/rc.local,
# as per BZ https://bugzilla.redhat.com/show_bug.cgi?id=1404381
# Also for each log file check if its permissions differ from 600. If so, correct them
if [ "$(/usr/bin/stat -c %a "$PATH")" -ne 600 ]
then
/bin/chmod 600 "$PATH"
fi
done
|
Ensure All Logs are Rotated by logrotate
[ref]groupEdit 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/rsyslog.conf .
All logs in use on a system must be rotated regularly, or the
log files will consume disk space over time, eventually interfering
with system operation. The file /etc/logrotate.d/syslog is the
configuration file used by the logrotate program to maintain all
log files written by syslog . By default, it rotates logs weekly and
stores four archival copies of each log. These settings can be
modified by editing /etc/logrotate.conf , but the defaults are
sufficient for purposes of this guide.
Note that logrotate is run nightly by the cron job
/etc/cron.daily/logrotate . If particularly active logs need to be
rotated more often than once a day, some other mechanism must be
used. |
contains 1 rule |
Ensure Logrotate Runs Periodically
[ref]ruleThe 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. |
Ensure rsyslog is Installed
[ref]rule
Rsyslog is installed by default.
The rsyslog package can be installed with the following command:
$ sudo yum install rsyslog
Rationale:
The rsyslog package provides the rsyslog daemon, which provides
system logging services.
Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | enable |
---|
# Function to install or uninstall packages on RHEL and Fedora systems.
#
# Example Call(s):
#
# package_command install aide
# package_command remove telnet-server
#
function package_command {
# Load function arguments into local variables
local package_operation=$1
local package=$2
# Check sanity of the input
if [ $# -ne "2" ]
then
echo "Usage: package_command 'install/uninstall' 'rpm_package_name"
echo "Aborting."
exit 1
fi
# If dnf is installed, use dnf; otherwise, use yum
if [ -f "/usr/bin/dnf" ] ; then
install_util="/usr/bin/dnf"
else
install_util="/usr/bin/yum"
fi
if [ "$package_operation" != 'remove' ] ; then
# If the rpm is not installed, install the rpm
if ! /bin/rpm -q --quiet $package; then
$install_util -y $package_operation $package
fi
else
# If the rpm is installed, uninstall the rpm
if /bin/rpm -q --quiet $package; then
$install_util -y $package_operation $package
fi
fi
}
package_command install rsyslog
Remediation Ansible snippet: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | enable |
---|
- name: Ensure rsyslog is installed
package:
name="{{item}}"
state=present
with_items:
- rsyslog
tags:
- package_rsyslog_installed
- medium_severity
- enable_strategy
- low_complexity
- low_disruption
- CCE-80187-8
- NIST-800-53-AU-9(2)
Remediation Puppet snippet: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | enable |
---|
include install_rsyslog
class install_rsyslog {
package { 'rsyslog':
ensure => 'installed',
}
}
Remediation Anaconda snippet: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | enable |
---|
package --add=rsyslog
|
Enable rsyslog Service
[ref]ruleThe rsyslog service provides syslog-style logging by default on Red Hat Enterprise Linux 7.
The rsyslog service can be enabled with the following command:
$ sudo systemctl enable rsyslog.service
Rationale:The rsyslog service must be running in order to provide
logging services, which are essential to system administration.
Identifiers:
CCE-80188-6 References:
AU-4(1), AU-12, CCI-001311, CCI-001312, CCI-001557, CCI-001851, 4.2.1.1, NT28(R5), NT28(R46), 164.312(a)(2)(ii), A.12.3.1 Remediation Shell script: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | enable |
---|
# Function to enable/disable and start/stop services on RHEL and Fedora systems.
#
# Example Call(s):
#
# service_command enable bluetooth
# service_command disable bluetooth.service
#
# Using xinetd:
# service_command disable rsh.socket xinetd=rsh
#
function service_command {
# Load function arguments into local variables
local service_state=$1
local service=$2
local xinetd=$(echo $3 | cut -d'=' -f2)
# Check sanity of the input
if [ $# -lt "2" ]
then
echo "Usage: service_command 'enable/disable' 'service_name.service'"
echo
echo "To enable or disable xinetd services add \'xinetd=service_name\'"
echo "as the last argument"
echo "Aborting."
exit 1
fi
# If systemctl is installed, use systemctl command; otherwise, use the service/chkconfig commands
if [ -f "/usr/bin/systemctl" ] ; then
service_util="/usr/bin/systemctl"
else
service_util="/sbin/service"
chkconfig_util="/sbin/chkconfig"
fi
# If disable is not specified in arg1, set variables to enable services.
# Otherwise, variables are to be set to disable services.
if [ "$service_state" != 'disable' ] ; then
service_state="enable"
service_operation="start"
chkconfig_state="on"
else
service_state="disable"
service_operation="stop"
chkconfig_state="off"
fi
# If chkconfig_util is not empty, use chkconfig/service commands.
if ! [ "x$chkconfig_util" = x ] ; then
$service_util $service $service_operation
$chkconfig_util --level 0123456 $service $chkconfig_state
else
$service_util $service_operation $service
$service_util $service_state $service
fi
# Test if local variable xinetd is empty using non-bashism.
# If empty, then xinetd is not being used.
if ! [ "x$xinetd" = x ] ; then
grep -qi disable /etc/xinetd.d/$xinetd && \
if ! [ "$service_operation" != 'disable' ] ; then
sed -i "s/disable.*/disable = no/gI" /etc/xinetd.d/$xinetd
else
sed -i "s/disable.*/disable = yes/gI" /etc/xinetd.d/$xinetd
fi
fi
}
service_command enable rsyslog
Remediation Ansible snippet: (show)
Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | enable |
---|
- name: Enable service rsyslog
service:
name="{{item}}"
enabled="yes"
state="started"
with_items:
- rsyslog
tags:
- service_rsyslog_enabled
- medium_severity
- enable_strategy
- low_complexity
- low_disruption
- CCE-80188-6
- NIST-800-53-AU-4(1)
- NIST-800-53-AU-12
|