openstack
/
ansible-hardening
Code Issues Proposed changes

Queens doc updates + removal of RHEL 6 STIG 

This patch begins the teardown of the RHEL 6 STIG content from the
ansible-hardening repository. It will still be maintained in
Pike and earlier branches.

This patch also updates the ansible-hardening documentation for the
Queens release and notes that Pike is the latest stable version.

Closes-Bug: 1715745
Change-Id: Iaae52c97a35d82dd807ef78a1a6593ce3aa33540
This commit is contained in:
Major Hayden 2017-09-12 08:19:54 -06:00
parent 75c06173c7
commit 0c0767b3f1
No known key found for this signature in database
GPG Key ID: 737051E0C1011FB1
296 changed files with 40 additions and 10173 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -13,7 +13,6 @@ to systems running the following distributions:
* openSUSE Leap 42.2 and 42.3
* Red Hat Enterprise Linux 7
* SUSE Linux Enterprise 12 (*experimental*)
* Ubuntu 14.04 *(deprecated)*
* Ubuntu 16.04
For more details, review the
@ -50,7 +49,6 @@ Running with Vagrant
This role can be tested easily on multiple platforms using Vagrant.
The `Vagrantfile` supports testing on:
* Ubuntu 14.04
* Ubuntu 16.04
* CentOS 7

356
defaults/main.yml
View File

