1.1.

2 Ensure /tmp is configured (Automated) : Fail

1.1.3 Ensure noexec option set on /tmp partition : Fail

1.1.4 Ensure nodev option set on /tmp partition : Fail

1.1.5 Ensure nosuid option set on /tmp partition : Fail

1.1.7 Ensure noexec option set on /dev/shm partition : Fail

1.1.8 Ensure nodev option set on /dev/shm partition : Fail

1.1.9 Ensure nosuid option set on /dev/shm partition : Fail

1.1.12 Ensure noexec option set on /var/tmp partition : Fail

1.1.13 Ensure nodev option set on /var/tmp partition : Fail

1.1.14 Ensure nosuid option set on /var/tmp partition : Fail

1.1.18 Ensure nodev option set on /home partition : Fail

1.1.19 Ensure noexec option set on removable media partitions : Fail

1.1.20 Ensure nodev option set on removable media partitions : Fail

1.1.21 Ensure nosuid option set on removable media partitions : Fail

1.1.22 Ensure sticky bit is set on all world-writable directories : Fail

Here /tmp is created as a file and mounted as a partition using loop mount option. Make sure there is
enough free space under / to spare a 2G file for /tmp. Run df -h command to verify the free space.

Use dd command to create a file of 2G. Change the count if you want to increase the size.

# dd if=/dev/zero of=/tmpfs bs=1024 count=2000000

Then format it using mkfs.ext4 command.

# mkfs.xfs /tmpfs

Add following lines by the end of /etc/fstab

# seprate/tmp as per Oracle Doc 2800019.1

/tmpfs /tmp xfs loop,nosuid,noexec,nodev,rw 0 0

Use lsof command to check if there is any application or process using /tmp actively. If you see any
outputs you need to get downtime and reboot the instance. You don't need to run the following
command. During booting, it will automatically get mounted as the entries are there in the fstab file.

# lsof /tmp

Mount it manually using the following command.

# mount -o remount,loop,nosuid,noexec,nodev /tmp

or

mount | grep /tmp

tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noexec,relatime)

Remediation

For new installations, during installation create a custom partition setup and specify a separate
partition for /tmp.

For systems that were previously installed, create a new partition for /tmp if not using tmpfs.

Run the following commands to enable systemd /tmp mounting:

# systemctl unmask tmp.mount

# systemctl enable tmp.mount

Edit /etc/systemd/system/local-fs.target.wants/tmp.mount to configure the /tmp mount:

[Mount]

What=tmpfs

Where=/tmp

Type=tmpfs

Options=mode=1777,strictatime,noexec,nodev,nosuid

Impact

1.1.23 Disable Automounting : Fail

========================================

Run the following command to mask autofs:

systemctl status autofs

systemctl disable autofs

systemctl stop autofs

systemctl status autofs

systemctl --now mask autofs

# systemctl --now mask autofs

OR run the following command to remove autofs

# yum remove autofs

1.1.24 Disable USB Storage : Fail

=======================================

vim /etc/modprobe.d/usb_storage.conf

install usb-storage /bin/true

rmmod usb-storage

Edit or create a file in the /etc/modprobe.d/ directory ending in .conf

Example: vim /etc/modprobe.d/usb_storage.conf

Add the following line:

install usb-storage /bin/true

Run the following command to unload the usb-storage module:

rmmod usb-storage

1.2.2 Ensure package manager repositories are configured : Fail

====================================================================

Systems need to have package manager repositories configured to ensure they receive the latest patches
and updates.
Rationale:

If a system's package repositories are misconfigured important patches may not be identified or a rogue
repository could introduce compromised software.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target
compliance.

Solution

Configure your package manager repositories according to site policy.

1.3.2 Ensure sudo commands use pty : Fail

================================================

visudo

Defaults use_pty

sudo can be configured to run only from a pseudo-pty

Note: visudo edits the sudoers file in a safe fashion, analogous to vipw(8). visudo locks the sudoers file
against multiple simultaneous edits, provides basic sanity checks, and checks for parse errors. If the
sudoers file is currently being edited you will receive a message to try again later. The -f option allows
you to tell visudo which file to edit.

