Guide to the Secure Configuration of Kylin Linux Advanced Server V10

with profile Standard System Security Profile for Kylin Linux Advanced Server V10
This profile contains rules to ensure standard security baseline of a Kylin Linux Advanced Server V10 SP3 system. Regardless of your system's workload all of these checks should pass.
This guide presents a catalog of security-relevant configuration settings for Kylin Linux Advanced Server V10. It is a rendering of content structured in the eXtensible Configuration Checklist Description Format (XCCDF) in order to support security automation. The SCAP content is is available in the config_item="scap-security-guide" package which is developed at https://www.open-scap.org/security-policies/scap-security-guide.

Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a italics="catalog, not a checklist," and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF italics="Profiles", which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG for Kylin Linux Advanced Server V10, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance.
Do not attempt to implement any of the settings in this guide without first testing them in a non-operational environment. The creators of this guidance assume no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic.

Profile Information

Profile TitleStandard System Security Profile for Kylin Linux Advanced Server V10
Profile IDxccdf_org.ssgproject.content_profile_kylin-standard

CPE Platforms

  • cpe:/o:kylin:linux_advanced:v10::server
  • cpe:/o:kylin:linux_advanced:v10sp3::server

Revision History

Current version: 0.1.39

  • draft (as of 2023-11-10)

Table of Contents

  1. Services
    1. Obsolete Services
    2. IMAP and POP3 Server
    3. Network Routing
    4. Mail Server Software
    5. Samba(SMB) Microsoft Windows File Sharing Server
    6. Network Time Protocol
    7. Base Services
    8. SSH Server
  2. System Settings
    1. Configure Syslog
    2. Network Configuration and Firewalls
    3. Account and Access Control
    4. File Permissions and Masks
    5. System Accounting with <tt>auditd</tt>
    6. Installing and Maintaining Software

Checklist

Group   Guide to the Secure Configuration of Kylin Linux Advanced Server V10   Group contains 45 groups and 52 rules
Group   Services   Group contains 15 groups and 18 rules

[ref]   The best protection against vulnerable software is running less software. This section describes how to review the software which Kylin Linux Advanced Server V10 installs on a system and disable software which is not needed. It then enumerates the software packages installed on a default Kylin Linux Advanced Server V10 system and provides guidance about which ones can be safely disabled.

Kylin Linux Advanced Server V10 provides a convenient minimal install option that essentially installs the bare necessities for a functional system. When building Kylin Linux Advanced Server V10 systems, it is highly recommended to select the minimal packages and then build up the system from there.

Group   Obsolete Services   Group contains 3 groups and 6 rules

[ref]   This section discusses a number of network-visible services which have historically caused problems for system security, and for which disabling or severely limiting the service has been the best available guidance for some time. As a result of this, many of these services are not installed as part of Red Hat Enterprise Linux 7 by default.

Organizations which are running these services should switch to more secure equivalents as soon as possible. If it remains absolutely necessary to run one of these services for legacy reasons, care should be taken to restrict the service as much as possible, for instance by configuring host firewall software such as firewalld to restrict access to the vulnerable service to only those remote hosts which have a known need to use it.

Group   Rlogin, Rsh, and Rexec   Group contains 2 rules

[ref]   The Berkeley r-commands are legacy services which allow cleartext remote access and have an insecure trust model.

Rule   Uninstall rsh Package   [ref]

The rsh package contains the client commands for the rsh services

Rationale:

These legacy clients contain numerous security exposures and have been replaced with the more secure SSH package. Even if the server is removed, it is best to ensure the clients are also removed to prevent users from inadvertently attempting to use these commands and therefore exposing their credentials. Note that removing the rsh package removes the clients for rsh,rcp, and rlogin.

Severity: 
unknown
Rule ID:xccdf_org.ssgproject.content_rule_package_rsh_removed
Identifiers and References

Identifiers:  CCE-27274-0

References:  2.3.2, 3.1.13, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), A.8.2.3, A.13.1.1, A.13.2.1, A.13.2.3, A.14.1.2, A.14.1.3



Complexity:low
Disruption:low
Strategy:disable
# Function to remove packages on RHEL, Fedora, Debian, and possibly other systems.
#
# Example Call(s):
#
#     package_remove telnet-server
#
function package_remove {

# Load function arguments into local variables
local package="$1"

# Check sanity of the input
if [ $# -ne "1" ]
then
  echo "Usage: package_remove 'package_name'"
  echo "Aborting."
  exit 1
fi

if which dnf ; then
  if rpm -q --quiet "$package"; then
    dnf remove -y "$package"
  fi
elif which yum ; then
  if rpm -q --quiet "$package"; then
    yum remove -y "$package"
  fi
elif which apt-get ; then
  apt-get remove -y "$package"
else
  echo "Failed to detect available packaging system, tried dnf, yum and apt-get!"
  echo "Aborting."
  exit 1
fi

}

package_remove rsh


Complexity:low
Disruption:low
Strategy:disable
- name: Ensure rsh is removed
  package:
    name="{{item}}"
    state=absent
  with_items:
    - rsh
  tags:
    - package_rsh_removed
    - unknown_severity
    - disable_strategy
    - low_complexity
    - low_disruption
    - CCE-27274-0
    - NIST-800-171-3.1.13


Complexity:low
Disruption:low
Strategy:disable
include remove_rsh

class remove_rsh {
  package { 'rsh':
    ensure => 'purged',
  }
}

Rule   Uninstall rsh-server Package   [ref]

The rsh-server package can be uninstalled with the following command:

$ sudo yum erase rsh-server

Rationale:

The rsh-server service provides unencrypted remote access service which does not provide for the confidentiality and integrity of user passwords or the remote session and has very weak authentication. If a privileged user were to login using this service, the privileged user password could be compromised. The rsh-server package provides several obsolete and insecure network services. Removing it decreases the risk of those services' accidental (or intentional) activation.

Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_package_rsh-server_removed
Identifiers and References

Identifiers:  CCE-27342-5

References:  CCI-000381, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), A.8.2.3, A.13.1.1, A.13.2.1, A.13.2.3, A.14.1.2, A.14.1.3, AC-17(8), CM-7(a), SRG-OS-000095-GPOS-00049