@ -24,10 +24,7 @@
# * SUSE Linux Enterprise 12
# * Ubuntu 16.04 Xenial LTS
#
# The RHEL 6 STIG content is deprecated in the Ocata release. It is compatible
# with Ubuntu 14.04 Trusty LTS.
#
# Valid options: rhel7, rhel6
# Valid options: rhel7
stig_version: rhel7
## APT Cache Options
@ -73,6 +70,16 @@ security_set_maximum_password_lifetime: no # V-71931
# Initialize the AIDE database immediately (may take time).
security_rhel7_initialize_aide: no # V-71973
# The default Ubuntu configuration for AIDE will cause it to wander into some
# terrible places on the system, such as /var/lib/lxc and images in /opt.
# The following three default exclusions are highly recommended for AIDE to
# work properly, but additional exclusions can be added to this list if needed.
security_aide_exclude_dirs:
- /openstack
- /opt
- /run
- /var
## Audit daemon (auditd)
# Send audit records to a different system using audisp.
#security_audisp_remote_server: '10.0.21.1' # V-72083
@ -243,6 +250,8 @@ security_enable_firewalld: no # V-72273
security_enable_firewalld_rate_limit: no # V-72271
security_enable_firewalld_rate_limit_per_minute: 25
security_enable_firewalld_rate_limit_burst: 100
# Update the grub configuration.
security_enable_grub_update: yes
# Require authentication in GRUB to boot into single-user or maintenance modes.
security_require_grub_authentication: no # V-71961 / V-71963
# The default password for grub authentication is 'secrete'.
@ -341,342 +350,3 @@ security_disallow_ip_forwarding: no # V-72309
security_rhel7_disable_usb_storage: yes # V-71983
# Disable kdump.
security_disable_kdump: yes # V-72057
###############################################################################
# ____ _ _ _____ _ __ ____ _____ ___ ____
# | _ \| | | | ____| | / /_ / ___|_ _|_ _/ ___|
# | |_) | |_| | _| | | | '_ \ \___ \ | | | | | _
# | _ <| _ | |___| |___ | (_) | ___) || | | | |_| |
# |_| \_\_| |_|_____|_____| \___/ |____/ |_| |___\____|
#
# DEPRECATED! The RHEL 6 STIG content and its tasks were deprecated in the
# Ocata release and will be removed in a future release.
#
# These configuration options apply to the RHEL 6 STIG content. Be sure to set
# `stig_version` to `rhel6` to use the tasks for the RHEL 6 STIG content.
#
###############################################################################
## AIDE
# The default Ubuntu configuration for AIDE will cause it to wander into some
# terrible places on the system, such as /var/lib/lxc and images in /opt.
# The following three default exclusions are highly recommended for AIDE to
# work properly, but additional exclusions can be added to this list if needed.
security_aide_exclude_dirs:
- /openstack
- /opt
- /run
- /var
#
# By default, the AIDE database won't be initialized immediately since it can
# consume plenty of CPU and I/O resources while it runs. To initialize the
# AIDE database immediately when the playbook finishes, set the following
# variable to 'true':
security_initialize_aide: false
## Audit daemon
# V-38438 requires that auditd is enabled at boot time with a parameter in the
# GRUB configuration.
#
# If 'security_enable_audit_during_boot' is set to 'yes', then the 'audit=1'
# parameter will be added in /etc/default/grub.d/.
# If 'security_enable_grub_update is set to 'yes', the grub.cfg will be
# updated automatically.
security_enable_audit_during_boot: yes # V-38438
security_enable_grub_update: yes # V-38438
# The following booleans control the rule sets added to auditd's default
# set of auditing rules. To see which rules will be added for each boolean,
# refer to the templates/osas-auditd.j2 file.
#
# If the template changes due to booleans being adjusted, the new template
# will be deployed onto the host and auditd will get the new rules loaded
# automatically with augenrules.
#
security_audit_account_modification: yes # V-38531, V-38534, V-38538
security_audit_change_localtime: yes # V-38530
security_audit_change_system_time: yes # V-38635
security_audit_clock_settime: yes # V-38527
security_audit_clock_settimeofday: yes # V-38522
security_audit_clock_stime: yes # V-38525
security_audit_DAC_chmod: no # V-38543
security_audit_DAC_chown: no # V-38545
security_audit_DAC_lchown: no # V-38558
security_audit_DAC_fchmod: no # V-38547
security_audit_DAC_fchmodat: no # V-38550
security_audit_DAC_fchown: no # V-38552
security_audit_DAC_fchownat: no # V-38554
security_audit_DAC_fremovexattr: no # V-38556
security_audit_DAC_lremovexattr: no # V-38559
security_audit_DAC_fsetxattr: no # V-38557
security_audit_DAC_lsetxattr: no # V-38561
security_audit_DAC_setxattr: no # V-38565
security_audit_deletions: no # V-38575
security_audit_failed_access: no # V-38566
security_audit_filesystem_mounts: yes # V-38568
security_audit_kernel_modules: yes # V-38580
security_audit_mac_changes: yes # V-38541
security_audit_network_changes: yes # V-38540
security_audit_sudoers: yes # V-38578
#
# **DANGER**
# Changing the options below can cause systems to go offline unexpectedly or
# stop serving requests as a security precaution. Read the developer notes for
# each STIG prior to adjusting the following variables.
# **DANGER**
#
# Set an action to occur when there is a disk error. Review the
# documentation for V-38464 before changing this option.
security_disk_error_action: SYSLOG # V-38464
#
# Set an action to occur when the disk is full. Review the documentation for
# V-38468 before changing this option.
security_disk_full_action: SYSLOG # V-38468
#
# V-38678 - Set the amount of megabytes left when the space_left_action
# triggers. The STIG guideline doesn't specify a size, but Ubuntu chooses a
# default of 75MB, which is reasonable.
security_space_left: 75 # V-38678
#
# Set an action to occur when the disk is approaching its capacity.
# Review the documentation for V-38470 before changing this option.
security_space_left_action: SYSLOG # V-38470
#
# Set the maximum size of a rotated log file. Ubuntu's default
# matches the STIG requirement of 6MB.
security_max_log_file: 6 # V 38633
#
# Sets the action to take when log files reach the maximum file size.
# Review the documentation for V-38634 before changing this option.
security_max_log_file_action: ROTATE # V-38634
#
# Set the number of rotated audit logs to keep. Ubuntu has 5 as the default
# and this matches the STIG's requirements.
security_num_logs: 5 # V-38636
#
# Set the email address of someone who can receive and respond to notifications
# about low disk space for log volumes.
security_action_mail_acct: root # V-38680
#
# **IMMINENT DANGER**
# The STIG says that the system should switch to single user mode when the
# storage capacity gets very low. This can cause serious service disruptions
# and should only be set to 'single' for deployers in extremely high security
# environments. Ubuntu's default is SUSPEND, which will suspend logging.
# **IMMENENT DANGER**
security_admin_space_left_action: SUSPEND # V-54381
## Chrony (NTP) configuration
# Install and enable chrony to sync time with NTP servers.
security_enable_chrony: yes # V-38620
# Adjust the following NTP servers if necessary.
security_ntp_servers:
- 0.north-america.pool.ntp.org
- 1.north-america.pool.ntp.org
- 2.north-america.pool.ntp.org
- 3.north-america.pool.ntp.org
# Chrony limits access to clients that are on certain subnets. Adjust the
# following subnets here to limit client access to chrony servers.
security_allowed_ntp_subnets:
- 10/8
- 192.168/16
- 172.16/12
# Listen for NTP requests only on local interfaces.
security_ntp_bind_local_interfaces_only: yes
## Core dumps
# V-38675 requires disabling core dumps for all users unless absolutely
# necessary. Set this variable to 'no' to skip this change.
security_disable_core_dumps: yes # V-38675
## Services
# The STIG recommends ensuring that some services are running if no services
# utilizing it are enabled. Setting a boolean to 'yes' here will ensure that
# a service isn't actively running and will not be started after boot-up.
# Setting a 'no' will ensure that this Ansible role does not alter the service
# in any way from its current configuration.
#
security_disable_abrtd: yes # V-38641
security_disable_atd: yes # V-38640
security_disable_autofs: yes # V-38437
security_disable_avahi: yes # V-31618
security_disable_bluetooth: yes # V-38691
security_disable_netconsole: yes # v-38672
security_disable_qpidd: yes # V-38648
security_disable_rdisc: yes # V-38650
security_disable_rsh: yes # V-38594
security_disable_ypbind: yes # V-38604
security_disable_xinetd: yes # V-38582
#
# The STIG recommends ensuring that some services aren't installed at ANY time.
# Those services are listed here. Setting a boolean here to 'yes' wiil
# ensure that the STIG is followed and the service is removed. Setting a
# boolean to 'no' means that the playbook will not alter the service.
#
security_remove_ldap_server: yes # V-38627
security_remove_rsh_server: yes # V-38591
security_remove_sendmail: yes # V-38671
security_remove_telnet_server: yes # V-38587
security_remove_tftp_server: yes # V-38606
security_remove_xinetd: yes # V-38584
security_remove_xorg: yes # v-38676
security_remove_ypserv: yes # V-38603
#
# The STIG does not allow the system to run a graphical interface. Set this
# variable to 'no' if you need a graphical interface on the server.
security_disable_x_windows: yes # V-38674
## SSH configuration
# The following configuration items will adjust how the ssh daemon is
# configured. The recommendations from the RHEL 6 STIG are shown below, but
# they can be adjusted to fit a particular environment.
#
# Set a 15 minute time out for SSH sessions if there is no activity
security_ssh_client_alive_interval: 900 # V-38608
#
# Timeout ssh sessions as soon as ClientAliveInterval is reached once
security_ssh_client_alive_count_max: 0 # V-38610
#
# The ssh daemon must not permit root logins. The default value of
# 'without-password' is a deviation from the STIG requirements due to how
# OpenStack-Ansible operates, especially within OpenStack CI gate jobs. See
# documentation for V-38613 for more details.
security_ssh_permit_root_login: 'without-password' # V-38613
## Kernel
# Set these booleans to 'yes' to disable the kernel module (following the
# STIG requirements). Set the boolean to 'no' to ensure no changes are made.
security_disable_module_bluetooth: yes # V-38682
security_disable_module_dccp: yes # V-38514
security_disable_module_rds: yes # V-38516
security_disable_module_sctp: yes # V-38515
security_disable_module_tipc: yes # V-38517
security_disable_module_usb_storage: no # V-38490
security_disable_icmpv4_redirects: no # V-38524
security_disable_icmpv4_redirects_secure: no # V-38526
security_disable_icmpv6_redirects: no # V-38548
#
# ** DANGER **
# It's strongly recommended to fully understand the effects of changing the
# following sysctl tunables. Refer to the documentation under 'Developer
# Notes' for each of the STIGs below before making any changes.
# ** DANGER **
#
security_sysctl_enable_tcp_syncookies: yes # V-38539
security_sysctl_enable_martian_logging: no # V-38528
#
# Deployers who wish to disable IPv6 entirely must set this configuration
# variable to 'yes'. See the documentation for V-38546 before making this
# change.
security_disable_ipv6: no # V-38546
# Sets the global challenge ACK counter to a large value such
# that a potential attacker could not reasonably come up against it.
security_set_tcp_challenge_ack_limit: yes # CVE-2016-5696
## Mail
# The STIG requires inet_interfaces to be set to 'localhost', but Ubuntu will
# configure it to be 'all' when dpkg-reconfigure is unavailable (as it is when
# Ansible installs packages). The default here is 'localhost' to meet the STIG
# requirement, but some deployers may want this set to 'all' if their hosts
# need to receive emails over the network (which isn't common).
#
# See the documentation for V-38622 for more details.
security_postfix_inet_interfaces: localhost # V-38622
#
# Configuring an email address here will cause hosts to forward the root user's
# email to another address.
#
#security_root_forward_email: user@example.com
## Linux Security Module (LSM)
# AppArmor and SELinux provide powerful security controls on a Linux system
# by setting policies for allowed actions. By setting the following variable
# to true, the appropriate LSM will be enabled for the Linux distribution:
#
# Ubuntu: AppArmor
# CentOS: SELinux
#
# See the ansible-hardening documentation for more details.
security_enable_linux_security_module: yes # V-51337
## PAM and authentication
# V-38497 requires that accounts with null passwords aren't allowed to
# authenticate via PAM. Ubuntu 14.04's default allows these logins -- see the
# documentation for V-38497 for more details. Set the variable below to 'yes'
# to remove 'nullok_secure' from the PAM configuration or set it to 'no' to
# leave the PAM configuration unaltered.
security_pam_remove_nullok: yes # V-38497
#
# V-38501 requires that failed login attempts must lock a user account using
# pam_faillock, but Ubuntu doesn't package that PAM module. Instead, fail2ban
# can be installed to lock out IP addresses with failed logins for 15 minutes.
# Set the variable below to 'yes' to install and configure fail2ban.
security_install_fail2ban: no # V-38501
#
# The STIG requires bans to last 15 minutes. Adjust the following variable
# to set the time an IP is banned by fail2ban (in seconds).
security_fail2ban_bantime: 900 # V-38501
## Password complexity and aging
# V-38475 - There is no password length requirement by default in Ubuntu 14.04.
# To set a password length requirement, uncomment
# security_password_minimum_length below. The STIG recommendation is 14
# characters.
#security_password_minimum_length: 14 # V-38475
# V-38477 - There is no password change limitation set by default in Ubuntu. To
# set the minimum number of days between password changes, uncomment the
# security_password_minimum_days variable below. The STIG recommendation is 1
# day.
#security_password_minimum_days: 1 # V-38477
# V-38479 - There is no age limit on password by default in Ubuntu. Uncomment
# line below to use the STIG recommendation of 60 days.
#security_password_maximum_days: 60 # V-38479
# V-38480 - To warn users before their password expires, uncomment the line
# below and they will be warned 7 days prior (following the STIG).
#security_password_warn_age: 7 # V-38480
# V-38684 - Setting the maximum number of simultaneous logins per user. The
# STIG sets a limit of 10.
#security_max_simultaneous_logins: 10 # V-38684
# V-38692 - Lock accounts that are inactive for 35 days.
#security_inactive_account_lock_days: 35 # V-38692
## sudo
# V-58901 requires that 'NOPASSWD' and '!authenticate' do not appear in any
# sudoers files since they could lead to a compromise. Set the following
# variables to 'yes' to comment out any lines found with these prohibited
# parameters or leave them set to 'no' (the default) to leave sudoers files
# unaltered. Deployers are urged to review the documentation for this STIG
# before making changes.
security_sudoers_remove_nopasswd: no # V-58901
security_sudoers_remove_authenticate: no # V-58901
## umask settings
# The STIG recommends changing various default umask settings for users and
# daemons via different methods. However, this could cause serious issues for
# production OpenStack environements which haven't been tested with these
# changes.
#
# The variables below are set to match the STIG requirements, but they are
# commented out to ensure they require deployers to opt-in for each change. To
# opt in for one of the changes below, simply uncomment the line and run the
# playbook. Deployers are strongly advised to review the documentation for
# these changes and review their systems to ensure these changes won't cause
# service disruptions.
#
# V-38642 - Set umask for daemons in init scripts to 027 or 022
#security_umask_daemons_init: 027 # V-38642
#
# V-38645 - System default umask in /etc/login.defs must be 077
#security_umask_login_defs: 077 # V-38645
#
# V-38649 - System default umask for csh must be 077
#security_umask_csh: 077 # V-38649
#
# V-38651 - System default umask for bash must be 077
#security_umask_bash: 077 # V-38651
## Unattended upgrades (APT) configuration
security_unattended_upgrades_enabled: false
security_unattended_upgrades_notifications: false

