ansible-lockdown.rhel7_cis

RHEL 7 CIS

Configurar una máquina RHEL/Centos 7 para cumplir con CIS

Basado en CIS RedHat Enterprise Linux 7 Benchmark v4.0.0 - 21-12-2023


Estrellas de Org Estrellas Forks seguidores Twitter URL

Insignia de Discord

Rama de Lanzamiento Etiqueta de Lanzamiento Fecha de Lanzamiento

Estado de la Pipeline Principal

Estado de la Pipeline de Desarrollo 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 charlar con otros usuarios de Ansible-Lockdown.


Precauciones

Este rol hará cambios en el sistema, lo que puede tener consecuencias no deseadas. No es una herramienta de auditoría, sino una herramienta de remediación que debe usarse después de haber realizado una auditoría.

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

Este rol fue desarrollado contra una instalación limpia del sistema operativo. Si lo estás implementando en un sistema existente, revisa este rol para ver si se necesitan cambios específicos del sitio.

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


Coincidencia de 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 defaults main también debe reflejar esto, ya que controla las pruebas que se llevan a cabo si estás utilizando el componente de auditoría.

Procedente de una versión anterior

Las versiones de CIS siempre contienen cambios. Se recomienda encarecidamente 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, lo que implica que se configuran ciertos requisitos previos en el sistema.

Más detalles pueden verse en el Changelog

Auditoría (nuevo)

Esto se puede activar o desactivar dentro del archivo defaults/main.yml con la variable rhel7cis_run_audit. El valor es falso por defecto; consulta la wiki para más detalles. El archivo por defecto también puebla las verificaciones de goss para comprobar solo los controles que se han habilitado en el rol de ansible.

Esta es una verificación más rápida y ligera, donde sea posible, para comprobar el cumplimiento de la configuración y las configuraciones activas.

Se ha desarrollado una nueva forma de auditoría utilizando un pequeño binario de go (12MB) llamado goss junto con las configuraciones relevantes para verificar, sin necesidad de infraestructura u otras herramientas. Esta auditoría no solo comprobará si la configuración tiene la configuración correcta, sino que también intentará capturar si se está ejecutando con esa configuración, eliminando así falsos positivos en el proceso.

Documentación

Requisitos

General:

  • Conocimiento básico de Ansible. A continuación, se presentan algunos enlaces a la documentación de Ansible para ayudarte a empezar si no estás familiarizado con Ansible:

  • Instalación y configuración de Ansible y/o Tower en funcionamiento. Esto incluye todas las configuraciones base de Ansible/Tower, paquetes necesarios instalados y configuración de infraestructura.

  • Lee las tareas en este rol para comprender lo que hace cada control. Algunas de las tareas son disruptivas y pueden tener consecuencias no deseadas en un sistema de producción activo. Familiarízate también con las variables en el archivo defaults/main.yml.

Dependencias Técnicas:

  • Configuración en ejecución de Ansible/Tower (este rol se prueba con la versión de Ansible 2.9.1 y versiones más nuevas).
  • Entorno de ejecución de Ansible con Python3.
  • python-def (debería estar incluido en RHEL/CentOS 7) - La primera tarea establece los requisitos previos (etiqueta de pre-requisitos) para python3 y python2 (donde sea necesario).
    • libselinux-python
    • python3-rpm (paquete utilizado por py3 para usar el paquete rpm).

Variables del Rol

Este rol está diseñado para que el usuario final no tenga que editar las tareas en sí. 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 mayor precisión en el control. Cada control tiene su propio conjunto de etiquetas que indican su nivel, si se califica o no, a qué elemento del sistema operativo se relaciona, si es un parche o auditoría, y el número de 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 configuras tu ejecución para omitir todos los controles con la etiqueta servicios, esta tarea será omitida. Lo opuesto también puede suceder, donde solo ejecutas controles etiquetados con servicios.

      tags:
      - nivel1-estación de trabajo
      - nivel1-servidor
      - automatizado
      - 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 pretendes fusionar con GPG.
  • Todas las Solicitudes de Extracción de la comunidad se integrarán en la rama de desarrollo.
  • Las Solicitudes de Extracción en desarrollo confirmarán que tus commits tienen una firma GPG, están firmados y han pasado una prueba funcional antes de ser aprobadas.
  • Una vez que tus cambios se hayan fusionado y se haya completado una revisión más detallada, un miembro autorizado fusionará tus cambios en la rama principal para una nueva versión.

Pruebas de Pipeline

Usa:

  • ansible-core 2.12
  • colecciones de ansible - trae la última versión basada en el archivo de requisitos.
  • Ejecuta la auditoría utilizando la rama de desarrollo.
  • Esta es una prueba automatizada que ocurre en solicitudes de extracción en desarrollo.

Pruebas Locales

  • Ansible

    • ansible-base 2.10.17 - python 3.8
    • ansible-core 2.13.4 - python 3.10
    • ansible-core 2.15.1 - python 3.11

Extras Añadidos

  • pre-commit se puede probar y ejecutar desde dentro del directorio.
pre-commit run

Créditos y Agradecimientos

Un agradecimiento enorme a la fantástica comunidad y todos sus miembros.

Esto incluye un gran agradecimiento y reconocimiento a los autores y mantenedores originales.

Josh Springer, Daniel Shepherd, Bas Meijeri, James Cassell, Mike Renfro, DFed, George Nalen, Mark Bolwell

Instalar
ansible-galaxy install ansible-lockdown.rhel7_cis
Licencia
mit
Descargas
3.5k
Propietario
Ansible Lockdown is a security baseline automation project sponsored by Mindpoint Group.