ANSSI Mapping | Rule Title | Description | Rationale | Variable Setting |
Ensure Users Re-Authenticate for Privilege Escalation - sudo NOPASSWD |
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/ .
|
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 |
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/ .
|
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. |
||
NT28(R5) NT28(R46) |
Ensure rsyslog is Installed |
Rsyslog is installed by default.
The rsyslog package can be installed with the following command:
$ sudo yum install rsyslog |
The rsyslog package provides the rsyslog daemon, which provides system logging services. | |
NT28(R5) NT28(R46) |
Enable rsyslog Service | The 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 |
The rsyslog service must be running in order to provide
logging services, which are essential to system administration.
|
|
Verify Permissions on shadow File |
To properly set the permissions of /etc/shadow , run the command:
$ sudo chmod 0000 /etc/shadow |
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. |
||
Verify Permissions on gshadow File |
To properly set the permissions of /etc/gshadow , run the command:
$ sudo chmod 0000 /etc/gshadow |
The /etc/gshadow file contains group password hashes. Protection of this file
is critical for system security. |
||
Verify Permissions on passwd File |
To properly set the permissions of /etc/passwd , run the command:
$ sudo chmod 0644 /etc/passwd |
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. |
||
Verify Permissions on group File |
To properly set the permissions of /etc/group , run the command:
$ sudo chmod 644 /etc/group |
The /etc/group file contains information regarding groups that are configured
on the system. Protection of this file is important for system security. |
||
Ensure /tmp Located On Separate Partition |
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.
|
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 | 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.
|
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 |
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.
|
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 |
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.
|
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 |
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.
|
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.
|
||
Ensure Log Files Are Owned By Appropriate User | The 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 LOGFILEIf the owner is not root , run the following command to
correct this:
$ sudo chown root LOGFILE |
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 | The 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 LOGFILEIf the owner is not root , run the following command to
correct this:
$ sudo chgrp root LOGFILE |
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 | The 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 LOGFILEIf the permissions are not 600 or more restrictive, run the following command to correct this: $ sudo chmod 0600 LOGFILE |
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. | ||
Ensure Logrotate Runs Periodically | The logrotate utility allows for the automatic rotation of
log files. The frequency of rotation is specified in /etc/logrotate.conf ,
which triggers a cron task. To configure logrotate to run daily, add or correct
the following line in /etc/logrotate.conf :
# rotate log files frequency daily |
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. | ||
Disable Core Dumps for SUID programs |
To set the runtime status of the fs.suid_dumpable kernel parameter,
run the following command:
$ sudo sysctl -w fs.suid_dumpable=0If this is not the system's default value, add the following line to /etc/sysctl.conf :
fs.suid_dumpable = 0 |
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. | ||
Enable Randomized Layout of Virtual Address Space |
To set the runtime status of the kernel.randomize_va_space kernel parameter,
run the following command:
$ sudo sysctl -w kernel.randomize_va_space=2If this is not the system's default value, add the following line to /etc/sysctl.conf :
kernel.randomize_va_space = 2 |
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. |