Ansible Role: cis_ubuntu_2004 :computer:

Rol de Ansible para aplicar el Marco de Referencia CIS para Ubuntu Linux 20.04 LTS.

Las versiones actualmente soportadas y disponibles son:

• Marco de Referencia CIS para Ubuntu Linux 20.04 LTS v1.1.0
• Marco de Referencia CIS para Ubuntu Linux 20.04 LTS v1.0.0

Versiones

La siguiente tabla especifica las versiones de la rol disponibles en Ansible Galaxy y GitHub Releases, en relación a las versiones correspondientes del Marco de Referencia CIS para Ubuntu Linux 20.04 LTS.

1. Instrucciones de instalación/descarga:

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

Sin archivo requirements.yml:

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

  ansible-galaxy install darkwizard242.cis_ubuntu_2004
  

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

  ansible-galaxy install darkwizard242.cis_ubuntu_2004,3.2.0
  

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

  ansible-galaxy install darkwizard242.cis_ubuntu_2004,master
  

• Instalando/descargando una versión específica de una rama del repositorio (usando la rama feature/cis_version_1.1.0 como ejemplo, que cumple con las últimas actualizaciones de la Versión del Marco de Referencia CIS Ubuntu 20.04 v1.1.0):

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

• Instalando/descargando una versión específica de una rama del repositorio (usando la rama feature/cis_version_1.0.0 como ejemplo, que cumple con las últimas actualizaciones de la Versión del Marco de Referencia CIS Ubuntu 20.04 v1.0.0):

  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.2.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 al requirements.yml:

ansible-galaxy install -r requirements.yml

NOTA: Instalar un rol como se menciona arriba solo descarga el rol para que esté disponible para su uso en tus playbooks de ansible. Puedes leer las instrucciones de instalación/descarga de roles aquí.

2. Algunas consideraciones:

Los controles sobre particionamiento de disco y sus puntos de montaje de la 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 u organización probablemente variarán. Recomiendo aplicarlos por tu cuenta. A continuación se encuentra una lista de esos controles:

• 1.1.10 Asegurarse de que existe una partición separada para /var (Automatizado)
• 1.1.11 Asegurarse de que existe 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 existe una partición separada para /var/log (Automatizado)
• 1.1.16 Asegurarse de que existe una partición separada para /var/log/audit (Automatizado)
• 1.1.17 Asegurarse de que existe 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é establecida en las particiones de medios extraíbles (Manual)
• 1.1.20 Asegurarse de que la opción nosuid esté establecida en las particiones de medios extraíbles (Manual)
• 1.1.21 Asegurarse de que la opción noexec esté establecida en las particiones de medios extraíbles (Manual)

Del mismo modo, los benchmarks de Sección 4 también no han sido implementados:

• 4.2.1.5 Asegurarse de que rsyslog esté configurado para enviar registros a un host de registro remoto (Automatizado)
• 4.2.1.6 Asegurarse de que se acepten mensajes remotos de rsyslog únicamente 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 del CIS, como las siguientes y las variables que pueden romper el sistema mencionadas en la sección 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 sección están ubicadas en sus respectivos archivos.

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

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

• Variables importantes

Los controles de endurecimiento del CIS Ubuntu 20.04 requieren la purga de muchos servicios que pueden ser explotables, tener vulnerabilidades conocidas, resultar en una exposición de la superficie de ataque o que deben ser desactivados si no son necesarios. Según el marco, 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 usar 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.

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

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

# Establecer en `true` si se requiere inalámbrico.
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 necesita el demonio SSH.
ubuntu_2004_cis_require_ssh_server: true

