RHEL 8 CIS

Configurar una máquina RHEL/Rocky/AlmaLinux 8 para cumplir con CIS

Basado en CIS RedHat Enterprise Linux 8 Benchmark v3.0.0 - 10-11-2023

¿Buscando soporte?

Lockdown Enterprise

Soporte de Ansible

Comunidad

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

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 debe usarse después de realizar una auditoría.

• Probar es lo más importante que puedes hacer.

• ¡El modo de verificación no está soportado! El rol completará la ejecución en modo de verificación sin errores, pero no está soportado y debe usarse con precaución. Se debe utilizar el rol RHEL8-CIS-Audit o un escáner de cumplimiento para verificar el cumplimiento en lugar del modo de verificación.

• Este rol fue desarrollado en una instalación limpia del sistema operativo. Si lo estás implementando en un sistema existente, revisa este rol por cualquier cambio específico del sitio que sea necesario.

• Para usar la versión de lanzamiento, por favor dirígete a la rama principal y a la etiqueta relevante para el estándar CIS con el que deseas trabajar.

• Si cambias entre versiones principales, por ejemplo, de v2.0.0 a v3.0.0, hay cambios significativos en los estándares y controles, se sugiere comenzar como un nuevo estándar en lugar de actualizar.

• Las referencias de contenedor vars/is_container.yml son un ejemplo que debes actualizar según tus necesidades.

• ¿Mencionamos la importancia de las pruebas?

Coincidencia con un nivel de seguridad para CIS

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

• level1_server
• level1_workstation
• level2_server
• level2_workstation

El control encontrado en defaults main también debe reflejar esto, ya que este control afecta las pruebas que se realizan si estás usando el componente de auditoría.

Viniendo de una versión anterior

La versión de CIS siempre contiene cambios; se recomienda revisar las nuevas referencias y las variables disponibles. Estos han 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 Changelog

Auditoría (nuevo)

Esto se puede activar o desactivar dentro del archivo defaults/main.yml con la variable rhel8cis_run_audit. El valor es falso de forma predeterminada; consulta la wiki para más detalles. El archivo de configuración predeterminado también llena las comprobaciones de goss para revisar solo los controles que se han activado en el rol de ansible.

Esta es una verificación mucho más rápida y ligera (donde sea posible) de compatibilidad de configuración y configuraciones activas.

Se ha desarrollado una nueva forma de auditoría utilizando un pequeño binario (12MB) en go llamado goss junto con las configuraciones relevantes a verificar. 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 tiene como objetivo capturar si se está ejecutando con esa configuración, tratando de eliminar falsos positivos en el proceso.

Consulta RHEL8-CIS-Audit.

Ejemplo de Resumen de Auditoría

Este se basa en una imagen de vagrant con selecciones habilitadas. Por ejemplo, sin GUI o firewall. Nota: Se realizan más pruebas durante la auditoría mientras verificamos la configuración y el estado en ejecución.

ok: [default] => {
    "msg": [
        "Los resultados de la previa a la remediación son: ['Duración total: 5.454s', 'Contador: 338, Fallidos: 47, Saltados: 5'].",
        "Los resultados posteriores a la remediación son: ['Duración total: 5.007s', 'Contador: 338, Fallidos: 46, Saltados: 5'].",
        "El desglose completo se puede encontrar en /var/tmp",
        ""
    ]
}

RESUMEN DE JUEGO *******************************************************************************************************************************************
default                    : ok=270  changed=23   unreachable=0    failed=0    skipped=140  rescued=0    ignored=0

Documentación

• Leer la documentación
• Introducción
• Personalización de roles
• Configuración por host
• Sacar el máximo provecho del rol

Requisitos

General:

• Conocimientos básicos de Ansible, a continuación hay algunos enlaces a la documentación de Ansible para ayudarte a comenzar si no estás familiarizado con Ansible

  • Página principal de documentación de Ansible
  • Introducción a Ansible
  • Guía del Usuario de Tower
  • Información de la Comunidad de Ansible

