Rol de Ansible: cis_ubuntu_2004 :computer:

Rol de Ansible para aplicar CIS Benchmark para Ubuntu Linux 20.04 LTS.

Las versiones actualmente soportadas y disponibles son:

• CIS Benchmark para Ubuntu Linux 20.04 LTS v1.1.0
• CIS Benchmark para Ubuntu Linux 20.04 LTS v1.0.0

Versiones

La siguiente tabla muestra las versiones del rol disponibles en Ansible Galaxy y GitHub Releases, en relación con el correspondiente CIS Benchmark para Ubuntu Linux 20.04 LTS.

Versión del Benchmark de CIS Ubuntu 20.04	Versión de Ansible Galaxy	Versión en el repositorio
1.0.0	1.0.0, 1.0.1, 1.0.2	1.0.0, 1.0.1, 1.0.2
1.1.0	2.0.0, 2.0.1, 2.1.0, 3.0.0, 3.1.0	2.0.0, 2.0.1, 2.1.0, 3.0.0, 3.1.0

1. Instrucciones de instalación/descarga:

Este rol está disponible en Ansible Galaxy. Hay varios métodos que puedes usar para instalar/descargar el rol cis_ubuntu_2004 en tu nodo controlador de Ansible, ya sea desde Ansible Galaxy o directamente desde el repositorio.

Sin un archivo requirements.yml:

• Instalando/descargando la última versión (por defecto):

  ansible-galaxy install darkwizard242.cis_ubuntu_2004
  

• Instalando/descargando una versión específica (usando 3.1.0 como ejemplo):

  ansible-galaxy install darkwizard242.cis_ubuntu_2004,3.1.0
  

• Instalando/descargando una versión de rama específica del repositorio (usando master como ejemplo, master siempre cumplirá con la última versión disponible del Benchmark CIS Ubuntu 20.04):

  ansible-galaxy install darkwizard242.cis_ubuntu_2004,master
  

• Instalando/descargando una versión de rama específica del repositorio (usando la rama feature/cis_version_1.1.0 como ejemplo):

  ansible-galaxy install darkwizard242.cis_ubuntu_2004,feature/cis_version_1.1.0
  

• Instalando/descargando una versión de rama específica del repositorio (usando la rama feature/cis_version_1.0.0 como ejemplo):

  ansible-galaxy install darkwizard242.cis_ubuntu_2004,feature/cis_version_1.0.0
  

Con un archivo requirements.yml:

Agrega a un archivo requirements.yml existente junto con tus otros roles o crea uno nuevo para instalar cis_ubuntu_2004.

• Última versión directamente desde Ansible Galaxy.

  - name: darkwizard242.cis_ubuntu_2004
  

• Versión específica directamente desde Ansible Galaxy.

  - name: darkwizard242.cis_ubuntu_2004
    version: 3.1.0
  

• Rama específica desde el repositorio.

  - name: cis_ubuntu_2004
    src: https://github.com/darkwizard242/cis_ubuntu_2004
    version: master
  

Instalando/descargando después de agregar a requirements.yml:

ansible-galaxy install -r requirements.yml

NOTA: Instalar un rol como se menciona solo descarga el rol para tenerlo disponible en tus playbooks de ansible. Puedes leer más sobre las instrucciones de instalación/descarga de roles aquí.

2. Algunas consideraciones:

Los benchmarks sobre la particionamiento de disco y sus puntos de montaje de Sección 1 no se aplican en este rol. La razón es que la arquitectura del sistema y el diseño del disco de cada individuo/organización probablemente variarán. Recomendaría aplicar esos tú mismo. A continuación se muestra una lista de esos benchmarks:

• 1.1.10 Asegurarse de que exista una partición separada para /var (Automatizado)
• 1.1.11 Asegurarse de que exista una partición separada para /var/tmp (Automatizado)
• 1.1.12 Asegurarse de que la partición /var/tmp incluya la opción nodev (Automatizado)
• 1.1.13 Asegurarse de que la partición /var/tmp incluya la opción nosuid (Automatizado)
• 1.1.14 Asegurarse de que la partición /var/tmp incluya la opción noexec (Automatizado)
• 1.1.15 Asegurarse de que exista una partición separada para /var/log (Automatizado)
• 1.1.16 Asegurarse de que exista una partición separada para /var/log/audit (Automatizado)
• 1.1.17 Asegurarse de que exista una partición separada para /home (Automatizado)
• 1.1.18 Asegurarse de que la partición /home incluya la opción nodev (Automatizado)
• 1.1.19 Asegurarse de que la opción nodev esté configurada en particiones de medios removibles (Manual)
• 1.1.20 Asegurarse de que la opción nosuid esté configurada en particiones de medios removibles (Manual)
• 1.1.21 Asegurarse de que la opción noexec esté configurada en particiones de medios removibles (Manual)

Los siguientes benchmarks de Sección 4 tampoco se han implementado:

• 4.2.1.5 Asegurarse de que rsyslog esté configurado para enviar registros a un host remoto (Automatizado)
• 4.2.1.6 Asegurarse de que los mensajes remotos de rsyslog solo se acepten en hosts de registro designados. (Manual)
• 4.3 Asegurarse de que logrotate esté configurado (Manual)

3. Requisitos

Ninguno.

4. Variables del rol

Las variables predeterminadas del rol que se utilizan en las tareas del rol se encuentran en defaults/main/.

defaults/main/main.yml contiene variables que se refieren a todas las secciones de CIS, como las siguientes y variables críticas del sistema como las mencionadas en Variables importantes:

ubuntu_2004_cis_section1: true
ubuntu_2004_cis_section2: true
ubuntu_2004_cis_section3: true
ubuntu_2004_cis_section4: true
ubuntu_2004_cis_section5: true
ubuntu_2004_cis_section6: true

El propósito de las variables mencionadas anteriormente es indicar que todas las tareas relacionadas con estas secciones deben aplicarse a través del rol cis_ubuntu_2004.

Las variables para cada una de las secciones se encuentran en sus propios archivos.

• Las variables de la Sección 1 están en defaults/main/section_01.yml
• Las variables de la Sección 2 están en defaults/main/section_02.yml
• Las variables de la Sección 3 están en defaults/main/section_03.yml
• Las variables de la Sección 4 están en defaults/main/section_04.yml
• Las variables de la Sección 5 están en defaults/main/section_05.yml
• Las variables de la Sección 6 están en defaults/main/section_06.yml

Los valores predeterminados del rol para todo en el rol cis_ubuntu_2004 pueden ser sobreescritos al pasarlos en un playbook o mediante cualquier otro método de precedencia de variables.

• Variables importantes

Los benchmarks de fortalecimiento de CIS Ubuntu 20.04 requieren la eliminación de muchos servicios que pueden ser explotados, que tienen vulnerabilidades conocidas, que resultan en una exposición de la superficie de ataque o que deben ser deshabilitados si no se requieren. Según el benchmark, por defecto, todos estos servicios serán eliminados y el valor de sus variables se ha establecido en false. Sin embargo, si aún necesitas el uso de estos servicios por alguna razón, cambia sus valores a true para que al aplicar el rol en un playbook, las tareas del rol para eliminar esos servicios puedan ser omitidas.

Además de la explicación anterior de algunas variables, también hay otras variables que definen si un servicio específico es deseado en el sistema o no (por ejemplo, el servicio SSH), parámetros para la configuración de varias herramientas (por ejemplo, auditd) etc. Estas también pueden ser sobreescritas en un playbook.

# Establecer en `true` si se requiere IPv6.
ubuntu_2004_cis_require_ipv6: false

# Establecer en `true` si se requiere conexión inalámbrica.
ubuntu_2004_cis_require_wireless: false

# Establecer en `true` si el sistema debe actuar como un enrutador.
ubuntu_2004_cis_require_router: false

# Establecer en `false` si no se requiere el servicio SSH.
ubuntu_2004_cis_require_ssh_server: true