3168
doc/metadata/U_RedHat_6_V1R12_Manual-xccdf.xml
View File

File diff suppressed because one or more lines are too long

61
doc/metadata/import-existing-notes.py
View File

@ -1,61 +0,0 @@
#!/usr/bin/env python
# Copyright 2016, Rackspace US, Inc.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
"""Import existing developer notes into base YAML format."""
import os
import jinja2
SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__))
METADATA_DIR = "{0}/rhel6".format(SCRIPT_DIR)
NOTES_DIR = "{0}/../source/stig-notes".format(SCRIPT_DIR)
yaml_tmp = """---
id: {{ note_data['id'] }}
status: {{ note_data['status'] }}
tag: {{ note_data['tag'] }}
---
{{ note_data['deployer_notes'] }}
"""
note_files = [x for x in os.listdir(NOTES_DIR) if 'developer' in x]
for note_file in note_files:
stig_id = note_file[0:7]
with open("{0}/{1}".format(NOTES_DIR, note_file), 'r') as f:
content = f.read()
first_line = content.splitlines()[0]
print(first_line)
if 'exception' in first_line.lower():
status = 'exception'
elif 'opt-in' in first_line.lower():
status = 'opt-in'
else:
status = 'implemented'
note_data = {
'id': stig_id,
'status': status,
'tag': 'misc',
'deployer_notes': content
}
with open("{0}/{1}.rst".format(METADATA_DIR, stig_id), 'w') as f:
template = jinja2.Template(yaml_tmp)
f.write(template.render(note_data=note_data))

12
doc/metadata/rhel6/V-38437.rst
View File

@ -1,12 +0,0 @@
---
id: V-38437
status: implemented
tag: services
---
If ``autofs`` is installed, it will be disabled by Ansible tasks. To opt-out
of this change, adjust the following variable:
.. code-block:: yaml
security_disable_autofs: no

19
doc/metadata/rhel6/V-38438.rst
View File

@ -1,19 +0,0 @@
---
id: V-38438
status: implemented
tag: boot
---
To opt-out of the change, set the following variable:
.. code-block:: yaml
security_enable_audit_during_boot: no
Deployers may opt-in for the change without automatically updating the active
``grub.cfg`` file by setting the following Ansible variables:
.. code-block:: yaml
security_enable_audit_during_boot: yes
security_enable_grub_update: no

9
doc/metadata/rhel6/V-38439.rst
View File

@ -1,9 +0,0 @@
---
id: V-38439
status: exception - manual intervention
tag: auth
---
Although adding centralized authentication and carefully managing user
accounts is critical for securing any system, that's left up to deployers
to handle via their internal business processes.

8
doc/metadata/rhel6/V-38443.rst
View File

@ -1,8 +0,0 @@
---
id: V-38443
status: implemented
tag: auth
---
The ``/etc/gshadow`` file is owned by root by default on Ubuntu 14.04, Ubuntu
16.04 and CentOS 7. The security role ensures that the file is owned by root.

8
doc/metadata/rhel6/V-38444.rst
View File

@ -1,8 +0,0 @@
---
id: V-38444
status: exception - manual intervention
tag: network
---
See V-38551 for additional details. IPv6 configuration and filtering is left
up to the deployer.

9
doc/metadata/rhel6/V-38445.rst
View File

@ -1,9 +0,0 @@
---
id: V-38445
status: implemented
tag: auditd
---
The logs generated by the audit daemon are owned by root in Ubuntu 14.04,
Ubuntu 16.04 and CentOS 7. The Ansible task for V-38445 ensures that the files
are owned by the root user.

12
doc/metadata/rhel6/V-38446.rst
View File

@ -1,12 +0,0 @@
---
id: V-38446
status: configuration required
tag: mail
---
Forwarding root's email to another user is highly recommended so that someone
can receive emails about errors or security events.
Deployers should set ``security_root_forward_email`` to a valid email address
of a user or mailing list that should receive critical automated emails from
the server.

24
doc/metadata/rhel6/V-38447.rst
View File

@ -1,24 +0,0 @@
---
id: V-38447
status: exception
tag: package
---
Although Ubuntu provides the ``debsums`` command for checking the contents of
files installed from packages, it cannot perform a detailed level of checking
sufficient to meet the STIG requirement. Some packages are not shipped with MD5
checksums for all files. Deployers are encouraged to use ``debsums -c``
regularly to check for alterations in as many packages as possible.
Ubuntu does not currently have a capability to check file permissions,
ownership, or group ownership against the permissions that were originally set
when the package was installed.
In CentOS, the ``rpm`` command can verify package contents, ownership, group
ownership, and permissions after the package has been installed. However, many
configuration files are changed by the security role and this will cause the
verification to fail.
Deployers should utilize the monitoring capabilities of the ``aide`` package
(which is installed by other Ansible tasks in this role) to determine which
configuration files, libraries or binaries may have been changed.

8
doc/metadata/rhel6/V-38448.rst
View File

@ -1,8 +0,0 @@
---
id: V-38448
status: implemented
tag: auth
---
Although the ``/etc/gshadow`` file is group-owned by root by default, the
Ansible tasks will ensure that it is configured that way.

8
doc/metadata/rhel6/V-38449.rst
View File

@ -1,8 +0,0 @@
---
id: V-38449
status: implemented
tag: auth
---
The ``/etc/gshadow`` file's permissions will be changed to ``0000`` to meet
the requirements of the STIG.

7
doc/metadata/rhel6/V-38450.rst
View File

@ -1,7 +0,0 @@
---
id: V-38450
status: implemented
tag: auth
---
The ownership of ``/etc/passwd`` will be changed to root.

7
doc/metadata/rhel6/V-38451.rst
View File

@ -1,7 +0,0 @@
---
id: V-38451
status: implemented
tag: auth
---
The group ownership for ``/etc/passwd`` will be set to root.

24
doc/metadata/rhel6/V-38452.rst
View File

