ansible-lockdown.rhel9_cis

Descripción general Versiones Perspectivas

RHEL 9 CIS

Configurar una máquina RHEL 9 para ser compatible con CIS

Basado en CIS RedHat Enterprise Linux 9 Benchmark v1.0.0 - 30-11-2022

Etiqueta de lanzamiento Fecha de lanzamiento

Commits de desarrollo

Problemas Abiertos Problemas Cerrados Solicitudes de extracción

Licencia

¿Buscas soporte?

Lockdown Enterprise

Soporte de Ansible

Comunidad

Únete a nuestro Servidor de Discord para hacer preguntas, discutir características o simplemente chatear con otros usuarios de Ansible-Lockdown.

Contribuyendo

Se aceptan problemas y solicitudes de extracción, asegúrate de que todos los commits estén firmados y con firma GPG. Consulta la Guía de Contribución

Precauciones

Este rol realizará cambios en el sistema que pueden tener consecuencias no deseadas. No es una herramienta de auditoría, sino una herramienta de remediación que se debe usar después de realizar una auditoría.

¡El Modo de Comprobación no es compatible! El rol se completará en modo de comprobación sin errores, pero no es compatible y debe usarse con precaución. Se debe usar el rol RHEL8-CIS-Audit o un escáner de cumplimiento para verificar el cumplimiento en lugar del modo de comprobación.

Este rol fue desarrollado en una instalación limpia del sistema operativo. Si lo estás aplicando a un sistema existente, revisa este rol para ver los cambios específicos del sitio que se necesiten.

Para usar la versión de lanzamiento, apunta a la rama main y la versión relevante para el estándar CIS con el que deseas trabajar.

Igualando un nivel de seguridad para CIS

Es posible ejecutar solo controles de nivel 1 o nivel 2 para CIS. Esto se gestiona mediante etiquetas:

nivel1-servidor
nivel1-estación de trabajo
nivel2-servidor
nivel2-estación de trabajo

El control encontrado en el defaults también debe reflejar esto, ya que este control es la prueba que se realiza si estás utilizando el componente de auditoría.

Procedente de una versión anterior

Las versiones de CIS siempre contienen cambios; se recomienda revisar las nuevas referencias y variables disponibles. Esto ha cambiado significativamente desde el lanzamiento inicial de ansible-lockdown. Ahora es compatible con python3 si se encuentra como el intérprete predeterminado. Esto viene con requisitos previos que configuran el sistema en consecuencia.

Más detalles se pueden ver en el Registro de cambios.

Auditoría (nuevo)

Esto se puede activar o desactivar dentro del archivo defaults/main.yml con las variables setup_audit y run_audit. El valor es falso de forma predeterminada. Por favor, consulta la wiki para más detalles. El archivo de valores predeterminados también llena las verificaciones de goss para verificar solo los controles que han sido habilitados en el rol de ansible.

Esta es una verificación mucho más rápida y ligera (donde sea posible) de cumplimiento de configuración y configuraciones en vivo/actuando.

Se ha desarrollado una nueva forma de auditoría utilizando un pequeño binario (12 MB) de Go llamado goss junto con las configuraciones relevantes para comprobar sin necesidad de infraestructura u otras herramientas. Esta auditoría no solo verificará que la configuración tenga el ajuste correcto, sino que también buscará si está funcionando con esa configuración y tratará de eliminar falsos positivos en el proceso.

Consulta RHEL9-CIS-Audit.

Documentación

Requisitos

RHEL 9
Almalinux 9
Rocky 9
OracleLinux 9

Acceso para descargar o agregar el binario de goss y contenido al sistema si se usa auditoría (hay otras opciones disponibles sobre cómo obtener el contenido en el sistema).

CentOS Stream - aunque esto generalmente funcionará, no está soportado y requiere configurar la siguiente variable

os_check: false

General:

Conocimientos básicos de Ansible, a continuación, algunos enlaces a la documentación de Ansible para ayudar a comenzar si no estás familiarizado con Ansible:
Tener Ansible y/o Tower funcionando, configurado y en ejecución. Esto incluye todas las configuraciones básicas de Ansible/Tower, los paquetes necesarios instalados y la infraestructura configurada.
Lee las tareas en este rol para comprender qué hace cada control. Algunas de las tareas pueden ser disruptivas y tener consecuencias no deseadas en un sistema de producción activo. También familiarízate con las variables en el archivo defaults/main.yml.

Dependencias Técnicas:

Python3
Ansible 2.10+
python-def (debería estar incluido en RHEL 9)
libselinux-python
Paquetes pip
- jmespath
Colecciones encontradas en collections/requirements.yml

pre-commit está disponible si está instalado en tu host para pruebas de solicitudes de extracción.

Variables del Rol

Este rol está diseñado para que el usuario final no tenga que editar las tareas. Toda la personalización debe hacerse sobrescribiendo las variables requeridas que se encuentran en el archivo defaults/main.yml, por ejemplo, usando inventario, group_vars, extra_vars.

Etiquetas

Hay muchas etiquetas disponibles para mayor precisión en el control. Cada control tiene su propio conjunto de etiquetas que indican qué nivel, si está puntuado/no puntuado, a qué elemento del sistema operativo se relaciona, si es un parche o auditoría, y el número de regla.

A continuación, un ejemplo de la sección de etiquetas de un control dentro de este rol. Usando este ejemplo, si configuras tu ejecución para omitir todos los controles con la etiqueta servicios, esta tarea será omitida. También puede suceder lo contrario, donde solo ejecutes controles etiquetados con servicios.

      tags:
      - nivel1-servidor
      - nivel1-estación de trabajo
      - puntuado
      - avahi
      - servicios
      - parche
      - regla_2.2.4

Contribución de la Comunidad

Te animamos (a la comunidad) a contribuir a este rol. Por favor, lee las reglas a continuación.

Tu trabajo se realiza en tu propia rama individual. Asegúrate de firmar y firmar todos los commits que pretendas fusionar.
Todas las Solicitudes de Extracción de la comunidad se fusionan en la rama de desarrollo.
Las Solicitudes de Extracción en desarrollo confirmarán que tus cambios tienen una firma GPG, están firmados y tienen una prueba funcional antes de ser aprobadas.
Una vez que tus cambios se fusionen y se complete una revisión más detallada, un miembro autorizado fusionará tus cambios en la rama principal para una nueva versión.

Problemas Conocidos

CIS 1.2.4 - repo_gpgcheck no se lleva a cabo para hosts de RedHat ya que los repos predeterminados no tienen esta función. Esto también afecta a EPEL (no cubierto por ninguna variable).
- Rocky y Alma no se ven afectados.
Variable utilizada para anular.
rhel9cis_rhel_default_repo: true # debe configurarse en falso si se usa un repositorio que sí tiene esta capacidad.

Pruebas de Pilas

utiliza:

ansible-core 2.12
colecciones de ansible - importa la última versión según el archivo de requisitos.
Ejecuta la auditoría utilizando la rama de desarrollo.
Ejecuta la configuración de pre-commit en la solicitud de extracción para garantizar que todo esté en su lugar como se espera.
Esta es una prueba automatizada que ocurre en solicitudes de extracción en el desarrollo.