Complexity:low
Disruption:low
Strategy:disable
# Function to remove packages on RHEL, Fedora, Debian, and possibly other systems.
#
# Example Call(s):
#
#     package_remove telnet-server
#
function package_remove {

# Load function arguments into local variables
local package="$1"

# Check sanity of the input
if [ $# -ne "1" ]
then
  echo "Usage: package_remove 'package_name'"
  echo "Aborting."
  exit 1
fi

if which dnf ; then
  if rpm -q --quiet "$package"; then
    dnf remove -y "$package"
  fi
elif which yum ; then
  if rpm -q --quiet "$package"; then
    yum remove -y "$package"
  fi
elif which apt-get ; then
  apt-get remove -y "$package"
else
  echo "Failed to detect available packaging system, tried dnf, yum and apt-get!"
  echo "Aborting."
  exit 1
fi

}

package_remove rsh-server


Complexity:low
Disruption:low
Strategy:disable
- name: Ensure rsh-server is removed
  package:
    name="{{item}}"
    state=absent
  with_items:
    - rsh-server
  tags:
    - package_rsh-server_removed
    - high_severity
    - disable_strategy
    - low_complexity
    - low_disruption
    - CCE-27342-5
    - NIST-800-53-AC-17(8)
    - NIST-800-53-CM-7(a)


Complexity:low
Disruption:low
Strategy:disable
include remove_rsh-server

class remove_rsh-server {
  package { 'rsh-server':
    ensure => 'purged',
  }
}
Group   TFTP Server   Group contains 2 rules

[ref]   TFTP is a lightweight version of the FTP protocol which has traditionally been used to configure networking equipment. However, TFTP provides little security, and modern versions of networking operating systems frequently support configuration via SSH or other more secure protocols. A TFTP server should be run only if no more secure method of supporting existing equipment can be found.

Rule   Remove tftp Daemon   [ref]

Trivial File Transfer Protocol (TFTP) is a simple file transfer protocol, typically used to automatically transfer configuration or boot files between systems. TFTP does not support authentication and can be easily hacked. The package tftp is a client program that allows for connections to a tftp server.

Rationale:

It is recommended that TFTP be removed, unless there is a specific need for TFTP (such as a boot server). In that case, use extreme caution when configuring the services.

Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_package_tftp_removed
Identifiers and References


Complexity:low
Disruption:low
Strategy:disable
# Function to remove packages on RHEL, Fedora, Debian, and possibly other systems.
#
# Example Call(s):
#
#     package_remove telnet-server
#
function package_remove {

# Load function arguments into local variables
local package="$1"

# Check sanity of the input
if [ $# -ne "1" ]
then
  echo "Usage: package_remove 'package_name'"
  echo "Aborting."
  exit 1
fi

if which dnf ; then
  if rpm -q --quiet "$package"; then
    dnf remove -y "$package"
  fi
elif which yum ; then
  if rpm -q --quiet "$package"; then
    yum remove -y "$package"
  fi
elif which apt-get ; then
  apt-get remove -y "$package"
else
  echo "Failed to detect available packaging system, tried dnf, yum and apt-get!"
  echo "Aborting."
  exit 1
fi

}

package_remove tftp


Complexity:low
Disruption:low
Strategy:disable
- name: Ensure tftp is removed
  package:
    name="{{item}}"
    state=absent
  with_items:
    - tftp
  tags:
    - package_tftp_removed
    - high_severity
    - disable_strategy
    - low_complexity
    - low_disruption


Complexity:low
Disruption:low
Strategy:disable
include remove_tftp

class remove_tftp {
  package { 'tftp':
    ensure => 'purged',
  }
}

Rule   Uninstall tftp-server Package   [ref]

The tftp-server package can be removed with the following command:

$ sudo yum erase tftp-server

Rationale:

Removing the tftp-server package decreases the risk of the accidental (or intentional) activation of tftp services.

If TFTP is required for operational support (such as transmission of router configurations), its use must be documented with the Information Systems Securty Manager (ISSM), restricted to only authorized personnel, and have access control rules established.

Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_package_tftp-server_removed
Identifiers and References

References:  CCI-000318, CCI-000368, CCI-001812, CCI-001813, CCI-001814, AC-17(8), CM-6(c), CM-7, SRG-OS-000480-GPOS-00227



Complexity:low
Disruption:low
Strategy:disable
# Function to remove packages on RHEL, Fedora, Debian, and possibly other systems.
#
# Example Call(s):
#
#     package_remove telnet-server
#
function package_remove {

# Load function arguments into local variables
local package="$1"

# Check sanity of the input
if [ $# -ne "1" ]
then
  echo "Usage: package_remove 'package_name'"
  echo "Aborting."
  exit 1
fi

if which dnf ; then
  if rpm -q --quiet "$package"; then
    dnf remove -y "$package"
  fi
elif which yum ; then
  if rpm -q --quiet "$package"; then
    yum remove -y "$package"
  fi
elif which apt-get ; then
  apt-get remove -y "$package"
else
  echo "Failed to detect available packaging system, tried dnf, yum and apt-get!"
  echo "Aborting."
  exit 1
fi

}

package_remove tftp-server


Complexity:low
Disruption:low
Strategy:disable
- name: Ensure tftp-server is removed
  package:
    name="{{item}}"
    state=absent
  with_items:
    - tftp-server
  tags:
    - package_tftp-server_removed
    - high_severity
    - disable_strategy
    - low_complexity
    - low_disruption
    - NIST-800-53-AC-17(8)
    - NIST-800-53-CM-6(c)
    - NIST-800-53-CM-7


Complexity:low
Disruption:low
Strategy:disable
include remove_tftp-server

class remove_tftp-server {
  package { 'tftp-server':
    ensure => 'purged',
  }
}
Group   Chat/Messaging Services   Group contains 2 rules

[ref]   The talk software makes it possible for users to send and receive messages across systems through a terminal session.

Rule   Uninstall talk Package   [ref]

The talk package contains the client program for the Internet talk protocol, which allows the user to chat with other users on different systems. Talk is a communication program which copies lines from one terminal to the terminal of another user. The talk package can be removed with the following command:

$ sudo yum erase talk

Rationale:

The talk software presents a security risk as it uses unencrypted protocols for communications. Removing the talk package decreases the risk of the accidental (or intentional) activation of talk client program.

Severity: 
unknown
Rule ID:xccdf_org.ssgproject.content_rule_package_talk_removed
Identifiers and References

Identifiers:  CCE-27432-4

References:  2.3.3, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii)



Complexity:low
Disruption:low
Strategy:disable
# Function to remove packages on RHEL, Fedora, Debian, and possibly other systems.
#
# Example Call(s):
#
#     package_remove telnet-server
#
function package_remove {

# Load function arguments into local variables
local package="$1"

# Check sanity of the input
if [ $# -ne "1" ]
then
  echo "Usage: package_remove 'package_name'"
  echo "Aborting."
  exit 1
fi

if which dnf ; then
  if rpm -q --quiet "$package"; then
    dnf remove -y "$package"
  fi
elif which yum ; then
  if rpm -q --quiet "$package"; then
    yum remove -y "$package"
  fi
elif which apt-get ; then
  apt-get remove -y "$package"
else
  echo "Failed to detect available packaging system, tried dnf, yum and apt-get!"
  echo "Aborting."
  exit 1
fi

}

package_remove talk


Complexity:low
Disruption:low
Strategy:disable
- name: Ensure talk is removed
  package:
    name="{{item}}"
    state=absent
  with_items:
    - talk
  tags:
    - package_talk_removed
    - unknown_severity
    - disable_strategy
    - low_complexity
    - low_disruption
    - CCE-27432-4


Complexity:low
Disruption:low
Strategy:disable
include remove_talk

class remove_talk {
  package { 'talk':
    ensure => 'purged',
  }
}

Rule   Uninstall talk-server Package   [ref]

The talk-server package can be removed with the following command:

$ sudo yum erase talk-server

Rationale:

The talk software presents a security risk as it uses unencrypted protocols for communications. Removing the talk-server package decreases the risk of the accidental (or intentional) activation of talk services.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_talk-server_removed
Identifiers and References

Identifiers:  CCE-27210-4

References:  2.2.21, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii)



Complexity:low
Disruption:low
Strategy:disable
# Function to remove packages on RHEL, Fedora, Debian, and possibly other systems.
#
# Example Call(s):
#
#     package_remove telnet-server
#
function package_remove {

# Load function arguments into local variables
local package="$1"

# Check sanity of the input
if [ $# -ne "1" ]
then
  echo "Usage: package_remove 'package_name'"
  echo "Aborting."
  exit 1
fi

if which dnf ; then
  if rpm -q --quiet "$package"; then
    dnf remove -y "$package"
  fi
elif which yum ; then
  if rpm -q --quiet "$package"; then
    yum remove -y "$package"
  fi
elif which apt-get ; then
  apt-get remove -y "$package"
else
  echo "Failed to detect available packaging system, tried dnf, yum and apt-get!"
  echo "Aborting."
  exit 1
fi

}

package_remove talk-server


Complexity:low
Disruption:low
Strategy:disable
- name: Ensure talk-server is removed
  package:
    name="{{item}}"
    state=absent
  with_items:
    - talk-server
  tags:
    - package_talk-server_removed
    - medium_severity
    - disable_strategy
    - low_complexity
    - low_disruption
    - CCE-27210-4


Complexity:low
Disruption:low
Strategy:disable
include remove_talk-server

class remove_talk-server {
  package { 'talk-server':
    ensure => 'purged',
  }
}
Group   IMAP and POP3 Server   Group contains 1 group and 1 rule

[ref]   Dovecot provides IMAP and POP3 services. It is not installed by default. The project page at http://www.dovecot.org contains more detailed information about Dovecot configuration.

Group   Disable Dovecot   Group contains 1 rule

[ref]   If the system does not need to operate as an IMAP or POP3 server, the dovecot software should be disabled and removed.

Rule   Uninstall dovecot Package   [ref]

The dovecot package can be uninstalled with the following command:

$ sudo yum erase dovecot

Rationale:

If there is no need to make the Dovecot software available, removing it provides a safeguard against its activation.

Severity: 
unknown
Rule ID:xccdf_org.ssgproject.content_rule_package_dovecot_removed
Identifiers and References

Identifiers:  CCE-80295-9



Complexity:low
Disruption:low
Strategy:disable
# Function to remove packages on RHEL, Fedora, Debian, and possibly other systems.
#
# Example Call(s):
#
#     package_remove telnet-server
#
function package_remove {

# Load function arguments into local variables
local package="$1"

# Check sanity of the input
if [ $# -ne "1" ]
then
  echo "Usage: package_remove 'package_name'"
  echo "Aborting."
  exit 1
fi

if which dnf ; then
  if rpm -q --quiet "$package"; then
    dnf remove -y "$package"
  fi
elif which yum ; then
  if rpm -q --quiet "$package"; then
    yum remove -y "$package"
  fi
elif which apt-get ; then
  apt-get remove -y "$package"
else
  echo "Failed to detect available packaging system, tried dnf, yum and apt-get!"
  echo "Aborting."
  exit 1
fi

}

package_remove dovecot


Complexity:low
Disruption:low
Strategy:disable
- name: Ensure dovecot is removed
  package:
    name="{{item}}"
    state=absent
  with_items:
    - dovecot
  tags:
    - package_dovecot_removed
    - unknown_severity
    - disable_strategy
    - low_complexity
    - low_disruption
    - CCE-80295-9


Complexity:low
Disruption:low
Strategy:disable
include remove_dovecot

class remove_dovecot {
  package { 'dovecot':
    ensure => 'purged',
  }
}
Group   Network Routing   Group contains 1 group and 1 rule

[ref]   A router is a very desirable target for a potential adversary because they fulfill a variety of infrastructure networking roles such as access to network segments, gateways to other networks, filtering, etc. Therefore, if one is required, the system acting as a router should be dedicated to that purpose alone and be stored in a physically secure location. The system's default routing software is Quagga, and provided in an RPM package of the same name.

Group   Disable Quagga if Possible   Group contains 1 rule

[ref]   If Quagga was installed and activated, but the system does not need to act as a router, then it should be disabled and removed.

Rule   Uninstall quagga Package   [ref]

The quagga package can be removed with the following command:

$ sudo yum erase quagga

Rationale:

Routing software is typically used on routers to exchange network topology information with other routers. If routing software is used when not required, system network information may be unnecessarily transmitted across the network.
If there is no need to make the router software available, removing it provides a safeguard against its activation.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_quagga_removed
Identifiers and References

Identifiers:  CCE-27594-1

References:  CCI-000366, SC-32, SRG-OS-000480-GPOS-00227



Complexity:low
Disruption:low
Strategy:disable
# Function to remove packages on RHEL, Fedora, Debian, and possibly other systems.
#
# Example Call(s):
#
#     package_remove telnet-server
#
function package_remove {

# Load function arguments into local variables
local package="$1"

# Check sanity of the input
if [ $# -ne "1" ]
then
  echo "Usage: package_remove 'package_name'"
  echo "Aborting."
  exit 1
fi

if which dnf ; then
  if rpm -q --quiet "$package"; then
    dnf remove -y "$package"
  fi
elif which yum ; then
  if rpm -q --quiet "$package"; then
    yum remove -y "$package"
  fi
elif which apt-get ; then
  apt-get remove -y "$package"
else
  echo "Failed to detect available packaging system, tried dnf, yum and apt-get!"
  echo "Aborting."
  exit 1
fi

}

package_remove quagga


Complexity:low
Disruption:low
Strategy:disable
- name: Ensure quagga is removed
  package:
    name="{{item}}"
    state=absent
  with_items:
    - quagga
  tags:
    - package_quagga_removed
    - medium_severity
    - disable_strategy
    - low_complexity
    - low_disruption
    - CCE-27594-1
    - NIST-800-53-SC-32


Complexity:low
Disruption:low
Strategy:disable
include remove_quagga

class remove_quagga {
  package { 'quagga':
    ensure => 'purged',
  }
}
Group   Mail Server Software   Group contains 1 rule

[ref]   Mail servers are used to send and receive email over the network. Mail is a very common service, and Mail Transfer Agents (MTAs) are obvious targets of network attack. Ensure that systems are not running MTAs unnecessarily, and configure needed MTAs as defensively as possible.

Very few systems at any site should be configured to directly receive email over the network. Users should instead use mail client programs to retrieve email from a central server that supports protocols such as IMAP or POP3. However, it is normal for most systems to be independently capable of sending email, for instance so that cron jobs can report output to an administrator. Most MTAs, including Postfix, support a submission-only mode in which mail can be sent from the local system to a central site MTA (or directly delivered to a local account), but the system still cannot receive mail directly over a network.

The alternatives program in Red Hat Enterprise Linux permits selection of other mail server software (such as Sendmail), but Postfix is the default and is preferred. Postfix was coded with security in mind and can also be more effectively contained by SELinux as its modular design has resulted in separate processes performing specific actions. More information is available on its website, http://www.postfix.org.

Rule   Install postfix   [ref]

Install the postfix package with the command:

$ sudo yum install postfix

Rationale:

postfix is a software package for sending and receiving mail on Linux operating systems. It is an open source mail transfer agent that can be used to send and receive email and supports protocols such as SMTP, POP3, and IMAP.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_postfix_installed
Identifiers and References


Complexity:low
Disruption:low
Strategy:enable
- name: Ensure postfix is installed
  package:
    name="{{item}}"
    state=present
  with_items:
    - postfix
  tags:
    - package_postfix_installed
    - medium_severity
    - enable_strategy
    - low_complexity
    - low_disruption


Complexity:low
Disruption:low
Strategy:enable
include install_postfix

class install_postfix {
  package { 'postfix':
    ensure => 'installed',
  }
}
Group   Samba(SMB) Microsoft Windows File Sharing Server   Group contains 1 group and 1 rule

[ref]   When properly configured, the Samba service allows Linux systems to provide file and print sharing to Microsoft Windows systems. There are two software packages that provide Samba support. The first, samba-client, provides a series of command line tools that enable a client system to access Samba shares. The second, simply labeled samba, provides the Samba service. It is this second package that allows a Linux system to act as an Active Directory server, a domain controller, or as a domain member. Only the samba-client package is installed by default.

Group   Configure Samba if Necessary   Group contains 1 rule

[ref]   All settings for the Samba daemon can be found in /etc/samba/smb.conf. Settings are divided between a [global] configuration section and a series of user created share definition sections meant to describe file or print shares on the system. By default, Samba will operate in user mode and allow client systems to access local home directories and printers. It is recommended that these settings be changed or that additional limitations be set in place.

Rule   Install the Samba Common Package   [ref]

The samba-common package should be installed. The samba-common package can be installed with the following command:

$ sudo yum install samba-common

Rationale:

If the samba-common package is not installed, samba cannot be configured.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_samba-common_installed
Identifiers and References

Identifiers:  CCE-80360-1



Complexity:low
Disruption:low
Strategy:enable
- name: Ensure samba-common is installed
  package:
    name="{{item}}"
    state=present
  with_items:
    - samba-common
  tags:
    - package_samba-common_installed
    - medium_severity
    - enable_strategy
    - low_complexity
    - low_disruption
    - CCE-80360-1


Complexity:low
Disruption:low
Strategy:enable
include install_samba-common

class install_samba-common {
  package { 'samba-common':
    ensure => 'installed',
  }
}
Group   Network Time Protocol   Group contains 2 rules

[ref]   The Network Time Protocol is used to manage the system clock over a network. Computer clocks are not very accurate, so time will drift unpredictably on unmanaged systems. Central time protocols can be used both to ensure that time is consistent among a network of systems, and that their time is consistent with the outside world.

If every system on a network reliably reports the same time, then it is much easier to correlate log messages in case of an attack. In addition, a number of cryptographic protocols (such as Kerberos) use timestamps to prevent certain types of attacks. If your network does not have synchronized time, these protocols may be unreliable or even unusable.

Depending on the specifics of the network, global time accuracy may be just as important as local synchronization, or not very important at all. If your network is connected to the Internet, using a public timeserver (or one provided by your enterprise) provides globally accurate timestamps which may be essential in investigating or responding to an attack which originated outside of your network.

A typical network setup involves a small number of internal systems operating as NTP servers, and the remainder obtaining time information from those internal servers.

There is a choice between the daemons ntpd and chronyd, which are available from the repositories in the ntp and chrony packages respectively.

The default chronyd daemon can work well when external time references are only intermittently accesible, can perform well even when the network is congested for longer periods of time, can usually synchronize the clock faster and with better time accuracy, and quickly adapts to sudden changes in the rate of the clock, for example, due to changes in the temperature of the crystal oscillator. Chronyd should be considered for all systems which are frequently suspended or otherwise intermittently disconnected and reconnected to a network. Mobile and virtual systems for example.

The ntpd NTP daemon fully supports NTP protocol version 4 (RFC 5905), including broadcast, multicast, manycast clients and servers, and the orphan mode. It also supports extra authentication schemes based on public-key cryptography (RFC 5906). The NTP daemon (ntpd) should be considered for systems which are normally kept permanently on. Systems which are required to use broadcast or multicast IP, or to perform authentication of packets with the Autokey protocol, should consider using ntpd.

Refer to https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Configuring_NTP_Using_the_chrony_Suite.html for more detailed comparison of features of chronyd and ntpd daemon features respectively, and for further guidance how to choose between the two NTP daemons.

The upstream manual pages at http://chrony.tuxfamily.org/manual.html for chronyd and http://www.ntp.org for ntpd provide additional information on the capabilities and configuration of each of the NTP daemons.

Rule   Install cronie   [ref]

check whether the cronie software package is installed.

Rationale:

cronie is a tool used to manage scheduled tasks in Linux. It is often used to manage scheduled tasks of the system, such as periodic backup and periodic clearing.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_cronie_installed
Identifiers and References


Complexity:low
Disruption:low
Strategy:enable
- name: Ensure cronie is installed
  package:
    name="{{item}}"
    state=present
  with_items:
    - cronie
  tags:
    - package_cronie_installed
    - medium_severity
    - enable_strategy
    - low_complexity
    - low_disruption


Complexity:low
Disruption:low
Strategy:enable
include install_cronie

class install_cronie {
  package { 'cronie':
    ensure => 'installed',
  }
}

Rule   Install chrony   [ref]

Install or update the Chrony time synchronization software package

Rationale:

Chrony is a daemon which implements the Network Time Protocol (NTP). It is designed to synchronize system clocks across a variety of systems More information on chrony can be found at http://chrony.tuxfamily.org/. Chrony can be configured to be a client and/or a server. Add or edit server or pool lines to /etc/chrony.conf as appropriate.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_chrony_installed
Identifiers and References

Identifiers:  CCE-84299-7

References:  1.3.1, 5.10.1.3, CM-3(d), CM-3(e), CM-6(d), CM-6(3), SC-28, SI-7, Req-11.5



Complexity:low
Disruption:low
Strategy:enable
- name: Ensure chrony is installed
  package:
    name="{{item}}"
    state=present
  with_items:
    - chrony
  tags:
    - package_chrony_installed
    - medium_severity
    - enable_strategy
    - low_complexity
    - low_disruption
    - CCE-84299-7
    - NIST-800-53-CM-3(d)
    - NIST-800-53-CM-3(e)
    - NIST-800-53-CM-6(d)
    - NIST-800-53-CM-6(3)
    - NIST-800-53-SC-28
    - NIST-800-53-SI-7
    - PCI-DSS-Req-11.5
    - CJIS-5.10.1.3


Complexity:low
Disruption:low
Strategy:enable
include install_chrony

class install_chrony {
  package { 'chrony':
    ensure => 'installed',
  }
}
Group   Base Services   Group contains 2 rules

[ref]   This section addresses the base services that are installed on a Red Hat Enterprise Linux 7 default installation which are not covered in other sections. Some of these services listen on the network and should be treated with particular discretion. Other services are local system utilities that may or may not be extraneous. In general, system services should be disabled if not required.

Rule   Install the ntp service   [ref]

The ntpd service should be installed.

Rationale:

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.

Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_package_ntp_installed
Identifiers and References

Identifiers:  CCE-

References:  NT012(R03), CCI-000160, AU-8(1), Req-10.4



Complexity:low
Disruption:low
Strategy:enable
- name: Ensure ntp is installed
  package:
    name="{{item}}"
    state=present
  with_items:
    - ntp
  tags:
    - package_ntp_installed
    - high_severity
    - enable_strategy
    - low_complexity
    - low_disruption
    - CCE-
    - NIST-800-53-AU-8(1)
    - PCI-DSS-Req-10.4


Complexity:low
Disruption:low
Strategy:enable
include install_ntp

class install_ntp {
  package { 'ntp':
    ensure => 'installed',
  }
}

Rule   Disable KDump Kernel Crash Analyzer (kdump)   [ref]

The kdump service provides a kernel crash dump analyzer. It uses the kexec system call to boot a secondary kernel ("capture" kernel) following a system crash, which can load information from the crashed kernel for analysis. The kdump service can be disabled with the following command:

$ sudo systemctl disable kdump.service

Rationale:

Kernel core dumps may contain the full contents of system memory at the time of the crash. Kernel core dumps consume a considerable amount of disk space and may result in denial of service by exhausting the available space on the target file system partition. Unless the system is used for kernel development or testing, there is little need to run the kdump service.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_service_kdump_disabled
Identifiers and References

Identifiers:  CCE-80258-7

References:  KYLIN-10-021300, CCI-000366, 164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e), AC-17(8), CM-7, CM-6(b), SRG-OS-000480-GPOS-00227



Complexity:low
Disruption:low
Strategy:disable
- name: Disable service kdump
  service:
    name="{{item}}"
    enabled="no"
    state="stopped"
  register: service_result
  failed_when: "service_result|failed and ('Could not find the requested service' not in service_result.msg)"
  with_items:
    - kdump
  tags:
    - service_kdump_disabled
    - medium_severity
    - disable_strategy
    - low_complexity
    - low_disruption
    - CCE-80258-7
    - NIST-800-53-AC-17(8)
    - NIST-800-53-CM-7
    - NIST-800-53-CM-6(b)
    - DISA-STIG-KYLIN-10-021300
Group   SSH Server   Group contains 1 group and 4 rules

[ref]   The SSH protocol is recommended for remote login and remote file transfer. SSH provides confidentiality and integrity for data exchanged between two systems, as well as server authentication, through the use of public key cryptography. The implementation included with the system is called OpenSSH, and more detailed documentation is available from its website, http://www.openssh.org. Its server program is called sshd and provided by the RPM package openssh-server.

Group   Configure OpenSSH Server if Necessary   Group contains 3 rules

[ref]   If the system needs to act as an SSH server, then certain changes should be made to the OpenSSH daemon configuration file /etc/ssh/sshd_config. The following recommendations can be applied to this file. See the sshd_config(5) man page for more detailed information.

Rule   Allow Only SSH Protocol 2   [ref]

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

Rationale:

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.

Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_sshd_allow_only_protocol2
Identifiers and References

References:  5.2.2, 5.5.6, 3.1.13, 3.5.4, CCI-000197, CCI-000366, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), AC-17(8).1(ii), IA-5(1)(c), SRG-OS-000074-GPOS-00042, SRG-OS-000480-GPOS-00227

Rule   Disable SSH Support for .rhosts Files   [ref]

SSH can emulate the behavior of the obsolete rsh command in allowing users to enable insecure access to their accounts via .rhosts files.

To ensure this behavior is disabled, add or correct the following line in /etc/ssh/sshd_config:

IgnoreRhosts yes

Rationale:

SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sshd_disable_rhosts
Identifiers and References

References:  5.2.6, 5.5.6, 3.1.12, CCI-000366, AC-3, CM-6(a), SRG-OS-000480-GPOS-00227

Rule   Disable Host-Based Authentication   [ref]

SSH's cryptographic host-based authentication is more secure than .rhosts authentication. However, it is not recommended that hosts unilaterally trust one another, even within an organization.

To disable host-based authentication, add or correct the following line in /etc/ssh/sshd_config:

HostbasedAuthentication no

Rationale:

SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_disable_host_auth
Identifiers and References

References:  5.2.7, 5.5.6, 3.1.12, CCI-000366, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), AC-3, CM-6(b), SRG-OS-000480-GPOS-00229

Rule   Uninstall certmonger Package   [ref]

The certmonger software package has been removed

Rationale:

Certmonger is an open source tool for managing SSL certificates that helps administrators automate the certificate application, renewal, and revocation process. Certmonger supports multiple certificate authorities (cas) and can be integrated with a variety of Linux systems.

Severity: 
unknown
Rule ID:xccdf_org.ssgproject.content_rule_package_certmonger_removed
Identifiers and References


Complexity:low
Disruption:low
Strategy:disable
# Function to remove packages on RHEL, Fedora, Debian, and possibly other systems.
#
# Example Call(s):
#
#     package_remove telnet-server
#
function package_remove {

# Load function arguments into local variables
local package="$1"

# Check sanity of the input
if [ $# -ne "1" ]
then
  echo "Usage: package_remove 'package_name'"
  echo "Aborting."
  exit 1
fi

if which dnf ; then
  if rpm -q --quiet "$package"; then
    dnf remove -y "$package"
  fi
elif which yum ; then
  if rpm -q --quiet "$package"; then
    yum remove -y "$package"
  fi
elif which apt-get ; then
  apt-get remove -y "$package"
else
  echo "Failed to detect available packaging system, tried dnf, yum and apt-get!"
  echo "Aborting."
  exit 1
fi

}

package_remove certmonger


Complexity:low
Disruption:low
Strategy:disable
- name: Ensure certmonger is removed
  package:
    name="{{item}}"
    state=absent
  with_items:
    - certmonger
  tags:
    - package_certmonger_removed
    - unknown_severity
    - disable_strategy
    - low_complexity
    - low_disruption


Complexity:low
Disruption:low
Strategy:disable
include remove_certmonger

class remove_certmonger {
  package { 'certmonger':
    ensure => 'purged',
  }
}
Group   System Settings   Group contains 28 groups and 34 rules

[ref]   Contains rules that check correct system settings.

Group   Configure Syslog   Group contains 1 rule

[ref]   The syslog service has been the default Unix logging mechanism for many years. It has a number of downsides, including inconsistent log format, lack of authentication for received messages, and lack of authentication, encryption, or reliable transport for messages sent over a network. However, due to its long history, syslog is a de facto standard which is supported by almost all Unix applications.

In Red Hat Enterprise Linux 7, rsyslog has replaced ksyslogd as the syslog daemon of choice, and it includes some additional security features such as reliable, connection-oriented (i.e. TCP) transmission of logs, the option to log to database formats, and the encryption of log data en route to a central logging server. This section discusses how to configure rsyslog for best effect, and how to use tools provided with the system to maintain and monitor logs.

Rule   Ensure rsyslog is Installed   [ref]

Rsyslog is installed by default. The rsyslog package can be installed with the following command:

$ sudo yum install rsyslog

Rationale:

The rsyslog package provides the rsyslog daemon, which provides system logging services.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_rsyslog_installed
Identifiers and References

Identifiers:  CCE-80187-8

References:  NT28(R5), NT28(R46), 4.2.3, CCI-001311, CCI-001312, 164.312(a)(2)(ii), A.12.3.1, AU-9(2)



Complexity:low
Disruption:low
Strategy:enable
- name: Ensure rsyslog is installed
  package:
    name="{{item}}"
    state=present
  with_items:
    - rsyslog
  tags:
    - package_rsyslog_installed
    - medium_severity
    - enable_strategy
    - low_complexity
    - low_disruption
    - CCE-80187-8
    - NIST-800-53-AU-9(2)


Complexity:low
Disruption:low
Strategy:enable
include install_rsyslog

class install_rsyslog {
  package { 'rsyslog':
    ensure => 'installed',
  }
}
Group   Network Configuration and Firewalls   Group contains 4 groups and 3 rules

[ref]   Most systems must be connected to a network of some sort, and this brings with it the substantial risk of network attack. This section discusses the security impact of decisions about networking which must be made when configuring a system.

This section also discusses firewalls, network access controls, and other network security frameworks, which allow system-level rules to be written that can limit an attackers' ability to connect to your system. These rules can specify that network traffic should be allowed or denied from certain IP addresses, hosts, and networks. The rules can also specify which of the system's network services are available to particular hosts or networks.

Group   IPSec Support   Group contains 1 rule

[ref]   Support for Internet Protocol Security (IPsec) is provided in Red Hat Enterprise Linux 7 with Libreswan.

Rule   Install libreswan Package   [ref]

The Libreswan package provides an implementation of IPsec and IKE, which permits the creation of secure tunnels over untrusted networks. The libreswan package can be installed with the following command:

$ sudo yum install libreswan

Rationale:

Providing the ability for remote users or systems to initiate a secure VPN connection protects information when it is transmitted over a wide area network.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_libreswan_installed
Identifiers and References

Identifiers:  CCE-80170-4

References:  CCI-001130, CCI-001131, AC-17, MA-4, SC-9, Req-4.1



Complexity:low
Disruption:low
Strategy:enable
- name: Ensure libreswan is installed
  package:
    name="{{item}}"
    state=present
  with_items:
    - libreswan
  tags:
    - package_libreswan_installed
    - medium_severity
    - enable_strategy
    - low_complexity
    - low_disruption
    - CCE-80170-4
    - NIST-800-53-AC-17
    - NIST-800-53-MA-4
    - NIST-800-53-SC-9
    - PCI-DSS-Req-4.1


Complexity:low
Disruption:low
Strategy:enable
include install_libreswan

class install_libreswan {
  package { 'libreswan':
    ensure => 'installed',
  }
}
Group   firewalld   Group contains 1 group and 1 rule

[ref]   The dynamic firewall daemon firewalld provides a dynamically managed firewall with support for network “zones” to assign a level of trust to a network and its associated connections and interfaces. It has support for IPv4 and IPv6 firewall settings. It supports Ethernet bridges and has a separation of runtime and permanent configuration options. It also has an interface for services or applications to add firewall rules directly.
A graphical configuration tool, firewall-config, is used to configure firewalld, which in turn uses iptables tool to communicate with Netfilter in the kernel which implements packet filtering.
The firewall service provided by firewalld is dynamic rather than static because changes to the configuration can be made at anytime and are immediately implemented. There is no need to save or apply the changes. No unintended disruption of existing network connections occurs as no part of the firewall has to be reloaded.

Group   Inspect and Activate Default firewalld Rules   Group contains 1 rule

[ref]   Firewalls can be used to separate networks into different zones based on the level of trust the user has decided to place on the devices and traffic within that network. NetworkManager informs firewalld to which zone an interface belongs. An interface's assigned zone can be changed by NetworkManager or via the firewall-config tool.
The zone settings in /etc/firewalld/ are a range of preset settings which can be quickly applied to a network interface. These are the zones provided by firewalld sorted according to the default trust level of the zones from untrusted to trusted:

  • drop

    Any incoming network packets are dropped, there is no reply. Only outgoing network connections are possible.

  • block

    Any incoming network connections are rejected with an icmp-host-prohibited message for IPv4 and icmp6-adm-prohibited for IPv6. Only network connections initiated from within the system are possible.

  • public

    For use in public areas. You do not trust the other computers on the network to not harm your computer. Only selected incoming connections are accepted.

  • external

    For use on external networks with masquerading enabled especially for routers. You do not trust the other computers on the network to not harm your computer. Only selected incoming connections are accepted.

  • dmz

    For computers in your demilitarized zone that are publicly-accessible with limited access to your internal network. Only selected incoming connections are accepted.

  • work

    For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

  • home

    For use in home areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

  • internal

    For use on internal networks. You mostly trust the other computers on the networks to not harm your computer. Only selected incoming connections are accepted.

  • trusted

    All network connections are accepted.


It is possible to designate one of these zones to be the default zone. When interface connections are added to NetworkManager, they are assigned to the default zone. On installation, the default zone in firewalld is set to be the public zone.
To find out all the settings of a zone, for example the public zone, enter the following command as root:
# firewall-cmd --zone=public --list-all
Example output of this command might look like the following:
# firewall-cmd --zone=public --list-all
public
  interfaces:
  services: mdns dhcpv6-client ssh
  ports:
  forward-ports:
  icmp-blocks: source-quench
To view the network zones currently active, enter the following command as root:
# firewall-cmd --get-service
The following listing displays the result of this command on common Red Hat Enterprise Linux 7 Server system:
# firewall-cmd --get-service
amanda-client bacula bacula-client dhcp dhcpv6 dhcpv6-client dns ftp
high-availability http https imaps ipp ipp-client ipsec kerberos kpasswd
ldap ldaps libvirt libvirt-tls mdns mountd ms-wbt mysql nfs ntp openvpn
pmcd pmproxy pmwebapi pmwebapis pop3s postgresql proxy-dhcp radius rpc-bind
samba samba-client smtp ssh telnet tftp tftp-client transmission-client
vnc-server wbem-https
Finally to view the network zones that will be active after the next firewalld service reload, enter the following command as root:
# firewall-cmd --get-service --permanent

Rule   Install firewalld   [ref]

Install the firewalld package with the command:

$ sudo yum install firewalld

Rationale:

The firewalld package should be installed to provide access control methods.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_firewalld_installed
Identifiers and References


Complexity:low
Disruption:low
Strategy:enable
- name: Ensure firewalld is installed
  package:
    name="{{item}}"
    state=present
  with_items:
    - firewalld
  tags:
    - package_firewalld_installed
    - medium_severity
    - enable_strategy
    - low_complexity
    - low_disruption


Complexity:low
Disruption:low
Strategy:enable
include install_firewalld

class install_firewalld {
  package { 'firewalld':
    ensure => 'installed',
  }
}
Group   Uncommon Network Protocols   Group contains 1 rule

[ref]   The system includes support for several network protocols which are not commonly used. Although security vulnerabilities in kernel networking code are not frequently discovered, the consequences can be dramatic. Ensuring uncommon network protocols are disabled reduces the system's risk to attacks targeted at its implementation of those protocols.

Rule   Uninstall avahi Package   [ref]

The avahi software package has been removed

Rationale:

Avahi is an open source network service discovery framework that helps devices discover and communicate with each other on a local network without the need to use a central server. Avahi provides support for several network service discovery protocols.

Severity: 
unknown
Rule ID:xccdf_org.ssgproject.content_rule_package_avahi_removed
Identifiers and References


Complexity:low
Disruption:low
Strategy:disable
# Function to remove packages on RHEL, Fedora, Debian, and possibly other systems.
#
# Example Call(s):
#
#     package_remove telnet-server
#
function package_remove {

# Load function arguments into local variables
local package="$1"

# Check sanity of the input
if [ $# -ne "1" ]
then
  echo "Usage: package_remove 'package_name'"
  echo "Aborting."
  exit 1
fi

if which dnf ; then
  if rpm -q --quiet "$package"; then
    dnf remove -y "$package"
  fi
elif which yum ; then
  if rpm -q --quiet "$package"; then
    yum remove -y "$package"
  fi
elif which apt-get ; then
  apt-get remove -y "$package"
else
  echo "Failed to detect available packaging system, tried dnf, yum and apt-get!"
  echo "Aborting."
  exit 1
fi

}

package_remove avahi


Complexity:low
Disruption:low
Strategy:disable
- name: Ensure avahi is removed
  package:
    name="{{item}}"
    state=absent
  with_items:
    - avahi
  tags:
    - package_avahi_removed
    - unknown_severity
    - disable_strategy
    - low_complexity
    - low_disruption


Complexity:low
Disruption:low
Strategy:disable
include remove_avahi

class remove_avahi {
  package { 'avahi':
    ensure => 'purged',
  }
}
Group   Account and Access Control   Group contains 9 groups and 15 rules

[ref]   In traditional Unix security, if an attacker gains shell access to a certain login account, they can perform any action or access any file to which that account has access. Therefore, making it more difficult for unauthorized people to gain shell access to accounts, particularly to privileged accounts, is a necessary part of securing a system. This section introduces mechanisms for restricting access to accounts under Kylin Linux Advanced Server V10.

Group   Protect Accounts by Restricting Password-Based Login   Group contains 2 groups and 5 rules

[ref]   Conventionally, Unix shell accounts are accessed by providing a username and password to a login program, which tests these values for correctness using the /etc/passwd and /etc/shadow files. Password-based login is vulnerable to guessing of weak passwords, and to sniffing and man-in-the-middle attacks against passwords entered over a network or at an insecure console. Therefore, mechanisms for accessing accounts by entering usernames and passwords should be restricted to those which are operationally necessary.

Group   Restrict Root Logins   Group contains 1 rule

[ref]   Direct root logins should be allowed only for emergency use. In normal situations, the administrator should access the system via a unique unprivileged account, and then use su or sudo to execute privileged commands. Discouraging administrators from accessing the root account directly ensures an audit trail in organizations with multiple administrators. Locking down the channels through which root can connect directly also reduces opportunities for password-guessing against the root account. The login program uses the file /etc/securetty to determine which interfaces should allow root logins. The virtual devices /dev/console and /dev/tty* represent the system consoles (accessible via the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default installation). The default securetty file also contains /dev/vc/*. These are likely to be deprecated in most environments, but may be retained for compatibility. Root should also be prohibited from connecting via network protocols. Other sections of this document include guidance describing how to prevent root from logging in via SSH.

Rule   Verify Only Root Has UID 0   [ref]

If any account other than root has a UID of 0, this misconfiguration should be investigated and the accounts other than root should be removed or have their UID changed.
If the account is associated with system commands or applications the UID should be changed to one greater than "0" but less than "1000." Otherwise assign a UID greater than "1000" that has not already been assigned.

Rationale:

An account has root authority if it has a UID of 0. Multiple accounts with a UID of 0 afford more opportunity for potential intruders to guess a password for a privileged account. Proper configuration of sudo is recommended to afford multiple system administrators access to root privileges in an accountable manner.

Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_accounts_no_uid_except_zero
Identifiers and References

Identifiers:  CCE-27175-9

References:  KYLIN-10-020310, 6.2.5, 3.1.1, 3.1.5, CCI-000366, AC-6, IA-2(1), IA-4, SRG-OS-000480-GPOS-00227

Group   Verify Proper Storage and Existence of Password Hashes   Group contains 1 rule

[ref]   By default, password hashes for local accounts are stored in the second field (colon-separated) in /etc/shadow. This file should be readable only by processes running with root credentials, preventing users from casually accessing others' password hashes and attempting to crack them. However, it remains possible to misconfigure the system and store password hashes in world-readable files such as /etc/passwd, or to even store passwords themselves in plaintext on the system. Using system-provided tools for password change/creation should allow administrators to avoid such misconfiguration.

Rule   All GIDs referenced in /etc/passwd must be defined in /etc/group   [ref]

Add a group to the system for each GID referenced without a corresponding group.

Rationale:

If a user is assigned the Group Identifier (GID) of a group not existing on the system, and a group with the Gruop Identifier (GID) is subsequently created, the user may have unintended rights to any files associated with the group.

Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_gid_passwd_group_same
Identifiers and References

Identifiers:  CCE-27503-2

References:  KYLIN-10-020300, 5.5.2, CCI-000764, IA-2, Req-8.5.a, SRG-OS-000104-GPOS-00051

Rule   Ensure All Groups on the System Have Unique Group ID   [ref]

Change the group name or delete groups, so each has a unique id.

Rationale:

To assure accountability and prevent unauthenticated access, groups must be identified uniquely to prevent potential misuse and compromise of the system.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_group_unique_id
Identifiers and References
Group   Protect Accounts by Configuring PAM   Group contains 3 groups and 9 rules

[ref]   PAM, or Pluggable Authentication Modules, is a system which implements modular authentication for Linux programs. PAM provides a flexible and configurable architecture for authentication, and it should be configured to minimize exposure to unnecessary risk. This section contains guidance on how to accomplish that.

PAM is implemented as a set of shared objects which are loaded and invoked whenever an application wishes to authenticate a user. Typically, the application must be running as root in order to take advantage of PAM, because PAM's modules often need to be able to access sensitive stores of account information, such as /etc/shadow. Traditional privileged network listeners (e.g. sshd) or SUID programs (e.g. sudo) already meet this requirement. An SUID root application, userhelper, is provided so that programs which are not SUID or privileged themselves can still take advantage of PAM.

PAM looks in the directory /etc/pam.d for application-specific configuration information. For instance, if the program login attempts to authenticate a user, then PAM's libraries follow the instructions in the file /etc/pam.d/login to determine what actions should be taken.

One very important file in /etc/pam.d is /etc/pam.d/system-auth. This file, which is included by many other PAM configuration files, defines 'default' system authentication measures. Modifying this file is a good way to make far-reaching authentication changes, for instance when implementing a centralized authentication service.

Group   Set Password Hashing Algorithm   Group contains 1 rule

[ref]   The system's default algorithm for storing password hashes in /etc/shadow is SHA-512. This can be configured in several locations.

Rule   Set PAM's Password Hashing Algorithm   [ref]

The PAM system service can be configured to only store encrypted representations of passwords. In /etc/pam.d/system-auth, the password section of the file controls which PAM modules execute during a password change. Set the pam_unix.so module in the password section to include the argument sha512, as shown below:

password    sufficient    pam_unix.so sha512 other arguments...

This will help ensure when local users change their passwords, hashes for the new passwords will be generated using the SHA-512 algorithm. This is the default.

Rationale:

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 kepy in plain text.

This setting ensures user and group account administration utilities are configured to store only encrypted representations of passwords. Additionally, the crypt_style configuration option ensures the use of a strong hashing algorithm that makes password cracking attacks more difficult.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_systemauth
Identifiers and References

Identifiers:  CCE-27104-9

References:  KYLIN-10-010200, 6.3.1, 5.6.2.2, 3.13.11, CCI-000196, IA-5(b), IA-5(c), IA-5(1)(c), IA-7, Req-8.2.1, SRG-OS-000073-GPOS-00041

Group   Set Password Quality Requirements   Group contains 1 group and 6 rules

[ref]   The default pam_pwquality PAM module provides strength checking for passwords. It performs a number of checks, such as making sure passwords are not similar to dictionary words, are of at least a certain length, are not the previous password reversed, and are not simply a change of case from the previous password. It can also require passwords to be in certain character classes. The pam_pwquality module is the preferred way of configuring password requirements.

The pam_cracklib PAM module can also provide strength checking for passwords as the pam_pwquality module. It performs a number of checks, such as making sure passwords are not similar to dictionary words, are of at least a certain length, are not the previous password reversed, and are not simply a change of case from the previous password. It can also require passwords to be in certain character classes.

The man pages pam_pwquality(8) and pam_cracklib(8) provide information on the capabilities and configuration of each.

Group   Set Password Quality Requirements with pam_pwquality   Group contains 6 rules

[ref]   The pam_pwquality PAM module can be configured to meet requirements for a variety of policies.

For example, to configure pam_pwquality to require at least one uppercase character, lowercase character, digit, and other (special) character, make sure that pam_pwquality exists in /etc/pam.d/system-auth:

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth. Next, modify the settings in /etc/security/pwquality.conf to match the following:
difok = 4
minlen = 14
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
maxrepeat = 3
The arguments can be modified to ensure compliance with your organization's security policy. Discussion of each parameter follows.

Rule   Set Password Minimum Length   [ref]

The pam_pwquality module's minlen parameter controls requirements for minimum characters required in a password. Add minlen=(N/A) after pam_pwquality to set minimum password length requirements.

Rationale:

The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromose the password.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_accounts_password_pam_minlen
Identifiers and References

Identifiers:  CCE-27293-0

References:  KYLIN-10-010280, 6.3.2, 5.6.2.1.1, CCI-000205, IA-5(1)(a), Req-8.2.3, SRG-OS-000078-GPOS-00046

Rule   Set Password Strength Minimum Digit Characters   [ref]

The pam_pwquality module's dcredit parameter controls requirements for usage of digits in a password. When set to a negative number, any password will be required to contain that many digits. When set to a positive number, pam_pwquality will grant +1 additional length credit for each digit. Modify the dcredit setting in /etc/security/pwquality.conf to require the use of a digit in passwords.

Rationale:

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possble combinations that need to be tested before the password is compromised. Requiring digits makes password guessing attacks more difficult by ensuring a larger search space.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_accounts_password_pam_dcredit
Identifiers and References

Identifiers:  CCE-27214-6

References:  KYLIN-10-010140, 6.3.2, CCI-000194, IA-5(1)(a), IA-5(b), IA-5(c), 194, Req-8.2.3, SRG-OS-000071-GPOS-00039

Rule   Set Password Strength Minimum Different Categories   [ref]

The pam_pwquality module's minclass parameter controls requirements for usage of different character classes, or types, of character that must exist in a password before it is considered valid. For example, setting this value to three (3) requires that any password must have characters from at least three different categories in order to be approved. The default value is zero (0), meaning there are no required classes. There are four categories available:

* Upper-case characters
* Lower-case characters
* Digits
* Special characters (for example, punctuation)
Modify the minclass setting in /etc/security/pwquality.conf entry to require (N/A) differing categories of characters when changing passwords.

Rationale:

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Requiring a minimum number of character categories makes password guessing attacks more difficult by ensuring a larger search space.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_accounts_password_pam_minclass
Identifiers and References

Identifiers:  CCE-27115-5

References:  KYLIN-10-010170, CCI-000195, IA-5, SRG-OS-000072-GPOS-00040

Rule   Set Password Strength Minimum Special Characters   [ref]

The pam_pwquality module's ocredit= parameter controls requirements for usage of special (or "other") characters in a password. When set to a negative number, any password will be required to contain that many special characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each special character. Modify the ocredit setting in /etc/security/pwquality.conf to equal (N/A) to require use of a special character in passwords.

Rationale:

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possble combinations that need to be tested before the password is compromised. Requiring a minimum number of special characters makes password guessing attacks more difficult by ensuring a larger search space.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_accounts_password_pam_ocredit
Identifiers and References

Identifiers:  CCE-27360-7

References:  KYLIN-10-010150, CCI-001619, IA-5(b), IA-5(c), IA-5(1)(a), SRG-OS-000266-GPOS-00101

Rule   Set Password Strength Minimum Lowercase Characters   [ref]

The pam_pwquality module's lcredit parameter controls requirements for usage of lowercase letters in a password. When set to a negative number, any password will be required to contain that many lowercase characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each lowercase character. Modify the lcredit setting in /etc/security/pwquality.conf to require the use of a lowercase character in passwords.

Rationale:

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possble combinations that need to be tested before the password is compromised. Requiring a minimum number of lowercase characters makes password guessing attacks more difficult by ensuring a larger search space.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_accounts_password_pam_lcredit
Identifiers and References

Identifiers:  CCE-27345-8

References:  KYLIN-10-010130, CCI-000193, IA-5(b), IA-5(c), IA-5(1)(a), Req-8.2.3, SRG-OS-000070-GPOS-00038

Rule   Set Password Strength Minimum Uppercase Characters   [ref]

The pam_pwquality module's ucredit= parameter controls requirements for usage of uppercase letters in a password. When set to a negative number, any password will be required to contain that many uppercase characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each uppercase character. Modify the ucredit setting in /etc/security/pwquality.conf to require the use of an uppercase character in passwords.

Rationale:

Use of a complex password helps to increase the time and resources reuiqred to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_accounts_password_pam_ucredit
Identifiers and References

Identifiers:  CCE-27200-5

References:  KYLIN-10-010120, 6.3.2, CCI-000192, IA-5(b), IA-5(c), IA-5(1)(a), Req-8.2.3, SRG-OS-000069-GPOS-00037

Rule   Accounts Name Should Not Be Contained In Password   [ref]

Accounts name should not be contained in password. There is no usercheck=0.

Rationale:

If the passowrd contains substring of accounts name, it is a risk.

Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_no_name_contained_in_password
Identifiers and References

Rule   Accounts Password Should Be Verified When Changing   [ref]

Accounts password should be verified when it is modifying. It is done by pam_unix.so.

Rationale:

Anyone can change the password if no verifying.

Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_verify_owner_password
Identifiers and References
Group   Secure Session Configuration Files for Login Accounts   Group contains 1 group and 1 rule

[ref]   When a user logs into a Unix account, the system configures the user's session by reading a number of files. Many of these files are located in the user's home directory, and may have weak permissions as a result of user error or misconfiguration. If an attacker can modify or even read certain types of account configuration information, they can often gain full access to the affected user's account. Therefore, it is important to test and correct configuration file permissions for interactive accounts, particularly those of privileged users such as root or system administrators.

Group   Ensure that Users Have Sensible Umask Values   Group contains 1 rule

[ref]   The umask setting controls the default permissions for the creation of new files. With a default umask setting of 077, files and directories created by users will not be readable by any other user on the system. Users who wish to make specific files group- or world-readable can accomplish this by using the chmod command. Additionally, users can make all their files readable to their group by default by setting a umask of 027 in their shell configuration files. If default per-user groups exist (that is, if every user has a default group whose name is the same as that user's username and whose only member is the user), then it may even be safe for users to select a umask of 007, making it very easy to intentionally share files with groups of which the user is a member.

Rule   Ensure the Default Bash Umask is Set Correctly   [ref]

To ensure the default umask for users of the Bash shell is set properly, add or correct the umask setting in /etc/bashrc to read as follows:

umask (N/A)

Rationale:

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.

Severity: 
unknown
Rule ID:xccdf_org.ssgproject.content_rule_accounts_umask_etc_bashrc
Identifiers and References

Identifiers:  CCE-80202-5

References:  5.4.4, CCI-000366, SA-8

Group   File Permissions and Masks   Group contains 2 groups and 8 rules

[ref]   Traditional Unix security relies heavily on file and directory permissions to prevent unauthorized users from reading or modifying files to which they should not have access.

Several of the commands in this section search filesystems for files or directories with certain characteristics, and are intended to be run on every local partition on a given system. When the variable PART appears in one of the commands below, it means that the command is intended to be run repeatedly, with the name of each local partition substituted for PART in turn.

The following command prints a list of all xfs partitions on the local system, which is the default filesystem for Red Hat Enterprise Linux 7 installations:

$ mount -t xfs | awk '{print $3}'
For any systems that use a different local filesystem type, modify this command as appropriate.

Group   Verify Permissions on Important Files and Directories   Group contains 1 group and 8 rules

[ref]   Permissions for many files on a system must be set restrictively to ensure sensitive information is properly protected. This section discusses important permission restrictions which can be verified to ensure that no harmful discrepancies have arisen.

Group   Verify Permissions on Files with Local Account Information and Credentials   Group contains 6 rules

Rule   Verify User Who Owns gshadow File   [ref]

To properly set the owner of /etc/gshadow, run the command:

$ sudo chown root /etc/gshadow 

Rationale:

The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_etc_gshadow
Identifiers and References

Identifiers:  CCE-27161-9

References:  6.1.5, AC-6



Complexity:low
Disruption:low
Strategy:configure

chown root /etc/gshadow


Complexity:low
Disruption:low
Strategy:configure

- name: Find /etc/gshadow file(s)
  find:
    paths: "{{ '/etc/gshadow' | dirname }}"
    patterns: "{{ '/etc/gshadow' | basename }}"
  register: files_found
  tags:
    - file_owner_etc_gshadow
    - medium_severity
    - configure_strategy
    - low_complexity
    - low_disruption
    - CCE-27161-9
    - NIST-800-53-AC-6

- name: Set user ownership to root
  file:
    path: "{{ item.path }}"
    owner: root
  with_items:
    - "{{ files_found.files }}"
  tags:
    - file_owner_etc_gshadow
    - medium_severity
    - configure_strategy
    - low_complexity
    - low_disruption
    - CCE-27161-9
    - NIST-800-53-AC-6

Rule   Verify Group Who Owns passwd File   [ref]

To properly set the group owner of /etc/passwd, run the command:

$ sudo chgrp root /etc/passwd 

Rationale:

The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_etc_passwd
Identifiers and References

Identifiers:  CCE-26639-5

References:  6.1.2, 5.5.2.2, AC-6, Req-8.7.c



Complexity:low
Disruption:low
Strategy:configure

chgrp root /etc/passwd


Complexity:low
Disruption:low
Strategy:configure

- name: Find /etc/passwd file(s)
  find:
    paths: "{{ '/etc/passwd' | dirname }}"
    patterns: "{{ '/etc/passwd' | basename }}"
  register: files_found
  tags:
    - file_groupowner_etc_passwd
    - medium_severity
    - configure_strategy
    - low_complexity
    - low_disruption
    - CCE-26639-5
    - NIST-800-53-AC-6
    - PCI-DSS-Req-8.7.c
    - CJIS-5.5.2.2

- name: Set group ownership to root
  file:
    path: "{{ item.path }}"
    group: root
  with_items:
    - "{{ files_found.files }}"
  tags:
    - file_groupowner_etc_passwd
    - medium_severity
    - configure_strategy
    - low_complexity
    - low_disruption
    - CCE-26639-5
    - NIST-800-53-AC-6
    - PCI-DSS-Req-8.7.c
    - CJIS-5.5.2.2

Rule   Verify Group Who Owns gshadow File   [ref]

To properly set the group owner of /etc/gshadow, run the command:

$ sudo chgrp root /etc/gshadow 

Rationale:

The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_etc_gshadow
Identifiers and References

Identifiers:  CCE-26840-9

References:  6.1.5, AC-6



Complexity:low
Disruption:low
Strategy:configure

chgrp root /etc/gshadow


Complexity:low
Disruption:low
Strategy:configure

- name: Find /etc/gshadow file(s)
  find:
    paths: "{{ '/etc/gshadow' | dirname }}"
    patterns: "{{ '/etc/gshadow' | basename }}"
  register: files_found
  tags:
    - file_groupowner_etc_gshadow
    - medium_severity
    - configure_strategy
    - low_complexity
    - low_disruption
    - CCE-26840-9
    - NIST-800-53-AC-6

- name: Set group ownership to root
  file:
    path: "{{ item.path }}"
    group: root
  with_items:
    - "{{ files_found.files }}"
  tags:
    - file_groupowner_etc_gshadow
    - medium_severity
    - configure_strategy
    - low_complexity
    - low_disruption
    - CCE-26840-9
    - NIST-800-53-AC-6

Rule   Verify User Who Owns passwd File   [ref]

To properly set the owner of /etc/passwd, run the command:

$ sudo chown root /etc/passwd 

Rationale:

The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_etc_passwd
Identifiers and References

Identifiers:  CCE-27138-7

References:  6.1.2, 5.5.2.2, AC-6, Req-8.7.c



Complexity:low
Disruption:low
Strategy:configure

chown root /etc/passwd


Complexity:low
Disruption:low
Strategy:configure

- name: Find /etc/passwd file(s)
  find:
    paths: "{{ '/etc/passwd' | dirname }}"
    patterns: "{{ '/etc/passwd' | basename }}"
  register: files_found
  tags:
    - file_owner_etc_passwd
    - medium_severity
    - configure_strategy
    - low_complexity
    - low_disruption
    - CCE-27138-7
    - NIST-800-53-AC-6
    - PCI-DSS-Req-8.7.c
    - CJIS-5.5.2.2

- name: Set user ownership to root
  file:
    path: "{{ item.path }}"
    owner: root
  with_items:
    - "{{ files_found.files }}"
  tags:
    - file_owner_etc_passwd
    - medium_severity
    - configure_strategy
    - low_complexity
    - low_disruption
    - CCE-27138-7
    - NIST-800-53-AC-6
    - PCI-DSS-Req-8.7.c
    - CJIS-5.5.2.2

Rule   Verify Permissions on gshadow File   [ref]

To properly set the permissions of /etc/gshadow, run the command:

$ sudo chmod 0000 /etc/gshadow

Rationale:

The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_etc_gshadow
Identifiers and References

Identifiers:  CCE-27162-7

References:  6.1.5, AC-6



Complexity:low
Disruption:low
Strategy:configure

chmod 0000 /etc/gshadow


Complexity:low
Disruption:low
Strategy:configure

- name: Find /etc/gshadow file(s)
  find:
    paths: "{{ '/etc/gshadow' | dirname }}"
    patterns: "{{ '/etc/gshadow' | basename }}"
  register: files_found
  tags:
    - file_permissions_etc_gshadow
    - medium_severity
    - configure_strategy
    - low_complexity
    - low_disruption
    - CCE-27162-7
    - NIST-800-53-AC-6

- name: Set permissions
  file:
    path: "{{ item.path }}"
    mode: 0000
  with_items:
    - "{{ files_found.files }}"
  tags:
    - file_permissions_etc_gshadow
    - medium_severity
    - configure_strategy
    - low_complexity
    - low_disruption
    - CCE-27162-7
    - NIST-800-53-AC-6

Rule   Verify Permissions on passwd File   [ref]

To properly set the permissions of /etc/passwd, run the command:

$ sudo chmod 0644 /etc/passwd

Rationale:

If the /etc/passwd file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the list of accounts on the system and associated information, and protection of this file is critical for system security.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_etc_passwd
Identifiers and References

Identifiers:  CCE-26887-0

References:  6.1.2, 5.5.2.2, AC-6, Req-8.7.c



Complexity:low
Disruption:low
Strategy:configure

chmod 0644 /etc/passwd


Complexity:low
Disruption:low
Strategy:configure

- name: Find /etc/passwd file(s)
  find:
    paths: "{{ '/etc/passwd' | dirname }}"
    patterns: "{{ '/etc/passwd' | basename }}"
  register: files_found
  tags:
    - file_permissions_etc_passwd
    - medium_severity
    - configure_strategy
    - low_complexity
    - low_disruption
    - CCE-26887-0
    - NIST-800-53-AC-6
    - PCI-DSS-Req-8.7.c
    - CJIS-5.5.2.2

- name: Set permissions
  file:
    path: "{{ item.path }}"
    mode: 0644
  with_items:
    - "{{ files_found.files }}"
  tags:
    - file_permissions_etc_passwd
    - medium_severity
    - configure_strategy
    - low_complexity
    - low_disruption
    - CCE-26887-0
    - NIST-800-53-AC-6
    - PCI-DSS-Req-8.7.c
    - CJIS-5.5.2.2

Rule   Ensure All Files Are Owned by a Group   [ref]

If any files are not owned by a group, then the cause of their lack of group-ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate group.

Rationale:

Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. They may be caused by an intruder, by incorrect software installation or draft software removal, or by failure to remove all files belonging to a deleted account. The files should be repaired so they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_ungroupowned
Identifiers and References

Identifiers:  CCE-80135-7

References:  KYLIN-10-020330, 6.1.12, CCI-002165, AC-3(4), AC-6, IA-2, SRG-OS-000480-GPOS-00227

Rule   Ensure All Files Are Owned by a User   [ref]

If any files are not owned by a user, then the cause of their lack of ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate user.

Rationale:

Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. They may be caused by an intruder, by incorrect software installation or draft software removal, or by failure to remove all files belonging to a deleted account. The files should be repaired so they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_no_files_unowned_by_user
Identifiers and References

Identifiers:  CCE-80134-0

References:  KYLIN-10-020320, 6.1.11, CCI-002165, AC-3(4), AC-6, CM-6(b), SRG-OS-000480-GPOS-00227

Group   System Accounting with <tt>auditd</tt>   Group contains 2 groups and 3 rules

[ref]   The audit service provides substantial capabilities for recording system activities. By default, the service audits about SELinux AVC denials and certain types of security-relevant events such as system logins, account modifications, and authentication events performed by programs such as sudo. Under its default configuration, auditd has modest disk space requirements, and should not noticeably impact system performance.

NOTE: The Linux Audit daemon auditd can be configured to use the augenrules program to read audit rules files (*.rules) located in /etc/audit/rules.d location and compile them to create the resulting form of the /etc/audit/audit.rules configuration file during the daemon startup (default configuration). Alternatively, the auditd daemon can use the auditctl utility to read audit rules from the /etc/audit/audit.rules configuration file during daemon startup, and load them into the kernel. The expected behavior is configured via the appropriate ExecStartPost directive setting in the /usr/lib/systemd/system/auditd.service configuration file. To instruct the auditd daemon to use the augenrules program to read audit rules (default configuration), use the following setting:

ExecStartPost=-/sbin/augenrules --load
in the /usr/lib/systemd/system/auditd.service configuration file. In order to instruct the auditd daemon to use the auditctl utility to read audit rules, use the following setting:
ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
in the /usr/lib/systemd/system/auditd.service configuration file. Refer to [Service] section of the /usr/lib/systemd/system/auditd.service configuration file for further details.

Government networks often have substantial auditing requirements and auditd can be configured to meet these requirements. Examining some example audit records demonstrates how the Linux audit system satisfies common requirements. The following example from Fedora Documentation available at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/sect-Security-Enhanced_Linux-Troubleshooting-Fixing_Problems.html#sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages shows the substantial amount of information captured in a two typical "raw" audit messages, followed by a breakdown of the most important fields. In this example the message is SELinux-related and reports an AVC denial (and the associated system call) that occurred when the Apache HTTP Server attempted to access the /var/www/html/file1 file (labeled with the samba_share_t type):
type=AVC msg=audit(1226874073.147:96): avc:  denied  { getattr } for pid=2465 comm="httpd"
path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13
a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48
gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd"
exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
  • msg=audit(1226874073.147:96)
    • The number in parentheses is the unformatted time stamp (Epoch time) for the event, which can be converted to standard time by using the date command.
  • { getattr }
    • The item in braces indicates the permission that was denied. getattr indicates the source process was trying to read the target file's status information. This occurs before reading files. This action is denied due to the file being accessed having the wrong label. Commonly seen permissions include getattr, read, and write.
  • comm="httpd"
    • The executable that launched the process. The full path of the executable is found in the exe= section of the system call (SYSCALL) message, which in this case, is exe="/usr/sbin/httpd".
  • path="/var/www/html/file1"
    • The path to the object (target) the process attempted to access.
  • scontext="unconfined_u:system_r:httpd_t:s0"
    • The SELinux context of the process that attempted the denied action. In this case, it is the SELinux context of the Apache HTTP Server, which is running in the httpd_t domain.
  • tcontext="unconfined_u:object_r:samba_share_t:s0"
    • The SELinux context of the object (target) the process attempted to access. In this case, it is the SELinux context of file1. Note: the samba_share_t type is not accessible to processes running in the httpd_t domain.
  • From the system call (SYSCALL) message, two items are of interest:
    • success=no: indicates whether the denial (AVC) was enforced or not. success=no indicates the system call was not successful (SELinux denied access). success=yes indicates the system call was successful - this can be seen for permissive domains or unconfined domains, such as initrc_t and kernel_t.
    • exe="/usr/sbin/httpd": the full path to the executable that launched the process, which in this case, is exe="/usr/sbin/httpd".

Group   Configure <tt>auditd</tt> Rules for Comprehensive Auditing   Group contains 1 group and 3 rules

[ref]   The auditd program can perform comprehensive monitoring of system activity. This section describes recommended configuration settings for comprehensive auditing, but a full description of the auditing system's capabilities is beyond the scope of this guide. The mailing list linux-audit@redhat.com exists to facilitate community discussion of the auditing system.

The audit subsystem supports extensive collection of events, including:

  • Tracing of arbitrary system calls (identified by name or number) on entry or exit.
  • Filtering by PID, UID, call success, system call argument (with some limitations), etc.
  • Monitoring of specific files for modifications to the file's contents or metadata.

Auditing rules at startup are controlled by the file /etc/audit/audit.rules. Add rules to it to meet the auditing requirements for your organization. Each line in /etc/audit/audit.rules represents a series of arguments that can be passed to auditctl and can be individually tested during runtime. See documentation in /usr/share/doc/audit-VERSION and in the related man pages for more details.

If copying any example audit rulesets from /usr/share/doc/audit-VERSION, be sure to comment out the lines containing arch= which are not appropriate for your system's architecture. Then review and understand the following rules, ensuring rules are activated as needed for the appropriate architecture.

After reviewing all the rules, reading the following sections, and editing as needed, the new rules can be activated as follows:
$ sudo service auditd restart

Group   Record Information on the Use of Privileged Commands   Group contains 1 rule

[ref]   At a minimum, the audit system should collect the execution of privileged commands for all users and root.

Rule   Ensure auditd Collects Information on the Use of Privileged Commands   [ref]

At a minimum, the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid / setgid programs, run the following command for each local partition PART:

$ sudo find PART -xdev -type f -perm -4000 -o -type f -perm -2000 2>/dev/null
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d for each setuid / setgid program on the system, replacing the SETUID_PROG_PATH part with the full path of that setuid / setgid program in the list:
-a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=4294967295 -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules for each setuid / setgid program on the system, replacing the SETUID_PROG_PATH part with the full path of that setuid / setgid program in the list:
-a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=4294967295 -F key=privileged

Rationale:

Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threast.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands
Identifiers and References

References:  5.2.10, 5.4.1.1, 3.1.7, CCI-002234, AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-2(4), AU-6(9), AU-12(a), AU-12(c), IR-5, Req-10.2.2, SRG-OS-000327-GPOS-00127

Rule   Record Events that Modify User/Group Information   [ref]

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d, in order to capture events that modify account changes:

-w /etc/group -p wa -k audit_rules_usergroup_modification
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file, in order to capture events that modify account changes:
-w /etc/group -p wa -k audit_rules_usergroup_modification
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

Rationale:

In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy.

Severity: 
unknown
Rule ID:xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification
Identifiers and References

References:  5.2.5, 5.4.1.1, 3.1.7, CCI-000018, CCI-000172, CCI-001403, CCI-002130, AC-2(4), AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, Req-10.2.5, SRG-OS-000004-GPOS-00004, SRG-OS-000239-GPOS-00089, SRG-OS-000241-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000476-GPOS-00221

Rule   Install audit   [ref]

Install the audit package with the command:

$ sudo yum install audit

Rationale:

"audit" usually refers to a software package used for system security audits. It can help system administrators monitor and record activities in the system to better understand the usage and security of the system.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_audit_installed
Identifiers and References


Complexity:low
Disruption:low
Strategy:enable
- name: Ensure audit is installed
  package:
    name="{{item}}"
    state=present
  with_items:
    - audit
  tags:
    - package_audit_installed
    - medium_severity
    - enable_strategy
    - low_complexity
    - low_disruption


Complexity:low
Disruption:low
Strategy:enable
include install_audit

class install_audit {
  package { 'audit':
    ensure => 'installed',
  }
}
Group   Installing and Maintaining Software   Group contains 5 groups and 4 rules

[ref]   The following sections contain information on security-relevant choices during the initial operating system installation process and the setup of software updates.

Group   GNOME Desktop Environment   Group contains 1 group and 1 rule

[ref]   GNOME is a graphical desktop environment bundled with many Linux distributions that allow users to easily interact with the operating system graphically rather than textually. The GNOME Graphical Display Manager (GDM) provides login, logout, and user switching contexts as well as display server management.

GNOME is developed by the GNOME Project and is considered the default Red Hat Graphical environment.

For more information on GNOME and the GNOME Project, see https://www.gnome.org

Group   GNOME System Settings   Group contains 1 rule

[ref]   GNOME provides configuration and functionality to a graphical desktop environment that changes grahical configurations or allow a user to perform actions that users normally would not be able to do in non-graphical mode such as remote access configuration, power policies, Geo-location, etc. Configuring such settings in GNOME will prevent accidential graphical configuration changes by users from taking place.

Rule   Install dconf   [ref]

Install the dconf package with the command:

$ sudo yum install dconf

Rationale:

The dconf package should be installed to change the Settings of various desktop environments.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_dconf_installed
Identifiers and References


Complexity:low
Disruption:low
Strategy:enable
- name: Ensure dconf is installed
  package:
    name="{{item}}"
    state=present
  with_items:
    - dconf
  tags:
    - package_dconf_installed
    - medium_severity
    - enable_strategy
    - low_complexity
    - low_disruption


Complexity:low
Disruption:low
Strategy:enable
include install_dconf

class install_dconf {
  package { 'dconf':
    ensure => 'installed',
  }
}
Group   System and Software Integrity   Group contains 1 group and 1 rule

[ref]   System and software integrity can be gained by installing antivirus, increasing system encryption strength with FIPS, verifying installed software, enabling SELinux, installing an Intrusion Prevention System, etc. However, installing or enabling integrity checking tools cannot prevent intrusions, but they can detect that an intrusion may have occurred. Requirements for integrity checking may be highly dependent on the environment in which the system will be used. Snapshot-based approaches such as AIDE may induce considerable overhead in the presence of frequent software updates.

Group   Federal Information Processing Standard (FIPS)   Group contains 1 rule

[ref]   The Federal Information Processing Standard (FIPS) is a computer security standard which is developed by the U.S. Government and industry working groups to validate the quality of cryptographic modules. The FIPS standard provides four security levels to ensure adequate coverage of different industries, implementation of cryptographic modules, and organizational sizes and requirements.

FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets industry and government requirements. For government systems, this allows Security Levels 1, 2, 3, or 4 for use on Red Hat Enterprise Linux.

See http://csrc.nist.gov/publications/PubsFIPS.html for more information.

Rule   Install the dracut-fips Package   [ref]

To enable FIPS, the system requires that the dracut-fips package be installed. The dracut-fips package can be installed with the following command:

$ sudo yum install dracut-fips

Rationale:

Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The operating system must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.

Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_dracut-fips_installed
Identifiers and References

Identifiers:  CCE-80358-5

References:  5.10.1.2, 3.13.11, 3.13.8, CCI-000068, CCI-002450, AC-17(2), SRG-OS-000033-GPOS-00014, SRG-OS-000396-GPOS-00176, SRG-OS-000478-GPOS-00223



Complexity:low
Disruption:low
Strategy:enable
- name: Ensure dracut-fips is installed
  package:
    name="{{item}}"
    state=present
  with_items:
    - dracut-fips
  tags:
    - package_dracut-fips_installed
    - medium_severity
    - enable_strategy
    - low_complexity
    - low_disruption
    - CCE-80358-5
    - NIST-800-53-AC-17(2)
    - NIST-800-171-3.13.11
    - NIST-800-171-3.13.8
    - CJIS-5.10.1.2


Complexity:low
Disruption:low
Strategy:enable
include install_dracut-fips

class install_dracut-fips {
  package { 'dracut-fips':
    ensure => 'installed',
  }
}
Group   Updating Software   Group contains 2 rules

[ref]   The yum command line tool is used to install and update software packages. The system also provides a graphical software update tool in the System menu, in the Administration submenu, called Software Update.

Red Hat Enterprise Linux systems contain an installed software catalog called the RPM database, which records metadata of installed packages. Consistently using yum or the graphical Software Update for all software installation allows for insight into the current inventory of installed software on the system.

Oracle Linux system contain an installed software catalog called the RPM database, which records metadata of installed packages. Consistently using yum or the graphical Software Update for all software installation allows for insight into the current inventory of installed software on the system.

Rule   Ensure gpgcheck Enabled For All Yum Package Repositories   [ref]

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

Rationale:

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).

Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_ensure_gpgcheck_never_disabled
Identifiers and References

References:  5.10.4.1, 3.4.8, CCI-001749, 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i), CM-5(3), SI-7, MA-1(b), Req-6.2, 366

Rule   Ensure gpgcheck Enabled In Main Yum Configuration   [ref]

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

Rationale:

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).

Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_ensure_gpgcheck_globally_activated
Identifiers and References

Identifiers:  CCE-26989-4

References:  KYLIN-10-020050, 1.2.2, 5.10.4.1, 3.4.8, CCI-001749, 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i), CM-5(3), SI-7, MA-1(b), Req-6.2, SRG-OS-000366-GPOS-00153

Red Hat and Red Hat Enterprise Linux are either registered trademarks or trademarks of Red Hat, Inc. in the United States and other countries. All other names are registered trademarks or trademarks of their respective companies.