@ -1,24 +0,0 @@
---
id: V-38452
status: exception
tag: package
---
Although Ubuntu provides the ``debsums`` command for checking the contents of
files installed from packages, it cannot perform a detailed level of checking
sufficient to meet the STIG requirement. Some packages are not shipped with MD5
checksums for all files. Deployers are encouraged to use ``debsums -c``
regularly to check for alterations in as many packages as possible.
Ubuntu does not currently have a capability to check file permissions,
ownership, or group ownership against the permissions that were originally set
when the package was installed.
In CentOS, the ``rpm`` command can verify package contents, ownership, group
ownership, and permissions after the package has been installed. However, many
configuration files are changed by the security role and this will cause the
verification to fail.
Deployers should utilize the monitoring capabilities of the ``aide`` package
(which is installed by other Ansible tasks in this role) to determine which
configuration files, libraries or binaries may have been changed.

11
doc/metadata/rhel6/V-38453.rst
View File

@ -1,11 +0,0 @@
---
id: V-38453
status: exception - ubuntu
tag: package
---
Verifying ownership and permissions of installed packages isn't possible in the
current version of ``dpkg`` as it is with ``rpm``. This security configuration
is skipped for Ubuntu.
For CentOS, this check is done as part of V-38637.

24
doc/metadata/rhel6/V-38454.rst
View File

@ -1,24 +0,0 @@
---
id: V-38454
status: exception
tag: package
---
Although Ubuntu provides the ``debsums`` command for checking the contents of
files installed from packages, it cannot perform a detailed level of checking
sufficient to meet the STIG requirement. Some packages are not shipped with MD5
checksums for all files. Deployers are encouraged to use ``debsums -c``
regularly to check for alterations in as many packages as possible.
Ubuntu does not currently have a capability to check file permissions,
ownership, or group ownership against the permissions that were originally set
when the package was installed.
In CentOS, the ``rpm`` command can verify package contents, ownership, group
ownership, and permissions after the package has been installed. However, many
configuration files are changed by the security role and this will cause the
verification to fail.
Deployers should utilize the monitoring capabilities of the ``aide`` package
(which is installed by other Ansible tasks in this role) to determine which
configuration files, libraries or binaries may have been changed.

12
doc/metadata/rhel6/V-38455.rst
View File

@ -1,12 +0,0 @@
---
id: V-38455
status: exception - initial provisioning
tag: boot
---
Configuring another mount for ``/tmp`` can disrupt a running system and this
configuration is skipped.
However, deployers are strongly urged to consider creating a separate
partition and/or LVM logical volume for ``/tmp`` during installation of the OS
if possible.

12
doc/metadata/rhel6/V-38456.rst
View File

@ -1,12 +0,0 @@
---
id: V-38456
status: exception - initial provisioning
tag: boot
---
Configuring another mount for ``/var`` can disrupt a running system and this
configuration is skipped.
However, deployers are strongly urged to consider creating a separate
partition and/or LVM logical volume for ``/var`` during installation of the OS
if possible.

7
doc/metadata/rhel6/V-38457.rst
View File

@ -1,7 +0,0 @@
---
id: V-38457
status: implemented
tag: auth
---
The permissions for ``/etc/passwd`` will be set to ``0644``.

8
doc/metadata/rhel6/V-38458.rst
View File

@ -1,8 +0,0 @@
---
id: V-38458
status: implemented
tag: auth
---
The Ansible task will ensure that the ``/etc/group`` file is owned by the root
user.

8
doc/metadata/rhel6/V-38459.rst
View File

@ -1,8 +0,0 @@
---
id: V-38459
status: implemented
tag: auth
---
The Ansible tasks will ensure that ``/etc/group`` is owned by the ``root``
user.

10
doc/metadata/rhel6/V-38460.rst
View File

@ -1,10 +0,0 @@
---
id: V-38460
status: implemented
tag: nfsd
---
The Ansible tasks will check for ``all_squash`` in ``/etc/exports`` (if it is
present). If found, a warning message will be printed. No configuration
changes will be made since neither Ubuntu or openstack-ansible configures
the NFS server by default.

8
doc/metadata/rhel6/V-38461.rst
View File

@ -1,8 +0,0 @@
---
id: V-38461
status: implemented
tag: auth
---
The Ansible tasks will ensure that the mode of ``/etc/group//` is set to
``0644``.

23
doc/metadata/rhel6/V-38462.rst
View File

@ -1,23 +0,0 @@
---
id: V-38462
status: implemented
tag: package
---
All versions of Ubuntu and CentOS supported by the role verify packages against
GPG signatures by default.
Deployers can disable GPG verification for all packages in Ubuntu by setting
the ``AllowUnauthenticated`` configuration option in a file within
``/etc/apt/apt.conf.d/``. The Ansible tasks will search for this configuration
option and will stop the playbook execution if the option is set. Note
that users can pass an argument on the apt command line to bypass the checks as
well, but that's outside the scope of this check and remediation.
In CentOS, deployers can set ``gpgcheck=0`` within individual yum repository
files in ``/etc/yum.repos.d/`` to disable GPG signature checking. The Ansible
tasks will check for this configuration option in those files and stop the
playbook execution.
Deployers can use ``--skip-tags V-38462`` to omit these tasks when applying the
security role on systems where GPG verification must be disabled.

12
doc/metadata/rhel6/V-38463.rst
View File

@ -1,12 +0,0 @@
---
id: V-38463
status: exception - initial provisioning
tag: misc
---
Configuring a separate partition for ``/var/log`` is currently left up to the
deployer. There are security and operational benefits that come from the
change, but it must be done when the system is initially installed.
Deployers are urged to consider making a separate partition for ``/var/log``
during OS installation.

26
doc/metadata/rhel6/V-38464.rst
View File

@ -1,26 +0,0 @@
---
id: V-38464
status: implemented
tag: auditd
---
The default configuration for ``disk_error_action`` is ``SUSPEND``, which
only suspends audit logging when there is a disk error on the system.
Suspending audit logging can lead to security problems because the system is no
longer keeping track of which syscalls were made.
The security role sets the configuration to ``SYSLOG`` so that messages are
sent to syslog when disk errors occur. There are additional options available,
like ``EXEC``, ``SINGLE`` or ``HALT``.
To configure a different ``disk_error_action``, set the following Ansible
variable:
.. code-block:: yaml
security_disk_error_action: SYSLOG
For details on available settings and what they do, run ``man auditd.conf``.
Some options can cause the host to go offline until the issue is fixed.
Deployers are urged to **carefully read the auditd documentation** prior to
changing the ``security_disk_error_action`` setting from the default.

9
doc/metadata/rhel6/V-38465.rst
View File

@ -1,9 +0,0 @@
---
id: V-38465
status: exception
tag: file_perms
---
Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 set library files to have ``0755`` (or
more restrictive) permissions by default. Deployers are urged to review the
permissions of libraries regularly to ensure the system has not been altered.

9
doc/metadata/rhel6/V-38466.rst
View File

@ -1,9 +0,0 @@
---
id: V-38466
status: exception
tag: file_perms
---
As with V-38465, Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 set the ownership of
library files to root by default. Deployers are urged to configure monitoring
for changes to these files.

8
doc/metadata/rhel6/V-38467.rst
View File

@ -1,8 +0,0 @@
---
id: V-38467
status: exception - initial provisioning
tag: auditd
---
Storing audit logs on a separate partition is recommended, but this change
is left up to deployers to configure during the installation of the OS.

27
doc/metadata/rhel6/V-38468.rst
View File

