UBUNTU18 CIS

Configurer une machine Ubuntu18 pour être conforme aux CIS

Basé sur le Benchmark CIS Ubuntu1804 v2.1.0

Besoin de soutien ?

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 apportera des modifications au système qui peuvent 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 un audit.

Le mode Vérification n'est pas supporté ! Le rôle se terminera en mode vérification sans erreurs, mais il n'est pas supporté et doit être utilisé avec précaution. Le rôle UBUNTU18-CIS-Audit ou un scanner de conformité doivent être utilisés 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 à un système existant, veuillez examiner ce rôle pour connaître les modifications spécifiques au site qui pourraient être nécessaires.

Pour utiliser la version de publication, veuillez pointer vers la branche principale et la publication pertinente du benchmark CIS avec laquelle vous souhaitez travailler.

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

Il est possible de faire fonctionner uniquement les contrôles de niveau 1 ou de niveau 2 pour le CIS. Ceci 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 cela contrôle les tests qui ont lieu si vous utilisez le composant d'audit.

Passer d'une version précédente

Les versions CIS contiennent toujours des changements, il est fortement recommandé de consulter les nouvelles références et les variables disponibles. Cela a changé de manière significative depuis la première publication d'ansible-lockdown. C'est maintenant compatible avec python3 s'il est trouvé comme l'interpréteur par défaut. Cela vient avec des prérequis qu'il configure sur 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 run_audit. La valeur est fausse par défaut, veuillez vous référer à la wiki pour plus de détails. Le fichier par défaut remplit également les vérifications goss pour ne vérifier que les contrôles qui ont été activés dans le rôle ansible.

C'est une vérification très rapide et légère (lorsque c'est possible) de la conformité de la configuration et des 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 ainsi que les configurations pertinentes à vérifier. Sans besoin d'infrastructure ou d'autres outils. Cet audit vérifiera non seulement si la configuration a les bons paramètres, mais vise également à capturer si elle fonctionne avec cette configuration en essayant d'éliminer les faux positifs dans le processus.

Consultez UBUNTU18-CIS-Audit.

Exemple de résumé d'audit

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

ok: [default] => {
    "msg": [
        "Les résultats de pré-remédiation sont : ['Durée totale : 5.454s', 'Nombre : 338, Échoué : 47, Ignoré : 5'].",
        "Les résultats de post-remédiation sont : ['Durée totale : 5.007s', 'Nombre : 338, Échoué : 46, Ignoré : 5'].",
        "L'analyse complète peut être trouvée dans /var/tmp",
        ""
    ]
}

RAPPORT DE JEU *******************************************************************************************************************************************
default                    : ok=270  changed=23   unreachable=0    failed=0    skipped=140  rescued=0    ignored=0

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éral :

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

  • Page principale de documentation d'Ansible
  • Prise en main Ansible
  • Guide de l'utilisateur de Tower
  • Info 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 l'infrastructure mise en place.

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

• Accès pour télécharger ou ajouter le binaire goss et son contenu sur le système si vous utilisez l'audit (d'autres options sont disponibles pour envoyer le contenu au système.)
• Python3
• Ansible 2.10.1+
• python-def
• libselinux-python

Variables du rôle

Ce rôle est conçu de sorte que l'utilisateur final n'ait 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 son niveau, s'il est noté ou non, quel élément du système d'exploitation 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 des étiquettes 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 l'étiquette services, cette tâche sera ignorée. L'inverse peut également se produire si vous exécutez uniquement les contrôles étiquetés avec 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 est effectué dans votre propre branche individuelle. Assurez-vous de signer et de signer GPG tous les commits que vous avez l'intention de fusionner.
• Toutes les demandes de tirage de la communauté sont fusionné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 vos modifications fusionnées et un examen plus approfondi effectué, 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. ubtu18cis_rule_1_1_3_3

bogue 1839899

Test de pipeline

utilise :

• ansible-core 2.16
• collections ansible - tire la dernière version en fonction du 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 les demandes de tirage vers le développement.

Extras ajoutés

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

pre-commit run