• Tener instalado, configurado y en funcionamiento Ansible y/o Tower. Esto incluye todas las configuraciones base de Ansible/Tower, los paquetes necesarios instalados y la infraestructura configurada.

• Por favor, revisa las tareas en este rol para entender qué hace cada control. Algunas de las tareas pueden ser disruptivas y tener consecuencias no deseadas en un sistema de producción en funcionamiento. Familiarízate también con las variables en el archivo defaults/main.yml.

Dependencias Técnicas:

RHEL/AlmaLinux/Rocky/Oracle 8 - Otras versiones no son compatibles.

• AlmaLinux/Rocky ha sido probado en 8.8 (habilitar criptografía (secciones 1.10 y 1.11) interrumpe las actualizaciones o instalaciones: 01 de julio de 2021).
• Acceso para descargar o agregar el binario goss y el contenido al sistema si se utiliza auditoría (hay otras opciones disponibles sobre cómo obtener el contenido en el sistema).
• Python 3.8
• Ansible 2.11+
• python-def (debería incluirse en RHEL 8).
• libselinux-python

Variables del Rol

Este rol está diseñado para que el usuario final no tenga que editar las tareas directamente. Toda la personalización debe hacerse a través del archivo defaults/main.yml o con variables adicionales dentro del proyecto, trabajo, flujo de trabajo, etc.

Etiquetas

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

A continuación se muestra un ejemplo de la sección de etiquetas de un control dentro de este rol. Usando este ejemplo, si estableces tu ejecución para omitir todos los controles con la etiqueta services, esta tarea se omitirá. Lo opuesto también puede ocurrir, donde solo ejecutas controles etiquetados con services.

      tags:
      - level1-server
      - level1-workstation
      - scored
      - avahi
      - services
      - patch
      - rule_2.2.4

Contribución de la Comunidad

Te animamos a que (la comunidad) contribuyas 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 con GPG todos los commits que desees fusionar.
• Todas las Solicitudes de Extracción de la comunidad son integradas en la rama de desarrollo.
• Las Solicitudes de Extracción a la rama de desarrollo confirmarán que tus commits tienen una firma GPG, están firmados y tienen una prueba funcional antes de ser aprobados.
• Una vez que tus cambios estén fusionados y se complete una revisión más detallada, un miembro autorizado fusionará tus cambios en la rama principal para un nuevo lanzamiento.

Problemas conocidos

cloud0init - debido a un error, esto dejará de funcionar si se agrega noexec a /var.
rhel8cis_rule_1_1_3_3

error 1839899

Los repositorios de AlmaLinux BaseOS, EPEL y muchos proveedores de nube no permiten repo_gpgcheck en la regla_1.2.3, esto causará problemas durante el playbook a menos que se encuentre una solución alternativa.

Pruebas de Pipeline

utiliza:

• ansible-core 2.12
• colecciones de ansible: obtiene la última versión según el archivo de requisitos
• ejecuta la auditoría usando la rama de desarrollo
• esta es una prueba automatizada que ocurre en las solicitudes de extracción a la rama de desarrollo

Pruebas locales

Molecule se puede utilizar para trabajar en este rol y probar en distintos escenarios.

ejemplos

molecule test -s default
molecule converge -s wsl -- --check
molecule verify -s localhost

la prueba local utiliza:

• ansible 2.13.3
• molecule 4.0.1
• molecule-docker 2.0.0
• molecule-podman 2.0.2
• molecule-vagrant 1.0.0
• molecule-azure 0.5.0

Extras añadidos

• pre-commit se puede probar y ejecutar desde el directorio

pre-commit run

Créditos y Agradecimientos

Un enorme agradecimiento a la comunidad fantástica y todos sus miembros.
Esto incluye también un gran agradecimiento y crédito a los autores y mantenedores originales.
Josh Springer, Daniel Shepherd, Bas Meijeri, James Cassell, Mike Renfro, DFed, George Nalen, Mark Bolwell.