@ -1,27 +0,0 @@
---
id: V-38468
status: implemented
tag: auditd
---
The default configuration for ``disk_full_action`` is ``SUSPEND``, which only
suspends audit logging. Suspending audit logging can lead to security problems
because the system is no longer keeping track of which syscalls were made.
The security role sets the configuration to ``SYSLOG`` so that messages are
sent to syslog when the disk is full. If syslog messages are being sent to
remote servers, these log messages should alert an administrator about the disk
being full. There are additional options available, like ``EXEC``, ``SINGLE``
or ``HALT``.
To configure a different ``disk_full_action``, set the following
Ansible variable:
.. code-block:: yaml
security_disk_full_action: SYSLOG
For details on available settings and what they do, run ``man auditd.conf``.
Some options can cause the host to go offline until the issue is fixed.
Deployers are urged to **carefully read the auditd documentation** prior to
changing the ``disk_full_action`` setting from the default.

9
doc/metadata/rhel6/V-38469.rst
View File

@ -1,9 +0,0 @@
---
id: V-38469
status: exception
tag: file_perms
---
Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 set the permissions for system
commands to ``0755`` or less already. Deployers are urged to review these
permissions for changes over time as they can be a sign of a compromise.

28
doc/metadata/rhel6/V-38470.rst
View File

@ -1,28 +0,0 @@
---
id: V-38470
status: implemented
tag: auditd
---
The default configuration for ``security_space_left_action`` is ``SUSPEND``,
which actually only suspends audit logging. Suspending audit logging can lead
to security problems because the system is no longer keeping track of which
syscalls were made.
The security role sets the configuration to ``SYSLOG`` so that messages are
sent to syslog when the available disk space reaches a low level. If syslog
messages are being sent to remote servers, these log messages should alert an
administrator about the disk being almost full. There are additional options
available, like ``EXEC``, ``SINGLE`` or ``HALT``.
To configure a different ``space_left_action``, set the following
Ansible variable:
.. code-block:: yaml
security_space_left_action: SYSLOG
For details on available settings and what they do, run ``man auditd.conf``.
Some options can cause the host to go offline until the issue is fixed.
Deployers are urged to **carefully read the auditd documentation** prior to
changing the ``space_left_action`` setting from the default.

10
doc/metadata/rhel6/V-38471.rst
View File

@ -1,10 +0,0 @@
---
id: V-38471
status: implemented
tag: auditd
---
An Ansible task will adjust ``active`` from ``no`` to ``yes`` in
``/etc/audisp/plugins.d/syslog.conf`` so that auditd records are forwarded to
syslog automatically. The auditd daemon will be restarted if the configuration
file is changed.

9
doc/metadata/rhel6/V-38472.rst
View File

@ -1,9 +0,0 @@
---
id: V-38472
status: exception
tag: file_perms
---
Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 set system commands to be owned by
root by default. Deployers are urged to review ownership changes via auditd
rules to ensure system commands haven't changed ownership over time.

8
doc/metadata/rhel6/V-38473.rst
View File

@ -1,8 +0,0 @@
---
id: V-38473
status: exception - initial provisioning
tag: misc
---
Creating ``/home`` on a different partition is highly recommended but it is
left to deployers to configure during the installation of the OS.

8
doc/metadata/rhel6/V-38474.rst
View File

@ -1,8 +0,0 @@
---
id: V-38474
status: exception
tag: x11
---
The openstack-ansible roles don't install X by default, so there is no
graphical desktop to configure.

15
doc/metadata/rhel6/V-38475.rst
View File

@ -1,15 +0,0 @@
---
id: V-38475
status: configuration required
tag: auth
---
The STIG recommends passwords to be a minimum of 14 characters in length. To
apply this setting, set the following Ansible variable:
.. code-block:: yaml
security_password_minimum_length: 14
Deployers are urged to avoid the use of passwords and rely upon SSH keys if
possible.

13
doc/metadata/rhel6/V-38476.rst
View File

@ -1,13 +0,0 @@
---
id: V-38476
status: implemented
tag: package
---
The security role verifies that the GPG keys that correspond to each supported
Linux distribution are installed on each host. If the GPG keys are not found,
or if they differ from the list of trusted GPG keys, the playbook execution
will stop.
Deployers can skip this task (and avoid this failure) by using ``--skip-tags
V-38476`` when they are applying the security role.

12
doc/metadata/rhel6/V-38477.rst
View File

@ -1,12 +0,0 @@
---
id: V-38477
status: configuration required
tag: auth
---
The STIG recommends setting a limit of one password change per day. To enable
this configuration, use this Ansible variable:
.. code-block:: yaml
security_password_minimum_days: 14

10
doc/metadata/rhel6/V-38478.rst
View File

@ -1,10 +0,0 @@
---
id: V-38478
status: exception
tag: package
---
Ubuntu and CentOS do not use the Red Hat Network Service. However, there are
tasks in the security role which ensure that all packages have GPG checks
enabled (see V-38462) and provide the option for deployers to apply updates
automatically.

12
doc/metadata/rhel6/V-38479.rst
View File

@ -1,12 +0,0 @@
---
id: V-38479
status: configuration required
tag: auth
---
The STIG recommends setting a limit of 60 days before a password must
be changed. To enable this configuration, use this Ansible variable:
.. code-block:: yaml
security_password_maximum_days: 60

14
doc/metadata/rhel6/V-38480.rst
View File

@ -1,14 +0,0 @@
---
id: V-38480
status: configuration required
tag: auth
---
After enabling password age limits in V-38479, be sure to configure
warnings for users so they know when their password is approaching expiration.
STIG's recommendation is seven days prior to the expiration. Use an Ansible
variable to configure the warning:
.. code-block:: yaml
security_password_warn_age: 7

32
doc/metadata/rhel6/V-38481.rst
View File

@ -1,32 +0,0 @@
---
id: V-38481
status: opt-in
tag: package
---
Operating system patching policies vary from organization to organization and
are typically established based on business requirements and risk tolerance.
.. note::
Automatically upgrading packages can provide significant security benefits,
but they can reduce availability and reliability. Updating packages can
cause daemons to restart on some systems and they can cause local
customizations of configuration files to be lost.
Deployers are **strongly urged** to understand the nature of this change
and the associated risks prior to enabling automatic upgrades.
Deployers can enable automatic updates by setting
``security_unattended_upgrades`` to ``True``:
.. code-block:: yaml
security_unattended_upgrades: true
In Ubuntu, the ``unattended-upgrades`` package is installed and enabled. This
will apply updates that are made available to the trusty-security (Ubuntu
14.04) or xenial-security (Ubuntu 16.04) repositories.
In CentOS, the ``yum-cron`` package is installed and configured to
automatically apply updates.

14
doc/metadata/rhel6/V-38482.rst
View File

@ -1,14 +0,0 @@
---
id: V-38482
status: exception
tag: auth
---
Password complexity requirements are left up to the deployer. Deployers are
urged to rely on SSH keys as often as possible to avoid problems with
passwords.
Review the pam_cracklib documentation by running ``man pam_cracklib`` or
read the `detailed documentation from Hal Pomeranz`_.
.. _detailed documentation from Hal Pomeranz: http://www.deer-run.com/~hal/sysadmin/pam_cracklib.html

9
doc/metadata/rhel6/V-38483.rst
View File

@ -1,9 +0,0 @@
---
id: V-38483
status: implemented
tag: package
---
The Ansible task for V-38462 already checks for configurations that would
disable any GPG checks when installing packages. However, it is possible for
the root user to override these configurations via command line parameters.

9
doc/metadata/rhel6/V-38484.rst
View File

@ -1,9 +0,0 @@
---
id: V-38484
status: implemented
tag: package
---
Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 already enable the display of the last
successful login for a user immediately after login. An Ansible task ensures
this setting is applied and restarts the ssh daemon if necessary.

9
doc/metadata/rhel6/V-38486.rst
View File

@ -1,9 +0,0 @@
---
id: V-38486
status: exception
tag: misc
---
System backups are left to the deployer to configure. Deployers are stringly
urged to maintain backups of each system, including log files and critical
configuration information.