# Variable para almacenar Cifrados fuertes para el demonio SSH.
ubuntu_2004_cis_require_ssh_ciphers: [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr

# Variable para almacenar Algoritmos MAC fuertes para el demonio 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 fuertes para el demonio 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 Vida del Cliente en segundos para el demonio SSH.
ubuntu_2004_cis_require_ssh_clientaliveinterval: '300'

# Variable para almacenar el número de Conteo Máximo de Clientes Vivos para el demonio SSH.
ubuntu_2004_cis_require_ssh_clientalivecountmax: '3'

# Variable para almacenar el Tiempo de Gracia de Inicio de Sesión en segundos para el demonio SSH.
ubuntu_2004_cis_require_ssh_logingracetime: '60'

# Variable para almacenar AllowUsers para el demonio SSH.
ubuntu_2004_cis_require_ssh_allowusers: ubuntu vagrant

# Variable para almacenar AllowGroups para el demonio SSH.
ubuntu_2004_cis_require_ssh_allowgroups: ubuntu vagrant

# Variable para almacenar DenyUsers para el demonio SSH.
ubuntu_2004_cis_require_ssh_denyusers: bogus dummy

# Variable para almacenar DenyGroups para el demonio SSH.
ubuntu_2004_cis_require_ssh_denygroups: bogus dummy

# Variable para almacenar la longitud mínima y la clase de caracteres para la calidad de 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ña.
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 en 30 días.
ubuntu_2004_cis_require_passwarnage: '7'

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

# Variable para almacenar el valor de Timeout de Shell en segundos.
ubuntu_2004_cis_require_shell_timeout: '900'

# Variable para almacenar el nombre del grupo que será requerido 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 propagará la ejecución del trabajo cron para la tarea de revisión de permisos de archivos de sistema de auditoría (Manual).
ubuntu_2004_cis_require_audit_system_file_permissions_logfile: /var/log/6_1_1_cis_audit_system.log

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

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

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

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

# SI se usa 'ufw', establecer en 'true' deniega todas las conexiones entrantes por defecto. Funciona igual que `ufw default deny incoming`. Establecer en `false` si no se requiere que esto sea aplicado.
ubuntu_2004_cis_section3_rule_ufw_default_deny_incoming: true

# SI se usa 'ufw', establecer en 'true' deniega todas las conexiones salientes por defecto. Funciona igual que `ufw default deny outgoing`. Establecer en `false` si no se requiere que esto sea aplicado.
ubuntu_2004_cis_section3_rule_ufw_default_deny_outgoing: true

# SI se usa 'ufw', establecer en 'true' deniega todas las conexiones enrutadas por defecto. Funciona igual que `ufw default deny routed`. Establecer en `false` si no se requiere que esto sea aplicado.
ubuntu_2004_cis_section3_rule_ufw_default_deny_routed: true

# SI se usa 'nftables', establecer en 'true' deniega todas las conexiones de entrada/avance/salida por defecto, dejando el sistema inaccesible. Establecer en `false` si no se requiere que esto sea aplicado o para no perder conectividad.
ubuntu_2004_cis_section3_rule_3_5_2_8: true

# SI se usa 'iptables', establecer en 'true' deniega todas las conexiones entrantes en ipv4 por defecto, dejando el sistema inaccesible. Establecer en `false` si no se requiere que esto sea aplicado o para no perder conectividad.
ubuntu_2004_cis_section3_rule_iptables_ipv4_default_deny_input: true

# SI se usa 'iptables', establecer en 'true' deniega todas las conexiones salientes en ipv4 por defecto, dejando el sistema inaccesible. Establecer en `false` si no se requiere que esto sea aplicado o para no perder conectividad.
ubuntu_2004_cis_section3_rule_iptables_ipv4_default_deny_output: true

# SI se usa 'iptables', establecer en 'true' deniega todas las conexiones de avance en ipv4 por defecto, dejando el sistema inaccesible. Establecer en `false` si no se requiere que esto sea aplicado o para no perder conectividad.
ubuntu_2004_cis_section3_rule_iptables_ipv4_default_deny_forward: true

# SI se usa 'iptables' y ipv6 está habilitado, establecer en 'true' deniega todas las conexiones entrantes en ipv4 por defecto, dejando el sistema inaccesible. Establecer en `false` si no se requiere que esto sea aplicado o para no perder conectividad.
ubuntu_2004_cis_section3_rule_iptables_ipv6_default_deny_input: true

# SI se usa 'iptables' y ipv6 está habilitado, establecer en 'true' deniega todas las conexiones salientes en ipv4 por defecto, dejando el sistema inaccesible. Establecer en `false` si no se requiere que esto sea aplicado o para no perder conectividad.
ubuntu_2004_cis_section3_rule_iptables_ipv6_default_deny_output: true

# SI se usa 'iptables' y ipv6 está habilitado, establecer en 'true' deniega todas las conexiones de avance en ipv4 por defecto, dejando el sistema inaccesible. Establecer en `false` si no se requiere que esto sea aplicado o para no 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 respaldo de auditd para almacenar registros suficientes al momento del arranque.
ubuntu_2004_cis_auditd_backloglimit: '8192'

# Tamaño del archivo de registro para los logs de auditd. Establecer según sea apropiado.
ubuntu_2004_cis_auditd_maxlogfile: '25'

# Acción a tomar cuando los logs de auditd han alcanzado el tamaño máximo. Establecer según sea apropiado.
ubuntu_2004_cis_auditd_maxlogfileaction: keep_logs

# Acción a tomar para el poco espacio restante para auditd. Establecer según sea apropiado.
ubuntu_2004_cis_auditd_spaceleftaction: email

# A quién enviar correos para auditd. Establecer según sea apropiado.
ubuntu_2004_cis_auditd_actionmailacct: root

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

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

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

# Establecer en `true` si se requiere X Windows System.
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 un servidor DHCP.
ubuntu_2004_cis_require_dhcp_server: false

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

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

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

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

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

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

# Establecer en `true` si se requiere el demonio 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 únicamente. Definir como `false` si se requiere que postfix actúe en modo local únicamente.
ubuntu_2004_cis_require_mail_server: true

# Establecer en `true` si RSYNC es requerido.
ubuntu_2004_cis_require_rsyncd_server: false

# Establecer en `true` si el servidor NIS es requerido.
ubuntu_2004_cis_require_nis_server: false

# Establecer en `true` si el cliente NIS es requerido.
ubuntu_2004_cis_require_nis_client: false

# Establecer en `true` si el cliente RSH es requerido.
ubuntu_2004_cis_require_rsh_client: false

# Establecer en `true` si el cliente TALK es requerido.
ubuntu_2004_cis_require_talk_client: false

# Establecer en `true` si el cliente TELNET es requerido.
ubuntu_2004_cis_require_telnet_client: false

# Establecer en `true` si el cliente LDAP es requerido.
ubuntu_2004_cis_require_ldap_client: false

# Establecer en `true` si el cliente RPCBIND es requerido.
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 por defecto y requisitos personalizados.

NOTA: Teniendo en cuenta que algunos de los controles del CIS relacionados con la red pueden romper el sistema y dejar al usuario incapaz de volver a iniciar sesión en él, recomendaría que apliques o experimentes utilizando el playbook-examples/playbook_with_custom_firewall_changes.yml primero. Modifica el tipo de conexión y los hosts en el playbook para que se adapten a tus necesidades.

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

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

ansible-playbook myplaybook.yml

Aplicando ejemplos usando etiquetas:

Todas las tareas en el rol tienen etiquetas asignadas según la asignación del nivel CIS, el número de regla y el número de sección. Por defecto, se aplicarán tanto los controles de Nivel 1 como los de Nivel 2. 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 <playbook-name-here>.yml --tags "level_1"

Ejemplo para aplicar solo controles de Nivel 2:

ansible-playbook <playbook-name-here>.yml --tags "level_2"

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

ansible-playbook <playbook-name-here>.yml --tags "section4"

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

ansible-playbook <playbook-name-here>.yml --tags "rule_6_2_2"

7. Desarrollo Local y CI/CD:

Para el desarrollo local del rol cis_ubuntu_2004, por favor realiza lo siguiente:

• 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 necesitas, puedes utilizar el rol darkwizard242.vagrant para instalarlo, pero por favor confirma si es compatible con tu sistema operativo.

• Instala Virtualbox en tu máquina. Las instrucciones de instalación están disponibles aquí o si necesitas, puedes utilizar el rol darkwizard242.virtualbox para instalarlo, pero por favor confirma si es compatible con tu sistema operativo.

• Instala los módulos requeridos usando:

  # Para instalar módulos pip globalmente cuando se esté ejecutando 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 esté ejecutando 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 secuencia de pruebas 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, realizar cambios y ejecutarlo mediante ansible-playbook en una máquina de prueba si no estás familiarizado con molecule.

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

• Clonar el código de la solicitud de extracción.
• Actualizar la caché del repositorio.
• Instalar paquetes previos requeridos.
• Instalar Vagrant y Virtualbox.
• Realizar una verificación de calidad de código de SonarCloud para toda la base de código del repositorio.
• Ejecutar la prueba molecule (que provisionará una caja vagrant, aplicará el código del rol y ejecutará la serie de pruebas de TestInfra para el rol cis_ubuntu_2004).

8. Contribuyendo:

Las contribuciones son muy bienvenidas. Las instrucciones para contribuir han sido mencionadas aquí.

Inspiración

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

Licencia

MIT

Información del autor

Este rol fue creado por Ali Muhammad.