HarryHarcourt.Ansible-RHEL7-CIS-Benchmarks

Tous les crédits vont à anthcourtney pour le cadre original trouvé ici : https://github.com/anthcourtney/ansible-role-cis-amazon-linux

Cette mise en œuvre a été convertie pour Red Hat Enterprise Linux 7.X (testée de 7.1 à 7.7) et CentOS 7.4 (testé de 7.4 à 7.7, notez que les versions de CentOS inférieures à 7.4 peuvent rencontrer des problèmes avec SSH).

Cette mise en œuvre a été rendue idempotente à plusieurs endroits et continue de l'être.

Cette mise en œuvre permet d'activer et de configurer certains services.

Le Benchmark CIS RHEL Linux. https://benchmarks.cisecurity.org/tools2/linux/CIS_Red_Hat_Enterprise_Linux_7_Benchmark_v2.1.1.pdf

Ce rôle a été développé et testé sur Red Hat Linux 7.1, 7.2, 7.3, 7.4, 7.5, 7.6 et 7.7 en utilisant des AMI AWS standards. Ce rôle a également été développé et testé sur CentOS 7.4 en utilisant des AMI AWS standards.

Pourquoi utiliser ce rôle ?

Si vous tentez d'obtenir une conformité avec une norme de sécurité reconnue, comme PCI DSS, APRA ou ISO 27001, vous devez démontrer que vous avez appliqué des normes de durcissement documentées à tous les systèmes concernés par l'évaluation.

Si vous utilisez Red Hat Linux, ce rôle essaie de fournir un élément de la solution pour la conformité.

Attention !

Si vous envisagez d'appliquer ce rôle à des serveurs, vous devriez avoir une familiarité de base avec le Benchmark CIS (ou d'autres benchmarks similaires) et comprendre l'impact que cela peut avoir sur un système.

Prenez le temps de vous familiariser avec la norme et avec les valeurs par défaut configurables, et excluez les éléments avant de les appliquer à un système.

Voici des exemples d'éléments qui devraient être immédiatement considérés pour exclusion (ou au moins, pour modification des valeurs par défaut associées) :

3.4.2 et 3.4.3, qui par défaut limitent effectivement l'accès à l'hôte (y compris via ssh) à localhost uniquement.

Exemple de Playbook

Un exemple de playbook utilisant ce rôle est le suivant :

---

- hosts: localhost
  connection: local
  gather_facts: true
  become: yes

  roles:
    - Ansible-RHEL7-CIS-Benchmarks

Un exemple plus avancé, qui inclut des modifications des valeurs par défaut utilisées, ainsi que l'exclusion de certains éléments du benchmark jugés inutiles dans un environnement fictif, est le suivant :

---

- hosts: localhost
  connection: local
  gather_facts: true
  become: yes

  vars:
    cis_level_1_exclusions:
      - 5.4.4
      - 3.4.2
      - 3.4.3
      - 6.2.13   
    cis_pass_max_days: 45
    cis_umask_default: 002
 
  roles:
    - Ansible-RHEL7-CIS-Benchmarks

Notez que l'utilisation de become: yes est nécessaire car 99 % des tâches nécessitent un accès privilégié pour s'exécuter.

Variables de Rôle

Voir defaults/main.yml pour les variables qui peuvent être remplacées selon les préférences.

Options

Des balises (et leurs combinaisons) peuvent être utilisées pour exécuter un niveau particulier de la norme CIS, une section ou une recommandation individuelle. Par exemple :

Exécuter uniquement les tâches de Niveau 1

ansible-playbook playbook.yml -t level-1

Exécuter uniquement les tâches de la Section 3

ansible-playbook playbook.yml -t section-3

Exécuter les tâches 1.3.1 et 2.2.10 uniquement

ansible-playbook playbook.yml -t 1.3.1,2.2.10

Exécuter uniquement les tâches scorées

ansible-playbook playbook.yml -t scored

Limitations

Pour le moment, seuls les éléments de Niveau 1 du benchmark sont implémentés. Les éléments de Niveau 2 seront ajoutés dès que possible.

Les vérifications suivantes n'ont pas été implémentées :

3.6.2. Les règles de pare-feu sont spécifiques à l'environnement.
3.6.3. Les règles de pare-feu sont spécifiques à l'environnement.
3.6.4. Les règles de pare-feu sont spécifiques à l'environnement.
3.6.5. Les règles de pare-feu sont spécifiques à l'environnement.
4.2.1.2. La détermination de ce qui doit être enregistré et la destination des messages est spécifique à l'environnement.
4.2.2.2. La détermination de ce qui doit être enregistré et la destination des messages est spécifique à l'environnement.
4.2.2.3. L'édition en ligne du fichier de configuration syslog-ng est considérée comme trop imprécise et est mieux résolue par un fichier de configuration fourni qui traite cette exigence et d'autres exigences connexes.
4.2.2.4. L'édition en ligne du fichier de configuration syslog-ng est considérée comme trop imprécise et est mieux résolue par un fichier de configuration fourni qui traite cette exigence et d'autres exigences connexes.
4.2.2.5. L'édition en ligne du fichier de configuration syslog-ng est considérée comme trop imprécise et est mieux résolue par un fichier de configuration fourni qui traite cette exigence et d'autres exigences connexes.
4.3. La configuration de logrotate est spécifique au site.
5.3.2. L'édition multi-lignes des fichiers de configuration pam est considérée comme trop imprécise et dangereuse, et est mieux résolue par un fichier de configuration fourni qui traite cette exigence et d'autres exigences connexes.
5.3.3. L'édition multi-lignes des fichiers de configuration pam est considérée comme trop imprécise et dangereuse, et est mieux résolue par un fichier de configuration fourni qui traite cette exigence et d'autres exigences connexes.

Compatibilité

Ce rôle est compatible avec les versions suivantes d'ansible :

2.0.2
2.1.3
2.2.0
2.3.0
2.7.0
2.8.x
2.9.x

Ce rôle n'a pas été testé sur d'autres versions d'ansible.

Tests

Les processus de test suivants sont appliqués par le développeur de ce rôle :

La syntaxe du rôle est vérifiée. Voir make syntax.
ansible-review est exécuté contre le rôle et tous les avertissements jugés appropriés sont corrigés. Voir make review.
Le rôle est appliqué à un conteneur docker en utilisant à la fois ansible v2.1.3 et ansible v2.2. voir make test.

Les tests suivants ont été signalés mais ne sont pas encore mis en œuvre :

Test d'application du rôle contre l'image Vagrant mvbcoding/awslinux, en utilisant le provisionneur ansible.

Licence

NOTE : Il y a eu une certaine confusion sur la licence à utiliser pour ce rôle Ansible, la source de base de ce rôle d'Anthony Courtney n'avait pas de fichier de licence, cependant, le meta/main.yml mentionnait MIT mais le README (ci-dessous) mentionnait BSD. N'ayant pas eu de retour d'Anthony (à travers l'ouverture d'un problème concernant la source originale et en contactant Anthony via LinkedIn), j'ai décidé d'adopter la licence MIT pour ce rôle.

MIT.