Rôle Ansible : cis_ubuntu_2004 :ordinateur:

Rôle Ansible pour appliquer le CIS Benchmark pour Ubuntu Linux 20.04 LTS.

Les versions actuellement supportées et disponibles sont :

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

Versionnage

Le tableau ci-dessous spécifie les versions du rôle disponibles sur Ansible Galaxy et GitHub Releases, par rapport au CIS Benchmark pour Ubuntu Linux 20.04 LTS.

1. Instructions d'installation/téléchargement :

Ce rôle est disponible sur Ansible Galaxy. Voici quelques méthodes pour installer/télécharger le rôle cis_ubuntu_2004 sur votre nœud Ansible Controller à partir d'Ansible Galaxy ou directement depuis le dépôt.

Sans fichier requirements.yml :

• Installer/télécharger la dernière version disponible (par défaut) :

  ansible-galaxy install darkwizard242.cis_ubuntu_2004
  

• Installer/télécharger une version de tag spécifique (en utilisant 3.2.0 comme exemple) :

  ansible-galaxy install darkwizard242.cis_ubuntu_2004,3.2.0
  

• Installer/télécharger une branche spécifique depuis le dépôt (en utilisant la branche master comme exemple, master sera toujours conforme à la version la plus récente du CIS Ubuntu 20.04 Benchmark) :

  ansible-galaxy install darkwizard242.cis_ubuntu_2004,master
  

• Installer/télécharger une branche spécifique depuis le dépôt (en utilisant la branche feature/cis_version_1.1.0 comme exemple, qui est conforme aux dernières mises à jour pour CIS Ubuntu 20.04 Benchmark Version v1.1.0) :

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

• Installer/télécharger une branche spécifique depuis le dépôt (en utilisant la branche feature/cis_version_1.0.0 comme exemple, qui est conforme aux dernières mises à jour pour CIS Ubuntu 20.04 Benchmark Version v1.0.0) :

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

Avec un fichier requirements.yml :

Ajoutez au fichier requirements.yml existant avec vos autres rôles ou créez-en un nouveau pour installer cis_ubuntu_2004.

• Dernière version directement depuis Ansible Galaxy.

  - name: darkwizard242.cis_ubuntu_2004
  

• Version spécifique directement depuis Ansible Galaxy.

  - name: darkwizard242.cis_ubuntu_2004
    version: 3.2.0
  

• Branche spécifique depuis le dépôt.

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

Téléchargement après ajout au requirements.yml :

ansible-galaxy install -r requirements.yml

REMARQUE : Installer un rôle comme mentionné ci-dessus ne fait que télécharger le rôle pour qu'il soit disponible pour usage dans vos playbooks Ansible. Vous pouvez lire les instructions d'installation/téléchargement des rôles ici.

2. Quelques considérations :

Les benchmarks concernant la partition de disque et leurs points de montage de Section 1 ne sont pas appliqués dans ce rôle. La raison est simplement que l'architecture de système et la disposition des disques vont probablement varier d'un individu à l'autre ou d'une organisation à l'autre. Je vous recommande de les appliquer vous-même. Voici une liste de ces benchmarks :

• 1.1.10 Assurer qu'une partition séparée existe pour /var (Automatisé)
• 1.1.11 Assurer qu'une partition séparée existe pour /var/tmp (Automatisé)
• 1.1.12 Assurer que la partition /var/tmp inclut l'option nodev (Automatisé)
• 1.1.13 Assurer que la partition /var/tmp inclut l'option nosuid (Automatisé)
• 1.1.14 Assurer que la partition /var/tmp inclut l'option noexec (Automatisé)
• 1.1.15 Assurer qu'une partition séparée existe pour /var/log (Automatisé)
• 1.1.16 Assurer qu'une partition séparée existe pour /var/log/audit (Automatisé)
• 1.1.17 Assurer qu'une partition séparée existe pour /home (Automatisé)
• 1.1.18 Assurer que la partition /home inclut l'option nodev (Automatisé)
• 1.1.19 Assurer que l'option nodev est définie sur les partitions de médias amovibles (Manuel)
• 1.1.20 Assurer que l'option nosuid est définie sur les partitions de médias amovibles (Manuel)
• 1.1.21 Assurer que l'option noexec est définie sur les partitions de médias amovibles (Manuel)

