RHEL 8 CIS

Configurer une machine RHEL/Rocky/AlmaLinux 8 pour être conforme au CIS

Basé sur le CIS RedHat Enterprise Linux 8 Benchmark v3.0.0 - 11-10-2023

Besoin d'aide ?

Lockdown Enterprise

Soutien Ansible

Communauté

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

Avertissement(s)

Ce rôle va apporter des modifications au système qui pourraient avoir des conséquences imprévues. Ce n'est pas un outil d'audit, mais plutôt un outil de remédiation à utiliser après avoir effectué un audit.

• Les tests sont la chose la plus importante que vous puissiez faire.

• 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 pris en charge et doit être utilisé avec prudence. Le rôle RHEL8-CIS-Audit ou un scanner de conformité devrait être utilisé pour vérifier la conformité plutôt qu'en mode vérification.

• Ce rôle a été développé sur une installation propre du système d'exploitation. Si vous l'appliquez à un système existant, merci de vérifier ce rôle pour tout changement spécifique au site qui pourrait être nécessaire.

• Pour utiliser la version de publication, veuillez pointer vers la branche principale et la version/tag pertinente pour le benchmark CIS avec lequel vous souhaitez travailler.

• Si vous passez d'une version majeure à une autre, par exemple de v2.0.0 à v3.0.0, il y a des changements significatifs dans les benchmarks et les contrôles, il est recommandé de commencer comme un nouveau standard plutôt que de mettre à jour.

• Les conteneurs font référence à vars/is_container.yml, c'est un exemple qui doit être mis à jour selon vos besoins.

• Avons-nous mentionné les tests ?

Correspondre à 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 en utilisant des étiquettes :

• level1_server
• level1_workstation
• level2_server
• level2_workstation

Le contrôle trouvé dans les paramètres par défaut doit également le refléter, car cela contrôle les tests effectués si vous utilisez le composant d'audit.

Passer d'une version précédente

Les versions du CIS contiennent toujours des modifications. Il est fortement recommandé de consulter les nouvelles références et variables disponibles. Ces dernières ont changé de manière significative depuis la première version d'ansible-lockdown. Ceci est maintenant compatible avec python3 s'il est trouvé comme l'interpréteur par défaut. Cela nécessite des prérequis qui configurent le système en conséquence.

D'autres détails peuvent être consultés dans le Journal des modifications

Audit (nouveau)

Cela peut être activé ou désactivé dans le fichier defaults/main.yml avec la variable rhel8cis_run_audit. La valeur est fausse par défaut, veuillez consulter le wiki pour plus de détails. Le fichier par défaut remplit également les vérifications goss pour vérifier uniquement les contrôles qui ont été activés dans le rôle ansible.

C'est une vérification beaucoup plus rapide et légère, vérifiant (là où c'est possible) la conformité de la configuration et les paramètres en cours d'exécution.

Une nouvelle forme d'audit a été développée, en utilisant un petit binaire go (12 Mo) appelé goss avec les configurations pertinentes pour vérifier. Sans avoir besoin d'infrastructure ou d'autres outils. Cet audit ne vérifiera pas seulement que la configuration a les bons paramètres, mais vise également à capturer s'il fonctionne selon cette configuration tout en essayant d'éliminer les faux positifs dans le processus.

Voir RHEL8-CIS-Audit.

Exemple de résumé d'audit

Ceci est basé sur une image vagrant avec les sélections activées, par exemple, sans interface graphique ni pare-feu. Remarque : Plus de tests sont effectués lors de l'audit pendant que nous vérifions l'état de la configuration et de l'exécution.

ok: [default] => {
    "msg": [
        "Les résultats avant remédiation sont : ['Durée totale : 5.454s', 'Compte : 338, Échoué : 47, Sauté : 5'].",
        "Les résultats après remédiation sont : ['Durée totale : 5.007s', 'Compte : 338, Échoué : 46, Sauté : 5'].",
        "La répartition complète peut être trouvée dans /var/tmp",
        ""
    ]
}

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

Documentation

• Lire la documentation
• Pour commencer
• Personnaliser les rôles
• Configuration par hôte
• Profiter au maximum du rôle

Exigences

Général :

• Connaissance de base d'Ansible, voici quelques liens vers la documentation d'Ansible pour vous aider à commencer si vous n'êtes pas familier avec Ansible

  • Page principale de la documentation Ansible
  • Guide de démarrage Ansible
  • Guide de l'utilisateur de Tower
  • Informations sur la communauté Ansible

