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
parent
75c06173c7
commit
0c0767b3f1
@ -13,7 +13,6 @@ to systems running the following distributions:
|
|||||||
* openSUSE Leap 42.2 and 42.3
|
* openSUSE Leap 42.2 and 42.3
|
||||||
* Red Hat Enterprise Linux 7
|
* Red Hat Enterprise Linux 7
|
||||||
* SUSE Linux Enterprise 12 (*experimental*)
|
* SUSE Linux Enterprise 12 (*experimental*)
|
||||||
* Ubuntu 14.04 *(deprecated)*
|
|
||||||
* Ubuntu 16.04
|
* Ubuntu 16.04
|
||||||
|
|
||||||
For more details, review the
|
For more details, review the
|
||||||
@ -50,7 +49,6 @@ Running with Vagrant
|
|||||||
This role can be tested easily on multiple platforms using Vagrant.
|
This role can be tested easily on multiple platforms using Vagrant.
|
||||||
|
|
||||||
The `Vagrantfile` supports testing on:
|
The `Vagrantfile` supports testing on:
|
||||||
* Ubuntu 14.04
|
|
||||||
* Ubuntu 16.04
|
* Ubuntu 16.04
|
||||||
* CentOS 7
|
* CentOS 7
|
||||||
|
|
||||||
|
|||||||
@ -24,10 +24,7 @@
|
|||||||
# * SUSE Linux Enterprise 12
|
# * SUSE Linux Enterprise 12
|
||||||
# * Ubuntu 16.04 Xenial LTS
|
# * Ubuntu 16.04 Xenial LTS
|
||||||
#
|
#
|
||||||
# The RHEL 6 STIG content is deprecated in the Ocata release. It is compatible
|
# Valid options: rhel7
|
||||||
# with Ubuntu 14.04 Trusty LTS.
|
|
||||||
#
|
|
||||||
# Valid options: rhel7, rhel6
|
|
||||||
stig_version: rhel7
|
stig_version: rhel7
|
||||||
|
|
||||||
## APT Cache Options
|
## APT Cache Options
|
||||||
@ -73,6 +70,16 @@ security_set_maximum_password_lifetime: no # V-71931
|
|||||||
# Initialize the AIDE database immediately (may take time).
|
# Initialize the AIDE database immediately (may take time).
|
||||||
security_rhel7_initialize_aide: no # V-71973
|
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)
|
## Audit daemon (auditd)
|
||||||
# Send audit records to a different system using audisp.
|
# Send audit records to a different system using audisp.
|
||||||
#security_audisp_remote_server: '10.0.21.1' # V-72083
|
#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: no # V-72271
|
||||||
security_enable_firewalld_rate_limit_per_minute: 25
|
security_enable_firewalld_rate_limit_per_minute: 25
|
||||||
security_enable_firewalld_rate_limit_burst: 100
|
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.
|
# Require authentication in GRUB to boot into single-user or maintenance modes.
|
||||||
security_require_grub_authentication: no # V-71961 / V-71963
|
security_require_grub_authentication: no # V-71961 / V-71963
|
||||||
# The default password for grub authentication is 'secrete'.
|
# 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
|
security_rhel7_disable_usb_storage: yes # V-71983
|
||||||
# Disable kdump.
|
# Disable kdump.
|
||||||
security_disable_kdump: yes # V-72057
|
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
|
|
||||||
|
|||||||
File diff suppressed because one or more lines are too long
@ -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))
|
|
||||||
@ -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
|
|
||||||
@ -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
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -1,7 +0,0 @@
|
|||||||
---
|
|
||||||
id: V-38450
|
|
||||||
status: implemented
|
|
||||||
tag: auth
|
|
||||||
---
|
|
||||||
|
|
||||||
The ownership of ``/etc/passwd`` will be changed to root.
|
|
||||||
@ -1,7 +0,0 @@
|
|||||||
---
|
|
||||||
id: V-38451
|
|
||||||
status: implemented
|
|
||||||
tag: auth
|
|
||||||
---
|
|
||||||
|
|
||||||
The group ownership for ``/etc/passwd`` will be set to root.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -1,7 +0,0 @@
|
|||||||
---
|
|
||||||
id: V-38457
|
|
||||||
status: implemented
|
|
||||||
tag: auth
|
|
||||||
---
|
|
||||||
|
|
||||||
The permissions for ``/etc/passwd`` will be set to ``0644``.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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``.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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
|
|
||||||
@ -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.
|
|
||||||
@ -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
|
|
||||||
@ -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
|
|
||||||
@ -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.
|
|
||||||
@ -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
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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).
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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``).
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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).
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -1,7 +0,0 @@
|
|||||||
---
|
|
||||||
id: V-38522
|
|
||||||
status: implemented
|
|
||||||
tag: misc
|
|
||||||
---
|
|
||||||
|
|
||||||
Rules are added for auditing changes to system time made via ``settimeofday``.
|
|
||||||
@ -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.
|
|
||||||
@ -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
|
|
||||||
@ -1,7 +0,0 @@
|
|||||||
---
|
|
||||||
id: V-38525
|
|
||||||
status: implemented
|
|
||||||
tag: auditd
|
|
||||||
---
|
|
||||||
|
|
||||||
Rules are added for auditing changes to system time done via ``stime``.
|
|
||||||
@ -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
|
|
||||||
@ -1,8 +0,0 @@
|
|||||||
---
|
|
||||||
id: V-38527
|
|
||||||
status: implemented
|
|
||||||
tag: auditd
|
|
||||||
---
|
|
||||||
|
|
||||||
Rules are added for auditing changes to system time done via
|
|
||||||
``clock_settime``.
|
|
||||||
@ -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
|
|
||||||
@ -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.
|
|
||||||
@ -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``.
|
|
||||||
@ -1,7 +0,0 @@
|
|||||||
---
|
|
||||||
id: V-38531
|
|
||||||
status: implemented
|
|
||||||
tag: auditd
|
|
||||||
---
|
|
||||||
|
|
||||||
The audit rules from V-38534 already cover all account modifications.
|
|
||||||
@ -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.
|
|
||||||
@ -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.
|
|
||||||
@ -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``.
|
|
||||||
@ -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.
|
|
||||||
@ -1,7 +0,0 @@
|
|||||||
---
|
|
||||||
id: V-38536
|
|
||||||
status: implemented
|
|
||||||
tag: auditd
|
|
||||||
---
|
|
||||||
|
|
||||||
The audit rules from V-38534 already cover all account modifications.
|
|
||||||
@ -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.
|
|
||||||
@ -1,7 +0,0 @@
|
|||||||
---
|
|
||||||
id: V-38538
|
|
||||||
status: implemented
|
|
||||||
tag: auditd
|
|
||||||
---
|
|
||||||
|
|
||||||
The audit rules from V-38534 already cover all account modifications.
|
|
||||||
@ -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>`_
|
|
||||||
@ -1,7 +0,0 @@
|
|||||||
---
|
|
||||||
id: V-38540
|
|
||||||
status: implemented
|
|
||||||
tag: auditd
|
|
||||||
---
|
|
||||||
|
|
||||||
Rules are added that allows auditd to track network configuration changes.
|
|
||||||
@ -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
|
|
||||||
@ -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
Loading…
Reference in New Issue
Block a user