Les benchmarks suivants de Section 4 n'ont pas non plus été implémentés :

• 4.2.1.5 Assurer que rsyslog est configuré pour envoyer des journaux à un hôte de journaux distant (Automatisé)
• 4.2.1.6 Assurer que les messages rsyslog distants ne soient acceptés que sur des hôtes de journaux désignés. (Manuel)
• 4.3 Assurer que logrotate est configuré (Manuel)

3. Exigences

Aucune.

4. Variables de rôle

Les variables par défaut du rôle utilisées dans les tâches sont situées dans defaults/main/.

defaults/main/main.yml comprend des variables se référant à l'ensemble des sections CIS comme suit et des variables critiques comme celles mentionnées dans la section 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

Le but des variables mentionnées ci-dessus est d'indiquer que toutes les tâches liées à ces sections doivent être appliquées via le rôle cis_ubuntu_2004.

Les variables pour chaque section se trouvent dans leurs propres fichiers.

• Les variables de la section 1 sont dans defaults/main/section_01.yml
• Les variables de la section 2 sont dans defaults/main/section_02.yml
• Les variables de la section 3 sont dans defaults/main/section_03.yml
• Les variables de la section 4 sont dans defaults/main/section_04.yml
• Les variables de la section 5 sont dans defaults/main/section_05.yml
• Les variables de la section 6 sont dans defaults/main/section_06.yml

Les valeurs par défaut du rôle pour tout dans le rôle cis_ubuntu_2004 peuvent être remplacées en les renseignant dans un playbook ou toute autre méthode de priorité de variable.

• Variables importantes

Les benchmarks de durcissement CIS Ubuntu 20.04 nécessitent la suppression de nombreux services pouvant être exploités, ayant des vulnérabilités connues, et qui exposent la surface d'attaque ou devraient être désactivés si non nécessaires. Selon le benchmark, par défaut - tous ces services seront supprimés et la valeur de leurs variables a été définie sur false. Cependant, si vous avez toujours besoin de ces services pour une raison quelconque, veuillez changer leurs valeurs en true afin que, lors de l'application du rôle dans un playbook, les tâches du rôle pour supprimer ces services puissent être ignorées.

En plus de l'explication ci-dessus pour certaines variables, il existe également d'autres variables qui définissent si un service spécifique est souhaité sur le système ou non (par exemple, le serveur SSH), des paramètres pour la configuration de divers outils (par exemple, auditd) etc. Celles-ci peuvent aussi être remplacées dans un playbook.

# Réglez sur `true` si IPv6 est requis.
ubuntu_2004_cis_require_ipv6: false

# Réglez sur `true` si le sans fil est requis.
ubuntu_2004_cis_require_wireless: false

# Réglez sur `true` si le système doit agir comme un routeur.
ubuntu_2004_cis_require_router: false

# Réglez sur `false` si le serveur SSH n'est pas requis.
ubuntu_2004_cis_require_ssh_server: true

