390ccd8473
Implements: blueprint security-hardening Change-Id: I72fd97ff1cdee96d87ad195828e723aad33934d1
214 lines
8.3 KiB
ReStructuredText
214 lines
8.3 KiB
ReStructuredText
.. include:: <xhtml1-lat1.txt>
|
|
`Home <index.html>`__ |raquo| Security hardening for openstack-ansible
|
|
|
|
Configuration
|
|
=============
|
|
|
|
The openstack-ansible-security role is highly configurable and it ships with
|
|
reasonable defaults that provide a balance of enhanced security with limited
|
|
interruptions to production environments. However, some deployers may need to
|
|
adjust the default configurations to fit the particular needs of their
|
|
OpenStack environment.
|
|
|
|
All of the default configurations are found within ``defaults/main.yml`` in the
|
|
role itself.
|
|
|
|
*NOTE: Deployers are strongly urged to test this role and any configuration
|
|
changes in a non-production, test environment.*
|
|
|
|
.. contents::
|
|
:local:
|
|
|
|
AIDE
|
|
----
|
|
|
|
The STIG sets requirements for integrity monitoring of the system and the role
|
|
will install AIDE to meet these requirements. However, Ubuntu's default
|
|
configuration will cause AIDE to search through container filesystems and this
|
|
will cause a serious performance hit to disk I/O for very long periods.
|
|
|
|
By default, this role exludes some directories that cause AIDE to spend a very
|
|
long time indexing the disk. Additional directories can be added to the
|
|
exclusion list, but the directories currenty listed **should not be removed**.
|
|
Deployers can add directories to ``aide_exlude_dirs``.
|
|
|
|
Audit daemon
|
|
------------
|
|
|
|
The `audit daemon`_ is required by the STIG and it provides useful logging of
|
|
critical events on a Linux server.
|
|
|
|
.. _audit daemon: http://people.redhat.com/sgrubb/audit/
|
|
|
|
Rules for auditd
|
|
^^^^^^^^^^^^^^^^
|
|
|
|
The openstack-ansible-security creates a file full of audit rules for hosts
|
|
and these rules can be configured via the ``auditd_rules`` dictionary in
|
|
``defaults/main.yml``.
|
|
|
|
Each key within the dictionary refers to a block of rules that perform a
|
|
certain function. Setting a value of ``yes`` for these keys will ensure that
|
|
the rules are present in the final auditd configuration file. Setting a value
|
|
of ``no`` will ensure that they are omitted.
|
|
|
|
To review the full list of rules and variables, refer to
|
|
``templates/osas-auditd.j2``.
|
|
|
|
Other auditd configuration
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
There are several configurations for auditd which are critical for deployers
|
|
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.
|
|
|
|
**NOTE:** 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
|
|
for each STIG requirement.
|
|
|
|
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 and
|
|
some cannot be met on Ubuntu systems due to the lack of certain packages.
|
|
|
|
Deployers are urged to review each item under the ``## Authentication`` comment
|
|
in ``defaults/main.yml`` as well as the developer notes for each requirement.
|
|
The notes explain the potential pitfalls from each configuration item and
|
|
they provide alternatives when a configuration isn't directly available.
|
|
|
|
fail2ban
|
|
^^^^^^^^
|
|
|
|
The fail2ban service is installed to meet some requirements around failed login
|
|
attempts. The STIG requires ``pam_faillock``, but that module isn't available
|
|
in Ubuntu 14.04.
|
|
|
|
To opt-in for the fail2ban service to be installed, set ``install_fail2ban`` to
|
|
``yes`` and set an appropriate time for bans with ``fail2ban_bantime``. See
|
|
the notes for V-38501 for more details.
|
|
|
|
Kernel
|
|
------
|
|
|
|
Kernel modules
|
|
^^^^^^^^^^^^^^
|
|
|
|
Certain kernel modules are restricted by the STIG and those are reflected in
|
|
the ``disable_module`` dictionary within ``defaults/main.yml``. 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
|
|
frequently with external hard drives, USB sticks, and with some IPMI
|
|
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.
|
|
|
|
sysctl settings
|
|
^^^^^^^^^^^^^^^
|
|
|
|
The STIG requires that TCP SYNcookes are 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
|
|
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 deployers can adjust this by changing ``disable_ipv6`` to ``yes``.
|
|
|
|
Core dumps are also disabled by default in the openstack-ansible-security role.
|
|
|
|
Mail
|
|
----
|
|
|
|
Deployers are strongly urged to configure an address to receive the ``root``
|
|
user's email on various hosts. This is done with the ``root_forward_email``
|
|
variable.
|
|
|
|
The STIG requires that a valid user receives the email in case of errors or a
|
|
security issue.
|
|
|
|
Services and packages
|
|
---------------------
|
|
|
|
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
|
|
the requirements of the deployer.
|
|
|
|
Disabling services
|
|
^^^^^^^^^^^^^^^^^^
|
|
|
|
By default, the role will disable any services that are recommended to be
|
|
disabled by the STIG. The list of these services can be found within the
|
|
``disable_services`` dictionary in ``defaults/main.yml``.
|
|
|
|
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,
|
|
it will remain stopped.
|
|
|
|
Removing services
|
|
^^^^^^^^^^^^^^^^^
|
|
|
|
The STIG requires that some packages are completely removed from the server.
|
|
By default, the role will remove the packages in accordance with the STIG's
|
|
requirements. These services are found within the ``remove_services``
|
|
dictionary within ``defaults/main.yml``.
|
|
|
|
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
|
|
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
|
|
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, see the section under the ``## SSH configuration`` comment in
|
|
``defaults/main.yml``.
|
|
|
|
Special note about PermitRootLogin
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
**NOTE:** There is one deviation from the STIG for the ``PermitRootLogin``
|
|
configuration option. The STIG requires that direct root logins are disabled,
|
|
and this is the recommended setting for secure production environments.
|
|
However, this can cause problems in some existing environments and the default
|
|
for the role is to set it to ``yes`` (direct root logins allowed).
|
|
|
|
Time synchronization with chrony
|
|
--------------------------------
|
|
|
|
Reliable time synchronization is a requirement in the STIG and the ``chrony``
|
|
package will be installed to handle NTP for systems secured with the
|
|
openstack-ansible-security role.
|
|
|
|
The default settings will work for most environments, but some deployers may
|
|
prefer to use NTP servers which are geographically closer to their servers.
|
|
Also, the default configuration allows `RFC1918`_ addresses to reach the NTP
|
|
server running on each host. That could be reduced to ``127.0.0.1/32`` for
|
|
greater security.
|
|
|
|
.. _RFC1918: https://en.wikipedia.org/wiki/Private_network#Private_IPv4_address_spaces
|
|
|
|
umask adjustments
|
|
-----------------
|
|
|
|
Certain umask adjustments are required by the STIG, but these can cause
|
|
problems with production systems. The requirements are commented out within
|
|
``defaults/main.yml`` and can be applied by uncommenting the variables that
|
|
start with ``umask_*``. There is extensive documentation available within
|
|
the developer notes for each STIG requirement.
|