9
doc/metadata/rhel6/V-38487.rst
View File

@ -1,9 +0,0 @@
---
id: V-38487
status: implemented
tag: package
---
The Ansible task for V-38462 already checks for apt configurations that would
disable any GPG checks when installing packages. However, it's possible for
the root user to override these configurations via command line parameters.

9
doc/metadata/rhel6/V-38488.rst
View File

@ -1,9 +0,0 @@
---
id: V-38488
status: exception
tag: misc
---
System backups are left to the deployer to configure. Deployers are stringly
urged to maintain backups of each system, including log files and critical
configuration information.

8
doc/metadata/rhel6/V-38489.rst
View File

@ -1,8 +0,0 @@
---
id: V-38489
status: implemented
tag: aide
---
The security role installs and configures the ``aide`` package to provide file
integrity monitoring on the host.

15
doc/metadata/rhel6/V-38490.rst
View File

@ -1,15 +0,0 @@
---
id: V-38490
status: opt-in
tag: kernel
---
Disabling the ``usb-storage`` module can add extra security, but it's not
necessary on most systems. To disable the ``usb-storage`` module on hosts,
set the following variable to ``yes``:
.. code-block:: yaml
security_disable_module_usb_storage: yes
**NOTE:** The module will be disabled on the next reboot.

12
doc/metadata/rhel6/V-38491.rst
View File

@ -1,12 +0,0 @@
---
id: V-38491
status: implemented
tag: auth
---
The Ansible task will check for the presence of ``/etc/hosts.equiv`` and
``/root/.rhosts``. Both of those files could potentially be used with ``rsh``
for host access.
The ``rshd`` daemon is not installed by default with Ubuntu 14.04, Ubuntu
16.04, CentOS 7, or OpenStack-Ansible.

14
doc/metadata/rhel6/V-38492.rst
View File

@ -1,14 +0,0 @@
---
id: V-38492
status: exception
tag: auth
---
Virtual consoles are helpful during an emergency and they can only be reached
by physical or other out-of-band access (such as DRAC, iLO, or iKVM). This
change can be confusing for system administrators and it is left up to the
deployer to complete.
As an alternative, deployers could take action to restrict physical access to
server terminals. Out-of-band access mechanisms should be segmented onto their
own restricted network and should use centralized authentication.

9
doc/metadata/rhel6/V-38493.rst
View File

@ -1,9 +0,0 @@
---
id: V-38493
status: implemented
tag: auditd
---
Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 set the mode of ``/var/log/audit/`` to
``0750`` by default. The Ansible task for this requirement ensures that the
mode is ``0750`` (which is more strict than the STIG requirement).

11
doc/metadata/rhel6/V-38494.rst
View File

@ -1,11 +0,0 @@
---
id: V-38494
status: exception
tag: auth
---
Removing serial consoles from ``/etc/securetty`` can make troubleshooting
a server extremely difficult. Deployers are urged to use strong physical
security practices to prevent unauthorized users from gaining physical access
to critical hosts. In addition, out-of-band systems that allow for serial
over LAN access should also be heavily secured.

8
doc/metadata/rhel6/V-38495.rst
View File

@ -1,8 +0,0 @@
---
id: V-38495
status: implemented
tag: auditd
---
The Ansible tasks will ensure that files in ``/var/log/audit`` are owned
by the root user.

17
doc/metadata/rhel6/V-38496.rst
View File

@ -1,17 +0,0 @@
---
id: V-38496
status: exception - manual intervention
tag: auth
---
The Ansible tasks will check for default system accounts (other than root)
that are not locked. The tasks won't take any action, however, because
any action could cause authorized users to be unable to access the system.
However, if any unlocked default system accounts are found, the playbook will
fail with an error message until the user accounts are locked.
Deployers who intentionally want to skip this step should use
``--skip-tags V-38496`` to avoid a playbook failure on this check.
Deployers are urged to audit the accounts on their systems and lock any users
that don't need to log in via consoles or via ssh.

28
doc/metadata/rhel6/V-38497.rst
View File

@ -1,28 +0,0 @@
---
id: V-38497
status: implemented
tag: auth
---
Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 allow accounts with null passwords to
authenticate via PAM by default. This STIG requires that those login attempts
are blocked.
For Ubuntu, the ``nullok_secure`` option will be removed from ``/etc/pam.d
/common-auth``.
For CentOS, the ``nullok`` option will be removed from ``/etc/pam.d/system-
auth``.
The effects of the change are **immediate** and no service restarts are
required.
Deployers can opt-out of this change by adjusting an Ansible variable:
.. code-block:: yaml
security_pam_remove_nullok: no
Setting the variable to ``yes`` (the default) will cause the Ansible tasks to
remove the ``nullok_secure`` parameter while setting the variable to ``no``
will leave the PAM configuration unchanged.

14
doc/metadata/rhel6/V-38498.rst
View File

@ -1,14 +0,0 @@
---
id: V-38498
status: implemented
tag: auditd
---
Ubuntu and CentOS set the current audit log (the one that is actively being
written to) to ``0600`` so that only the root user can read and write to it.
The older, rotated logs are set to ``0400`` since they should not receive
any more writes.
The STIG requirement states that log files must have mode ``0640`` or less. The
security role will remove any permissions that are not allowed by the STIG
(``u-x,g-wx,o-rwx``).

8
doc/metadata/rhel6/V-38499.rst
View File

@ -1,8 +0,0 @@
---
id: V-38499
status: implemented
tag: auth
---
The Ansible task will search for password hashes in ``/etc/passwd`` using
awk and report a failure if any are found.

13
doc/metadata/rhel6/V-38500.rst
View File

@ -1,13 +0,0 @@
---
id: V-38500
status: implemented
tag: auth
---
The Ansible tasks will search for accounts in ``/etc/passwd`` that have UID 0
that aren't the normal root account. If any matching accounts are found, a
warning is printed to stdout and the Ansible play will fail.
No action is taken on those accounts as that action may disrupt a production
environment. Deployers are strongly urged to use ``sudo`` for these types of
actions.

43
doc/metadata/rhel6/V-38501.rst
View File

@ -1,43 +0,0 @@
---
id: V-38501
status: opt-in
tag: auth
---
Adjusting PAM configurations is very risky since it affects how all users
authenticate. In addition, ``pam_faillock.so`` isn't available in Ubuntu.
Another option is to utilize ``pam_tally`` to deny logins after failed
attempts. Adjusting PAM configurations automatically can disrupt the operation
of production systems, so this is left up to the deployer to configure.
For more details on how to configure ``pam_tally``, refer to `this AskUbuntu
article about pam_tally`_.
Another alternative is `fail2ban`_. Read the notes below for more tails on
this option.
The Ansible tasks will install `fail2ban`_ and configure it to ban IP
addresses using the following logic
* The IP has attempted three logins in the last 10 minutes and all have failed
* That IP will be banned for 15 minutes (via iptables rules)
Deployers must opt-in for fail2ban to be installed and configured. To opt-in,
set the ``security_install_fail2ban`` Ansible variable to ``yes``. The time
period for bans can also be configured (in seconds) via tha
``security_fail2ban_bantime`` variable:
.. code-block:: yaml
security_install_fail2ban: yes
security_fail2ban_bantime: 900
**NOTE:** Fail2ban can only review authentication attempts for services that
listen on the network, such as ssh. It has no control over physical consoles.
Deployers are strongly urged to use stong physical security policies to
prevent unauthorized users from accessing server consoles. In addition,
deployers must secure out-of-band access methods, like IPMI, as they can be
vectors for physical console access as well.
.. _this AskUbuntu article about pam_tally: http://askubuntu.com/questions/59459/how-do-i-enable-account-lockout-using-pam-tally
.. _fail2ban: https://en.wikipedia.org/wiki/Fail2ban

