RHEL 7 CIS

Configurer une machine RHEL/Centos 7 pour être conforme aux CIS

Basé sur CIS RedHat Enterprise Linux 7 Benchmark v4.0.0 - 21-12-2023

Recherche de soutien ?

Lockdown Enterprise

Soutien Ansible

Communauté

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

Précautions

Ce rôle va apporter 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 supporté ! Le rôle se terminera en mode vérification sans erreurs, mais ce n'est pas supporté et doit être utilisé avec prudence. Le rôle RHEL7-CIS-Audit ou un scanner de conformité devraient être utilisés pour le contrôle de conformité plutôt que le mode vérification.

Ce rôle a été développé sur une installation propre du système d'exploitation. Si vous l'implémentez 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 publication, veuillez pointer vers la branche principale et la version pertinente pour la norme CIS avec laquelle vous souhaitez travailler.

Correspondance avec un niveau de sécurité pour les CIS

Il est possible de ne faire fonctionner que les contrôles de niveau 1 ou de niveau 2 pour les CIS. Cela est géré à l'aide d'étiquettes :

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

Le contrôle trouvé dans les paramètres par défaut doit également refléter cela, car c'est ce contrôle qui teste ce qui se passe si vous utilisez le composant d'audit.

Provenant d'une version précédente

La sortie CIS contient toujours des changements. Il est fortement recommandé de revoir les nouvelles références et les variables disponibles. Cela a considérablement changé depuis la première sortie d'ansible-lockdown. Cela est maintenant compatible avec python3 s'il est trouvé comme 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 consultés dans le Changelog.

Audits (nouveau)

Cela peut être activé ou désactivé dans le fichier defaults/main.yml avec la variable rhel7cis_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 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 très légère (là où c'est possible) de la conformité de la configuration et des paramètres en cours.

Une nouvelle forme d'audit a été développée, en utilisant un petit binaire Go (12 Mo) appelé goss accompagné des configurations pertinentes à vérifier. Sans avoir besoin d'infrastructure ou d'autres outils. Cet audit ne vérifiera pas seulement que la configuration a le bon réglage, mais vise également à capturer si elle s'exécute avec cette configuration tout en essayant d'éliminer les faux positifs dans le processus.

Documentation

• Lire la documentation
• Prise en main
• Personnalisation des rôles
• Configuration par hôte
• Tirer le meilleur parti du rôle

Exigences

Générales :

• Connaissances de base d'Ansible, ci-dessous quelques liens vers la documentation Ansible pour vous aider à commencer si vous n'êtes pas familier avec Ansible :

  • Page principale de la documentation Ansible
  • Prendre en main Ansible
  • Guide utilisateur 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 d'Ansible/Tower, les paquets nécessaires installés et la configuration de l'infrastructure.

• Veuillez lire les tâches dans ce rôle pour comprendre ce que chaque contrôle fait. Certaines des tâches peuvent être perturbatrices et 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 :

• Environnement d'exécution Ansible/Tower (ce rôle est testé avec la version Ansible 2.9.1 et plus récente)
• Environnement d'exécution Ansible Python3
• python-def (doit être inclus dans RHEL/CentOS 7) - La première tâche met en place les prérequis (Tag pré-requis) pour python3 et python2 (le cas échéant)
  • libselinux-python
  • python3-rpm (paquet utilisé par py3 pour utiliser le paquet rpm)

Variables de rôle

Ce rôle est conçu pour que l'utilisateur final ne doive pas modifier les tâches lui-même. Toute personnalisation doit être effectuée 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 indiquant quel niveau, s'il est noté/non noté, à quel élément OS il se rapporte, s'il s'agit d'un correctif ou d'un audit, et le numéro de règle.

Voici un exemple de la section des étiquettes d'un contrôle dans ce rôle. Dans 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. Inversement, vous pouvez exécuter uniquement les contrôles étiquetés avec services.

      tags:
      - level1-workstation
      - level1-server
      - automatisé
      - 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 est effectué dans votre propre branche individuelle. Assurez-vous de signer et de signer tous les commits que vous souhaitez fusionner.
• Toutes les demandes de tirage de la communauté 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, ont été signés et ont passé un test fonctionnel avant d'être approuvés.
• Une fois vos modifications fusionnées et un examen plus approfondi terminé, un membre autorisé fusionnera vos modifications dans la branche principale pour une nouvelle version.

Tests de pipeline

utilise :

• ansible-core 2.12
• collections ansible - tire la dernière version basée sur le fichier des exigences
• exécute l'audit en utilisant la branche de développement
• Il s'agit d'un test automatisé qui se produit sur des demandes de tirage vers le développement.

Tests locaux

• 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

• 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 énorme merci et des remerciements aux auteurs et mainteneurs originaux.

Josh Springer, Daniel Shepherd, Bas Meijeri, James Cassell, Mike Renfro, DFed, George Nalen, Mark Bolwell