MindPointGroup.ubuntu18_cis

UBUNTU18 CIS

Configurar una máquina Ubuntu18 para cumplir con CIS

Basado en CIS Ubuntu1804 Benchmark v2.1.0


Estrellas de la Organización Estrellas Forks Seguidores URL de Twitter

Calidad de Ansible Galaxy 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 realizará cambios en el sistema que pueden tener consecuencias no deseadas. Esta no es una herramienta de auditoría, sino más bien una herramienta de remediación que se debe usar 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 es compatible y debe usarse con precaución. Se debe utilizar el rol UBUNTU18-CIS-Audit o un escáner de cumplimiento para comprobar 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 cualquier cambio específico necesario para tu sitio.

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


Igualar un nivel de seguridad para CIS

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

  • level1_server
  • level1_workstation
  • level2_server
  • level2_workstation

El control encontrado en defaults main también necesita reflejar esto, ya que este control determina las pruebas que se realizan si estás usando 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. 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 la variable run_audit. Su valor es falso por defecto; por favor, consulta la wiki para más detalles. El archivo de predeterminados también llena las verificaciones de goss para comprobar solo los controles que han sido habilitados en el rol de ansible.

Esta es una comprobación mucho más rápida y ligera, (donde sea posible) para verificar el cumplimiento de la configuración y los ajustes en vivo/ejecutándose.

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

Consulta UBUNTU18-CIS-Audit.

Ejemplo de Resumen de Auditoría

Esto se basa en una imagen vagrant con selecciones habilitadas. Por ejemplo, sin GUI ni firewall. Nota: Se realizan más pruebas durante la auditoría, ya que comprobamos la configuración y el estado en ejecución.


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

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

Documentación

Requisitos

Generales:

  • Conocimientos básicos de Ansible. A continuación se presentan 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 base de Ansible/Tower, paquetes necesarios instalados y la infraestructura configurada.

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

Dependencias Técnicas:

  • Acceso para descargar o agregar el binario de goss y contenido al sistema si se está utilizando la auditoría (hay otras opciones disponibles sobre cómo llevar el contenido al sistema).
  • Python3
  • Ansible 2.10.1+
  • python-def
  • libselinux-python

Variables del Rol

Este rol está diseñado para que el usuario final no tenga que editar las tareas por sí mismo. Toda la personalización debe hacerse a través del archivo defaults/main.yml o con vars 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 qué nivel, si está calificado/no calificado, 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 services, esta tarea se omitirá. Lo opuesto también puede suceder, donde solo se ejecutan 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 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 GPG firmar todos los commits que desees fusionar.
  • Todas las solicitudes de extracción de la comunidad se incorporan a la rama de desarrollo.
  • Las solicitudes de extracción en desarrollo confirmarán que tus commits tienen una firma GPG, están firmados y tienen una prueba funcional antes de ser aprobadas.
  • Una vez que tus cambios sean fusionados 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

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

bug 1839899

Pruebas de Pipeline

utiliza:

  • ansible-core 2.16
  • colecciones de ansible - se extrae 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

Extras Adicionales

  • pre-commit se puede probar y se puede ejecutar desde dentro del directorio
pre-commit run
Instalar
ansible-galaxy install MindPointGroup.ubuntu18_cis
Licencia
mit
Descargas
998
Propietario
Ansible Lockdown is a security baseline automation project sponsored by Mindpoint Group.