8
doc/metadata/rhel6/V-38502.rst
View File

@ -1,8 +0,0 @@
---
id: V-38502
status: implemented
tag: auth
---
The user and group ownership of ``/etc/passwd`` is root by default. The Ansible
task will ensure that the default is maintained.

8
doc/metadata/rhel6/V-38503.rst
View File

@ -1,8 +0,0 @@
---
id: V-38503
status: implemented
tag: auth
---
The user and group ownership of ``/etc/passwd`` is root by default. The Ansible
task will ensure that the default is maintained.

14
doc/metadata/rhel6/V-38504.rst
View File

@ -1,14 +0,0 @@
---
id: V-38504
status: implemented
tag: auth
---
Ubuntu 14.04 and Ubuntu 16.04 set the mode of ``/etc/shadow`` to ``0640``, but
CentOS 7 sets it to ``000``. The STIG requires the mode to be ``000`` and the
Ansible tasks in the security role ensure that the mode meets the requirement.
**Special note for Ubuntu:** This change doesn't affect how the system operates
since root is the only user that should be able to read from and write to
``/etc/shadow``. Allowing users to read the file could open up the system to
attacks since the password hashes can be dumped and brute forced.

9
doc/metadata/rhel6/V-38511.rst
View File

@ -1,9 +0,0 @@
---
id: V-38511
status: implemented
tag: misc
---
Running virtual infrastructure requires IP forwarding to be enabled on various
interfaces. The STIG allows for this, so long as the system is being operated
as a router (as is the case for an OpenStack host).

14
doc/metadata/rhel6/V-38512.rst
View File

@ -1,14 +0,0 @@
---
id: V-38512
status: exception
tag: network
---
Although a minimal set of iptables rules are configured on openstack-ansible
hosts, the "deny all" requirement of the STIG is not met. This is largely left
up to the deployer to do, based on their assessment of their own network
segmentation.
Deployers are urged to review the network access controls that are applied
on the network devices between their OpenStack environment and the rest of
their network.

14
doc/metadata/rhel6/V-38513.rst
View File

@ -1,14 +0,0 @@
---
id: V-38513
status: exception - manual intervention
tag: network
---
Although a minimal set of iptables rules are configured on openstack-ansible
hosts, the "deny all" requirement of the STIG is not met. This is largely left
up to the deployer to do, based on their assessment of their own network
segmentation.
Deployers are urged to review the network access controls that are applied
on the network devices between their OpenStack environment and the rest of
their network.

18
doc/metadata/rhel6/V-38514.rst
View File

@ -1,18 +0,0 @@
---
id: V-38514
status: implemented
tag: kernel
---
The Datagram Congestion Control Protocol (DCCP) must be disabled if it's not
needed. Although this protocol is occasionally used in some OpenStack
environments for quality of service functions, it is not in the default
implementation.
To opt-out of this change, simply change the following variable to ``no``:
.. code-block:: yaml
security_disable_module_dccp: no
**NOTE:** The module will be disabled on the next reboot.

14
doc/metadata/rhel6/V-38515.rst
View File

@ -1,14 +0,0 @@
---
id: V-38515
status: implemented
tag: kernel
---
The Stream Control Transmission Protocol (SCTP) must be disabled. To opt-out of
this change, set the following variable to ``no``:
.. code-block:: yaml
security_disable_module_sctp: no
**NOTE:** The module will be disabled on the next reboot.

18
doc/metadata/rhel6/V-38516.rst
View File

@ -1,18 +0,0 @@
---
id: V-38516
status: implemented
tag: kernel
---
The `Reliable Datagram Sockets (RDS)`_ protocol must be disabled. The Ansible
tasks in this role will disable the module.
.. _Reliable Datagram Sockets (RDS): https://en.wikipedia.org/wiki/Reliable_Datagram_Sockets
To opt-out of this change, set the following variable to ``no``:
.. code-block:: yaml
security_disable_module_rds: no
**NOTE:** The module will be disabled on the next reboot.

16
doc/metadata/rhel6/V-38517.rst
View File

@ -1,16 +0,0 @@
---
id: V-38517
status: implemented
tag: kernel
---
The `Transparent Inter-Process Communication (TIPC)`_ protocol must be
disabled. To opt-out of this change, set the following variable to ``no``:
.. _Transparent Inter-Process Communication (TIPC): https://en.wikipedia.org/wiki/TIPC
.. code-block:: yaml
security_disable_module_tipc: no
**NOTE:** The module will be disabled on the next reboot.

12
doc/metadata/rhel6/V-38518.rst
View File

@ -1,12 +0,0 @@
---
id: V-38518
status: exception
tag: file_perms
---
Different systems may have different log files populated depending on the type
of data that ``rsyslogd`` receives. By default, log files are created with the
user and group ownership set to root.
Deployers should review the files generated by the ``rsyslogd`` daemon to
verify that they have the most restrictive ownership and permissions.

12
doc/metadata/rhel6/V-38519.rst
View File

@ -1,12 +0,0 @@
---
id: V-38519
status: exception
tag: file_perms
---
Different systems may have different log files populated depending on the type
of data that ``rsyslogd`` receives. By default, log files are created with the
user and group ownership set to root.
Deployers should review the files generated by the ``rsyslogd`` daemon to
verify that they have the most restrictive ownership and permissions.

12
doc/metadata/rhel6/V-38520.rst
View File

@ -1,12 +0,0 @@
---
id: V-38520
status: exception - manual intervention
tag: log
---
At the moment, openstack-ansible already sends logs to the rsyslog container
from various containers and hosts. However, deployers are strongly urged
to forward these logs to a system outside their openstack-ansible environment
to ensure that they cannot be altered.
Some compliance programs require centralized logging, including PCI-DSS.

12
doc/metadata/rhel6/V-38521.rst
View File

@ -1,12 +0,0 @@
---
id: V-38521
status: exception - manual intervention
tag: log
---
At the moment, openstack-ansible already sends logs to the rsyslog container
from various containers and hosts. However, deployers are strongly urged
to forward these logs to a system outside their openstack-ansible environment
to ensure that they cannot be altered.
Some compliance programs require centralized logging, including PCI-DSS.

7
doc/metadata/rhel6/V-38522.rst
View File

@ -1,7 +0,0 @@
---
id: V-38522
status: implemented
tag: misc
---
Rules are added for auditing changes to system time made via ``settimeofday``.

17
doc/metadata/rhel6/V-38523.rst
View File

@ -1,17 +0,0 @@
---
id: V-38523
status: exception
tag: kernel
---
The STIG makes several requirements for IPv4 network restrictions, but these
restrictions can impact certain network interfaces and cause service
disruptions. Some security configurations make sense for certain types of
network interfaces, like bridges, but other restrictions cause the network
interface to stop passing valid traffic between hosts, containers, or virtual
machines.
The default network scripts and LXC userspace tools already configure various
network devices to their most secure setting. Since some hosts will act as
routers, enabling security configurations that restrict network traffic can
cause service disruptions for OpenStack environments.

15
doc/metadata/rhel6/V-38524.rst
View File

@ -1,15 +0,0 @@
---
id: V-38524
status: opt-in
tag: kernel
---
The STIG requires that ICMPv4 redirects are disabled on the host. However, this
can cause problems with LXC-based deployments, such as environments deployed
with OpenStack-Ansible.
Deployers can opt-in for this change by setting the following Ansible variable:
.. code-block:: yaml
security_disable_icmpv4_redirects: yes

7
doc/metadata/rhel6/V-38525.rst
View File

@ -1,7 +0,0 @@
---
id: V-38525
status: implemented
tag: auditd
---
Rules are added for auditing changes to system time done via ``stime``.

16
doc/metadata/rhel6/V-38526.rst
View File

