Reference (anssi) | Rule Title | Description | Rationale | Variable Setting |
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 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. | |
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 systemd_timesyncd Service | The systemd_timesyncd service can be enabled with the following command: $ sudo systemctl enable systemd_timesyncd.service |
Enabling the systemd_timesyncd service ensures that this host
uses the ntp protocol to fetch time data from a ntp server.
Synchronizing time is essential for authentication
services such as Kerberos, but it is also important for maintaining accurate
logs and auditing possible security breaches.
Additional information on Ubuntu network time protocol is available at https://help.ubuntu.com/lts/serverguide/NTP.html.en. |
|
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 loghost.example.com appropriately.
The choice of protocol depends on the environment of the system;
although TCP and RELP provide more reliable message delivery,
they may not be supported in all environments.
To use UDP for log message delivery: *.* @loghost.example.com To use TCP for log message delivery: *.* @@loghost.example.com To use RELP for log message delivery: *.* :omrelp:loghost.example.com There must be a resolvable DNS CNAME or Alias record set to " |
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(R1) | Uninstall DHCP Server Package | If the system does not need to act as a DHCP server,
the dhcp package can be uninstalled.
The dhcp package can be removed with the following command:
$ sudo yum erase dhcp |
Removing the DHCP server ensures that it cannot be easily or accidentally reactivated and disrupt network operation. | |
NT28(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. | |
NT28(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. | |
NT28(R4) | Ensure SELinux State is Enforcing | The SELinux state should be set to at
system boot time. In the file /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. | |
NT28(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. | |
NT28(R5) | Enable syslog-ng Service | The syslog-ng service (in replacement of rsyslog) provides syslog-style logging by default on Debian 8.
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. |
|
NT28(R5) | Enable rsyslog Service | The rsyslog service provides syslog-style logging by default on Red Hat Enterprise Linux 8.
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. |
|
NT28(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. | |
NT28(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. |
|
NT28(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. |
|
NT28(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 loghost.example.com appropriately.
The choice of protocol depends on the environment of the system;
although TCP and RELP provide more reliable message delivery,
they may not be supported in all environments.
To use UDP for log message delivery: *.* @loghost.example.com To use TCP for log message delivery: *.* @@loghost.example.com To use RELP for log message delivery: *.* :omrelp:loghost.example.com There must be a resolvable DNS CNAME or Alias record set to " |
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(R08) | Ensure Software Patches Installed |
If the system is joined to the Red Hat Network, a Red Hat Satellite Server,
or a yum server, run the following command to install updates:
$ sudo yum updateIf the system is not configured to use one of these sources, updates (in the form of RPM packages) can be manually downloaded from the Red Hat Network 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. | |
NT28(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. | |
NT28(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. |
|
NT28(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. | |
NT28(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. |
|
NT28(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. | |
NT28(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. |
|
NT28(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. | |
NT28(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. |
|
NT28(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. |
|
NT28(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. |
|
NT28(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. |
|
NT28(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. |
|
NT28(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/ . |
|
NT28(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. |
|
NT28(R15) | Disable unauthenticated repositories in APT configuration | Unauthenticated repositories should not be used for updates. | Repositories hosts all packages that will be intsalled on the system during update. If a repository is not authenticated, the associated packages can't be trusted, and then should not be installed localy. | |
NT28(R15) | Ensure that official distribution repositories are used | Check that official Debian repositories, including security repository, are configured in apt. | The Debian distribution deliver DSA (Debian Security Announce), through the official Debian security repository, to correct various vulnerabilities impacting the Debian packages. Using the official repositories is the best way to ensure that the Debian updates are integrated soon enough. | |
NT28(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)." | |
NT28(R15) | Ensure Red Hat GPG Key Installed | To ensure the system can cryptographically verify base software packages
come from Red Hat (and to connect to the Red Hat Network to receive them),
the Red Hat GPG key must properly be installed. To install the Red Hat GPG
key, run:
$ sudo subscription-manager registerIf the system is not connected to the Internet or an RHN Satellite, then install the Red Hat GPG key from trusted media such as the Red Hat installation CD-ROM or DVD. Assuming the disc is mounted in /media/cdrom , use the following command as the root user to import
it into the keyring:
$ sudo rpm --import /media/cdrom/RPM-GPG-KEYAlternatively, the key may be pre-loaded during the RHEL installation. In such cases, the key can be installed by running the following command: sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release |
Changes to 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. The Red Hat GPG key is necessary to cryptographically verify packages are from Red Hat. | |
NT28(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). |
|
NT28(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. |
|
NT28(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.
To do so, select a superuser account name and password and and modify the /etc/grub.d/01_users configuration file with the new account name.
Since plaintext passwords are a security risk, generate a hash for the pasword by running the following command: $ grub2-setpasswordWhen prompted, enter the password that was selected. NOTE: It is recommended 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/root/bootuser/g /etc/grub.d/01_users To meet FISMA Moderate, the bootloader superuser account and password MUST differ from the root account and password. Once the superuser account and password have been added, update the grub.cfg file by running:
grub2-mkconfig -o /boot/grub2/grub.cfgNOTE: Do NOT manually add the superuser account and password to the grub.cfg file as the grub2-mkconfig command overwrites this file. |
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. | |
NT28(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.
To do so, select a superuser account name and password and and modify the /etc/grub.d/01_users configuration file with the new account name.
Since plaintext passwords are a security risk, generate a hash for the pasword by running the following command: $ grub2-setpasswordWhen prompted, enter the password that was selected. NOTE: It is recommended 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/root/bootuser/g /etc/grub.d/01_users To meet FISMA Moderate, the bootloader superuser account and password MUST differ from the root account and password. Once the superuser account and password have been added, update the grub.cfg file by running:
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfgNOTE: Do NOT manually add the superuser account and password to the grub.cfg file as the grub2-mkconfig command overwrites this file. |
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. | |
NT28(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. | |
NT28(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, Red Hat Enterprise Linux 8'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. | |
NT28(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=0If this is not the system default value, 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. | |
NT28(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=0If this is not the system default value, 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. |
|
NT28(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=0If this is not the system default value, 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. | |
NT28(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=0If this is not the system default value, 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. | |
NT28(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=0If this is not the system default value, 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. |
|
NT28(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=1If this is not the system default value, 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. | |
NT28(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=0If this is not the system default value, 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. | |
NT28(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=0If this is not the system default value, 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. | |
NT28(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=0If this is not the system default value, 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." |
|
NT28(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=1If this is not the system default value, 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. | |
NT28(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=1If this is not the system default value, 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. | |
NT28(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=1If this is not the system default value, 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. | |
NT28(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=1If this is not the system default value, 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. | |
NT28(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=0If this is not the system default value, 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. |
|
NT28(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=0If this is not the system default value, 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. |
|
NT28(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=0If this is not the system default value, 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. | |
NT28(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=0If this is not the system default value, 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. |
|
NT28(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=0If this is not the system default value, 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. |
|
NT28(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=1If this is not the system default value, 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() . |
|
NT28(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=1If this is not the system default value, 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() . |
|
NT28(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=0If this is not the system default value, 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. | |
NT28(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=1If this is not the system default value, 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. |
|
NT28(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=2If this is not the system default value, 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. | |
NT28(R23) | Disallow kernel profiling by unprivileged users | To set the runtime status of the kernel.perf_event_paranoid kernel parameter, run the following command: $ sudo sysctl -w kernel.perf_event_paranoid=2If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d : kernel.perf_event_paranoid = 2 |
Kernel profiling can reveal sensitive information about kernel behaviour. | |
NT28(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=1If this is not the system default value, 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. | |
NT28(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=1If this is not the system default value, 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). | |
NT28(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:
ClientAliveIntervalThe timeout interval is given in seconds. To have a timeout of e.g. 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 here. 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. | |
NT28(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. | |
NT28(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. |
|
NT28(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. | |
NT28(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. | |
NT28(R36) | Verify Permissions on shadow File |
To properly set the permissions of /etc/shadow , run the command:
$ sudo chmod 0640 /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. |
|
NT28(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. |
|
NT28(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. |
|
NT28(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. |
|
NT28(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. | |
NT28(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. | |
NT28(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. | |
NT28(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. | |
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 loghost.example.com appropriately.
The choice of protocol depends on the environment of the system;
although TCP and RELP provide more reliable message delivery,
they may not be supported in all environments.
To use UDP for log message delivery: *.* @loghost.example.com To use TCP for log message delivery: *.* @@loghost.example.com To use RELP for log message delivery: *.* :omrelp:loghost.example.com There must be a resolvable DNS CNAME or Alias record set to " |
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(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. | |
NT28(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. | |
NT28(R46) | Enable syslog-ng Service | The syslog-ng service (in replacement of rsyslog) provides syslog-style logging by default on Debian 8.
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. |
|
NT28(R46) | Enable rsyslog Service | The rsyslog service provides syslog-style logging by default on Red Hat Enterprise Linux 8.
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. |
|
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(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/ . |
|
NT28(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. | |
NT28(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 comparision with potential local access control policy such as SELinux policy. | |
NT28(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. | |
NT28(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+sha256AIDE 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. | |
NT28(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+sha256AIDE 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. | |
NT28(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@localhostOtherwise, add the following line to /etc/crontab :
05 4 * * * root /usr/sbin/aide --check | /bin/mail -s "$(hostname) - AIDE Integrity Check" root@localhostAIDE 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. |
|
NT28(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 --checkTo 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 --checkAIDE 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. |
|
NT28(R51) | Build and Test AIDE Database | Run the following command to generate a new database:
$ sudo /usr/sbin/aide --initBy 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.gzTo initiate a manual check, run the following command: $ sudo /usr/sbin/aide --checkIf 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. | |
NT28(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. |
|
NT28(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. |
|
NT28(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
. |
|
NT28(R67) | Disable the ssh_sysadm_login SELinux Boolean | By default, the SELinux boolean ssh_sysadm_login is disabled.
If this setting is enabled, it should be disabled.
To disable the ssh_sysadm_login SELinux boolean, run the following command:
$ sudo setsebool -P ssh_sysadm_login off |
||
NT28(R67) | Disable the secure_mode_insmod SELinux Boolean | By default, the SELinux boolean secure_mode_insmod is disabled.
If this setting is enabled, it should be disabled.
To disable the secure_mode_insmod SELinux boolean, run the following command:
$ sudo setsebool -P secure_mode_insmod off |
||
NT28(R68) | Uninstall setroubleshoot Package | The SETroubleshoot service notifies desktop users of SELinux
denials. The service provides information around configuration errors,
unauthorized intrusions, and other potential errors.
The setroubleshoot package can be removed with the following command:
$ sudo yum erase setroubleshoot |
The SETroubleshoot service is an unnecessary daemon to have running on a server |