Trivial fix to the documentation
- Removing extra space _ Fixing some typos Change-Id: Ib4f86c7a29074ce0150a3cd55478ed94f2d62c43
This commit is contained in:
Rahul Nair
@@ -5,7 +5,7 @@ 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``
|
||||
``/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
|
||||
|
||||
@@ -7,5 +7,5 @@ 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
|
||||
to critical hosts. In addition, out-of-band systems that allow for serial
|
||||
over LAN access should also be heavily secured.
|
||||
|
||||
@@ -9,5 +9,5 @@ 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
|
||||
environment. Deployers are strongly urged to use ``sudo`` for these types of
|
||||
actions.
|
||||
|
||||
@@ -20,7 +20,7 @@ Deployers can disable TCP SYN cookies by setting an Ansible variable:
|
||||
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 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>`_
|
||||
|
||||
@@ -9,13 +9,13 @@ openstack-ansible roles don't configure IPv6 (at this time) and adding
|
||||
persistent ip6tables rules could harm a running system.
|
||||
|
||||
However, deployers are strongly recommended to implement IPv6 filtering at the
|
||||
edges of the network via network devices. In addition, deployers should be
|
||||
edges of the network via network devices. In addition, deployers should be
|
||||
aware that link-local IPv6 addresses are configured automatcally by the system
|
||||
and those addresses could open up new network paths for future attacks.
|
||||
|
||||
For example, if IPv4 access was tightly controlled and segmented, hosts and/or
|
||||
containers could possibly communicate across these boundaries using IPv6
|
||||
link-local addresses. For more detailed information on this security topic,
|
||||
link-local addresses. For more detailed information on this security topic,
|
||||
review Cisco's documentation titled `IPv6 Security Brief`_ that is available
|
||||
on their website.
|
||||
|
||||
|
||||
@@ -5,6 +5,6 @@ tag: file_perms
|
||||
---
|
||||
|
||||
Keeping the list of setuid/setgid applications up to date and adding the paths
|
||||
to those files within the ``audit.rules`` file is challenging. Deployers are
|
||||
to those files within the ``audit.rules`` file is challenging. Deployers are
|
||||
urged to use setuid/setgid sparingly and carefully monitor all applications
|
||||
with those permissions set.
|
||||
|
||||
@@ -5,7 +5,7 @@ tag: services
|
||||
---
|
||||
|
||||
The ``xinetd`` service will be removed by the Ansible tasks, if it is
|
||||
installed. To opt-out of this change, adjust the following variable
|
||||
installed. To opt-out of this change, adjust the following variable
|
||||
to ``no``:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@@ -5,6 +5,6 @@ tag: boot
|
||||
---
|
||||
|
||||
Configuring a password for the bootloader is left up to the deployer to
|
||||
configure. Each deployer should consider the potential damage to their
|
||||
configure. Each deployer should consider the potential damage to their
|
||||
system should someone gain unauthorized physical access at the server
|
||||
itself or via an out-of-band management solution (like IPMI, DRAC, or iLO).
|
||||
|
||||
@@ -5,7 +5,7 @@ tag: boot
|
||||
---
|
||||
|
||||
As with V-38585, this is left to the deployer to configure based on their
|
||||
exposure to physical threats. If there is a concern around a user gaining
|
||||
exposure to physical threats. If there is a concern around a user gaining
|
||||
unauthorized physical access and/or gaining access through an out-of-band
|
||||
access mechanism, deployers are strongly urged to consider applying this
|
||||
security configuration.
|
||||
|
||||
@@ -5,7 +5,7 @@ tag: services
|
||||
---
|
||||
|
||||
The ``telnetd`` service will be removed by the Ansible tasks, if it is
|
||||
installed. To opt-out of this change, adjust the following variable
|
||||
installed. To opt-out of this change, adjust the following variable
|
||||
to ``no``:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@@ -7,6 +7,6 @@ tag: console
|
||||
While providing text screen locking does add additional security, deployers
|
||||
are strongly urged to limit physical access and out-of-band access to
|
||||
servers where someone else might be able to join a user's session when
|
||||
they step away. In addition, if a user is logging in remotely via ssh,
|
||||
they step away. In addition, if a user is logging in remotely via ssh,
|
||||
they should lock their entire workstation to prevent unauthorized access
|
||||
to their system as well as the systems they are actively accessing.
|
||||
|
||||
@@ -5,7 +5,7 @@ tag: services
|
||||
---
|
||||
|
||||
The ``rshd`` service will be removed by the Ansible tasks, if it is
|
||||
installed. To opt-out of this change, adjust the following variable
|
||||
installed. To opt-out of this change, adjust the following variable
|
||||
to ``no``:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@@ -5,7 +5,7 @@ tag: sshd
|
||||
---
|
||||
|
||||
The ``ClientAliveInterval`` in the ssh configuration will be set to 15 minutes
|
||||
as recommended by the STIG. However, this time is configurable by setting
|
||||
as recommended by the STIG. However, this time is configurable by setting
|
||||
``security_ssh_client_alive_interval`` to another value, in seconds.
|
||||
|
||||
To change to 10 minutes, adjust the configuration item to 600 seconds:
|
||||
|
||||
@@ -5,7 +5,7 @@ tag: misc
|
||||
---
|
||||
|
||||
The ``chrony`` service is installed to manage clock synchronization for hosts
|
||||
and to serve as an NTP server for NTP clients. Chrony was chosen over ntpd
|
||||
and to serve as an NTP server for NTP clients. Chrony was chosen over ntpd
|
||||
because it's actively maintained and has some enhancements for virtualized
|
||||
environments.
|
||||
|
||||
@@ -20,11 +20,11 @@ There are two configurations available for users to adjust chrony's default
|
||||
configuration:
|
||||
|
||||
The ``security_ntp_servers`` variable is a list of NTP servers that
|
||||
chrony should use to synchronize time. They are set to North American NTP
|
||||
chrony should use to synchronize time. They are set to North American NTP
|
||||
servers by default.
|
||||
|
||||
The ``security_allowed_ntp_subnets`` variable is a list of subnets (in CIDR
|
||||
notation) that are allowed to reach your servers running chrony. A sane
|
||||
notation) that are allowed to reach your servers running chrony. A sane
|
||||
default is chosen (all RFC1918 networks are allowed), but this can be easily
|
||||
adjusted.
|
||||
|
||||
|
||||
@@ -5,5 +5,5 @@ tag: auditd
|
||||
---
|
||||
|
||||
Audit rules are added in a task so that any events associated with altering
|
||||
system time are logged. The new audit rule will be loaded immediately with
|
||||
system time are logged. The new audit rule will be loaded immediately with
|
||||
``augenrules --load``.
|
||||
|
||||
@@ -5,7 +5,7 @@ tag: console
|
||||
---
|
||||
|
||||
In Ubuntu 14.04, the Ansible tasks disable the control-alt-delete keyboard
|
||||
sequence via a configuration in ``/etc/init/control-alt-delete.conf``. A
|
||||
sequence via a configuration in ``/etc/init/control-alt-delete.conf``. A
|
||||
reboot is recommended to apply the change.
|
||||
|
||||
Linux distributions that use systemd, such as Ubuntu 16.04 and CentOS 7,
|
||||
|
||||
@@ -7,7 +7,7 @@ tag: lsm
|
||||
The tasks in the security role will enable the Linux Security
|
||||
Module (LSM) that is appropriate for the Linux distribution in use.
|
||||
|
||||
For Ubuntu, the default LSM is AppArmor. Refer to Ubuntu's `AppArmor
|
||||
For Ubuntu, the default LSM is AppArmor. Refer to Ubuntu's `AppArmor
|
||||
documentation`_ for more details on how AppArmor works. The tasks will enable
|
||||
AppArmor and start it immediately on the system.
|
||||
|
||||
|
||||
@@ -5,5 +5,5 @@ tag: auth
|
||||
---
|
||||
|
||||
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
|
||||
successful login for a user immediately after login. An Ansible task ensures
|
||||
this setting is applied and restarts the ssh daemon if necessary.
|
||||
|
||||
@@ -5,6 +5,6 @@ tag: boot
|
||||
---
|
||||
|
||||
Altering partitions and how they are mounted is left up to the deployer
|
||||
to configure during the OS installation process. Mounting ``/tmp/``
|
||||
to configure during the OS installation process. Mounting ``/tmp/``
|
||||
with the ``noexec`` option is highly recommended to prevent scripts
|
||||
or binaries from being executed from ``/tmp``.
|
||||
|
||||
@@ -6,7 +6,7 @@ tag: packages
|
||||
|
||||
Ansible tasks will check the ``rpm -Va`` output (on CentOS and RHEL) or the
|
||||
output of ``debsums`` (on Ubuntu) to see if any files installed from packages
|
||||
have been altered. The tasks will print a list of files that have changed
|
||||
have been altered. The tasks will print a list of files that have changed
|
||||
since their package was installed.
|
||||
|
||||
Deployers should be most concerned with any checksum failures for binaries and
|
||||
|
||||
@@ -5,7 +5,7 @@ tag: graphical
|
||||
---
|
||||
|
||||
The session inactivity timeout is set to 900 seconds to meet the STIG
|
||||
requirements. After this time, users must re-enter their credentials to regain
|
||||
requirements. After this time, users must re-enter their credentials to regain
|
||||
access to the system.
|
||||
|
||||
Deployers can adjust this timeout by setting an Ansible variable:
|
||||
|
||||
@@ -6,7 +6,7 @@ tag: auth
|
||||
|
||||
The STIG requires that accounts with excessive failed login attempts are
|
||||
locked. It sets a limit of three failed attempts in a 15 minute interval and
|
||||
these restrictions are applied to all users (including root). Accounts cannot
|
||||
these restrictions are applied to all users (including root). Accounts cannot
|
||||
be automatically unlocked for seven days.
|
||||
|
||||
This change might cause disruptions in production environments without proper
|
||||
|
||||
@@ -7,4 +7,4 @@ tag: auth
|
||||
Deployers are strongly urged to review the list of user accounts on each server
|
||||
regularly. Evaluation of user accounts must be done on a case-by-case basis and
|
||||
the tasks in the security role are unable to determine which user accounts are
|
||||
valid. Deployers must complete this work manually.
|
||||
valid. Deployers must complete this work manually.
|
||||
|
||||
@@ -5,7 +5,7 @@ tag: packages
|
||||
---
|
||||
|
||||
On Ubuntu systems, the tasks comment out the ``no-debsig`` configuration line
|
||||
in ``/etc/dpkg/dpkg.cfg``. This causes ``dpkg`` to verify GPG signatures for
|
||||
in ``/etc/dpkg/dpkg.cfg``. This causes ``dpkg`` to verify GPG signatures for
|
||||
all packages that are installed locally.
|
||||
|
||||
On CentOS 7 systems, the tasks set the ``localpkg_gpgcheck`` option to ``1`` in
|
||||
|
||||
@@ -7,7 +7,7 @@ tag: lsm
|
||||
The tasks in the security role enable the appropriate Linux Security Module
|
||||
(LSM) for the operating system.
|
||||
|
||||
For Ubuntu systems, AppArmor is installed and enabled. This change takes
|
||||
For Ubuntu systems, AppArmor is installed and enabled. This change takes
|
||||
effect immediately.
|
||||
|
||||
For CentOS or Red Hat Enterprise Linux systems, SELinux is enabled (in
|
||||
|
||||
@@ -5,7 +5,7 @@ tag: packages
|
||||
---
|
||||
|
||||
The STIG requires that the current release of the operating system is still
|
||||
supported and is actively receiving security updates. Deployers are urged to
|
||||
supported and is actively receiving security updates. Deployers are urged to
|
||||
stay current with the latest releases from Ubuntu, CentOS and Red Hat.
|
||||
|
||||
The following links provide more details on end of life (EOL) dates for the
|
||||
|
||||
@@ -4,7 +4,7 @@ status: opt-in
|
||||
tag: auditd
|
||||
---
|
||||
|
||||
The ``audispd`` service transmits audit logs to other servers. Deployers
|
||||
The ``audispd`` service transmits audit logs to other servers. Deployers
|
||||
should specify the address of another server that can receive audit logs by
|
||||
setting the following Ansible variable:
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ tag: auditd
|
||||
|
||||
The ``audispd`` daemon transmits audit logs without encryption by default. The
|
||||
STIG requires that these logs are encrypted while they are transferred across
|
||||
the network. The encryption is controlled by the ``enable_krb5`` option in
|
||||
the network. The encryption is controlled by the ``enable_krb5`` option in
|
||||
``/etc/audisp/audisp-remote.conf``.
|
||||
|
||||
Deployers can opt-in for encrypted audit log transmission by setting the
|
||||
|
||||
@@ -6,7 +6,7 @@ tag: misc
|
||||
|
||||
The STIG requires that a virus scanner is installed and running, but the value
|
||||
of a virus scanner within an OpenStack control plane or on a hypervisor is
|
||||
negligible in many cases. In addition, the disk I/O impact of a virus scanner
|
||||
negligible in many cases. In addition, the disk I/O impact of a virus scanner
|
||||
can impact a production environment negatively.
|
||||
|
||||
The security role has tasks to deploy ClamAV with automatic updates, but the
|
||||
|
||||
@@ -5,7 +5,7 @@ tag: sshd
|
||||
---
|
||||
|
||||
The tasks in the security role deploy a standard notice and consent banner into
|
||||
``/etc/motd`` on each server. Ubuntu, CentOS and Red Hat Enterprise Linux
|
||||
``/etc/motd`` on each server. Ubuntu, CentOS and Red Hat Enterprise Linux
|
||||
display this banner after each successful login via ssh or the console.
|
||||
|
||||
Deployers can choose a different destination for the banner by setting the
|
||||
|
||||
@@ -8,7 +8,7 @@ Deployers are strongly urged to utilize ``sssd`` for systems that authenticate
|
||||
against LDAP or Active Directory (AD) servers.
|
||||
|
||||
To meet this control, deployers must ensure that ``ldap_tls_cacert`` or
|
||||
``ldap_tls_cacertdir`` are set in the ``/etc/sssd/sssd.conf`` file. The
|
||||
``ldap_tls_cacertdir`` are set in the ``/etc/sssd/sssd.conf`` file. The
|
||||
``ldap_tls_cacert`` directive specifies a single certificate while
|
||||
``ldap_tls_cacertdir`` specifies a directory where ``sssd`` can find CA
|
||||
certificates.
|
||||
|
||||
@@ -8,7 +8,7 @@ Deployers are strongly urged to utilize ``sssd`` for systems that authenticate
|
||||
against LDAP or Active Directory (AD) servers.
|
||||
|
||||
To meet this control, deployers must ensure that ``ldap_tls_cacert`` or
|
||||
``ldap_tls_cacertdir`` are set in the ``/etc/sssd/sssd.conf`` file. The
|
||||
``ldap_tls_cacertdir`` are set in the ``/etc/sssd/sssd.conf`` file. The
|
||||
``ldap_tls_cacert`` directive specifies a single certificate while
|
||||
``ldap_tls_cacertdir`` specifies a directory where ``sssd`` can find CA
|
||||
certificates.
|
||||
|
||||
@@ -6,7 +6,7 @@ tag: misc
|
||||
|
||||
The STIG requires that a firewall is configured on each server. This might be
|
||||
disruptive to some environments since the default firewall policy for
|
||||
``firewalld`` is very restrictive. Therefore, the tasks in the security role
|
||||
``firewalld`` is very restrictive. Therefore, the tasks in the security role
|
||||
do not install or enable the ``firewalld`` daemon by default.
|
||||
|
||||
Deployers can opt in for this change by setting the following Ansible variable:
|
||||
@@ -18,6 +18,6 @@ Deployers can opt in for this change by setting the following Ansible variable:
|
||||
.. warning::
|
||||
|
||||
Deployers must pre-configure ``firewalld`` or copy over a working XML file
|
||||
in ``/etc/firewalld/zones/`` from another server. The default firewalld
|
||||
in ``/etc/firewalld/zones/`` from another server. The default firewalld
|
||||
restrictions on Ubuntu, CentOS and Red Hat Enterprise Linux are highly
|
||||
restrictive.
|
||||
|
||||
@@ -16,6 +16,6 @@ Deployers can opt out of this change by setting the following Ansible variable:
|
||||
.. warning::
|
||||
|
||||
Ensure that a regular user account exists with a pathway to root access
|
||||
(preferably via ``sudo``) before applying the security role. This
|
||||
(preferably via ``sudo``) before applying the security role. This
|
||||
configuration change disallows any direct logins with the ``root``
|
||||
user.
|
||||
|
||||
@@ -8,14 +8,14 @@ Why should this role be applied to a system?
|
||||
--------------------------------------------
|
||||
|
||||
First and foremost, this role should be applied to production systems in
|
||||
environments where security is a priority. If an OpenStack environment is
|
||||
environments where security is a priority. If an OpenStack environment is
|
||||
exposed to the internet or to large internal corporate networks, applying
|
||||
this role will reduce the risk of compromised OpenStack infrastructure. The
|
||||
changes made by the role should also reduce the impact of potential
|
||||
compromises as well.
|
||||
|
||||
Some deployers may be subject to industry compliance programs, such as
|
||||
PCI-DSS, ISO 27001/27002, or NIST 800-53. Many of these programs require
|
||||
PCI-DSS, ISO 27001/27002, or NIST 800-53. Many of these programs require
|
||||
hardening standards to be applied to critical systems, such as OpenStack
|
||||
infrastructure components.
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ exists as `YAML frontmatter <https://jekyllrb.com/docs/frontmatter/>`_ for each
|
||||
STIG configuration. The frontmatter is followed by the text of the deployer
|
||||
note itself.
|
||||
|
||||
All of the notes are found within ``doc/metadata/rhel6``. Here is an example
|
||||
All of the notes are found within ``doc/metadata/rhel6``. Here is an example
|
||||
of V-38497:
|
||||
|
||||
.. literalinclude:: ../metadata/rhel6/V-38497.rst
|
||||
@@ -49,7 +49,7 @@ must include:
|
||||
* ``tag``: The Ansible tag associated with the task(s) that make changes based
|
||||
on the STIG requirement, such as ``auditd``, ``kernel``, or ``lsm``.
|
||||
|
||||
The next block is the deployer note. The note should be brief, but it must
|
||||
The next block is the deployer note. The note should be brief, but it must
|
||||
answer a few critical questions:
|
||||
|
||||
* What does the change do to a system?
|
||||
|
||||
@@ -29,7 +29,7 @@ Initial configuration
|
||||
---------------------
|
||||
|
||||
Some of the security configurations need initial configuration or they may
|
||||
require you to opt-in for a change to be applied. Start by reviewing the list
|
||||
require you to opt-in for a change to be applied. Start by reviewing the list
|
||||
of STIG controls that
|
||||
:ref:`require initial configuration <implementation-status-configuration-required>`
|
||||
or :ref:`require opt-in <implementation-status-opt-in>`.
|
||||
|
||||
@@ -6,7 +6,7 @@ Abstract
|
||||
~~~~~~~~
|
||||
|
||||
The openstack-ansible-security role provides security hardening for
|
||||
`OpenStack`_ environments deployed with `openstack-ansible`_. The role has
|
||||
`OpenStack`_ environments deployed with `openstack-ansible`_. The role has
|
||||
multiple goals:
|
||||
|
||||
* Provide additional security in a highly configurable, integrated way without
|
||||
@@ -64,7 +64,7 @@ Mitaka
|
||||
~~~~~~
|
||||
|
||||
The Mitaka release of the openstack-ansible-security role was first released
|
||||
with the 13.0.0 tag on April 1st, 2016. Refer to the `Mitaka release notes
|
||||
with the 13.0.0 tag on April 1st, 2016. Refer to the `Mitaka release notes
|
||||
<http://docs.openstack.org/releasenotes/openstack-ansible-security/mitaka.html>`_
|
||||
for more details on the improvements and fixes.
|
||||
|
||||
@@ -79,7 +79,7 @@ Liberty
|
||||
|
||||
Refer to the `Liberty release notes
|
||||
<http://docs.openstack.org/releasenotes/openstack-ansible-security/liberty.html>`_
|
||||
for more details on the improvements and fixes. The Libery release will reach
|
||||
for more details on the improvements and fixes. The Liberty release will reach
|
||||
EOL on November 17th, 2016.
|
||||
|
||||
Ubuntu 14.04 is supported in the Liberty release.
|
||||
|
||||
@@ -93,7 +93,7 @@ Rules for auditd
|
||||
|
||||
Handling audit emergencies
|
||||
There are several configurations for auditd which are critical for deployers
|
||||
to review in detail. The options beneath the ``## Auditd configuration``
|
||||
to review in detail. The options beneath the ``## Auditd configuration``
|
||||
comment will change how auditd handles log files and what it should do in
|
||||
case of emergencies.
|
||||
|
||||
@@ -101,7 +101,7 @@ Handling audit emergencies
|
||||
|
||||
Some of these configuration options can cause serious issues on
|
||||
production systems, ranging from a reduction in security to servers going
|
||||
offline unexpectedly. There is extensive documentation in the developer notes
|
||||
offline unexpectedly. There is extensive documentation in the developer notes
|
||||
for each STIG requirement.
|
||||
|
||||
Authentication
|
||||
@@ -109,16 +109,16 @@ Authentication
|
||||
|
||||
The STIG sets requirements for various authentication-related security
|
||||
controls, including password complexity, password aging/locking, and
|
||||
simultaneous logins. All of these can cause issues on production systems.
|
||||
simultaneous logins. All of these can cause issues on production systems.
|
||||
|
||||
Handling multiple failed login attempts
|
||||
The fail2ban service is installed to meet some requirements around failed
|
||||
login attempts. The STIG requires ``pam_faillock``, but that module isn't
|
||||
login attempts. The STIG requires ``pam_faillock``, but that module isn't
|
||||
available in the Linux distributions supported by this role.
|
||||
|
||||
To opt-in for the fail2ban service to be installed, set
|
||||
``security_install_fail2ban`` to ``yes`` and set an appropriate time for bans
|
||||
with ``security_fail2ban_bantime``. See the notes for
|
||||
with ``security_fail2ban_bantime``. See the notes for
|
||||
:ref:`V-38501 <stig-V-38501>` for more details.
|
||||
|
||||
Note that fail2ban will not take action on failed logins via physical
|
||||
@@ -143,10 +143,10 @@ variables matching the pattern ``security_disable_module_MODULENAME``. Refer to
|
||||
A setting of ``yes`` means that the module will be disabled on the next boot
|
||||
and a setting of ``no`` means that the state of the module will not be changed.
|
||||
|
||||
All of the defaults are set in accordance with the STIG's requitements with
|
||||
the exception of the ``usb_storage`` kernel module. This module is used
|
||||
All of the defaults are set in accordance with the STIG's requirements with
|
||||
the exception of the ``usb_storage`` kernel module. This module is used
|
||||
frequently with external hard drives, USB sticks, and with some IPMI
|
||||
implementations. Deployers who wish to follow the STIG guidelines will need
|
||||
implementations. Deployers who wish to follow the STIG guidelines will need
|
||||
to set ``usb_storage`` to ``yes`` so that the ``usb_storage`` module is
|
||||
disabled on the next boot.
|
||||
|
||||
@@ -164,7 +164,7 @@ Mail
|
||||
----
|
||||
|
||||
Deployers are strongly urged to configure an address to receive the ``root``
|
||||
user's email on various hosts. This is done with the
|
||||
user's email on various hosts. This is done with the
|
||||
``security_root_forward_email`` variable.
|
||||
|
||||
The STIG requires that a valid user receives the email in case of errors or a
|
||||
@@ -174,7 +174,7 @@ Removing and disabling services
|
||||
-------------------------------
|
||||
|
||||
The STIG has recommendations for which services shouldn't be running and which
|
||||
packages shouldn't be installed. These removals can be configured to meet
|
||||
packages shouldn't be installed. These removals can be configured to meet
|
||||
the requirements of the deployer.
|
||||
|
||||
Disabling services
|
||||
@@ -186,8 +186,8 @@ Disabling services
|
||||
A setting of ``yes`` for a service will cause the service to be disabled in
|
||||
accordance to the STIG's requirements.
|
||||
|
||||
A setting of ``no`` causes the role to ignore the service entirely. If the
|
||||
service is running, it will remain running. If the service is stopped,
|
||||
A setting of ``no`` causes the role to ignore the service entirely. If the
|
||||
service is running, it will remain running. If the service is stopped,
|
||||
it will remain stopped.
|
||||
|
||||
Removing services
|
||||
@@ -198,24 +198,24 @@ Removing services
|
||||
``defaults/main.yml`` for more details.
|
||||
|
||||
A setting of ``yes`` for a service will cause the package that contains the
|
||||
service to be removed from the system. If the service happens to be running
|
||||
service to be removed from the system. If the service happens to be running
|
||||
at the time, it will be stopped by ``apt``.
|
||||
|
||||
A setting of ``no`` for a service will cause the role to ignore the package
|
||||
that contains the service. If the package is installed, it will be left
|
||||
that contains the service. If the package is installed, it will be left
|
||||
installed.
|
||||
|
||||
SSH server
|
||||
----------
|
||||
|
||||
The STIG has some requirements for ssh server configuration and these
|
||||
requirements are applied by default by the role. To opt-out or change these
|
||||
requirements are applied by default by the role. To opt-out or change these
|
||||
requirements, see the section under the ``## SSH configuration`` comment in
|
||||
``defaults/main.yml``.
|
||||
|
||||
Deviation for PermitRootLogin
|
||||
There is one deviation from the STIG for the ``PermitRootLogin``
|
||||
configuration option. The STIG requires that direct root logins are
|
||||
configuration option. The STIG requires that direct root logins are
|
||||
disabled, and this is the recommended setting for secure production
|
||||
environments.
|
||||
|
||||
@@ -226,12 +226,12 @@ sysctl settings
|
||||
---------------
|
||||
|
||||
The STIG requires that TCP SYN cookies enabled by default to protect against
|
||||
certain types of attacks, like SYN floods. This can cause issues in some
|
||||
environments with busy load balancers. Deployers should review the notes for
|
||||
certain types of attacks, like SYN floods. This can cause issues in some
|
||||
environments with busy load balancers. Deployers should review the notes for
|
||||
:ref:`V-38539 <stig-V-38539>` for more details.
|
||||
|
||||
Also, the STIG requires IPv6 support to be fully disabled, and this could cause
|
||||
issues for production systems. The role will not disable IPv6 by default, but
|
||||
issues for production systems. The role will not disable IPv6 by default, but
|
||||
deployers can adjust this by changing ``security_disable_ipv6`` to ``yes``.
|
||||
|
||||
Core dumps are also disabled by default in the openstack-ansible-security role.
|
||||
@@ -260,7 +260,7 @@ umask adjustments
|
||||
-----------------
|
||||
|
||||
Certain umask adjustments are required by the STIG, but these can cause
|
||||
problems with production systems. The requirements are commented out within
|
||||
problems with production systems. The requirements are commented out within
|
||||
``defaults/main.yml`` and can be applied by uncommenting the variables that
|
||||
start with ``security_umask_*``. There is extensive documentation available
|
||||
start with ``security_umask_*``. There is extensive documentation available
|
||||
within the developer notes for each STIG requirement.
|
||||
|
||||
Reference in New Issue
Block a user