• Ansible et/ou Tower fonctionnels installés, configurés et en cours d'exécution. Cela inclut toutes les configurations de base Ansible/Tower, les paquets nécessaires installés et la configuration de l'infrastructure.

• Veuillez lire les tâches de ce rôle pour comprendre ce que chaque contrôle effectue. Certaines tâches peuvent être disruptives et avoir des conséquences imprévues dans un système de production en direct. Familiarisez-vous également avec les variables dans le fichier defaults/main.yml.

Dépendances techniques :

RHEL/AlmaLinux/Rocky/Oracle 8 - D'autres versions ne sont pas prises en charge.

• AlmaLinux/Rocky a été testé sur 8.8 (l'activation de crypto (sections 1.10 & 1.11) empêche la mise à jour ou l'installation : 1er juillet 2021)
• Accès pour télécharger ou ajouter le binaire goss et le contenu au système si l'audit est utilisé (d'autres options sont disponibles sur la façon d'apporter le contenu au système.)
• Python3.8
• Ansible 2.11+
• python-def (devrait être inclus dans RHEL 8)
• libselinux-python

Variables de rôle

Ce rôle est conçu de manière à ce que l'utilisateur final n'ait pas besoin de modifier les tâches elles-mêmes. Toute personnalisation doit se faire via le fichier defaults/main.yml ou avec des variables supplémentaires dans le projet, le travail, le flux de travail, etc.

Étiquettes

Il existe de nombreuses étiquettes disponibles pour une précision de contrôle accrue. Chaque contrôle a son propre ensemble d'étiquettes notant quel niveau, s'il est noté / non noté, quel élément OS il concerne, s'il s'agit d'un correctif ou d'un audit, et le numéro de règle.

Voici un exemple de la section d'étiquette d'un contrôle au sein de ce rôle. En utilisant cet exemple, si vous définissez votre exécution pour ignorer tous les contrôles avec l'étiquette services, cette tâche sera ignorée. À l'inverse, vous ne pouvez exécuter que les contrôles étiquetés avec services.

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

Contribution communautaire

Nous encourageons la communauté à contribuer à ce rôle. Merci de lire les règles ci-dessous.

• Votre travail se fait dans votre propre branche individuelle. Assurez-vous de signer et de signer tous les commits que vous avez l'intention de fusionner avec GPG.
• Tous les Pull Requests communautaires sont fusionnées dans la branche de développement.
• Les Pull Requests vers le développement confirmeront que vos commits ont une signature GPG, sont signés et ont passé un test fonctionnel avant d'être approuvés.
• Une fois vos changements fusionnés et après un examen plus détaillé, un membre autorisé fusionnera vos modifications dans la branche principale pour une nouvelle version.

Problèmes connus

cloud0init - en raison d'un bogue, cela ne fonctionnera plus si noexec est ajouté à /var. rhel8cis_rule_1_1_3_3

bug 1839899

Les dépôts Almalinux BaseOS, EPEL et de nombreux fournisseurs cloud ne permettent pas repo_gpgcheck sur la règle_1.2.3, cela causera des problèmes pendant l'exécution du playbook à moins qu'une solution de contournement ne soit trouvée.

Tests de pipeline

utilise :

• ansible-core 2.12
• collections Ansible - extrait la dernière version basée sur le fichier de requirements
• effectue l'audit en utilisant la branche de développement
• C'est un test automatisé qui se produit lors des pull requests vers le développement.

Tests locaux

Molecule peut être utilisé pour travailler sur ce rôle et tester dans des scénarios distincts.

exemples

molecule test -s default
molecule converge -s wsl -- --check
molecule verify -s localhost

les tests locaux utilisent :

• ansible 2.13.3
• molecule 4.0.1
• molecule-docker 2.0.0
• molecule-podman 2.0.2
• molecule-vagrant 1.0.0
• molecule-azure 0.5.0

Extras supplémentaires

• pre-commit peut être testé et exécuté depuis le répertoire

pre-commit run

Crédits et remerciements

Un grand merci à la fantastique communauté et à tous ses membres. Cela inclut un immense merci et des crédits aux auteurs et aux mainteneurs originaux. Josh Springer, Daniel Shepherd, Bas Meijeri, James Cassell, Mike Renfro, DFed, George Nalen, Mark Bolwell