Rationale:

Attackers can run a malicious program using sudo, which would again fork a background process that
remains even when the main program has finished executing.
This can be mitigated by configuring sudo to run other commands only from a pseudo-pty, whether I/O
logging is turned on or not.

Solution

Edit the file /etc/sudoers or a file in /etc/sudoers.d/ with visudo or visudo -f <PATH TO FILE> and add the
following line:

Defaults use_pty

1.3.3 Ensure sudo log file exists : Fail

==============================================

visudo

Defaults logfile='/var/log/sudo.log'

sudo can use a custom log file

Note: visudo edits the sudoers file in a safe fashion, analogous to vipw(8). visudo locks the sudoers file
against multiple simultaneous edits, provides basic sanity checks, and checks for parse errors. If the
sudoers file is currently being edited you will receive a message to try again later. The -f option allows
you to tell visudo which file to edit.

Rationale:

A sudo log file simplifies auditing of sudo commands

Impact:

Editing the sudo configuration incorrectly can cause sudo to stop functioning
Solution

edit the file /etc/sudoers or a file in /etc/sudoers.d/ with visudo or visudo -f <PATH TO FILE> and add the
following line:

Defaults logfile='<PATH TO CUSTOM LOG FILE>'

Example:

Defaults logfile='/var/log/sudo.log'

1.4.2 Ensure filesystem integrity is regularly checked : Fail

===============================================================

Periodic checking of the filesystem integrity is needed to detect changes to the filesystem.

Rationale:

Periodic file checking allows the system administrator to determine on a regular basis if critical files have
been changed in an unauthorized fashion.

Solution

If cron will be used to schedule and run aide check

Run the following command:

# crontab -u root -e

Add the following line to the crontab:

0 5 * * * /usr/sbin/aide --check

OR if aidecheck.service and aidecheck.timer will be used to schedule and run aide check:

Create or edit the file /etc/systemd/system/aidecheck.service and add the following lines:

[Unit]

Description=Aide Check

[Service]

Type=simple

ExecStart=/usr/sbin/aide --check

[Install]

WantedBy=multi-user.target

Create or edit the file /etc/systemd/system/aidecheck.timer and add the following lines:

[Unit]

Description=Aide check every day at 5AM

[Timer]

OnCalendar=*-*-* 05:00:00

Unit=aidecheck.service
[Install]

WantedBy=multi-user.target

Run the following commands:

# chown root:root /etc/systemd/system/aidecheck.*

# chmod 0644 /etc/systemd/system/aidecheck.*

# systemctl daemon-reload

# systemctl enable aidecheck.service

# systemctl --now enable aidecheck.timer

1.5.1 Ensure bootloader password is set : Fail

1.5.3 Ensure authentication required for single user mode : Fail

1.6.2 Ensure XD/NX support is enabled : Fail

====================================================

Recent processors in the x86 family support the ability to prevent code execution on a per memory page
basis. Generically and on AMD processors, this ability is called No Execute (NX), while on Intel processors
it is called Execute Disable (XD). This ability can help prevent exploitation of buffer overflow
vulnerabilities and should be activated whenever possible. Extra steps must be taken to ensure that this
protection is enabled, particularly on 32-bit x86 systems. Other processors, such as Itanium and POWER,
have included such support since inception and the standard kernel for those platforms supports the
feature.

Note: Ensure your system supports the XD or NX bit and has PAE support before implementing this
recommendation as this may prevent it from booting if these are not supported by your hardware
Rationale:

Enabling any feature that can protect against buffer overflow attacks enhances the security of the
system.

Solution

On 32 bit systems install a kernel with PAE support, no installation is required on 64 bit systems:

If necessary configure your bootloader to load the new kernel and reboot the system.

You may need to enable NX or XD support in your bios.

1.6.3 Ensure address space layout randomization (ASLR) is enabled : Fail

===============================================================================

Address space layout randomization (ASLR) is an exploit mitigation technique which randomly arranges
the address space of key data areas of a process.

Rationale:

Randomly placing virtual memory regions will make it difficult to write memory page exploits as the
memory placement will be consistently shifting.

