RHEL 9 CIS

Configurer une machine RHEL 9 pour être conforme au CIS

Basé sur le CIS RedHat Enterprise Linux 9 Benchmark v1.0.0 - 30-11-2022

Besoin de soutien ?

Lockdown Enterprise

Support Ansible

Communauté

Rejoignez-nous sur notre serveur Discord pour poser des questions, discuter des fonctionnalités ou simplement chatter avec d'autres utilisateurs d'Ansible-Lockdown.

Contribuer

Les problèmes et les demandes de tirage sont les bienvenus. Veuillez vous assurer que tous les commits sont signés et signés par gpg. Référez-vous au Guide de contribution

Précautions

Ce rôle fera des modifications au système qui peuvent avoir des conséquences inattendues. Ce n'est pas un outil d'audit mais plutôt un outil de remédiation à utiliser après un audit.

Le mode vérification n'est pas pris en charge ! Le rôle se terminera en mode vérification sans erreurs, mais il n'est pas supporté et doit être utilisé avec prudence. Le rôle RHEL8-CIS-Audit ou un scanner de conformité doit être utilisé pour vérifier la conformité au lieu du mode vérification.

Ce rôle a été développé sur une installation propre du système d'exploitation. Si vous l'appliquez sur un système existant, veuillez revoir ce rôle pour toute modification spécifique au site qui pourrait être nécessaire.

Pour utiliser la version de release, veuillez vous référer à la branche main et à la release pertinente pour le benchmark cis avec lequel vous souhaitez travailler.

Correspondance d'un niveau de sécurité pour le CIS

Il est possible de n'exécuter que les contrôles de niveau 1 ou de niveau 2 pour le CIS. Cela se gère via des tags :

• level1-server
• level1-workstation
• level2-server
• level2-workstation

Le contrôle trouvé dans le defaults principal doit également le refléter, car ce contrôle est le test effectué si vous utilisez le composant d'audit.

Provenant d'une version précédente

La version CIS contient toujours des changements, il est donc fortement recommandé de revoir les nouvelles références et les variables disponibles. Cela a changé de manière significative depuis la première release d'ansible-lockdown. C'est maintenant compatible avec python3 si ce dernier est trouvé comme l'interpréteur par défaut. Cela vient avec des prérequis qui configurent le système en conséquence.

Des détails supplémentaires peuvent être vus dans le Changelog

Audit (nouveau)

Ceci peut être activé ou désactivé dans le fichier defaults/main.yml avec les variables setup_audit et run_audit. La valeur est false par défaut. Veuillez vous référer au wiki pour plus de détails. Le fichier par défaut remplit également les vérifications goss pour ne contrôler que les contrôles qui ont été activés dans le rôle ansible.

Ceci est un contrôle de conformité de configuration et de paramètres en direct/en cours d'exécution, plus rapide et très léger (là où possible).

Une nouvelle forme d'audit a été développée en utilisant un petit binaire go (12 Mo) appelé goss ainsi que les configurations nécessaires pour vérifier sans avoir besoin d'infrastructure ou d'autres outils. Cet audit vérifiera non seulement que la configuration a les bons paramètres, mais vise également à capturer si elle fonctionne avec cette configuration et à essayer d'éliminer les faux positifs dans le processus.

Référez-vous à RHEL9-CIS-Audit.

Documentation

• Lire la documentation
• Commencer
• Personnaliser les rôles
• Configuration par hôte
• Tirer le meilleur parti du rôle

Exigences

RHEL 9 Almalinux 9 Rocky 9 OracleLinux 9

• Accès pour télécharger ou ajouter le binaire goss et son contenu au système si vous utilisez l'audit (d'autres options sont disponibles pour obtenir le contenu sur le système).

CentOS stream - bien que cela fonctionne généralement, ce n'est pas supporté et nécessite le paramètre suivant

os_check: false

Général :