# Variable pour stocker des ciphers forts pour le serveur SSH.
ubuntu_2004_cis_require_ssh_ciphers: [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr

# Variable pour stocker de forts algorithmes MAC pour le serveur SSH.
ubuntu_2004_cis_require_ssh_macs: [email protected],[email protected],hmac-sha2-512,hmac-sha2-256

# Variable pour stocker des algorithmes d'échange de clés forts pour le serveur 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 pour stocker l'intervalle Alive Client en secondes pour le serveur SSH.
ubuntu_2004_cis_require_ssh_clientaliveinterval: '300'

# Variable pour stocker le nombre maximum de Client Alive Count pour le serveur SSH.
ubuntu_2004_cis_require_ssh_clientalivecountmax: '3'

# Variable pour stocker le temps de grâce de connexion en secondes pour le serveur SSH.
ubuntu_2004_cis_require_ssh_logingracetime: '60'

# Variable pour stocker les utilisateurs autorisés pour le serveur SSH.
ubuntu_2004_cis_require_ssh_allowusers: ubuntu vagrant

# Variable pour stocker les groupes autorisés pour le serveur SSH.
ubuntu_2004_cis_require_ssh_allowgroups: ubuntu vagrant

# Variable pour stocker les utilisateurs interdits pour le serveur SSH.
ubuntu_2004_cis_require_ssh_denyusers: bogus dummy

# Variable pour stocker les groupes interdits pour le serveur SSH.
ubuntu_2004_cis_require_ssh_denygroups: bogus dummy

# Variable pour stocker la longueur minimum et les classes de caractères pour la qualité des mots de passe de pam.
ubuntu_2004_cis_require_pam_pwquality:
  - key: 'minlen'
    value: '14'
  - key: 'minclass'
    value: '4'

# Variable pour stocker la valeur de PASS_MAX_DAYS pour l'expiration du mot de passe.
ubuntu_2004_cis_require_passmaxdays: '365'

# Variable pour stocker la valeur de PASS_MIN_DAYS pour le changement de mot de passe.
ubuntu_2004_cis_require_passmindays: '1'

# Variable pour stocker la valeur d'INACTIVE afin de définir la période d'inactivité par défaut du mot de passe à 30 jours.
ubuntu_2004_cis_require_passwarnage: '7'

# Variable pour stocker la valeur de PASS_WARN_AGE pour définir l'alerte d'expiration de mot de passe en nombre de jours.
ubuntu_2004_cis_require_passinactive: '30'

# Variable pour stocker la valeur du délai d'expiration du shell en secondes.
ubuntu_2004_cis_require_shell_timeout: '900'

# Variable pour stocker la valeur du nom de groupe qui sera requis pour l'utilisation de l'exécution su.
ubuntu_2004_cis_require_su_group: sugroup

# Variable pour stocker le fichier journal auquel la tâche manuelle 6.1.1 Audit système de permissions de fichiers se propage pour examen.
ubuntu_2004_cis_require_audit_system_file_permissions_logfile: /var/log/6_1_1_cis_audit_system.log

# peut être l'un des 'iptables', 'nftables' ou 'ufw'.
ubuntu_2004_cis_firewall: ufw

# SI 'ufw' est utilisé, le réglage sur 'yes' permet de configurer et d'autoriser un profil d'application UFW pour git.
ubuntu_2004_cis_section3_rule_3_5_1_7_ufw_require_git_profile: yes

# SI 'ufw' est utilisé, le réglage sur 'yes' permet de configurer et d'autoriser un profil d'application UFW pour HTTP.
ubuntu_2004_cis_section3_rule_3_5_1_7_ufw_require_http_profile: yes

# SI 'ufw' est utilisé, le réglage sur 'yes' permet de configurer et d'autoriser un profil d'application UFW pour HTTPS.
ubuntu_2004_cis_section3_rule_3_5_1_7_ufw_require_https_profile: yes

# SI 'ufw' est utilisé, le réglage sur 'true' refusera toutes les connexions entrantes par défaut. Fonctionne de la même manière que `ufw default deny incoming`. Réglez sur `false` si vous ne souhaitez pas appliquer cela.
ubuntu_2004_cis_section3_rule_ufw_default_deny_incoming: true

# SI 'ufw' est utilisé, le réglage sur 'true' refusera toutes les connexions sortantes par défaut. Fonctionne de la même manière que `ufw default deny outgoing`. Réglez sur `false` si vous ne souhaitez pas appliquer cela.
ubuntu_2004_cis_section3_rule_ufw_default_deny_outgoing: true

# SI 'ufw' est utilisé, le réglage sur 'true' refusera toutes les connexions routées par défaut. Fonctionne de la même manière que `ufw default deny routed`. Réglez sur `false` si vous ne souhaitez pas appliquer cela.
ubuntu_2004_cis_section3_rule_ufw_default_deny_routed: true

# SI 'nftables' est utilisé, régler sur 'true' refusera toutes les connexions d'entrée/forward/sortie par défaut, rendant le système injoignable. Réglez sur `false` si vous ne souhaitez pas appliquer cela ou perdre la connectivité.
ubuntu_2004_cis_section3_rule_3_5_2_8: true

# SI 'iptables' est utilisé, régler sur 'true' refusera toutes les connexions entrantes sur ipv4 par défaut, rendant le système injoignable. Réglez sur `false` si vous ne souhaitez pas appliquer cela ou perdre la connectivité.
ubuntu_2004_cis_section3_rule_iptables_ipv4_default_deny_input: true

# SI 'iptables' est utilisé, régler sur 'true' refusera toutes les connexions sortantes sur ipv4 par défaut, rendant le système injoignable. Réglez sur `false` si vous ne souhaitez pas appliquer cela ou perdre la connectivité.
ubuntu_2004_cis_section3_rule_iptables_ipv4_default_deny_output: true

# SI 'iptables' est utilisé, régler sur 'true' refusera toutes les connexions forward sur ipv4 par défaut, rendant le système injoignable. Réglez sur `false` si vous ne souhaitez pas appliquer cela ou perdre la connectivité.
ubuntu_2004_cis_section3_rule_iptables_ipv4_default_deny_forward: true

# SI 'iptables' est utilisé et ipv6 est activé, régler sur 'true' refusera toutes les connexions entrantes sur ipv4 par défaut, rendant le système injoignable. Réglez sur `false` si vous ne souhaitez pas appliquer cela ou perdre la connectivité.
ubuntu_2004_cis_section3_rule_iptables_ipv6_default_deny_input: true

# SI 'iptables' est utilisé et ipv6 est activé, régler sur 'true' refusera toutes les connexions sortantes sur ipv4 par défaut, rendant le système injoignable. Réglez sur `false` si vous ne souhaitez pas appliquer cela ou perdre la connectivité.
ubuntu_2004_cis_section3_rule_iptables_ipv6_default_deny_output: true

# SI 'iptables' est utilisé et ipv6 est activé, régler sur 'true' refusera toutes les connexions forward sur ipv4 par défaut, rendant le système injoignable. Réglez sur `false` si vous ne souhaitez pas appliquer cela ou perdre la connectivité.
ubuntu_2004_cis_section3_rule_iptables_ipv6_default_deny_forward: true

# peut être l'un de 'ntp', 'chrony', ou 'systemd-timesyncd'.
ubuntu_2004_cis_time_synchronization: systemd-timesyncd

# Limite de backlog d'audit pour stocker suffisamment d'enregistrements au démarrage.
ubuntu_2004_cis_auditd_backloglimit: '8192'

# Taille du fichier journal pour les journaux auditd. Réglez comme approprié.
ubuntu_2004_cis_auditd_maxlogfile: '25'

# Action à entreprendre lorsque les journaux auditd ont atteint la taille maximum. Réglez comme approprié.
ubuntu_2004_cis_auditd_maxlogfileaction: keep_logs

# Action à entreprendre pour un espace faible pour auditd. Réglez comme approprié.
ubuntu_2004_cis_auditd_spaceleftaction: email

# À qui envoyer un e-mail pour auditd. Réglez comme approprié.
ubuntu_2004_cis_auditd_actionmailacct: root

# Option pour arrêter lorsque les journaux d'audit sont pleins. Réglez comme approprié.
ubuntu_2004_cis_auditd_adminspaceleftaction: halt

# Utilisateurs autorisés à programmer des cronjobs.
ubuntu_2004_cis_cron_allow_users:
  - root
  - ubuntu

# Utilisateurs autorisés à utiliser 'at' pour programmer des tâches.
ubuntu_2004_cis_at_allow_users:
  - root
  - ubuntu

# Réglez sur `true` si le système X Windows est requis.
ubuntu_2004_cis_require_xwindows_system: false

# Réglez sur `true` si CUPS est requis.
ubuntu_2004_cis_require_cups: false

# Réglez sur `true` si un serveur DHCP est requis.
ubuntu_2004_cis_require_dhcp_server: false

# Réglez sur `true` si un serveur LDAP est requis.
ubuntu_2004_cis_require_ldap_server: false

# Réglez sur `true` si un serveur NFS est requis.
ubuntu_2004_cis_require_nfs_server: false

# Réglez sur `true` si un serveur DNS est requis.
ubuntu_2004_cis_require_dns_server: false

# Réglez sur `true` si un serveur FTP est requis.
ubuntu_2004_cis_require_ftp_server: false

# Réglez sur `true` si un serveur HTTP (apache2) est requis.
ubuntu_2004_cis_require_http_server: false

# Réglez sur `true` si les serveurs IMAP et POP3 sont requis.
ubuntu_2004_cis_require_imap_pop3_server: false

# Réglez sur `true` si le démon Samba est requis.
ubuntu_2004_cis_require_samba_server: false

# Réglez sur `true` si le serveur Squid est requis.
ubuntu_2004_cis_require_squid_server: false

# Réglez sur `true` si le serveur SNMP est requis.
ubuntu_2004_cis_require_snmp_server: false

# Pour éviter de configurer postfix pour agir en mode local uniquement. Définissez comme `false` si postfix doit agir en mode local uniquement.
ubuntu_2004_cis_require_mail_server: true

# Réglez sur `true` si RSYNC est requis.
ubuntu_2004_cis_require_rsyncd_server: false

# Réglez sur `true` si le serveur NIS est requis.
ubuntu_2004_cis_require_nis_server: false

# Réglez sur `true` si le client NIS est requis.
ubuntu_2004_cis_require_nis_client: false

# Réglez sur `true` si le client RSH est requis.
ubuntu_2004_cis_require_rsh_client: false

# Réglez sur `true` si le client TALK est requis.
ubuntu_2004_cis_require_talk_client: false

# Réglez sur `true` si le client TELNET est requis.
ubuntu_2004_cis_require_telnet_client: false

# Réglez sur `true` si le client LDAP est requis.
ubuntu_2004_cis_require_ldap_client: false

# Réglez sur `true` si le client RPCBIND est requis.
ubuntu_2004_cis_require_rpcbind_client: false

5. Dépendances

Aucune

6. Exemples de playbooks :

Des exemples de playbooks sont fournis dans le dossier playbook-examples. Il contient des playbooks avec des valeurs par défaut et des exigences personnalisées.

REMARQUE : Étant donné que certains des contrôles CIS concernant le réseau peuvent casser le système et laisser l'utilisateur incapable de se reconnecter au système, je vous recommande d'appliquer ou d'expérimenter en utilisant le playbook playbook-examples/playbook_with_custom_firewall_changes.yml en premier lieu. Modifiez le type de connexion et les hôtes dans le playbook pour correspondre à vos besoins.

Application des exemples :

Si vous utilisez l'un des playbooks fournis dans le dossier playbook-examples, vous pouvez choisir l'un d'eux et exécuter la commande suivante pour les appliquer :

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

En supposant que vous créiez votre propre playbook personnalisé nommé myplaybook.yml, vous pouvez simplement l'exécuter avec la commande suivante.

ansible-playbook myplaybook.yml

Application des exemples en utilisant des tags :

Toutes les tâches du rôle ont des tags attribués en fonction de l'attribution de niveau CIS, du numéro de règle et du numéro de section. Par défaut, les contrôles de niveau 1 et 2 seront appliqués. Ainsi, si vous souhaitez effectuer des applications personnalisées pour les niveaux, les numéros de règles ou les sections - vous pouvez utiliser les exemples suivants :

Exemple pour appliquer uniquement les contrôles de niveau 1 :

ansible-playbook <nom-du-playbook-ici>.yml --tags "level_1"

Exemple pour appliquer uniquement les contrôles de niveau 2 :

ansible-playbook <nom-du-playbook-ici>.yml --tags "level_2"

Exemple pour appliquer les contrôles d'une section spécifique (par exemple, section 4 du benchmark CIS Ubuntu 20.04) :

ansible-playbook <nom-du-playbook-ici>.yml --tags "section4"

Exemple pour appliquer un contrôle spécifique (par exemple, contrôle 6.2.2 du benchmark CIS Ubuntu 20.04) :

ansible-playbook <nom-du-playbook-ici>.yml --tags "rule_6_2_2"

7. Développement local et CI/CD :

Pour le développement local du rôle cis_ubuntu_2004, veuillez effectuer les étapes suivantes :

• Forkez le dépôt.

• Clônez-le localement.

• Installez Vagrant sur votre machine. Les instructions d'installation sont disponibles ici ou si nécessaire, vous pouvez utiliser le rôle darkwizard242.vagrant pour l'installer - mais veuillez confirmer s'il supporte votre OS.

• Installez Virtualbox sur votre machine. Les instructions d'installation sont disponibles ici ou si nécessaire, vous pouvez utiliser le rôle darkwizard242.virtualbox pour l'installer - mais veuillez confirmer s'il supporte votre OS.

• Installez les modules requis en utilisant :

  # Pour installer des modules pip globalement lorsque vous exécutez en tant qu'utilisateur non-root.
  sudo -H python3 -m pip install -U molecule ansible-lint flake8 pytest-testinfra molecule-vagrant
  

  OU

  # Pour installer des modules pip localement dans le répertoire utilisateur lorsque vous exécutez en tant qu'utilisateur non-root.
  python3 -m pip install -U molecule ansible-lint flake8 pytest-testinfra molecule-vagrant
  

• Apportez des modifications et exécutez molecule test ou molecule converge.

La commande molecule test exécutera l'ensemble de la suite de tests configurée.

La commande molecule converge créera seulement l'instance vagrant et appliquera toutes les opérations définies dans le rôle.

Bien sûr, vous pouvez également simplement télécharger le code pour le rôle cis_ubuntu_2004, apporter des modifications et l'exécuter via ansible-playbook sur une machine de test si vous n'êtes pas familiarisé avec molecule.

Lors de la création d'une Pull Request – cela déclenchera automatiquement un build TravisCI ici. La configuration pour le build TravisCI est présente dans .travis.yml. Cela effectuera diverses tâches telles que :

• Cloner le code de la pull request.
• Mettre à jour le cache du dépôt.
• Installer les paquets pré-requis.
• Installer Vagrant et Virtualbox.
• Effectuer une vérification de la qualité du code SonarCloud pour l'ensemble du code du dépôt.
• Exécuter le test de molecule (ce qui provisionnera une boîte vagrant, appliquera le code du rôle et exécutera la suite de test TestInfra pour le rôle cis_ubuntu_2004).

8. Contribuer :

Les contributions sont les bienvenues. Les instructions pour contribuer sont mentionnées ici.

Inspiration

Inspiré par le grand travail réalisé par de nombreux membres de la communauté Ansible (Florian Utz et ansible-lockdown pour n'en nommer que quelques-uns parmi tant d'autres). Continuez de rock :metal:

Licence

MIT

Informations sur l'auteur

Ce rôle a été créé par Ali Muhammad.