Rules with anssi Reference in Guide to the Secure Configuration of Oracle Linux 7
| Reference (anssi) |
Rule Title |
Description |
Rationale |
Variable Setting |
| BP28(R1) |
Uninstall Sendmail Package |
Sendmail is not the default mail transfer agent and is
not installed by default.
The sendmail package can be removed with the following command:
$ sudo yum erase sendmail
|
The sendmail software was not developed with security in mind and
its design prevents it from being effectively contained by SELinux. Postfix
should be used instead. |
|
| BP28(R1) |
Uninstall the telnet server |
The telnet daemon should be uninstalled. |
telnet allows clear text communications, and does not protect
any data transmission between client and server. Any confidential data
can be listened and no integrity checking is made.' |
|
| BP28(R4) |
Ensure SELinux State is Enforcing |
The SELinux state should be set to /etc/selinux/config, add or correct the
following line to configure the system to boot into enforcing mode:
SELINUX=
|
Setting the SELinux state to enforcing ensures SELinux is able to confine
potentially compromised processes to the security policy, which is designed to
prevent them from causing damage to the system or further elevating their
privileges. |
|
| BP28(R5) |
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. |
|
| BP28(R5) |
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. |
|
| BP28(R5) |
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. |
|
| BP28(R5) |
Enable rsyslog Service |
The rsyslog service provides syslog-style logging by default on Oracle 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. |
|
| BP28(R5) |
Ensure Log Files Are Owned By Appropriate Group |
The group-owner of all log files written by
rsyslog should be /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 $ sudo chgrp 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. |
|
| BP28(R5) |
Ensure Log Files Are Owned By Appropriate User |
The owner of all log files written by
rsyslog should be /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 $ sudo chown 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. |
|
| BP28(R5) |
Ensure syslog-ng is Installed |
syslog-ng can be installed in replacement of rsyslog.
The syslog-ng-core package can be installed with the following command:
$ sudo yum install syslog-ng-core
|
The syslog-ng-core package provides the syslog-ng daemon, which provides
system logging services. |
|
| BP28(R5) |
Enable syslog-ng Service |
The syslog-ng service (in replacement of rsyslog) provides syslog-style logging by default on Debian.
The syslog-ng service can be enabled with the following command:
$ sudo systemctl enable syslog-ng.service
|
The syslog-ng service must be running in order to provide
logging services, which are essential to system administration. |
|
| BP28(R7) |
Ensure Logs Sent To Remote Host |
To configure rsyslog to send logs to a remote log server,
open /etc/rsyslog.conf and read and understand the last section of the file,
which describes the multiple directives necessary to activate remote
logging.
Along with these other directives, the system can be configured
to forward its logs to a particular log server by
adding or correcting one of the following lines,
substituting
To use UDP for log message delivery:
*.* @
To use TCP for log message delivery:
*.* @@
To use RELP for log message delivery:
*.* :omrelp:
There must be a resolvable DNS CNAME or Alias record set to "" for logs to be sent correctly to the centralized logging utility. |
A log server (loghost) receives syslog messages from one or more
systems. This data can be used as an additional log source in the event a
system is compromised and its local logs are suspect. Forwarding log messages
to a remote loghost also provides system administrators with a centralized
place to view the status of multiple hosts within the enterprise. |
|
| BP28(R08) |
Ensure Software Patches Installed |
If the system is joined to the ULN
or a yum server, run the following command to install updates:
$ sudo yum update
If the system is not configured to use one of these sources, updates (in the form of RPM packages)
can be manually downloaded from the ULN and installed using rpm.
NOTE: U.S. Defense systems are required to be patched within 30 days or sooner as local policy
dictates. |
Installing software updates is a fundamental mitigation against
the exploitation of publicly-known vulnerabilities. If the most
recent security patches and updates are not installed, unauthorized
users may take advantage of weaknesses in the unpatched software. The
lack of prompt attention to patching could result in a system compromise. |
|
| BP28(R10) |
Prefer to use a 64-bit Operating System when supported |
Prefer installation of 64-bit operating systems when the CPU supports it. |
Use of a 64-bit operating system offers a few advantages, like a larger address space range for
Address Space Layout Randomization (ASLR) and systematic presence of No eXecute and Execute Disable (NX/XD) protection bits. |
|
| BP28(R11) |
IOMMU configuration directive |
On x86 architecture supporting VT-d, the IOMMU manages the access control policy between the hardware devices and some
of the system critical units such as the memory. |
On x86 architectures, activating the I/OMMU prevents the system from arbritrary accesses potentially made by
hardware devices. |
|
| BP28(R12) |
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. |
|
| BP28(R12) |
Ensure /boot Located On Separate Partition |
It is recommended that the /boot directory resides on a separate
partition. This makes it easier to apply restrictions e.g. through the
noexec mount option. Eventually, the /boot partition can
be configured not to be mounted automatically with the noauto mount
option. |
The /boot partition contains the kernel and bootloader files.
Access to this partition should be restricted. |
|
| BP28(R12) |
Ensure /var/tmp Located On Separate Partition |
The /var/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 /var/tmp partition is used as temporary storage by many programs.
Placing /var/tmp in its own partition enables the setting of more
restrictive mount options, which can help protect programs which use it. |
|
| BP28(R12) |
Ensure /usr Located On Separate Partition |
It is recommended that the /usr directory resides on a separate
partition. |
The /usr partition contains system software, utilities and files.
Putting it on a separate partition allows limiting its size and applying
restrictions through mount options. |
|
| BP28(R12) |
Ensure /srv Located On Separate Partition |
If a file server (FTP, TFTP...) is hosted locally, create a separate partition
for /srv at installation time (or migrate it later using LVM). If
/srv 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. |
Srv deserves files for local network file server such as FTP. Ensuring
that /srv 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. |
|
| BP28(R12) |
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. |
|
| BP28(R12) |
Ensure /opt Located On Separate Partition |
It is recommended that the /opt directory resides on a separate
partition. |
The /opt partition contains additional software, usually installed
outside the packaging system. Putting this directory on a separate partition
makes it easier to apply restrictions e.g. through the nosuid mount
option. |
|
| BP28(R12) |
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. |
|
| BP28(R12) |
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/. |
|
| BP28(R12) |
Add nodev Option to /tmp |
The nodev mount option can be used to prevent device files from
being created in /tmp. Legitimate character and block devices
should not exist within temporary directories like /tmp.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/tmp. |
The only legitimate location for device files is the /dev directory
located on the root partition. The only exception to this is chroot jails. |
|
| BP28(R12) |
Add noexec Option to /var |
The noexec mount option can be used to prevent binaries from being
executed out of /var.
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/var. |
The /var directory contains variable system data such as logs,
mails and caches. No binaries should be executed from this directory. |
|
| BP28(R12) |
Add nosuid Option to /tmp |
The nosuid mount option can be used to prevent
execution of setuid programs in /tmp. The SUID and SGID permissions
should not be required in these world-writable directories.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/tmp. |
The presence of SUID and SGID executables should be tightly controlled. Users
should not be able to execute SUID or SGID binaries from temporary storage partitions. |
|
| BP28(R12) |
Add nosuid Option to /srv |
The nosuid mount option can be used to prevent
execution of setuid programs in /srv. The SUID and SGID permissions
should not be required in this directory.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/srv. |
The presence of SUID and SGID executables should be tightly controlled. The
/srv directory contains files served by various network services such as FTP. Users should
not be able to execute SUID or SGID binaries from this directory. |
|
| BP28(R12) |
Add nodev Option to Non-Root Local Partitions |
The nodev mount option prevents files from being interpreted as
character or block devices. Legitimate character and block devices should
exist only in the /dev directory on the root partition or within
chroot jails built for system services.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
any non-root local partitions. |
The nodev mount option prevents files from being
interpreted as character or block devices. The only legitimate location
for device files is the /dev directory located on the root partition.
The only exception to this is chroot jails, for which it is not advised
to set nodev on these filesystems. |
|
| BP28(R12) |
Add noexec Option to /var/log |
The noexec mount option can be used to prevent binaries
from being executed out of /var/log.
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/log. |
Allowing users to execute binaries from directories containing log files
such as /var/log should never be necessary in normal operation and
can expose the system to potential compromise. |
|
| BP28(R12) |
Add nodev Option to /home |
The nodev mount option can be used to prevent device files from
being created in /home.
Legitimate character and block devices should exist only in
the /dev directory on the root partition or within chroot
jails built for system services.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/home. |
The only legitimate location for device files is the /dev directory
located on the root partition. The only exception to this is chroot jails. |
|
| BP28(R12) |
Add nosuid Option to /var/tmp |
The nosuid mount option can be used to prevent
execution of setuid programs in /var/tmp. The SUID and SGID permissions
should not be required in these world-writable directories.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/tmp. |
The presence of SUID and SGID executables should be tightly controlled. Users
should not be able to execute SUID or SGID binaries from temporary storage partitions. |
|
| BP28(R12) |
Add noexec Option to /home |
The noexec mount option can be used to prevent binaries from being
executed out of /home.
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/home. |
The /home directory contains data of individual users. Binaries in
this directory should not be considered as trusted and users should not be
able to execute them. |
|
| BP28(R12) |
Add nosuid Option to /opt |
The nosuid mount option can be used to prevent
execution of setuid programs in /opt. The SUID and SGID permissions
should not be required in this directory.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/opt. |
The presence of SUID and SGID executables should be tightly controlled. The
/opt directory contains additional software packages. Users should
not be able to execute SUID or SGID binaries from this directory. |
|
| BP28(R12) |
Add nosuid Option to /var/log |
The nosuid mount option can be used to prevent
execution of setuid programs in /var/log. The SUID and SGID permissions
should not be required in directories containing log files.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/log. |
The presence of SUID and SGID executables should be tightly controlled. Users
should not be able to execute SUID or SGID binaries from partitions
designated for log files. |
|
| BP28(R12) |
Add noexec Option to /tmp |
The noexec mount option can be used to prevent binaries
from being executed out of /tmp.
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/tmp. |
Allowing users to execute binaries from world-writable directories
such as /tmp should never be necessary in normal operation and
can expose the system to potential compromise. |
|
| BP28(R12) |
Add noauto Option to /boot |
The noauto mount option is used to prevent automatic mounting of th
/boot partition.
Add the noauto option to the fourth column of
/etc/fstab for the line which controls mounting of
/boot. |
The /boot partition contains the kernel and the bootloader. Access
to the partition after the boot process finishes should not be needed. Files
contained within this partition can be analysed and gained information can
be used for exploit creation. |
|
| BP28(R12) |
Add nosuid Option to /boot |
The nosuid mount option can be used to prevent
execution of setuid programs in /boot. The SUID and SGID permissions
should not be required on the boot partition.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/boot. |
The presence of SUID and SGID executables should be tightly controlled. Users
should not be able to execute SUID or SGID binaries from boot partitions. |
|
| BP28(R12) |
Add noexec Option to /boot |
The noexec mount option can be used to prevent binaries from being
executed out of /boot.
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/boot. |
The /boot partition contains the kernel and the bootloader. No
binaries should be executed from this partition after the booting process
finishes. |
|
| BP28(R12) |
Add nosuid Option to /home |
The nosuid mount option can be used to prevent
execution of setuid programs in /home. The SUID and SGID permissions
should not be required in these user data directories.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/home. |
The presence of SUID and SGID executables should be tightly controlled. Users
should not be able to execute SUID or SGID binaries from user home directory partitions. |
|
| BP28(R12) |
Add nodev Option to /var/tmp |
The nodev mount option can be used to prevent device files from
being created in /var/tmp. Legitimate character and block devices
should not exist within temporary directories like /var/tmp.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/tmp. |
The only legitimate location for device files is the /dev directory
located on the root partition. The only exception to this is chroot jails. |
|
| BP28(R12) |
Add noexec Option to /var/tmp |
The noexec mount option can be used to prevent binaries
from being executed out of /var/tmp.
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/tmp. |
Allowing users to execute binaries from world-writable directories
such as /var/tmp should never be necessary in normal operation and
can expose the system to potential compromise. |
|
| BP28(R13) |
Verify that local System.map file (if exists) is readable only by root |
Files containing sensitive informations should be protected by restrictive
permissions. Most of the time, there is no need that these files need to be read by any non-root user
To properly set the permissions of /boot/System.map-*, run the command:
$ sudo chmod 0600 /boot/System.map-*
|
The System.map file contains information about kernel symbols and
can give some hints to generate local exploitation. |
|
| BP28(R15) |
Ensure gpgcheck Enabled for All yum Package Repositories |
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
|
Verifying the authenticity of the software prior to installation validates
the integrity of the patch or upgrade received from a vendor. This ensures
the software has not been tampered with and that it has been provided by a
trusted vendor. Self-signed certificates are disallowed by this
requirement. Certificates used to verify the software must be from an
approved Certificate Authority (CA)." |
|
| BP28(R15) |
Ensure gpgcheck Enabled In Main yum Configuration |
The gpgcheck option controls whether
RPM packages' signatures are always checked prior to installation.
To configure yum to check package signatures before installing
them, ensure the following line appears in /etc/yum.conf in
the [main] section:
gpgcheck=1
|
Changes to any software components can have significant effects on the
overall security of the operating system. This requirement ensures the
software has not been tampered with and that it has been provided by a
trusted vendor.
Accordingly, patches, service packs, device drivers, or operating system
components must be signed with a certificate recognized and approved by the
organization.
Verifying the authenticity of the software prior to installation
validates the integrity of the patch or upgrade received from a vendor.
This ensures the software has not been tampered with and that it has been
provided by a trusted vendor. Self-signed certificates are disallowed by
this requirement. Certificates used to verify the software must be from an
approved Certificate Authority (CA). |
|
| BP28(R15) |
Ensure gpgcheck Enabled for Local Packages |
yum should be configured to verify the signature(s) of local packages
prior to installation. To configure yum to verify signatures of local
packages, set the localpkg_gpgcheck to 1 in /etc/yum.conf. |
Changes to any software components can have significant effects to the overall security
of the operating system. This requirement ensures the software has not been tampered and
has been provided by a trusted vendor.
Accordingly, patches, service packs, device drivers, or operating system components must
be signed with a certificate recognized and approved by the organization. |
|
| BP28(R17) |
Set Boot Loader Password in grub2 |
The grub2 boot loader should have a superuser account and password
protection enabled to protect boot-time settings.
Since plaintext passwords are a security risk, generate a hash for the password
by running the following command:
$ grub2-setpassword
When prompted, enter the password that was selected.
Once the superuser password has been added,
update the
grub.cfg file by running:
grub2-mkconfig -o /boot/grub2/grub.cfg
|
Password protection on the boot loader configuration ensures
users with physical access cannot trivially alter
important bootloader settings. These include which kernel to use,
and whether to enter single-user mode. |
|
| BP28(R17) |
Set the Boot Loader Admin Username to a Non-Default Value |
The grub2 boot loader should have a superuser account and password
protection enabled to protect boot-time settings.
To maximize the protection, select a password-protected superuser account with unique name, and modify the
/etc/grub.d/01_users configuration file to reflect the account name change.
Do not to use common administrator account names like root,
admin, or administrator for the grub2 superuser account.
Change the superuser to a different username (The default is 'root').
$ sed -i 's/\(set superuser=\).*/\1"<unique user ID>"/g' /etc/grub.d/01_users
Once the superuser account has been added,
update the
grub.cfg file by running:
grub2-mkconfig -o /boot/grub2/grub.cfg
|
Having a non-default grub superuser username makes password-guessing attacks less effective. |
|
| BP28(R17) |
Set the UEFI Boot Loader Admin Username to a Non-Default Value |
The grub2 boot loader should have a superuser account and password
protection enabled to protect boot-time settings.
To maximize the protection, select a password-protected superuser account with unique name, and modify the
/etc/grub.d/01_users configuration file to reflect the account name change.
It is highly suggested not to use common administrator account names like root,
admin, or administrator for the grub2 superuser account.
Change the superuser to a different username (The default is 'root').
$ sed -i 's/\(set superuser=\).*/\1"<unique user ID>"/g' /etc/grub.d/01_users
Once the superuser account has been added,
update the
grub.cfg file by running:
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
|
Having a non-default grub superuser username makes password-guessing attacks less effective. |
|
| BP28(R17) |
Set the UEFI Boot Loader Password |
The grub2 boot loader should have a superuser account and password
protection enabled to protect boot-time settings.
Since plaintext passwords are a security risk, generate a hash for the password
by running the following command:
$ grub2-setpassword
When prompted, enter the password that was selected.
Once the superuser password has been added,
update the
grub.cfg file by running:
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
|
Password protection on the boot loader configuration ensures
users with physical access cannot trivially alter
important bootloader settings. These include which kernel to use,
and whether to enter single-user mode. |
|
| BP28(R19) |
Direct root Logins Not Allowed |
To further limit access to the root account, administrators
can disable root logins at the console by editing the /etc/securetty file.
This file lists all devices the root user is allowed to login to. If the file does
not exist at all, the root user can login through any communication device on the
system, whether via the console or via a raw network interface. This is dangerous
as user can login to the system as root via Telnet, which sends the password in
plain text over the network. By default, Oracle Linux 7's
/etc/securetty file only allows the root user to login at the console
physically attached to the system. To prevent root from logging in, remove the
contents of this file. To prevent direct root logins, remove the contents of this
file by typing the following command:
$ sudo echo > /etc/securetty
|
Disabling direct root logins ensures proper accountability and multifactor
authentication to privileged accounts. Users will first login, then escalate
to privileged (root) access via su / sudo. This is required for FISMA Low
and FISMA Moderate systems. |
|
| BP28(R19) |
Disable SSH Root Login |
The root user should never be allowed to login to a
system directly over a network.
To disable root login via SSH, add or correct the following line
in /etc/ssh/sshd_config:
PermitRootLogin no
|
Even though the communications channel may be encrypted, an additional layer of
security is gained by extending the policy of not logging directly on as root.
In addition, logging in with a user-specific account provides individual
accountability of actions performed on the system and also helps to minimize
direct attack attempts on root's password. |
|
| BP28(R22) |
Disable Kernel Parameter for Accepting Source-Routed Packets on IPv6 Interfaces by Default |
To set the runtime status of the net.ipv6.conf.default.accept_source_route kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.default.accept_source_route=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv6.conf.default.accept_source_route = 0
|
Source-routed packets allow the source of the packet to suggest routers
forward the packet along a different path than configured on the router, which can
be used to bypass network security measures. This requirement applies only to the
forwarding of source-routerd traffic, such as when IPv6 forwarding is enabled and
the system is functioning as a router.
Accepting source-routed packets in the IPv6 protocol has few legitimate
uses. It should be disabled unless it is absolutely required. |
|
| BP28(R22) |
Disable Kernel Parameter for Accepting Source-Routed Packets on all IPv6 Interfaces |
To set the runtime status of the net.ipv6.conf.all.accept_source_route kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.all.accept_source_route=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv6.conf.all.accept_source_route = 0
|
Source-routed packets allow the source of the packet to suggest routers
forward the packet along a different path than configured on the router, which can
be used to bypass network security measures. This requirement applies only to the
forwarding of source-routerd traffic, such as when IPv6 forwarding is enabled and
the system is functioning as a router.
Accepting source-routed packets in the IPv6 protocol has few legitimate
uses. It should be disabled unless it is absolutely required. |
|
| BP28(R22) |
Disable Accepting ICMP Redirects for All IPv6 Interfaces |
To set the runtime status of the net.ipv6.conf.all.accept_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.all.accept_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv6.conf.all.accept_redirects = 0
|
An illicit ICMP redirect message could result in a man-in-the-middle attack. |
|
| BP28(R22) |
Disable Kernel Parameter for Accepting ICMP Redirects by Default on IPv6 Interfaces |
To set the runtime status of the net.ipv6.conf.default.accept_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.default.accept_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv6.conf.default.accept_redirects = 0
|
An illicit ICMP redirect message could result in a man-in-the-middle attack. |
|
| BP28(R22) |
Disable Kernel Parameter for Accepting Source-Routed Packets on IPv4 Interfaces by Default |
To set the runtime status of the net.ipv4.conf.default.accept_source_route kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.default.accept_source_route=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.default.accept_source_route = 0
|
Source-routed packets allow the source of the packet to suggest routers
forward the packet along a different path than configured on the router,
which can be used to bypass network security measures.
Accepting source-routed packets in the IPv4 protocol has few legitimate
uses. It should be disabled unless it is absolutely required, such as when
IPv4 forwarding is enabled and the system is legitimately functioning as a
router. |
|
| BP28(R22) |
Enable Kernel Parameter to Ignore Bogus ICMP Error Responses on IPv4 Interfaces |
To set the runtime status of the net.ipv4.icmp_ignore_bogus_error_responses kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.icmp_ignore_bogus_error_responses = 1
|
Ignoring bogus ICMP error responses reduces
log size, although some activity would not be logged. |
|
| BP28(R22) |
Disable Kernel Parameter for Accepting ICMP Redirects by Default on IPv4 Interfaces |
To set the runtime status of the net.ipv4.conf.default.accept_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.default.accept_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.default.accept_redirects = 0
|
ICMP redirect messages are used by routers to inform hosts that a more
direct route exists for a particular destination. These messages modify the
host's route table and are unauthenticated. An illicit ICMP redirect
message could result in a man-in-the-middle attack.
This feature of the IPv4 protocol has few legitimate uses. It should
be disabled unless absolutely required. |
|
| BP28(R22) |
Enable Kernel Parameter to Use Reverse Path Filtering on all IPv4 Interfaces by Default |
To set the runtime status of the net.ipv4.conf.default.rp_filter kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.default.rp_filter=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.default.rp_filter = 1
|
Enabling reverse path filtering drops packets with source addresses
that should not have been able to be received on the interface they were
received on. It should not be used on systems which are routers for
complicated networks, but is helpful for end hosts and routers serving small
networks. |
|
| BP28(R22) |
Disable Kernel Parameter for Accepting Secure ICMP Redirects on all IPv4 Interfaces |
To set the runtime status of the net.ipv4.conf.all.secure_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.secure_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.secure_redirects = 0
|
Accepting "secure" ICMP redirects (from those gateways listed as
default gateways) has few legitimate uses. It should be disabled unless it is
absolutely required. |
|
| BP28(R22) |
Disable Kernel Parameter for Accepting Source-Routed Packets on all IPv4 Interfaces |
To set the runtime status of the net.ipv4.conf.all.accept_source_route kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.accept_source_route=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.accept_source_route = 0
|
Source-routed packets allow the source of the packet to suggest routers
forward the packet along a different path than configured on the router,
which can be used to bypass network security measures. This requirement
applies only to the forwarding of source-routerd traffic, such as when IPv4
forwarding is enabled and the system is functioning as a router.
Accepting source-routed packets in the IPv4 protocol has few legitimate
uses. It should be disabled unless it is absolutely required. |
|
| BP28(R22) |
Disable Accepting ICMP Redirects for All IPv4 Interfaces |
To set the runtime status of the net.ipv4.conf.all.accept_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.accept_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.accept_redirects = 0
|
ICMP redirect messages are used by routers to inform hosts that a more
direct route exists for a particular destination. These messages modify the
host's route table and are unauthenticated. An illicit ICMP redirect
message could result in a man-in-the-middle attack.
This feature of the IPv4 protocol has few legitimate uses. It should be
disabled unless absolutely required." |
|
| BP28(R22) |
Enable Kernel Parameter to Log Martian Packets on all IPv4 Interfaces |
To set the runtime status of the net.ipv4.conf.all.log_martians kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.log_martians=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.log_martians = 1
|
The presence of "martian" packets (which have impossible addresses)
as well as spoofed packets, source-routed packets, and redirects could be a
sign of nefarious network activity. Logging these packets enables this activity
to be detected. |
|
| BP28(R22) |
Enable Kernel Parameter to Use Reverse Path Filtering on all IPv4 Interfaces |
To set the runtime status of the net.ipv4.conf.all.rp_filter kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.rp_filter=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.rp_filter = 1
|
Enabling reverse path filtering drops packets with source addresses
that should not have been able to be received on the interface they were
received on. It should not be used on systems which are routers for
complicated networks, but is helpful for end hosts and routers serving small
networks. |
|
| BP28(R22) |
Configure Kernel Parameter for Accepting Secure Redirects By Default |
To set the runtime status of the net.ipv4.conf.default.secure_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.default.secure_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.default.secure_redirects = 0
|
Accepting "secure" ICMP redirects (from those gateways listed as
default gateways) has few legitimate uses. It should be disabled unless it is
absolutely required. |
|
| BP28(R22) |
Enable Kernel Parameter to Use TCP Syncookies on IPv4 Interfaces |
To set the runtime status of the net.ipv4.tcp_syncookies kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.tcp_syncookies=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.tcp_syncookies = 1
|
A TCP SYN flood attack can cause a denial of service by filling a
system's TCP connection table with connections in the SYN_RCVD state.
Syncookies can be used to track a connection when a subsequent ACK is received,
verifying the initiator is attempting a valid connection and is not a flood
source. This feature is activated when a flood condition is detected, and
enables the system to continue servicing valid connection requests. |
|
| BP28(R22) |
Disable Kernel Parameter for IP Forwarding on IPv4 Interfaces |
To set the runtime status of the net.ipv4.ip_forward kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.ip_forward=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.ip_forward = 0
|
Routing protocol daemons are typically used on routers to exchange
network topology information with other routers. If this capability is used when
not required, system network information may be unnecessarily transmitted across
the network. |
|
| BP28(R22) |
Disable Kernel Parameter for Sending ICMP Redirects on all IPv4 Interfaces |
To set the runtime status of the net.ipv4.conf.all.send_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.send_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.send_redirects = 0
|
ICMP redirect messages are used by routers to inform hosts that a more
direct route exists for a particular destination. These messages contain information
from the system's route table possibly revealing portions of the network topology.
The ability to send ICMP redirects is only appropriate for systems acting as routers. |
|
| BP28(R22) |
Disable Kernel Parameter for Sending ICMP Redirects on all IPv4 Interfaces by Default |
To set the runtime status of the net.ipv4.conf.default.send_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.default.send_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.default.send_redirects = 0
|
ICMP redirect messages are used by routers to inform hosts that a more
direct route exists for a particular destination. These messages contain information
from the system's route table possibly revealing portions of the network topology.
The ability to send ICMP redirects is only appropriate for systems acting as routers. |
|
| BP28(R23) |
Enable Kernel Parameter to Enforce DAC on Symlinks |
To set the runtime status of the fs.protected_symlinks kernel parameter, run the following command: $ sudo sysctl -w fs.protected_symlinks=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: fs.protected_symlinks = 1
|
By enabling this kernel parameter, symbolic links are permitted to be followed
only when outside a sticky world-writable directory, or when the UID of the
link and follower match, or when the directory owner matches the symlink's owner.
Disallowing such symlinks helps mitigate vulnerabilities based on insecure file system
accessed by privileged programs, avoiding an exploitation vector exploiting unsafe use of
open() or creat(). |
|
| BP28(R23) |
Enable Kernel Parameter to Enforce DAC on Hardlinks |
To set the runtime status of the fs.protected_hardlinks kernel parameter, run the following command: $ sudo sysctl -w fs.protected_hardlinks=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: fs.protected_hardlinks = 1
|
By enabling this kernel parameter, users can no longer create soft or hard links to
files which they do not own. Disallowing such hardlinks mitigate vulnerabilities
based on insecure file system accessed by privileged programs, avoiding an
exploitation vector exploiting unsafe use of open() or creat(). |
|
| BP28(R23) |
Restrict Access to Kernel Message Buffer |
To set the runtime status of the kernel.dmesg_restrict kernel parameter, run the following command: $ sudo sysctl -w kernel.dmesg_restrict=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: kernel.dmesg_restrict = 1
|
Unprivileged access to the kernel syslog can expose sensitive kernel
address information. |
|
| BP28(R23) |
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=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 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. |
|
| BP28(R23) |
Restrict Exposed Kernel Pointer Addresses Access |
To set the runtime status of the kernel.kptr_restrict kernel parameter, run the following command: $ sudo sysctl -w kernel.kptr_restrict=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: kernel.kptr_restrict = 1
|
Exposing kernel pointers (through procfs or seq_printf()) exposes
kernel writeable structures that can contain functions pointers. If a write vulnereability occurs
in the kernel allowing a write access to any of this structure, the kernel can be compromise. This
option disallow any program withtout the CAP_SYSLOG capability from getting the kernel pointers addresses,
replacing them with 0. |
|
| BP28(R23) |
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=2
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 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. |
|
| BP28(R25) |
Restrict usage of ptrace to descendant processes |
To set the runtime status of the kernel.yama.ptrace_scope kernel parameter, run the following command: $ sudo sysctl -w kernel.yama.ptrace_scope=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: kernel.yama.ptrace_scope = 1
|
Unrestricted usage of ptrace allows compromised binaries to run ptrace
on another processes of the user. Like this, the attacker can steal
sensitive information from the target processes (e.g. SSH sessions, web browser, ...)
without any additional assistance from the user (i.e. without resorting to phishing).
|
|
| BP28(R29) |
Set Interactive Session Timeout |
Setting the TMOUT option in /etc/profile ensures that
all user sessions will terminate based on inactivity. The TMOUT
setting in /etc/profile should read as follows:
TMOUT=
|
Terminating an idle session within a short time period reduces
the window of opportunity for unauthorized personnel to take control of a
management session enabled on the console or console port that has been
left unattended. |
|
| BP28(R29) |
Set SSH Idle Timeout Interval |
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
The timeout interval is given in seconds. For example, have a timeout
of 10 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 in /etc/ssh/sshd_config. Keep in mind that
some processes may stop SSH from correctly detecting that the user is idle. |
Terminating an idle ssh session within a short time period reduces the window of
opportunity for unauthorized personnel to take control of a management session
enabled on the console or console port that has been let unattended. |
|
| BP28(R32) |
Set Password Hashing Algorithm in /etc/login.defs |
In /etc/login.defs, add or correct the following line to ensure
the system will use SHA-512 as the hashing algorithm:
ENCRYPT_METHOD SHA512
|
Passwords need to be protected at all times, and encryption is the standard method for protecting passwords.
If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords
that are encrypted with a weak algorithm are no more protected than if they are kept in plain text.
Using a stronger hashing algorithm makes password cracking attacks more difficult. |
|
| BP28(R32) |
Set number of Password Hashing Rounds - password-auth |
Configure the number or rounds for the password hashing algorithm. This can be
accomplished by using the rounds option for the pam_unix PAM module.
In file /etc/pam.d/password-auth append rounds=
to the pam_unix.so file, as shown below:
password sufficient pam_unix.so ...existing_options... rounds=
The system's default number of rounds is 5000. |
Using a higher number of rounds makes password cracking attacks more difficult. |
|
| BP28(R32) |
Set number of Password Hashing Rounds - system-auth |
Configure the number or rounds for the password hashing algorithm. This can be
accomplished by using the rounds option for the pam_unix PAM module.
In file /etc/pam.d/system-auth append rounds=
to the pam_unix.so file, as shown below:
password sufficient pam_unix.so ...existing_options... rounds=
The system's default number of rounds is 5000. |
Using a higher number of rounds makes password cracking attacks more difficult. |
|
| BP28(R35) |
Ensure the Default Umask is Set Correctly in login.defs |
To ensure the default umask controlled by /etc/login.defs is set properly,
add or correct the UMASK setting in /etc/login.defs to read as follows:
UMASK
|
The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read and
written to by unauthorized users. |
|
| BP28(R35) |
Ensure the Default Umask is Set Correctly in /etc/profile |
To ensure the default umask controlled by /etc/profile is set properly,
add or correct the umask setting in /etc/profile to read as follows:
umask
|
The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read or
written to by unauthorized users. |
|
| BP28(R36) |
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 LOGFILE
If 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. |
|
| BP28(R36) |
Verify Permissions on group File |
To properly set the permissions of /etc/passwd, run the command:
$ sudo chmod 0644 /etc/passwd
|
The /etc/group file contains information regarding groups that are configured
on the system. Protection of this file is important for system security. |
|
| BP28(R36) |
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. |
|
| BP28(R36) |
Verify User Who Owns gshadow File |
To properly set the owner of /etc/gshadow, run the command: $ sudo chown root /etc/gshadow
|
The /etc/gshadow file contains group password hashes. Protection of this file
is critical for system security. |
|
| BP28(R36) |
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. |
|
| BP28(R36) |
Verify User Who Owns shadow File |
To properly set the owner of /etc/shadow, run the command: $ sudo chown root /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. |
|
| BP28(R36) |
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. |
|
| BP28(R37) |
Ensure All SGID Executables Are Authorized |
The SGID (set group id) bit should be set only on files that were
installed via authorized means. A straightforward means of identifying
unauthorized SGID files is determine if any were not installed as part of an
RPM package, which is cryptographically verified. Investigate the origin
of any unpackaged SGID files.
This configuration check considers authorized SGID files which were installed via RPM.
It is assumed that when an individual has sudo access to install an RPM
and all packages are signed with an organizationally-recognized GPG key,
the software should be considered an approved package on the system.
Any SGID file not deployed through an RPM will be flagged for further review. |
Executable files with the SGID permission run with the privileges of
the owner of the file. SGID files of uncertain provenance could allow for
unprivileged users to elevate privileges. The presence of these files should be
strictly controlled on the system. |
|
| BP28(R37) |
Ensure All SUID Executables Are Authorized |
The SUID (set user id) bit should be set only on files that were
installed via authorized means. A straightforward means of identifying
unauthorized SUID files is determine if any were not installed as part of an
RPM package, which is cryptographically verified. Investigate the origin
of any unpackaged SUID files.
This configuration check considers authorized SUID files which were installed via RPM.
It is assumed that when an individual has sudo access to install an RPM
and all packages are signed with an organizationally-recognized GPG key,
the software should be considered an approved package on the system.
Any SUID file not deployed through an RPM will be flagged for further review. |
Executable files with the SUID permission run with the privileges of
the owner of the file. SUID files of uncertain provenance could allow for
unprivileged users to elevate privileges. The presence of these files should be
strictly controlled on the system. |
|
| BP28(R38) |
Ensure All SGID Executables Are Authorized |
The SGID (set group id) bit should be set only on files that were
installed via authorized means. A straightforward means of identifying
unauthorized SGID files is determine if any were not installed as part of an
RPM package, which is cryptographically verified. Investigate the origin
of any unpackaged SGID files.
This configuration check considers authorized SGID files which were installed via RPM.
It is assumed that when an individual has sudo access to install an RPM
and all packages are signed with an organizationally-recognized GPG key,
the software should be considered an approved package on the system.
Any SGID file not deployed through an RPM will be flagged for further review. |
Executable files with the SGID permission run with the privileges of
the owner of the file. SGID files of uncertain provenance could allow for
unprivileged users to elevate privileges. The presence of these files should be
strictly controlled on the system. |
|
| BP28(R38) |
Ensure All SUID Executables Are Authorized |
The SUID (set user id) bit should be set only on files that were
installed via authorized means. A straightforward means of identifying
unauthorized SUID files is determine if any were not installed as part of an
RPM package, which is cryptographically verified. Investigate the origin
of any unpackaged SUID files.
This configuration check considers authorized SUID files which were installed via RPM.
It is assumed that when an individual has sudo access to install an RPM
and all packages are signed with an organizationally-recognized GPG key,
the software should be considered an approved package on the system.
Any SUID file not deployed through an RPM will be flagged for further review. |
Executable files with the SUID permission run with the privileges of
the owner of the file. SUID files of uncertain provenance could allow for
unprivileged users to elevate privileges. The presence of these files should be
strictly controlled on the system. |
|
| BP28(R39) |
Configure Polyinstantiation of /var/tmp Directories |
To configure polyinstantiated /tmp directories, first create the parent directories
which will hold the polyinstantiation child directories. Use the following command:
$ sudo mkdir --mode 000 /var/tmp/tmp-inst
Then, add the following entry to /etc/security/namespace.conf:
/var/tmp /var/tmp/tmp-inst/ level root,adm
|
Polyinstantiation of temporary directories is a proactive security measure
which reduces chances of attacks that are made possible by /var/tmp
directories being world-writable. |
|
| BP28(R39) |
Configure Polyinstantiation of /tmp Directories |
To configure polyinstantiated /tmp directories, first create the parent directories
which will hold the polyinstantiation child directories. Use the following command:
$ sudo mkdir --mode 000 /tmp/tmp-inst
Then, add the following entry to /etc/security/namespace.conf:
/tmp /tmp/tmp-inst/ level root,adm
|
Polyinstantiation of temporary directories is a proactive security measure
which reduces chances of attacks that are made possible by /tmp
directories being world-writable. |
|
| BP28(R40) |
Ensure All World-Writable Directories Are Owned by root user |
All directories in local partitions which are world-writable should be owned
by root. If any world-writable directories are not owned by root, this
should be investigated. Following this, the files should be deleted or
assigned to root user. |
Allowing a user account to own a world-writable directory is
undesirable because it allows the owner of that directory to remove
or replace any files that may be placed in the directory by other
users. |
|
| BP28(R43) |
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. |
|
| BP28(R46) |
Ensure Log Files Are Owned By Appropriate Group |
The group-owner of all log files written by
rsyslog should be /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 $ sudo chgrp 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. |
|
| BP28(R46) |
Ensure Log Files Are Owned By Appropriate User |
The owner of all log files written by
rsyslog should be /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 $ sudo chown 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. |
|
| BP28(R46) |
Ensure syslog-ng is Installed |
syslog-ng can be installed in replacement of rsyslog.
The syslog-ng-core package can be installed with the following command:
$ sudo yum install syslog-ng-core
|
The syslog-ng-core package provides the syslog-ng daemon, which provides
system logging services. |
|
| BP28(R46) |
Enable syslog-ng Service |
The syslog-ng service (in replacement of rsyslog) provides syslog-style logging by default on Debian.
The syslog-ng service can be enabled with the following command:
$ sudo systemctl enable syslog-ng.service
|
The syslog-ng service must be running in order to provide
logging services, which are essential to system administration. |
|
| BP28(R47) |
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/. |
|
| BP28(R49) |
Configure System to Forward All Mail For The Root Account |
Make sure that mails delivered to root user are forwarded to a monitored
email address. Make sure that the address
is a valid email address
reachable from the system in question. Use the following command to
configure the alias:
$ sudo echo "root: " >> /etc/aliases
$ sudo newaliases
|
A number of system services utilize email messages sent to the root user to
notify system administrators of active or impending issues. These messages must
be forwarded to at least one monitored email address. |
|
| BP28(R50) |
Ensure the audit Subsystem is Installed |
The audit package should be installed. |
The auditd service is an access monitoring and accounting daemon, watching system calls to audit any access, in comparison with potential local access control policy such as SELinux policy. |
|
| BP28(R50) |
Install the cron service |
The Cron service should be installed. |
The cron service allow periodic job execution, needed for almost all administrative tasks and services (software update, log rotating, etc.). Access to cron service should be restricted to administrative accounts only. |
|
| BP28(R51) |
Install AIDE |
The aide package can be installed with the following command:
$ sudo yum install aide
|
The AIDE package must be installed if it is to be available for integrity checking. |
|
| BP28(R51) |
Configure AIDE to Verify Extended Attributes |
By default, the xattrs option is added to the FIPSR ruleset in AIDE.
If using a custom ruleset or the xattrs option is missing, add xattrs
to the appropriate ruleset.
For example, add xattrs to the following line in /etc/aide.conf:
FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256
AIDE rules can be configured in multiple ways; this is merely one example that is already
configured by default. |
Extended attributes in file systems are used to contain arbitrary data and file metadata
with security implications. |
|
| BP28(R51) |
Configure AIDE to Verify Access Control Lists (ACLs) |
By default, the acl option is added to the FIPSR ruleset in AIDE.
If using a custom ruleset or the acl option is missing, add acl
to the appropriate ruleset.
For example, add acl to the following line in /etc/aide.conf:
FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256
AIDE rules can be configured in multiple ways; this is merely one example that is already
configured by default. |
ACLs can provide permissions beyond those permitted through the file mode and must be
verified by the file integrity tools. |
|
| BP28(R51) |
Configure Notification of Post-AIDE Scan Details |
AIDE should notify appropriate personnel of the details of a scan after the scan has been run.
If AIDE has already been configured for periodic execution in /etc/crontab, append the
following line to the existing AIDE line:
| /bin/mail -s "$(hostname) - AIDE Integrity Check" root@localhost
Otherwise, add the following line to /etc/crontab:
05 4 * * * root /usr/sbin/aide --check | /bin/mail -s "$(hostname) - AIDE Integrity Check" root@localhost
AIDE can be executed periodically through other means; this is merely one example. |
Unauthorized changes to the baseline configuration could make the system vulnerable
to various attacks or allow unauthorized access to the operating system. Changes to
operating system configurations can have unintended side effects, some of which may
be relevant to security.
Detecting such changes and providing an automated response can help avoid unintended,
negative consequences that could ultimately affect the security state of the operating
system. The operating system's Information Management Officer (IMO)/Information System
Security Officer (ISSO) and System Administrators (SAs) must be notified via email and/or
monitoring system trap when there is an unauthorized modification of a configuration item. |
|
| BP28(R51) |
Configure Periodic Execution of AIDE |
At a minimum, AIDE should be configured to run a weekly scan.
To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab:
05 4 * * * root /usr/sbin/aide --check
To implement a weekly execution of AIDE at 4:05am using cron, add the following line to /etc/crontab:
05 4 * * 0 root /usr/sbin/aide --check
AIDE can be executed periodically through other means; this is merely one example.
The usage of cron's special time codes, such as @daily and
@weekly is acceptable. |
By default, AIDE does not install itself for periodic execution. Periodically
running AIDE is necessary to reveal unexpected changes in installed files.
Unauthorized changes to the baseline configuration could make the system vulnerable
to various attacks or allow unauthorized access to the operating system. Changes to
operating system configurations can have unintended side effects, some of which may
be relevant to security.
Detecting such changes and providing an automated response can help avoid unintended,
negative consequences that could ultimately affect the security state of the operating
system. The operating system's Information Management Officer (IMO)/Information System
Security Officer (ISSO) and System Administrators (SAs) must be notified via email and/or
monitoring system trap when there is an unauthorized modification of a configuration item. |
|
| BP28(R51) |
Build and Test AIDE Database |
Run the following command to generate a new database:
$ sudo /usr/sbin/aide --init
By default, the database will be written to the file /var/lib/aide/aide.db.new.gz.
Storing the database, the configuration file /etc/aide.conf, and the binary
/usr/sbin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity.
The newly-generated database can be installed as follows:
$ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
To initiate a manual check, run the following command:
$ sudo /usr/sbin/aide --check
If this check produces any unexpected output, investigate. |
For AIDE to be effective, an initial database of "known-good" information about files
must be captured and it should be able to be verified against the installed files. |
|
| BP28(R58) |
Ensure Privileged Escalated Commands Cannot Execute Other Commands - sudo NOEXEC |
The sudo NOEXEC tag, when specified, prevents user executed
commands from executing other commands, like a shell for example.
This should be enabled by making sure that the NOEXEC tag exists in
/etc/sudoers configuration file or any sudo configuration snippets
in /etc/sudoers.d/. |
Restricting the capability of sudo allowed commands to execute sub-commands
prevents users from running programs with privileges they wouldn't have otherwise. |
|
| BP28(R58) |
Ensure Only Users Logged In To Real tty Can Execute Sudo - sudo requiretty |
The sudo requiretty tag, when specified, will only execute sudo
commands from users logged in to a real tty.
This should be enabled by making sure that the requiretty tag exists in
/etc/sudoers configuration file or any sudo configuration snippets
in /etc/sudoers.d/. |
Restricting the use cases in which a user is allowed to execute sudo commands
reduces the attack surface. |
|
| BP28(R58) |
Ensure Only Users Logged In To Real tty Can Execute Sudo - sudo use_pty |
The sudo use_pty tag, when specified, will only execute sudo
commands from users logged in to a real tty.
This should be enabled by making sure that the use_pty tag exists in
/etc/sudoers configuration file or any sudo configuration snippets
in /etc/sudoers.d/. |
Requiring that sudo commands be run in a pseudo-terminal can prevent an attacker from retaining
access to the user's terminal after the main program has finished executing. |
|
| BP28(R59) |
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. |
|
| BP28(R59) |
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. |
|
| BP28(R60) |
Don't target root user in the sudoers file |
The targeted users of a user specification should be, as much as possible, non privileged users (i.e.: non-root).
User specifications have to explicitly list the runas spec (i.e. the list of target users that can be impersonated), and ALL or root should not be used. |
It is common that the command to be executed does not require superuser rights (editing a file
whose the owner is not root, sending a signal to an unprivileged process,etc.). In order to limit
any attempt of privilege escalation through a command, it is better to apply normal user rights. |
|
| BP28(R61) |
Don't define allowed commands in sudoers by means of exclusion |
Policies applied by sudo through the sudoers file should not involve negation.
Each user specification in the sudoers file contains a comma-delimited list of command specifications.
The definition can make use glob patterns, as well as of negations.
Indirect definition of those commands by means of exclusion of a set of commands is trivial to bypass, so it is not allowed to use such constructs. |
Specifying access right using negation is inefficient and can be easily circumvented.
For example, it is expected that a specification like
# To avoid absolutely , this rule can be easily circumvented!
user ALL = ALL ,!/ bin/sh
prevents the execution of the shell
but that’s not the case: just copy the binary /bin/sh to a different name to make it executable
again through the rule keyword ALL. |
|
| BP28(R63) |
Explicit arguments in sudo specifications |
All commands in the sudoers file must strictly specify the arguments allowed to be used for a given user.
If the command is supposed to be executed only without arguments, pass "" as an argument in the corresponding user specification. |
Any argument can modify quite significantly the behavior of a program, whether regarding the
realized operation (read, write, delete, etc.) or accessed resources (path in a file system tree). To
avoid any possibility of misuse of a command by a user, the ambiguities must be removed at the
level of its specification.
For example, on some systems, the kernel messages are only accessible by root.
If a user nevertheless must have the privileges to read them, the argument of the dmesg command has to be restricted
in order to prevent the user from flushing the buffer through the -c option:
user ALL = dmesg ""
|
|
| BP28(R66) |
Configure SELinux Policy |
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=
Other policies, such as mls, provide additional security labeling
and greater confinement but are not compatible with many general-purpose
use cases. |
Setting the SELinux policy to targeted or a more specialized policy
ensures the system will confine processes that are likely to be
targeted for exploitation, such as network or system services.
Note: During the development or debugging of SELinux modules, it is common to
temporarily place non-production systems in permissive mode. In such
temporary cases, SELinux policies should be developed, and once work
is completed, the system should be reconfigured to
|
|
| BP28(R66) |
Ensure SELinux State is Enforcing |
The SELinux state should be set to /etc/selinux/config, add or correct the
following line to configure the system to boot into enforcing mode:
SELINUX=
|
Setting the SELinux state to enforcing ensures SELinux is able to confine
potentially compromised processes to the security policy, which is designed to
prevent them from causing damage to the system or further elevating their
privileges. |
|
| BP28(R67) |
disable the selinuxuser_execstack SELinux Boolean |
By default, the SELinux boolean selinuxuser_execstack is enabled.
This setting should be disabled as unconfined executables should not be able
to make their stack executable.
To disable the selinuxuser_execstack SELinux boolean, run the following command:
$ sudo setsebool -P selinuxuser_execstack off
|
|
|
| BP28(R67) |
Disable the selinuxuser_execheap SELinux Boolean |
By default, the SELinux boolean selinuxuser_execheap is disabled.
If this setting is enabled, it should be disabled.
To disable the selinuxuser_execheap SELinux boolean, run the following command:
$ sudo setsebool -P selinuxuser_execheap off
|
|
|
| NT007(R1) |
Allow Only SSH Protocol 2 |
Only SSH protocol version 2 connections should be
permitted. The default setting in
/etc/ssh/sshd_config is correct, and can be
verified by ensuring that the following
line appears:
Protocol 2
|
SSH protocol version 1 is an insecure implementation of the SSH protocol and
has many well-known vulnerability exploits. Exploits of the SSH daemon could provide
immediate root access to the system. |
|
| NT007(R02) |
Uninstall the ssl compliant telnet server |
The telnet daemon, even with ssl support, should be uninstalled. |
telnet, even with ssl support, should not be installed.
When remote shell is required, up-to-date ssh daemon can be used. |
|
| NT007(R03) |
Uninstall the telnet server |
The telnet daemon should be uninstalled. |
telnet allows clear text communications, and does not protect
any data transmission between client and server. Any confidential data
can be listened and no integrity checking is made.' |
|
| NT007(R03) |
Uninstall the inet-based telnet server |
The inet-based telnet daemon should be uninstalled. |
telnet allows clear text communications, and does not protect any
data transmission between client and server. Any confidential data can be
listened and no integrity checking is made. |
|
| NT007(R17) |
Disable SSH Access via Empty Passwords |
To explicitly disallow SSH login from accounts with
empty passwords, add or correct the following line in /etc/ssh/sshd_config:
PermitEmptyPasswords no
Any accounts with empty passwords should be disabled immediately, and PAM configuration
should prevent users from being able to assign themselves empty passwords. |
Configuring this setting for the SSH daemon provides additional assurance
that remote login via SSH will require a password, even in the event of
misconfiguration elsewhere. |
|
| NT007(R21) |
Disable SSH Root Login |
The root user should never be allowed to login to a
system directly over a network.
To disable root login via SSH, add or correct the following line
in /etc/ssh/sshd_config:
PermitRootLogin no
|
Even though the communications channel may be encrypted, an additional layer of
security is gained by extending the policy of not logging directly on as root.
In addition, logging in with a user-specific account provides individual
accountability of actions performed on the system and also helps to minimize
direct attack attempts on root's password. |
|
| NT012(R03) |
Install the ntp service |
The ntpd service should be installed. |
Time synchronization (using NTP) is required by almost all network and administrative tasks (syslog, cryptographic based services (authentication, etc.), etc.). Ntpd is regulary maintained and updated, supporting security features such as RFC 5906. |
|
| NT012(R03) |
Enable the NTP Daemon |
The ntpd service can be enabled with the following command: $ sudo systemctl enable ntpd.service
|
Enabling the ntpd service ensures that the ntpd
service will be running and that the system will synchronize its time to
any servers specified. This is important whether the system is configured to be
a client (and synchronize only its own clock) or it is also acting as an NTP
server to other systems. Synchronizing time is essential for authentication
services such as Kerberos, but it is also important for maintaining accurate
logs and auditing possible security breaches.
The NTP daemon offers all of the functionality of ntpdate, which is now
deprecated. Additional information on this is available at
http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate. |
|
| NT12(R5) |
Ensure Logs Sent To Remote Host |
To configure rsyslog to send logs to a remote log server,
open /etc/rsyslog.conf and read and understand the last section of the file,
which describes the multiple directives necessary to activate remote
logging.
Along with these other directives, the system can be configured
to forward its logs to a particular log server by
adding or correcting one of the following lines,
substituting
To use UDP for log message delivery:
*.* @
To use TCP for log message delivery:
*.* @@
To use RELP for log message delivery:
*.* :omrelp:
There must be a resolvable DNS CNAME or Alias record set to "" for logs to be sent correctly to the centralized logging utility. |
A log server (loghost) receives syslog messages from one or more
systems. This data can be used as an additional log source in the event a
system is compromised and its local logs are suspect. Forwarding log messages
to a remote loghost also provides system administrators with a centralized
place to view the status of multiple hosts within the enterprise. |
|
| NT12(R18) |
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. |
|
| NT28(R43) |
Ensure Logs Sent To Remote Host |
To configure rsyslog to send logs to a remote log server,
open /etc/rsyslog.conf and read and understand the last section of the file,
which describes the multiple directives necessary to activate remote
logging.
Along with these other directives, the system can be configured
to forward its logs to a particular log server by
adding or correcting one of the following lines,
substituting
To use UDP for log message delivery:
*.* @
To use TCP for log message delivery:
*.* @@
To use RELP for log message delivery:
*.* :omrelp:
There must be a resolvable DNS CNAME or Alias record set to "" for logs to be sent correctly to the centralized logging utility. |
A log server (loghost) receives syslog messages from one or more
systems. This data can be used as an additional log source in the event a
system is compromised and its local logs are suspect. Forwarding log messages
to a remote loghost also provides system administrators with a centralized
place to view the status of multiple hosts within the enterprise. |
|
| 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(R46) |
Enable rsyslog Service |
The rsyslog service provides syslog-style logging by default on Oracle 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. |
|