• Connaissance de base d'Ansible, ci-dessous quelques liens vers la documentation d'Ansible pour vous aider à démarrer si vous ne connaissez pas Ansible

  • Page principale de documentation Ansible
  • Ansible guide d'introduction
  • Guide de l'utilisateur Ansible Tower
  • Infos de la communauté Ansible

• Ansible et/ou Tower fonctionnant, configurés et opérationnels. Cela comprend toutes les configurations de base requises d'Ansible/Tower, les packages nécessaires installés et l'infrastructure mise en place.

• Veuillez parcourir les tâches de ce rôle pour comprendre ce que chaque contrôle fait. Certaines tâches sont perturbatrices et peuvent avoir des conséquences inattendues dans un système de production en direct. Familiarisez-vous également avec les variables dans le fichier defaults/main.yml.

Dépendances techniques :

• Python3
• Ansible 2.10+
• python-def (devrait être inclus dans RHEL 9)
• libselinux-python
• packages pip
  • jmespath
• collections trouvées dans collections/requirements.yml

pre-commit est disponible si installé sur votre hôte pour les tests de demande de tirage.

Variables de rôle

Ce rôle est conçu pour que l'utilisateur final n'ait pas à modifier les tâches lui-même. Toute personnalisation doit se faire en remplaçant les variables nécessaires telles que trouvées dans le fichier defaults/main.yml. Par exemple, en utilisant l'inventaire, group_vars, extra_vars

Tags

Il existe de nombreux tags disponibles pour une meilleure précision de contrôle. Chaque contrôle a son propre ensemble de tags indiquant son niveau, s'il est noté/non noté, à quel élément du système d'exploitation il se rapporte, si c'est un patch ou un audit, et le numéro de la règle.

Voici un exemple de la section des tags d'un contrôle dans ce rôle. En utilisant cet exemple, si vous définissez votre exécution pour ignorer tous les contrôles avec le tag services, cette tâche sera ignorée. L'opposé peut également se produire, où vous n'exécutez que les contrôles étiquetés comme services.

      tags:
      - level1-server
      - level1-workstation
      - scored
      - avahi
      - services
      - patch
      - rule_2.2.4

Contribution de la communauté

Nous encourageons vous (la communauté) à contribuer à ce rôle. Veuillez lire les règles ci-dessous.

• Votre travail s'effectue dans votre propre branche individuelle. Veillez à signer et à signer tous les commits que vous souhaitez fusionner avec GPG.
• Toutes les demandes de tirage communautaires sont intégrées dans la branche de développement.
• Les demandes de tirage dans le développement confirmeront que vos commits ont une signature GPG, sont signés et qu'un test fonctionnel a été effectué avant d'être approuvés.
• Une fois que vos modifications sont fusionnées et qu'un examen plus détaillé est réalisé, un membre autorisé fusionnera vos changements dans la branche principale pour une nouvelle version.

Problèmes connus

CIS 1.2.4 - le repo_gpgcheck n'est pas réalisé pour les hôtes RedHat car les dépôts par défaut n'ont pas cette fonction. Cela affecte également EPEL (non couvert par var). - Rocky et Alma ne sont pas affectés. Variable utilisée pour désactiver. rhel9cis_rhel_default_repo: true # à définir sur false si vous utilisez un dépôt qui a cette capacité

Test de la pipeline

utilise :

• ansible-core 2.12
• collections Ansible - tire dans la dernière version basée sur le fichier des exigences
• Exécute l'audit en utilisant la branche de développement
• Exécute la configuration pré-commit sur la PR pour s'assurer que tout est en place comme prévu.
• Ce test automatisé se produit sur les demandes de tirage dans le développement

Test local

• 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 ajoutés

• makefile - ceci est là uniquement à des fins de test et d'installation initiale.
• pre-commit peut être testé et peut être exécuté à partir du répertoire

pre-commit run

Crédits et remerciements

Basé sur un concept original de Sam Doran

Un grand merci à la fantastique communauté et à tous ses membres.

Cela inclut un énorme merci et un crédit aux auteurs et mainteneurs d'origine.

Mark Bolwell, George Nalen, Steve Williams, Fred Witty