@ -1,16 +0,0 @@
---
id: V-38526
status: opt-in
tag: kernel
---
The STIG requires that secure ICMP redirects are disabled, but this can cause
issues in some virtualized or containerized environments. The Ansible tasks
in the security role will not disable these redirects by default.
Deployers who want to enable the task (and disable ICMP redirects), should set
the following Ansible variable:
.. code-block:: yaml
security_disable_icmpv4_redirects_secure: yes

8
doc/metadata/rhel6/V-38527.rst
View File

@ -1,8 +0,0 @@
---
id: V-38527
status: implemented
tag: auditd
---
Rules are added for auditing changes to system time done via
``clock_settime``.

26
doc/metadata/rhel6/V-38528.rst
View File

@ -1,26 +0,0 @@
---
id: V-38528
status: opt-in
tag: kernel
---
The STIG requires that all martian packets are logged by setting the sysctl
parameter ``net.ipv4.conf.all.log_martians`` to ``1``.
Although the logs can be valuable in some situations, the setting can generate
a *significant* amount of logging in OpenStack environments, especially those
that use neutron's Linux bridge networking. In some situations, the logging can
flood the physical terminal and make troubleshooting at the console or via out
of band (like iKVM, DRAC and iLO) **extremely difficult**.
The role will ensure that martian packet logging is disabled by default.
Deployers that need this logging enabled will need to set the following
Ansible variable:
.. code-block:: yaml
security_sysctl_enable_martian_logging: yes
Wikpedia's article on `martian packets`_ provides additional information.
.. _martian packets: https://en.wikipedia.org/wiki/Martian_packet

17
doc/metadata/rhel6/V-38529.rst
View File

@ -1,17 +0,0 @@
---
id: V-38529
status: exception
tag: kernel
---
The STIG makes several requirements for IPv4 network restrictions, but these
restrictions can impact certain network interfaces and cause service
disruptions. Some security configurations make sense for certain types of
network interfaces, like bridges, but other restrictions cause the network
interface to stop passing valid traffic between hosts, containers, or virtual
machines.
The default network scripts and LXC userspace tools already configure various
network devices to their most secure setting. Since some hosts will act as
routers, enabling security configurations that restrict network traffic can
cause service disruptions for OpenStack environments.

8
doc/metadata/rhel6/V-38530.rst
View File

@ -1,8 +0,0 @@
---
id: V-38530
status: implemented
tag: auditd
---
Rules are added to auditd to log all attempts to change the system time using
``/etc/localtime``.

7
doc/metadata/rhel6/V-38531.rst
View File

@ -1,7 +0,0 @@
---
id: V-38531
status: implemented
tag: auditd
---
The audit rules from V-38534 already cover all account modifications.

17
doc/metadata/rhel6/V-38532.rst
View File

@ -1,17 +0,0 @@
---
id: V-38532
status: exception
tag: kernel
---
The STIG makes several requirements for IPv4 network restrictions, but these
restrictions can impact certain network interfaces and cause service
disruptions. Some security configurations make sense for certain types of
network interfaces, like bridges, but other restrictions cause the network
interface to stop passing valid traffic between hosts, containers, or virtual
machines.
The default network scripts and LXC userspace tools already configure various
network devices to their most secure setting. Since some hosts will act as
routers, enabling security configurations that restrict network traffic can
cause service disruptions for OpenStack environments.

17
doc/metadata/rhel6/V-38533.rst
View File

@ -1,17 +0,0 @@
---
id: V-38533
status: exception
tag: kernel
---
The STIG makes several requirements for IPv4 network restrictions, but these
restrictions can impact certain network interfaces and cause service
disruptions. Some security configurations make sense for certain types of
network interfaces, like bridges, but other restrictions cause the network
interface to stop passing valid traffic between hosts, containers, or virtual
machines.
The default network scripts and LXC userspace tools already configure various
network devices to their most secure setting. Since some hosts will act as
routers, enabling security configurations that restrict network traffic can
cause service disruptions for OpenStack environments.

9
doc/metadata/rhel6/V-38534.rst
View File

@ -1,9 +0,0 @@
---
id: V-38534
status: implemented
tag: auditd
---
Audit rules are added in a task so that any events associated with
account modifications are logged. The new audit rule will be loaded immediately
with ``augenrules --load``.

9
doc/metadata/rhel6/V-38535.rst
View File

@ -1,9 +0,0 @@
---
id: V-38535
status: implemented
tag: kernel
---
The Ansible tasks will ensure that ``net.ipv4.icmp_echo_ignore_broadcasts`` is
set to ``1``, which will cause the system to stop responding to ICMPv4 packets
sent to the broadcast address.

7
doc/metadata/rhel6/V-38536.rst
View File

@ -1,7 +0,0 @@
---
id: V-38536
status: implemented
tag: auditd
---
The audit rules from V-38534 already cover all account modifications.

9
doc/metadata/rhel6/V-38537.rst
View File

@ -1,9 +0,0 @@
---
id: V-38537
status: implemented
tag: kernel
---
The Ansible tasks will ensure that
``net.ipv4.icmp_ignore_bogus_error_responses`` is set to ``1``. This prevents
a host from responding to bogus ICMPv4 error messages.

7
doc/metadata/rhel6/V-38538.rst
View File

@ -1,7 +0,0 @@
---
id: V-38538
status: implemented
tag: auditd
---
The audit rules from V-38534 already cover all account modifications.

27
doc/metadata/rhel6/V-38539.rst
View File

@ -1,27 +0,0 @@
---
id: V-38539
status: implemented
tag: kernel
---
The STIG recommends enabling TCP SYN cookies to deal with TCP SYN floods.
Note that high-traffic environments may require TCP SYN cookies to be disabled.
Certain load balancers may forward requests in such a way that web servers may
think they're being SYN flooded during peak traffic events. Putting well-
configured hardware network devices in front of OpenStack environments is
always recommended and this may allow some deployers to turn off SYN cookies
within their environment.
Deployers can disable TCP SYN cookies by setting an Ansible variable:
.. code-block:: yaml
security_sysctl_enable_tcp_syncookies: no
Most operating systems, such as Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 have
TCP syncookies enabled by default upon installation. For more information on
TCP SYN cookies and TCP SYN floods, refer to these links:
* `Wikipedia: SYN flood <https://en.wikipedia.org/wiki/SYN_flood>`_
* `Wikipedia: SYN cookies <https://en.wikipedia.org/wiki/SYN_cookies>`_

7
doc/metadata/rhel6/V-38540.rst
View File

@ -1,7 +0,0 @@
---
id: V-38540
status: implemented
tag: auditd
---
Rules are added that allows auditd to track network configuration changes.

17
doc/metadata/rhel6/V-38541.rst
View File

@ -1,17 +0,0 @@
---
id: V-38541
status: implemented
tag: auditd
---
For Ubuntu, rules are added to auditd that will log any changes made in the
``/etc/apparmor`` directory.
For CentOS, rules are added to auditd that will log any changes made in the
``/etc/selinux`` directory.
To opt-out of this change, set the following Ansible variable:
.. code-block:: yaml
security_audit_mac_changes: no

17
doc/metadata/rhel6/V-38542.rst
View File

@ -1,17 +0,0 @@
---
id: V-38542
status: exception
tag: kernel
---
The STIG makes several requirements for IPv4 network restrictions, but these
restrictions can impact certain network interfaces and cause service
disruptions. Some security configurations make sense for certain types of
network interfaces, like bridges, but other restrictions cause the network
interface to stop passing valid traffic between hosts, containers, or virtual
machines.
The default network scripts and LXC userspace tools already configure various
network devices to their most secure setting. Since some hosts will act as
routers, enabling security configurations that restrict network traffic can
cause service disruptions for OpenStack environments.

Some files were not shown because too many files have changed in this diff Show More