Rôle Ansible : Sécurité (Bases)

Tout d'abord, un avertissement MAJEUR : la sécurité de vos serveurs est de VOTRE responsabilité. Si vous pensez qu'il suffit d'inclure ce rôle et d'ajouter un pare-feu pour sécuriser un serveur, vous vous trompez. Renseignez-vous sur la sécurité Linux, réseau et applicative, et sachez que peu importe vos connaissances, vous pouvez toujours rendre chaque partie de votre infrastructure plus sûre.

Cela dit, ce rôle effectue quelques configurations de sécurité de base sur les systèmes Linux basés sur RedHat et Debian. Il tente de :

• Installer un logiciel pour surveiller les accès SSH indésirables (fail2ban)
• Configurer SSH pour être plus sécurisé (désactivation de la connexion root, exigence d'authentification par clé, et possibilité de définir un port SSH personnalisé)
• Mettre en place des mises à jour automatiques (si configuré ainsi)

Il y a quelques autres choses que vous pouvez ou non vouloir faire (qui ne sont pas incluses dans ce rôle) pour garantir que vos serveurs soient plus sécurisés, telles que :

• Utiliser logwatch ou un serveur de journalisation centralisé pour analyser et surveiller les fichiers journaux
• Configurer en toute sécurité les comptes utilisateurs et les clés SSH (ce rôle suppose que vous n'utilisez pas l'authentification par mot de passe ou que vous ne vous connectez pas en tant que root)
• Avoir un pare-feu bien configuré (regardez le rôle geerlingguy.firewall sur Ansible Galaxy pour un exemple flexible)

Encore une fois : la sécurité de vos serveurs est votre responsabilité.

Exigences

Pour des raisons évidentes, sudo doit être installé si vous souhaitez gérer le fichier sudoers avec ce rôle.

Sur les systèmes RedHat/CentOS, assurez-vous que le dépôt EPEL est installé (vous pouvez inclure le rôle geerlingguy.repo-epel pour l'installer).

Pas d'exigences spéciales pour les systèmes Debian/Ubuntu.

Variables du Rôle

Les variables disponibles sont listées ci-dessous, avec des valeurs par défaut (voir defaults/main.yml) :

security_ssh_port: 22

Le port par lequel vous souhaitez que SSH soit accessible. La valeur par défaut est le port 22, mais si vous gérez un serveur sur Internet ouvert, et qu'aucun pare-feu ne bloque l'accès au port 22, vous constaterez rapidement que des milliers de tentatives de connexion par jour ne sont pas rares. Vous pouvez changer le port pour un port non standard (par exemple 2849) si vous souhaitez éviter ces milliers de tentatives d'intrusion automatisées.

security_ssh_password_authentication: "no"
security_ssh_permit_root_login: "no"
security_ssh_usedns: "no"
security_ssh_permit_empty_password: "no"
security_ssh_challenge_response_auth: "no"
security_ssh_gss_api_authentication: "no"
security_ssh_x11_forwarding: "no"

Paramètres de sécurité pour l'authentification SSH. Il est préférable de laisser ces options réglées sur "no", mais il peut y avoir des cas (surtout lors de la configuration initiale du serveur ou si vous n'avez pas encore mis en place l'authentification par clé) où l'une ou l'autre peut être réglée sur 'yes' sans danger. REMARQUE : Il est très important de mettre des guillemets autour des valeurs 'yes' ou 'no'. Ne pas le faire peut vous verrouiller hors de votre serveur.

security_ssh_allowed_users: []
# - alice
# - bob
# - charlie

Une liste des utilisateurs autorisés à se connecter à l'hôte via SSH. Si aucun utilisateur n'est défini dans la liste, la tâche sera ignorée.

security_ssh_allowed_groups: []
# - admins
# - devs

Une liste des groupes autorisés à se connecter à l'hôte via SSH. Si aucun groupe n'est défini dans la liste, la tâche sera ignorée.

security_sshd_state: started

L'état du démon SSH. En général, cela doit rester started.

security_ssh_restart_handler_state: restarted

L'état du gestionnaire restart ssh. En général, cela doit rester restarted.

security_sudoers_passwordless: []
security_sudoers_passworded: []

Une liste d'utilisateurs qui devraient être ajoutés au fichier sudoers afin de pouvoir exécuter n'importe quelle commande en tant que root (via sudo), soit sans mot de passe, soit en exigeant un mot de passe pour chaque commande, respectivement.

security_autoupdate_enabled: true

Indique si yum-cron (pour les systèmes basés sur RedHat) ou unattended-upgrades (pour les systèmes basés sur Debian) doit être installé/activé. Les redémarrages systèmes ne se feront pas automatiquement dans tous les cas, et les mises à jour automatiques ne sont pas une excuse pour une mauvaise gestion des correctifs et des paquets, mais les mises à jour automatiques peuvent être utiles comme mesure de sécurité supplémentaire.

security_autoupdate_blacklist: []

(Debian/Ubuntu uniquement) Une liste de paquets qui ne devraient pas être mis à jour automatiquement.

security_autoupdate_additional_origins: []
# - "${distro_id}ESM:${distro_codename}-infra-security"
# - "Docker:${distro_codename}"

(Debian/Ubuntu uniquement) Une liste d'origines à référencer.

security_autoupdate_reboot: false

(Debian/Ubuntu uniquement) Indique s'il faut redémarrer si nécessaire lors des mises à jour automatiques.

security_autoupdate_reboot_time: "03:00"

(Debian/Ubuntu uniquement) L'heure à laquelle déclencher un redémarrage, si nécessaire, si security_autoupdate_reboot est réglé sur true. Au format 24h "hh:mm".

security_autoupdate_mail_to: ""
security_autoupdate_mail_on_error: true

(Debian/Ubuntu uniquement) Si security_autoupdate_mail_to est défini avec une valeur non vide, les mises à jour automatiques enverront un e-mail à cette adresse lorsqu'une erreur se produit. Vous pouvez soit définir cela sur un e-mail complet : [email protected], soit sur quelque chose comme root, qui utilisera /etc/aliases pour acheminer le message. Si vous définissez security_autoupdate_mail_on_error sur false, vous recevrez un e-mail après chaque installation de paquet.

security_fail2ban_enabled: true

Indique s'il faut installer/activer fail2ban. Vous ne voudrez peut-être pas utiliser fail2ban si vous utilisez déjà un autre service pour la détection de connexion et d'intrusion (par exemple, ConfigServer).

security_fail2ban_custom_configuration_template: "jail.local.j2"

Le nom du fichier de modèle utilisé pour générer la configuration de fail2ban.

Dépendances

Aucune.

Exemple de Playbook

- hosts: servers
  vars_files:
    - vars/main.yml
  roles:
    - geerlingguy.security

À l'intérieur de vars/main.yml :

security_sudoers_passworded:
  - johndoe
  - deployacct

Licence

MIT (Expat) / BSD

Informations sur l'auteur

Ce rôle a été créé en 2014 par Jeff Geerling, auteur de Ansible for DevOps.