# Variable para almacenar cifrados seguros para el servicio SSH.
ubuntu_2004_cis_require_ssh_ciphers: [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr

# Variable para almacenar algoritmos MAC seguros para el servicio SSH.
ubuntu_2004_cis_require_ssh_macs: [email protected],[email protected],hmac-sha2-512,hmac-sha2-256

# Variable para almacenar algoritmos de intercambio de claves seguros para el servicio SSH.
ubuntu_2004_cis_require_ssh_kexalgorithms: curve25519-sha256,[email protected],diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

# Variable para almacenar el intervalo de cliente en segundos para el servicio SSH.
ubuntu_2004_cis_require_ssh_clientaliveinterval: '300'

# Variable para almacenar el número de conteo de cliente máximo para el servicio SSH.
ubuntu_2004_cis_require_ssh_clientalivecountmax: '3'

# Variable para almacenar el tiempo de gracia de inicio de sesión en segundos para el servicio SSH.
ubuntu_2004_cis_require_ssh_logingracetime: '60'

# Variable para almacenar los usuarios permitidos para el servicio SSH.
ubuntu_2004_cis_require_ssh_allowusers: ubuntu vagrant

# Variable para almacenar los grupos permitidos para el servicio SSH.
ubuntu_2004_cis_require_ssh_allowgroups: ubuntu vagrant

# Variable para almacenar los usuarios denegados para el servicio SSH.
ubuntu_2004_cis_require_ssh_denyusers: bogus dummy

# Variable para almacenar los grupos denegados para el servicio SSH.
ubuntu_2004_cis_require_ssh_denygroups: bogus dummy

# Variable para almacenar la longitud mínima y clase de caracteres para la calidad de la contraseña de pam.
ubuntu_2004_cis_require_pam_pwquality:
  - key: 'minlen'
    value: '14'
  - key: 'minclass'
    value: '4'

# Variable para almacenar el valor de PASS_MAX_DAYS para la expiración de contraseñas.
ubuntu_2004_cis_require_passmaxdays: '365'

# Variable para almacenar el valor de PASS_MIN_DAYS para el cambio de contraseña.
ubuntu_2004_cis_require_passmindays: '1'

# Variable para almacenar el valor de INACTIVE para establecer el período de inactividad de contraseña predeterminado a 30 días.
ubuntu_2004_cis_require_passwarnage: '7'

# Variable para almacenar el valor de PASS_WARN_AGE para establecer la alerta de expiración de contraseña en un número de días.
ubuntu_2004_cis_require_passinactive: '30'

# Variable para almacenar el valor del tiempo de espera de la sesión en segundos.
ubuntu_2004_cis_require_shell_timeout: '900'

# Variable para almacenar el nombre del grupo que será obligatorio para el uso de la ejecución de su.
ubuntu_2004_cis_require_su_group: sugroup

# Variable para almacenar el archivo de registro al que se propaga la ejecución del trabajo cron para revisar los permisos de archivos del sistema (Manual).
ubuntu_2004_cis_require_audit_system_file_permissions_logfile: /var/log/6_1_1_cis_audit_system.log

# Puede ser uno de 'iptables' o 'nftables' o 'ufw'.
ubuntu_2004_cis_firewall: ufw

# SI se usa 'ufw', establecer en 'sí' permite que se configure y permita un perfil de aplicación de git UFW.
ubuntu_2004_cis_section3_rule_3_5_1_7_ufw_require_git_profile: yes

# SI se usa 'ufw', establecer en 'sí' permite que se configure y permita un perfil de aplicación HTTP UFW.
ubuntu_2004_cis_section3_rule_3_5_1_7_ufw_require_http_profile: yes

# SI se usa 'ufw', establecer en 'sí' permite que se configure y permita un perfil de aplicación HTTPS UFW.
ubuntu_2004_cis_section3_rule_3_5_1_7_ufw_require_https_profile: yes

# SI se usa 'ufw', establecer en 'true' negará todas las conexiones entrantes por defecto. Funciona igual que `ufw default deny incoming`. Establecer en `false` si no requieres que se aplique.
ubuntu_2004_cis_section3_rule_ufw_default_deny_incoming: true

# SI se usa 'ufw', establecer en 'true' negará todas las conexiones salientes por defecto. Funciona igual que `ufw default deny outgoing`. Establecer en `false` si no requieres que se aplique.
ubuntu_2004_cis_section3_rule_ufw_default_deny_outgoing: true

# SI se usa 'ufw', establecer en 'true' negará todas las conexiones enrutadas por defecto. Funciona igual que `ufw default deny routed`. Establecer en `false` si no requieres que se aplique.
ubuntu_2004_cis_section3_rule_ufw_default_deny_routed: true

# SI se usa 'nftables', establecer en 'true' negará todas las conexiones de entrada/salida/enrutadas por defecto, dejando el sistema inalcanzable. Establecer en `false` si no requieres que se aplique o si deseas perder conectividad.
ubuntu_2004_cis_section3_rule_3_5_2_8: true

# SI se usa 'iptables', establecer en 'true' negará todas las conexiones entrantes en ipv4 de forma predeterminada, dejando el sistema inalcanzable. Establecer en `false` si no requieres que se aplique o si deseas perder conectividad.
ubuntu_2004_cis_section3_rule_iptables_ipv4_default_deny_input: true

# SI se usa 'iptables', establecer en 'true' negará todas las conexiones salientes en ipv4 de forma predeterminada, dejando el sistema inalcanzable. Establecer en `false` si no requieres que se aplique o si deseas perder conectividad.
ubuntu_2004_cis_section3_rule_iptables_ipv4_default_deny_output: true

# SI se usa 'iptables', establecer en 'true' negará todas las conexiones enrutadas en ipv4 de forma predeterminada, dejando el sistema inalcanzable. Establecer en `false` si no requieres que se aplique o si deseas perder conectividad.
ubuntu_2004_cis_section3_rule_iptables_ipv4_default_deny_forward: true

# SI se usa 'iptables' y ipv6 está habilitado, establecer en 'true' negará todas las conexiones entrantes en ipv4 de forma predeterminada, dejando el sistema inalcanzable. Establecer en `false` si no requieres que se aplique o si deseas perder conectividad.
ubuntu_2004_cis_section3_rule_iptables_ipv6_default_deny_input: true

# SI se usa 'iptables' y ipv6 está habilitado, establecer en 'true' negará todas las conexiones salientes en ipv4 de forma predeterminada, dejando el sistema inalcanzable. Establecer en `false` si no requieres que se aplique o si deseas perder conectividad.
ubuntu_2004_cis_section3_rule_iptables_ipv6_default_deny_output: true

# SI se usa 'iptables' y ipv6 está habilitado, establecer en 'true' negará todas las conexiones enrutadas en ipv4 de forma predeterminada, dejando el sistema inalcanzable. Establecer en `false` si no requieres que se aplique o si deseas perder conectividad.
ubuntu_2004_cis_section3_rule_iptables_ipv6_default_deny_forward: true

# Puede ser uno de 'ntp' o 'chrony' o 'systemd-timesyncd'.
ubuntu_2004_cis_time_synchronization: systemd-timesyncd

# Límite de retención de auditd para almacenar suficientes registros al arrancar.
ubuntu_2004_cis_auditd_backloglimit: '8192'

# Tamaño del archivo de registro para logs de auditd. Establecer apropiadamente.
ubuntu_2004_cis_auditd_maxlogfile: '25'

# Acción a tomar cuando los logs de auditd hayan alcanzado el tamaño máximo. Establecer apropiadamente.
ubuntu_2004_cis_auditd_maxlogfileaction: keep_logs

# Acción a tomar para bajo espacio disponible para auditd. Establecer apropiadamente.
ubuntu_2004_cis_auditd_spaceleftaction: email

# A quién enviar un correo por auditd. Establecer apropiadamente.
ubuntu_2004_cis_auditd_actionmailacct: root

# Opción para detener cuando los logs de auditoría están llenos. Establecer apropiadamente.
ubuntu_2004_cis_auditd_adminspaceleftaction: halt

# Usuarios permitidos para programar trabajos cron.
ubuntu_2004_cis_cron_allow_users:
  - root
  - ubuntu

# Usuarios permitidos para usar 'at' para programar trabajos.
ubuntu_2004_cis_at_allow_users:
  - root
  - ubuntu

# Establecer en `true` si se requiere el sistema X Windows.
ubuntu_2004_cis_require_xwindows_system: false

# Establecer en `true` si se requiere CUPS.
ubuntu_2004_cis_require_cups: false

# Establecer en `true` si se requiere el servidor DHCP.
ubuntu_2004_cis_require_dhcp_server: false

# Establecer en `true` si se requiere el servidor LDAP.
ubuntu_2004_cis_require_ldap_server: false

# Establecer en `true` si se requiere el servidor NFS.
ubuntu_2004_cis_require_nfs_server: false

# Establecer en `true` si se requiere el servidor DNS.
ubuntu_2004_cis_require_dns_server: false

# Establecer en `true` si se requiere el servidor FTP.
ubuntu_2004_cis_require_ftp_server: false

# Establecer en `true` si se requiere el servidor HTTP (apache2).
ubuntu_2004_cis_require_http_server: false

# Establecer en `true` si se requieren los servidores IMAP y POP3.
ubuntu_2004_cis_require_imap_pop3_server: false

# Establecer en `true` si se requiere el demonio de Samba.
ubuntu_2004_cis_require_samba_server: false

# Establecer en `true` si se requiere el servidor Squid.
ubuntu_2004_cis_require_squid_server: false

# Establecer en `true` si se requiere el servidor SNMP.
ubuntu_2004_cis_require_snmp_server: false

# Para evitar que postfix actúe en modo local solamente. Definir como `false` si es necesario que postfix actúe en modo local solamente.
ubuntu_2004_cis_require_mail_server: true

# Establecer en `true` si se requiere RSYNC.
ubuntu_2004_cis_require_rsyncd_server: false

# Establecer en `true` si se requiere el servidor NIS.
ubuntu_2004_cis_require_nis_server: false

# Establecer en `true` si se requiere el cliente NIS.
ubuntu_2004_cis_require_nis_client: false

# Establecer en `true` si se requiere el cliente RSH.
ubuntu_2004_cis_require_rsh_client: false

# Establecer en `true` si se requiere el cliente TALK.
ubuntu_2004_cis_require_talk_client: false

# Establecer en `true` si se requiere el cliente TELNET.
ubuntu_2004_cis_require_telnet_client: false

# Establecer en `true` si se requiere el cliente LDAP.
ubuntu_2004_cis_require_ldap_client: false

# Establecer en `true` si se requiere el cliente RPCBIND.
ubuntu_2004_cis_require_rpcbind_client: false

5. Dependencias

Ninguna

6. Ejemplos de playbooks:

Se han proporcionado ejemplos de playbooks en la carpeta playbook-examples. Contiene playbooks con configuraciones predeterminadas y requisitos personalizados.

NOTA: Teniendo en cuenta que algunos de los controles de CIS sobre redes pueden romper el sistema y dejar al usuario incapaz de volver a conectarse al mismo, recomendaría que apliques o experimentes utilizando el playbook playbook-examples/playbook_with_custom_firewall_changes.yml. Modifica el tipo de conexión y hosts en el playbook según sea necesario.

Aplicando ejemplos:

Si estás usando cualquiera de los playbooks proporcionados en la carpeta de ejemplos, puedes elegir cualquiera de ellos y ejecutar el siguiente comando para aplicarlos:

ansible-playbook playbook_with_defaults.yml

ansible-playbook playbook_with_custom_firewall_changes.yml

ansible-playbook playbook_with_ipv6.yml

ansible-playbook playbook_with_ufw.yml

Asumiendo que crees tu propio playbook personalizado llamado myplaybook.yml, puedes ejecutarlo simplemente con el siguiente comando.

ansible-playbook myplaybook.yml

Aplicando ejemplos usando etiquetas:

Todas las tareas en el rol tienen etiquetas asignadas basadas en la asignación de nivel de CIS, número de regla y número de sección. Por defecto, tanto los controles de Nivel 1 como de Nivel 2 se aplicarán. Por lo tanto, si deseas ejecutar aplicaciones personalizadas para niveles, números de regla o secciones, puedes usar los siguientes ejemplos:

Ejemplo para aplicar solo controles de Nivel 1:

ansible-playbook <nombre-del-playbook-aqui>.yml --tags "level_1"

Ejemplo para aplicar solo controles de Nivel 2:

ansible-playbook <nombre-del-playbook-aqui>.yml --tags "level_2"

Ejemplo para aplicar controles de una sección específica (es decir, sección 4 del benchmark de CIS Ubuntu 20.04 como ejemplo):

ansible-playbook <nombre-del-playbook-aqui>.yml --tags "section4"

Ejemplo para aplicar un control específico (es decir, control 6.2.2 del benchmark de CIS Ubuntu 20.04 como ejemplo):

ansible-playbook <nombre-del-playbook-aqui>.yml --tags "rule_6_2_2"

7. Desarrollo local y CI/CD:

Para el desarrollo local del rol cis_ubuntu_2004, por favor sigue los siguientes pasos:

• Haz un fork del repositorio.

• Clónalo localmente.

• Instala Vagrant en tu máquina. Las instrucciones de instalación están disponibles aquí o si lo necesitas, puedes utilizar el rol darkwizard242.vagrant para la instalación - pero asegúrate de que es compatible con tu sistema operativo.

• Instala Virtualbox en tu máquina. Las instrucciones de instalación están disponibles aquí o si lo necesitas, puedes utilizar el rol darkwizard242.virtualbox para la instalación - pero asegúrate de que es compatible con tu sistema operativo.

• Instala los módulos requeridos usando:

  # Para instalar módulos pip globalmente cuando se ejecuta como un usuario no root.
  sudo -H python3 -m pip install -U molecule ansible-lint flake8 pytest-testinfra molecule-vagrant
  

  O

  # Para instalar módulos pip localmente en el directorio del usuario cuando se ejecuta como un usuario no root.
  python3 -m pip install -U molecule ansible-lint flake8 pytest-testinfra molecule-vagrant
  

• Realiza cambios y ejecuta molecule test o molecule converge.

El comando molecule test ejecutará toda la suite de pruebas de molécula configuradas.

El comando molecule converge solo creará la instancia de vagrant y aplicará todas las operaciones definidas en el rol.

Por supuesto, también puedes simplemente descargar el código del rol cis_ubuntu_2004, hacer cambios y ejecutarlo a través de ansible-playbook en una máquina de prueba si no estás familiarizado con molecule.

Cuando crees un Pull Request, esto activará automáticamente una construcción de TravisCI aquí. La configuración para la construcción de TravisCI se encuentra en .travis.yml. Esto realizará varias tareas, tales como:

• Clonar el código desde el pull request.
• Actualizar la caché del repositorio.
• Instalar paquetes pre-requisitos.
• Instalar Vagrant y Virtualbox.
• Realizar una verificación de calidad del código de SonarCloud para toda la base de código del repositorio.
• Ejecutar la prueba de molécula (que provisionará una caja vagrant, aplicará el código del rol y ejecutará la suite de pruebas de TestInfra para el rol cis_ubuntu_2004).

8. Contribuciones:

Las contribuciones son muy bienvenidas. Las instrucciones para contribuir se mencionan aquí.

Inspiración

Inspirado en el gran trabajo realizado por muchos de los miembros de la Comunidad de Ansible (Florian Utz y ansible-lockdown, entre otros). ¡Sigue rockeando! :metal:

Licencia

MIT

Información del autor

Este rol fue creado por Ali Muhammad.