Solution

Set the following parameter in /etc/sysctl.conf or a /etc/sysctl.d/* file:

kernel.randomize_va_space = 2

Run the following commands to comment out entries that override the default setting of
kernel.randomize_va_space:
# sed -ri 's/^s*kernel.randomize_va_spaces*=s*([0-1]|[3-9]|[1-9][0-9]+)/# &/gi' /etc/sysctl.conf

# [ -e /etc/sysctl.d/* ] && sed -ri 's/^s*kernel.randomize_va_spaces*=s*([0-1]|[3-9]|[1-9][0-9]+)/#

&/gi' /etc/sysctl.d/*

Run the following command to set the active kernel parameter:

1.7.1.3 Ensure SELinux policy is configured : Fail

1.7.1.4 Ensure the SELinux mode is enforcing or permissive : Fail

1.8.1.1 Ensure message of the day is configured properly : Fail

===================================================================

rm /etc/motd

The contents of the /etc/motd file are displayed to users after login and function as a message of the day
for authenticated users.

Unix-based systems have typically displayed information about the OS release and patch level upon
logging in to the system. This information can be useful to developers who are developing software for a
particular OS platform. If mingetty(8) supports the following options, they display operating system
information: m - machine architecture r - operating system release s - operating system name v -
operating system version

Rationale:

Warning messages inform users who are attempting to login to the system of their legal status regarding
the system and must include the name of the organization that owns the system and any monitoring
policies that are in place. Displaying OS and patch level information in login banners also has the side
effect of providing detailed system information to attackers attempting to target specific exploits of a
system. Authorized users can easily get this information by running the ' uname -a ' command once they
have logged in.

Solution

Edit the /etc/motd file with the appropriate contents according to your site policy, remove any instances
of m , r , s , v or references to the OS platform

OR

If the motd is not used, this file can be removed.

Run the following command to remove the motd file:

# rm /etc/motd

2.2.1.3 Ensure ntp is configured : Fail

========================================

systemctl status ntpd

systemctl enable ntpd

systemctl start ntpd

systemctl status ntpd

ntp is a daemon which implements the Network Time Protocol (NTP). It is designed to synchronize
system clocks across a variety of systems and use a source that is highly accurate. More information on
NTP can be found at http://www.ntp.org. ntp can be configured to be a client and/or a server.

This recommendation only applies if ntp is in use on the system.

Rationale:
If ntp is in use on the system proper configuration is vital to ensuring time synchronization is working
properly.

Solution

Add or edit restrict lines in /etc/ntp.conf to match the following:

restrict -4 default kod nomodify notrap nopeer noquery

restrict -6 default kod nomodify notrap nopeer noquery

Add or edit server or pool lines to /etc/ntp.conf as appropriate:

server <remote-server>

Add or edit the OPTIONS in /etc/sysconfig/ntpd to include ' -u ntp:ntp ':

OPTIONS='-u ntp:ntp'

2.2.7 Ensure nfs-utils is not installed or the nfs-server service is masked : Fail

=====================================================================================
=====

systemctl status nfs-server

systemctl disable nfs-server

systemctl stop nfs-server

systemctl --now mask nfs-server

The Network File System (NFS) is one of the first and most widely distributed file systems in the UNIX
environment. It provides the ability for systems to mount file systems of other servers through the
network.

Rationale:

If the system does not require network shares, it is recommended that the nfs-utils and nfs-kernel-server
packages be removed to reduce the attack surface of the system.

Note: many of the libvirt packages used by Enterprise Linux virtualization are dependent on the nfs-utils
package. If the nfs-utils or nfs-kernel-server packages are required as a dependency, the nfs-server
service should be disabled and masked to reduce the attack surface of the system

Solution

Run the following commands to remove nfs-utils and nfs-kernel-server:

# zypper remove nfs-utils

# zypper remove nfs-kernel-server

OR

If the nfs-utils or nfs-kernel-server packages are required as a dependency

Run the following command to stop and mask the nfs-server service:

# systemctl --now mask nfs-server

2.2.8 Ensure rpcbind is not installed or the rpcbind services are masked : Fail

=====================================================================================
==
systemctl status rpcbind

systemctl disable rpcbind

systemctl stop rpcbind

systemctl status rpcbind

systemctl --now mask rpcbind.socket

The rpcbind utility maps RPC services to the ports on which they listen. RPC processes notify rpcbind
when they start, registering the ports they are listening on and the RPC program numbers they expect to
serve. The client system then contacts rpcbind on the server with a particular RPC program number. The
rpcbind service redirects the client to the proper port number so it can communicate with the requested
service

Portmapper is an RPC service, which always listens on tcp and udp 111, and is used to map other RPC
services (such as nfs, nlockmgr, quotad, mountd, etc.) to their corresponding port number on the server.
When a remote host makes an RPC call to that server, it first consults with portmap to determine where
the RPC server is listening.

Rationale:

A small request (~82 bytes via UDP) sent to the Portmapper generates a large response (7x to 28x
amplification), which makes it a suitable tool for DDoS attacks. If rpcbind is not required, it is
recommended that the rpcbind package be removed to reduce the attack surface of the system.

Note: many of the libvirt packages used by Enterprise Linux virtualization, and the nfs-utils package used
for The Network File System (NFS) are dependent on the rpcbind package. If the rpcbind is required as a
dependency, the services rpcbind.service and rpcbind.socket should be stopped and masked to reduce
the attack surface of the system.

Solution

Run the following command to remove nfs-utils:

# zypper remove rpcbind

OR

If the rpcbind package is required as a dependency

Run the following commands to stop and mask the rpcbind and rpcbind.socket services:

# systemctl --now mask rpcbind

# systemctl --now mask rpcbind.socket

2.2.11 Ensure HTTP server is not installed : Fail

==========================================================

HTTP or web servers provide the ability to host web site content.

Rationale:

Unless there is a need to run the system as a web server, it is recommended that the package be
removed to reduce the potential attack surface.

Notes:

Several http servers exist. apache, apache2, lighttpd, and nginx are example packages that provide an
HTTP server.

These and other packages should also be audited, and removed if not required.
Solution

Run the following command to remove httpd:

# yum remove httpd

2.2.17 Ensure rsync is not installed or the rsyncd service is masked : Fail

===========================================================================

systemctl status rsyncd

systemctl disable rsyncd

systemctl stop rsyncd

systemctl status rsyncd

The rsyncd service can be used to synchronize files between systems over network links.

Rationale:

Unless required, the rsync package should be removed to reduce the attack surface area of the system.

The rsyncd service presents a security risk as it uses unencrypted protocols for communication.

Note: If a required dependency exists for the rsync package, but the rsyncd service is not required, the
service should be masked.

Impact:
There are packages that are dependent on the rsync package. If the rsync package is removed, these
packages will be removed as well.

Before removing the rsync package, review any dependent packages to determine if they are required on
the system. If a dependent package is required, mask the rsyncd service and leave the rsync package
installed.

Solution

Run the following command to remove the rsync package:

# zypper remove rsync

OR

Run the following command to mask the rsyncd service:

# systemctl --now mask rsyncd

3.1.2 Ensure wireless interfaces are disabled : Fail

============================================================

Wireless networking is used when wired networks are unavailable. Red Hat Enterprise Linux contains a
wireless tool kit to allow system administrators to configure and use wireless networks.

Rationale:

If wireless is not to be used, wireless devices can be disabled to reduce the potential attack surface.

Solution

Run the following command to disable any wireless interfaces:

# nmcli radio all off

Disable any wireless interfaces in your network configuration.

Impact:
Many if not all laptop workstations and some desktop workstations will connect via wireless requiring
these interfaces be enabled.

3.2.2 Ensure packet redirect sending is disabled : Fail

=========================================================

ICMP Redirects are used to send routing information to other hosts. As a host itself does not act as a
router (in a host only configuration), there is no need to send redirects. An attacker could use a
compromised host to send invalid ICMP redirects to other router devices in an attempt to corrupt
routing and have users access a system set up by the attacker as opposed to a valid system.

Solution

Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:

net.ipv4.conf.all.send_redirects = 0

net.ipv4.conf.default.send_redirects = 0

Run the following commands to set the active kernel parameters:

# sysctl -w net.ipv4.conf.all.send_redirects=0

# sysctl -w net.ipv4.conf.default.send_redirects=0

# sysctl -w net.ipv4.route.flush=1

3.3.1 Ensure source routed packets are not accepted : Fail

==============================================================

In networking, source routing allows a sender to partially or fully specify the route packets take through
a network. In contrast, non-source routed packets travel a path determined by routers in the network. In
some cases, systems may not be routable or reachable from some locations (e.g. private addresses vs.
Internet routable), and so source routed packets would need to be used.

Rationale

Setting net.ipv4.conf.all.accept_source_route and net.ipv4.conf.default.accept_source_route to 0

disables the system from accepting source routed packets. Assume this system was capable of routing
packets to Internet routable addresses on one interface and private addresses on another interface.
Assume that the private addresses were not routable to the Internet routable addresses and vice versa.
Under normal routing circumstances, an attacker from the Internet routable addresses could not use the
system as a way to reach the private address systems. If, however, source routed packets were allowed,
they could be used to gain access to the private address systems as the route could be specified, rather
than rely on routing protocols that did not allow this routing.

Audit

Run the following command and verify output matches:

# sysctl net.ipv4.conf.all.accept_source_route

net.ipv4.conf.all.accept_source_route = 0

# sysctl net.ipv4.conf.default.accept_source_route

net.ipv4.conf.default.accept_source_route = 0

Remediation

Set the following parameter in the /etc/sysctl.conf file:

net.ipv4.conf.all.accept_source_route = 0

net.ipv4.conf.default.accept_source_route = 0

Run the following commands to set the active kernel parameters:

# sysctl -w net.ipv4.conf.all.accept_source_route=0

# sysctl -w net.ipv4.conf.default.accept_source_route=0

# sysctl -w net.ipv4.route.flush=1

3.3.2 Ensure ICMP redirects are not accepted : Fail

==============================================================
ICMP redirect messages are packets that convey routing information and tell your host (acting as a
router) to send packets via an alternate path. It is a way of allowing an outside routing device to update
your system routing tables. By setting net.ipv4.conf.all.accept_redirects to 0, the system will not accept
any ICMP redirect messages, and therefore, won't allow outsiders to update the system's routing tables.

Rationale:

Attackers could use bogus ICMP redirect messages to maliciously alter the system routing tables and get
them to send packets to incorrect networks and allow your system packets to be captured.

Solution

Set the following parameters in /etc/sysctl.conf or a /etc/sysctl.d/* file:

net.ipv4.conf.all.accept_redirects = 0

net.ipv4.conf.default.accept_redirects = 0

net.ipv6.conf.all.accept_redirects = 0

net.ipv6.conf.default.accept_redirects = 0

3.5.1.4 Ensure firewalld service is enabled and running : Fail

3.5.1.5 Ensure default zone is set : Fail

3.5.3.1.1 Ensure iptables packages are installed : Fail

3.5.3.2.1 Ensure default deny firewall policy : Fail

3.5.3.2.5 Ensure iptables rules are saved : Fail

3.5.3.2.6 Ensure iptables is enabled and running : Fail

3.5.3.3.1 Ensure IPv6 default deny firewall policy : Fail

3.5.3.3.5 Ensure ip6tables rules are saved : Fail

3.5.3.3.6 Ensure ip6tables is enabled and running : Fail

4.2.1.3 Ensure rsyslog default file permissions configured : Fail

======================================================================

systemctl disable rsyslog

systemctl stop rsyslog

systemctl status rsyslog

rsyslog will create logfiles that do not already exist on the system. This setting controls what
permissions will be applied to these newly created files.

Rationale:

It is important to ensure that log files have the correct permissions to ensure that sensitive data is
archived and protected.

Solution

Edit the /etc/rsyslog.conf and /etc/rsyslog.d/*.conf files and set every instance of $FileCreateMode to
0640 or more restrictive:

$FileCreateMode 0640

4.2.1.5 Ensure rsyslog is configured to send logs to a remote log host : Fail

==================================================================================

RSyslog supports the ability to send log events it gathers to a remote log host or to receive messages
from remote hosts, thus enabling centralised log management.
Rationale:

Storing log data on a remote host protects log integrity from local attacks. If an attacker gains root
access on the local system, they could tamper with or remove log data that is stored on the local
system.

Solution

Edit the /etc/rsyslog.conf and /etc/rsyslog.d/*.conf files and add the following line (where
loghost.example.com is the name of your central log host). The target directive may either be a fully
qualified domain name or an IP address.

*.* action(type='omfwd' target='192.168.2.100' port='514' protocol='tcp'

action.resumeRetryCount='100'

queue.type='LinkedList' queue.size='1000')

Run the following command to reload the rsyslogd configuration:

# systemctl restart rsyslog

4.2.1.6 Ensure remote rsyslog messages are only accepted on designated log hosts. : Fail

4.2.2.1 Ensure journald is configured to send logs to rsyslog : Fail

4.2.2.2 Ensure journald is configured to compress large log files : Fail

4.2.2.3 Ensure journald is configured to write logfiles to persistent disk : Fail

5.2.4 Ensure SSH access is limited : Fail

=================================================

There are several options available to limit which users and group can access the system via SSH. It is
recommended that at least one of the following options be leveraged:

AllowUsers:

The AllowUsers variable gives the system administrator the option of allowing specific users to ssh into
the system. The list consists of space separated user names. Numeric user IDs are not recognized with
this variable. If a system administrator wants to restrict user access further by only allowing the allowed
users to log in from a particular host, the entry can be specified in the form of user@host.

AllowGroups:

The AllowGroups variable gives the system administrator the option of allowing specific groups of users
to ssh into the system. The list consists of space separated group names. Numeric group IDs are not
recognized with this variable.

DenyUsers:

The DenyUsers variable gives the system administrator the option of denying specific users to ssh into
the system. The list consists of space separated user names. Numeric user IDs are not recognized with
this variable. If a system administrator wants to restrict user access further by specifically denying a
user's access from a particular host, the entry can be specified in the form of user@host.

DenyGroups:

The DenyGroups variable gives the system administrator the option of denying specific groups of users to
ssh into the system. The list consists of space separated group names. Numeric group IDs are not
recognized with this variable.

Rationale:
Restricting which users can remotely access the system via SSH will help ensure that only authorized
users access the system.

Solution

Edit the /etc/ssh/sshd_config file to set one or more of the parameter as follows:

AllowUsers <userlist>

OR

AllowGroups <grouplist>

OR

DenyUsers <userlist>

OR

DenyGroups <grouplist>

Default Value:

None

5.2.21 Ensure SSH MaxStartups is configured : Fail

=========================================================
The MaxStartups parameter specifies the maximum number of concurrent unauthenticated connections
to the SSH daemon.

Rationale:

To protect a system from denial of service due to a large number of pending authentication connection
attempts, use the rate limiting function of MaxStartups to protect availability of sshd logins and prevent
overwhelming the daemon.

Solution

Edit the /etc/ssh/sshd_config file to set the parameter as follows:

maxstartups 10:30:60

5.2.22 Ensure SSH MaxSessions is limited : Fail

======================================================

The MaxSessions parameter specifies the maximum number of open sessions permitted from a given
connection.

Rationale:

To protect a system from denial of service due to a large number of concurrent sessions, use the rate
limiting function of MaxSessions to protect availability of sshd logins and prevent overwhelming the
daemon.

Solution

Edit the /etc/ssh/sshd_config file to set the parameter as follows:

MaxSessions 10
Default Value:

MaxSessions 10

See Also

5.3.1 Ensure password creation requirements are configured : Fail

5.3.2 Ensure lockout for failed password attempts is configured : Mann

5.4.1.1 Ensure password expiration is 365 days or less : Fail

5.4.1.4 Ensure inactive password lock is 30 days or less : Fail

5.4.4 Ensure default user shell timeout is configured : Fail